- git과 관련된 협업을 어떻게 해야하는지 따로 공부하는 과정에서 알게 된 점 몇가지를 여기에 정리했다.
git remote
-
처음 git을 하면서 가장 많이 써본 명령어는... github에서 남의 repository를 fork 후
git clone이었다. -
이때
git clone은 단순히 해당 repository를 로컬에 집어넣을 뿐만 아니라 github상에 있는 원격 repository와의 연결도 설정을 해 준다. -
게다가 굳이 저 원격 repository뿐만 아니라 다른 원격 repository와도 연결이 가능하며 이를 가능하게 해주는게
git remote명령어다. -
이 '원격' repository는 본인 동작 머신에 있는것 외의 모든 관련 repository를 말하는 것이기에 다른 사람의 로컬 repository일 수도 있다.
-
이를 통해 여러 협업자들의 repository를
git remote를 통해 연결해가지고 협업을 하는 것이 원할하게 이루어질 수 있다. 실제로 해본적은 없지만, 딱 보니 그럴만하다. 가장 큰 이유는 타 협업자의 작업물을 쉽게 가져올 수 있기 때문이다.
git commit vs git push
-
commit은 로컬상에 자신의 발자취를 하나 남기는 것이고,push는 특정 remote repository의 branch에 그 발자취들을 반영하는 것이다. -
commit은 원격 연결된 repository 상태에 상관없이 맘대로 가능하나 push는 본인이 작업하는 원격 연결된 repository의 branch가 본인이 받은 상태 이후로 변동이 없었어야 한다. 만일 해당 branch가 업데이트가 있었을 경우 그걸fetch하고merge를 시도해야 한다. 아니면 pull로 한번에 해결을 시도하거나.
fork 후의 pull request vs branch의 pull request vs git push
-
fork를 하면 해당 repository의 복사본 및 관련 작업 히스토리가 전부 복제가 된다. 여기서 본인이 개인적으로 작업이 가능하다.
-
이후 이것을 원본 repository의 default branch에다가 반영을 하고 싶은 경우에 하는 것이 pull request다. 이때 원본 repository가 기존과 변동이 있을 수 있기 때문에 fetch를 하는 것이 좋다. 만일 본인이 수정한 파일들에서 변동이 있었을 경우에는 pull request 후에 이를 해결하는 것을 시도해봐야 한다.
-
pull request가 이루어지면 원본 repository에서 작업 중인 다른 협업자들 및 관리자들이 검토 후에 이를 반영할 것이다.
-
branch의 pull request도 fork 후의 pull request랑 비슷하다만 동일 repository의 타 branch를 default branch에다가 merging하는 것을 요청하는 것이다. 역시나 fetch를 먼저 하는 것이 좋고, 본인이 수정한 파일들이 다른 변동이 있었을 경우에 pull request 후에 이를 해결하는 것을 시도해야 한다.
-
반면에
git push의 경우에는 특정 repository의 branch에다가 바로 본인의 편집물을 반영하는 것이다. 이 경우 해당 branch의 최신 상태에서 본인이 작업을 했어야 하며, 그렇지 않을 경우 먼저fetch+merge혹은 pull을 꼭 먼저 하고 다시 시도해야 한다.
git fetch vs git merge vs git pull
-
앞의 내용을 통해 어느정도 알 수 있는데, fetch는 원격 repository의 특정 branch의 내용물을 가져오고, merge는 이렇게 가져온 원격 repository의 특정 branch의 내용물을 현재 작업중인 branch와의 융합을 시도하는 것이다.
-
git pull은 fetch와 merge 작업을 둘 다 동시에 해준다.
참고
