Git으로 프로젝트를 진행해본 적은 여러 번 있었지만 그때는 동기들끼리 모여서 이것저것 부딪혀 가면서 했지만 요즘은 프로젝트 크기도 좀 커지고, 물리적으로 가까이 있는 팀원도 없는 상황에서 이것저것 건드리다가 잘못되면 안되니 협업하면서 알게 된 걸 정리해 보려고 한다. 또, Windows를 사용할 때에는 SourceTree나 GitKraken과 같은 GUI를 주로 이용했다면, 지금은 Mac을 사용하면서 그냥 터미널 상에서 커맨드를 치면서 이용하고 있기 때문에 적응하기 위해서 좀 정리를 해야겠구나 느꼈다.
떠올랐던 의문점
Git에서 original repo를 fork해서 작업한 후 변경 사항을 commit하고 push 후 pull request를 넣고, 각자가 pull request한 것들이 original repo의 master branch에 모두 merge가 됐다면, 내 로컬 저장소의 파일도 이 original repo와 동기화한 후에 작업할 필요가 있다.
그렇다면 그냥 git pull upstream master를 하면 될까? 물론 안될 건 없겠지만...
original repo를 내 Git에 등록하기
$ git remote add upstream <UPSTREAM URL>
$ git remote -v
가장 기초부터 시작하자. 일단 original repo를 내 Git에 인식시켜 줘야 할 것이다. forked repo의 입장에서 original repo는 upstream이라고 한단다. 그러므로 upstream이라는 이름으로 original repo의 URL을 등록해 주자. 그리고 git remote -v로 해당 repo가 잘 등록되었는지 확인하자.
그리고 어찌저찌 작업을 완료하고 각자의 commit, push, pull request부터 merge까지 모두 완료되었다고 하자.
upstream의 변경 사항을 forked repo에 반영하기
그러면 upstream은 모두의 변경 사항을 담고 있을텐데, 우리는 그대로 뒤처진 채로 우리 repo에서만 작업을 할 수는 없는 노릇이다. 그러므로 upstream의 변경 사항을 forked repo에 반영해야 한다.
$ git checkout master
$ git fetch upstream master
$ git rebase upstream/master
일단 나의 master 브랜치로 checkout하자. 이후, upstream에 적용된 commit들을 불러오기 위해 fetch를 실행해 준다. 이후, rebase 명령어로 upstream/master 브랜치의 변경 사항을 나의 master 브랜치에 적용시킨다. merge와 rebase는 모두 두 브랜치를 합친다는 공통점이 있지만, merge는 두 브랜치의 공통된 부모 커밋에 양쪽의 변경 사항들을 적용시키는 것인 반면 rebase는 한 브랜치의 변경사항을 다른 한 브랜치에 적용시킨다는 차이가 있다(고 한다).
이렇게 되면 모든 것이 끝났다. 이제는 upstream에 push된 모든 commit들을 불러왔으므로, 이 환경에서 다시 작업을 시작하면 된다.
2022. 2. 22. 추가
이렇게 fetch 후 rebase를 실행하면 upstream에 commit이 추가되었을 때 내 repo의 commit과 차이가 나는 경우가 발생하게 된다. rebase(merge) 시 conflict가 발생하지 않았다면 딱히 문제가 없으므로, push해 주면 된다.
협업할 때 쓰는 Git에서 뭔가 모르는 게 생겨서 해결해야 할 게 필요할 때는 혹여나 뭔가 건드렸을 때 되돌릴 수 없는 사고가 일어나게 되는 것이 무서워서 구글링을 생활화하면서도 반신반의하면서 결국은 팀에 다시 한 번 물어 보고 승인이 떨어지면 하게 된다. 혹시 이 글을 보게 되는 사람들도 구글링으로 해결하는 것도 좋지만 이런 것들은 혹시 모르니 팀원들에게 한번 물어보기 바랍니다.
'공부 > Git' 카테고리의 다른 글
GitHub을 이용한 React 프로젝트 배포하기 (0) | 2022.11.24 |
---|---|
하나의 컴퓨터로 여러 Git 계정 쓰기 (GitHub, GitLab 등) (0) | 2022.03.22 |