레이블이 git인 게시물을 표시합니다. 모든 게시물 표시
레이블이 git인 게시물을 표시합니다. 모든 게시물 표시

2020년 8월 3일 월요일

.gitignore 사용하기

.gitignore 사용하기

  • 민감한 정보나, 업데이트하고 싶지 않은 정보는 gitignore를 통해 관리할 수 있다.

    # class 확장자
    *.class
    
    # build 하위 파일
    build/
    
    # 해당 파일 제외
    !gradle/wrapper/gradle-wrapper.jar
    
  • 내가 해놓은 .gitignore

    target/
    !.mvn/wrapper/maven-wrapper.jar
    
    ### GRADLE ###
    .gradle
    /build/
    !gradle/wrapper/gradle-wrapper.jar
    /out
    
    ### STS ###
    .apt_generated
    .classpath
    .factorypath
    .project
    .settings
    .springBeans
    
    ### IntelliJ IDEA ###
    .idea
    *.iws
    *.iml
    *.ipr
    
    ### NetBeans ###
    nbproject/private/
    build/
    nbbuild/
    dist/
    nbdist/
    .nb-gradle/
    /bin/
    
    ### querydsl
    generated
    
    
    
  • 여기서 .gitignore 예시도 제공해준다.

  • 개발 중간에 .gitignore에 추가하였지만, commit 목록에는 표시될 때 !!

    • cached 옵션을 통해 로컬에는 파일을 남기고 원격저장소에 파일을 지울 수 있다. (이미 파일이 원격저장소에 있는 경우 ignore가 안먹히는 것 같다!!)
    • git rm --cached 제외할파일명

2019년 1월 2일 수요일

그림과 실습으로 git branch 연습하기

개발자 커뮤니티 페이지를 돌아다니다가 git이 어렵다면 branch가 어려운 일 겁니다. 라는 제목을 보았다.
이 글에서 git branch 관련해서 연습을 하는 사이트를 추천해주셨는데

아주 직관적이고 그림으로 움직이면서 설명을 해줘서 브랜치에 대해 이해하기 쉽게 만들어져있었다.
마침 매번 사용할 때마다 찾아보고, 이클립스 안에서만 간단하게 commit, push만 하는 나에게 유익하다고 생각되었다.
commit, branch, checkout, cherry-pick, reset, revert, rebase, merge
의 명령어를 사용할 수 있고, 다음과 같은 단계별로 진행된다.

각 단계마다 명령어횟수를 측정하는데 모범답안 횟수에 도달하거나 하지 못할 때 메시지를 보여준다.

하단부에서 답안을 확인할 수 있으며, 초기화(Reset)이나 되돌리기(Undo)가 가능하다.

단계별로 되어있어 복습하기 쉽고, 답안까지 친절하게 제공해주고 있어 학습하기 좋은 것 같다. 



나도 언젠가 누군가에게 쉽고 간단하게 설명해줄 수 있는 날이 올까....?

2018년 9월 9일 일요일

git 작성자 수정하기

rebase란?

공부가 필요해.....
http://mafams.tistory.com/66
https://backlog.com/git-tutorial/kr/stepup/stepup2_8.html
https://elegantcoder.com/git-merge-or-rebase/
http://cyberx.tistory.com/96




git에 자꾸 다른 이름으로 커밋이 되어 작성자를 바꾸려고 하는데

rebase를 통해 가능한 것같다.


git저장소에

git rebase -i -p   [커밋번호]

>[커밋번호] 이 후의 커밋들이 rebase의 대상이 된다.


vi창이 보이는데 a를 눌러 바꾸고싶은 커밋을 pick 을 edit으로 교체 후 esc  > :wq

나의 경우에는 작성자를 바꾸려고했으니
 git commit --amend --author="cotgyu <이메일 주소>"

를 입력하면  해당 커밋 내용 같은게 보인다.. :wq 로 나와서
 git rebase --continue
