회사에서는 형상관리 툴로 svn에서 git으로 변경된게 그렇게 오래되지는 않았다. git으로 변경되고 나서 사용하는 명령어는 clone, add, commit, push, merge 정도였다. 일을 하면서 코드리뷰를 하지 않으니 pr은 생소했고, fork도 사용해본적도 적었고, 그냥 하는법만 알았기 때문에 이번 기회에 다시 정확하게 정리해 보는게 좋을것 같다.
pull request(pr)에 대해서
Fork
-
다른 사람의 레포(repository)를 나의 레포로 복사하는 것이다.
-
리액트를 fork해보자
-
페이스북 저장소의 리액트 레포를 나의 저장소로 가져왔다.
💡 그럼 fork쓰지 말고 clone쓰면 되지 않음? → 기여 권한이 없을 경우 fork한 다음에 pr을 보내 관리자들이 변경된 부분을 보고 리뷰, 승인으로 원본 프로젝트에 기여를 진행할 수 있다.
Clone
git clone 내 원격 저장소에 fork된 주소- fork를 하면 내 원격 저장소에 fork된 소스가 있기 때문에 이를 clone해서 내 로컬 저장소로 가져온다.
git remote -v- git remote -v 명령어로 원격 저장소의 목록을 확인한다.(-v 옵션은 원격 저장소의 url을 표시한다.)
- fetch와 push는 각각 가져오기와 푸시 동작에 사용되는 url을 보여준다.
근데 Clone을 하면 내 원격 저장소만 보이고, 원본 저장소는 보이지 않는다.
git remote add upstream 원본 저장소의 주소- 꼭 upstream이라고 이름을 지을 필요는 없지만, 통상적으로 upstream으로 많이 사용하는것 같다.
- 원본 저장소도 보이게 됐다!
Checkout
git checkout -b 브랜치이름- 내가 작업할 브랜치를 만든다.
Add, Commit
git add .
git commit -m "커밋 메시지"- 내가 작업한 브랜치에서 작업이 끝난다면 git add, git commit을 통해 로컬 저장소에 변경된 부분을 반영한다.
Push
git push origin 브랜치이름- git push를 통해 내 원격 저장소에 변경 사항을 올린다.
Pull Request
- 이제 pull request를 작성해서 원본 레파지토리 개발자한테 내가 작업한 내용을 코드에 반영해달라고 요청할 수 있다.(코드리뷰 요청)
- base(원본)
- repository : 원본 레포
- base : 원본 레포의 브랜치
- head(fork된 레포 - 내 레포)
- repository : 내 레포
- compare : 내 레포의 브랜치
Merge
- 코드리뷰가 끝나고 merge 전략은 3가지가 있다.
- Merge Commit
- 두 개의 브랜치를 병합할 때 새로운 커밋을 생성하는 것
- 병합된 브랜치의 변경사항을 모두 포함하고, 병합 기록을 보여주기 때문에 병합 과정을 추적할 수 있다.
- 커밋 히스토리가 복잡해질 수 있으며, 로그가 지저분해져서 한눈에 보기 어려울 수 있다.
- (git merge —no-ff랑 똑같은 방식인것 같다.)
- Squash and Merge
- 하나의 브랜치를 다른 브랜치에 병합할 때, 병합되는 브랜치의 모든 커밋을 하나의 커밋으로 합치고 단일 커밋으로 나타나는 경우이다.
- 커밋이 간결해 진다는 장점이 있지만, 개별 커밋 히스토리가 없어져서 세부 사항의 추적이 어려울 수 있다.
- Rebase and Merge
- 기본 브랜치의 가장 최근 커밋 위로 병합하려는 커밋을 적용한 후 병합한다.
- 히스토리가 깔끔하고 직선형으로 유지되지만, rebase상의 충돌이 발생할 수 있으며 해결에 어려움이 있다.
- Merge Commit
