pull request
앞서, Branch를 파서 main으로 pull request를 날린다는 발언을 했다. 이게 무슨 뜻일까?
간단하다. 말 그대로, main 브랜치에 merge하고 싶다는 뜻이다. 아니 사실 말 그대로는 아니지. 왜 이름이 merge request가 아닌가? 이에 대한 공식적인 설명이 있는지는 모르겠으나, 필자는 내 브랜치 pull 땡겨서 되는지 봐주세요라는 의미로 해석했다.
merge conflict
앞서, Branch A 와 B가 둘 다 분기 이후에 똑같은 파일의 똑같은 줄을 서로 다르게 수정했을 때, 누구의 손을 들어 줘야 하는가에 대한 이야기를 했다. 이 역시 답은 간단하다.
git이 자동으로 merge conflict를 터트려 준다. 난 못하겠으니 merge 하고 싶으면 알아서 해결해오라는 소리다. 참으로 불친절해 보이지만 그렇지 않다. 당연히 프로그래머가 하는 게 맞지.. 사실 상당히 친절하다. merge conflict를 해결하라고 말하며, 코드를 다음과 같이 바꿔 준다.
<<<<<< A
어쩌구 저쩌구 A가 바꾼 내용
------
저쩌구 어쩌구 B가 바꾼 내용
>>>>>> B이 부분이 이렇게 코드가 다르게 수정되었으니 알아서 해결하세요 ㅎㅎ 하는 것이다. 그러면 프로그래머는 다른 위치를 딱 보고, conflict를 해결한 다음 git이 추가해 준 친절한 친구들을 지우면, 이제서야 merge할 수 있게 된다.
협업 방식
그래서 이 브랜치들과 pull request들을 어떻게 잘 사용할 수 있느냐? 사실 혼자 할 거면 딱히 필요 없다. 이는 최소 2인 이상이 같은 repository 위에서 협업할 때 빛을 발하며, 이럴 때 쓰이는 일반적인 업무 진행 방식이 있다.
git flow
git에 최적화된 방식이다. 아주 큰 프로젝트에서 주로 사용하는데, 버그 픽스를 이리 날리고 저리 날리고 브랜치들끼리 이리 갔다 저리 갔다 하는 방식인데.. 너무 복잡해서 시간이 날 때 추가로 설명할 테니 우선은 구글링하길 바란다.
github flow
github를 사용하는 사람들이 많은데, 사실 git flow는 아주 복잡하지만 드럽게 엄밀하기 때문에 아주 큰 - 코드 리뷰에만 몇 주가 걸리는 - 프로젝트에 적합하다. 그 정도가 아니라, 적당한 수준의, 작은 규모의 그룹에서 사용하는 코드라면 github flow가 더 좋을 수 있다.
- main 브랜치는 아주 고귀한 존재로, 절대 여기에 직접 어떠한 변화를 가할 수 없다. 모든 변화는 merge를 통해 이루어진다.
- 변화를 가할 때마다, Branch를 파고, 변화를 위해 코드를 수정하고, 잘 되는 거 같다면 main을 향해 pull request를 쏜다. 그러면 팀원이 pull을 땡겨서 잘 되는지 확인하고, 잘 된다면 main으로 merge한다.
- 일반적으로 변화를 가하는 단위는 그리 크지 않다. (상당히 작아야 한다.) 가령 '버튼 위치 조정', '작은 버그 1 수정' 등등. 큰 변화를 pull request를 통해 가한다면, 협업 과정에서 merge conflict 폭탄을 맞을 수 있다.
- 일반적으로 main은 배포를 위한 브랜치라고 소개되나, 가끔, 분명 문제가 없었는데 merge해 보니 문제가 생겨 있을 수도 있다. 이런 상황을 위해 보험용으로 코드 배포를 위한 브랜치를 따로 파는 경우도 많다.
그러니, github flow의 경우 main이 아닌 branch에서 branch가 분기되어 나올 일이 그리 많진 않다. git flow는 분명 아주 좋은 협업 방식이고, 아주 엄밀한 방식이지만, 빛을 발하는 상황이 그리 많지는 않기 때문에 일반적인 수준의 작은 프로젝트의 경우에는 github flow를 사용하는 게 훨씬 좋을 수 있다.