를 입력하면 다음 수정할 커밋이 나온다.

이 과정을 마지막 커밋까지 반복하면
Successfully rebased and updated ~~ 가 나온다.

이제 pull 후 push하면 수정한 것들이 새롭게 커밋된다..


(그냥 새로운 작성자의 같은 내용의 기록이 새롭게 커밋되는 형태로 되었다.... 기존의 기록을 수정은 안되는건가.. 좀 더 공부할 것)

참조

2018년 8월 19일 일요일

Eclipse cannot open git-upload-pack 오류: 인증·인증서·프록시 확인

cannot open git-upload-pack만으로 원인을 단정할 수 없습니다. Eclipse의 Error Log에서 함께 나온 메시지를 확인한 뒤 저장소 주소, 인증, 인증서, 프록시 순서로 범위를 좁혀 보세요.

2026년 10월 16일 수정: 이 글의 예전 내용은 http.sslVerify=false 설정만 안내했습니다. 인증서 검증을 끄는 방법을 일반 해결책으로 제시한 부분을 바로잡았습니다.

1. 상세 오류부터 확인하기

Eclipse의 Error Log 보기에서 실패한 시각의 예외와 하위 원인을 확인합니다. 사용 중인 Eclipse·EGit·Java 버전, HTTPS인지 SSH인지도 함께 기록하세요. 오류 로그를 공유할 때 토큰·비밀번호·내부 주소는 가립니다.

  • 401 또는 인증 실패: 계정과 인증 수단을 확인합니다.
  • 403 또는 저장소 접근 거부: 계정의 접근 권한과 조직 정책을 확인합니다.
  • 404 또는 저장소를 찾을 수 없음: 복제 URL과 접근 권한을 함께 확인합니다. 비공개 저장소는 권한 문제도 의심해야 합니다.
  • 인증서·PKIX 관련 메시지: 서버 인증서와 Eclipse가 사용하는 Java 환경의 신뢰 설정을 확인합니다.
  • 타임아웃·호스트 조회 실패: 네트워크와 프록시 설정을 확인합니다.

이 목록은 진단 순서이며 각 메시지의 원인이 하나로 정해진다는 뜻은 아닙니다.

2. URL과 인증 확인하기

저장소 서비스에서 복제 URL을 다시 확인합니다. GitHub HTTPS 인증에서 토큰을 요구하는 경우 일반 계정 비밀번호 대신 적절한 권한의 토큰을 사용합니다. 토큰을 URL에 직접 넣지 말고 인증 입력란이나 지원되는 자격 증명 저장소를 사용하세요.

명령줄 Git이 설치되어 있다면 같은 저장소 폴더에서 아래 읽기 전용 조회로 비교할 수 있습니다. 출력에는 사설 저장소 주소가 포함될 수 있습니다.

git remote -v
git ls-remote origin

명령줄에서는 성공하고 Eclipse에서 실패해도 서버가 완전히 정상이라고 단정할 수는 없습니다. 두 도구가 사용하는 인증 저장소·프록시·인증서 환경을 비교하는 단서로 사용하세요.

3. 인증서 검증을 끄기보다 신뢰 경로 확인하기

Git의 http.sslVerify는 HTTPS 인증서 검증 여부이며 기본값은 true입니다. 인증서 오류라면 서버의 만료·호스트 이름·체인 설정을 확인하고, 사내 인증서를 사용하는 환경에서는 관리자가 제공한 신뢰 설정을 따르세요. EGit의 HTTP 구현과 Java 실행 환경도 확인 대상입니다.

이전 글을 따라 검증을 껐다면 해당 설정의 위치와 적용 범위를 확인해 해제한 설정을 되돌리세요. 인증 문제가 해결되는지 확인하지 않고 전역 설정을 반복 변경하지 마세요.

4. 프록시와 재확인

회사 네트워크에서만 실패한다면 Eclipse의 Preferences → General → Network Connections를 확인합니다. EGit은 HTTP 연결 구현에 따라 프록시 동작이 다를 수 있습니다. 설정을 하나씩 바꾸며 동일한 조회로 결과를 비교하세요.

이 글은 공식 문서에 근거한 진단 안내입니다. 특정 Eclipse 설치에서 같은 장애를 재현해 해결했다고 주장하는 글은 아닙니다.

공식 참고 문서

2018년 2월 8일 목요일

git branch 관련

브랜치란?
독립적인 여러 작업을 진행하기 위한 개념

여러 명이서 동시에 작업을 할 때에 다른 사람의 작업에 영향을 주거나 받지 않도록, 먼저 메인 브랜치에서 자신의 작업 전용 브랜치를 만듭니다. 그리고 각자 작업을 진행한 후, 작업이 끝난 사람은 메인 브랜치에 자신의 브랜치의 변경 사항을 적용합니다. 이렇게 함으로써 다른 사람의 작업에 영향을 받지 않고 독립적으로 특정 작업을 수행하고 그 결과를 하나로 모아 나가게 됩니다. 이러한 방식으로 작업할 경우 '작업 단위', 즉 브랜치로 그 작업의 기록을 중간 중간에 남기게 되므로 문제가 발생했을 경우 원인이 되는 작업을 찾아내거나 그에 따른 대책을 세우기 쉬워집니다.


>>결국 개발자들이 서로에 작업에 영향을 주지 않으면 독립된 공간에서 다양한 작업을 진행할 수 있게 도와주는 것 같음


master - 최종 배포용
develop - 개발용
feature - develop에서 새로운 기능을 만들때 쓰는 브랜치?

*************************************
출처
https://backlog.com/git-tutorial/kr/stepup/stepup1_1.html


브랜치 설명
https://mylko72.gitbooks.io/git/content/branch/branch_type.html




**********************************************
쓰는 흐름은
develop에서  feature를 따서 작은 기능을 개발 -> 작은 기능이 개발완료되면 develop으로 merge -> 반복 -> 모든 기능들이 완료되어 develop으로 합쳐지고, 정상적으로 동작하면 master에 올려서 최종배포

인듯 하다.

2018년 1월 21일 일요일

git에서 공유받은 maven dependencies / missing artifact 문제

http://parkpurong.tistory.com/133

깃으로 받은 프로젝트의 maven dependencies가 제대로 안받아지는것같다 ㅠ
위 블로그 방법으로해서 Missing artifact  는 없앴는데 계속안되서 그냥 내 로컬프로젝트 중 하나 pom.xml에서 버전 바꿔서 새버전 다시 받고 했음...

2017년 9월 29일 금요일

git 커밋 되돌리기

git에 커밋 후 커밋내용을 아예 지우고 싶을때 사용.....



프로젝트있는 폴더에서 명령프롬프트을 열어서 

git reset HEAD~1(숫자는 되돌리는 커밋횟수??) 

git push origin + master 




잘못하면 커밋 다 날라가니 쓰기전에 한번 더 찾아보고 사용할 것!!
(git무서웡 ㅠ) 

2017년 9월 12일 화요일

[rejected] master -> master (non-fast-forward)

git을쓰면서 이클립스에서 커밋앤 푸쉬를 하는데 저런 문구가 되면서 git저장소에 커밋이 되지 않는 현상이 발생하였다.

프로젝트 팀 메뉴에서 히스토리를 보니 아직 기록이 남아있는 것같아 'push branch master' 로 했더니 저번 내용까지 갱신되었다. 


git 어렵다 ㅠㅠ  소스날라갈까봐 무서움 ㅠㅠㅠ
공부 필요한듯..



--추가--
9/17
readme 파일을 git페이지에서 업데이트하고 커밋할때 발생하는듯.
내생각엔.. 변경된 내용이 이클립스에 적용이 안되서 그런듯??