[Github으로 따라하는 버전 관리] Git 협업

Git 잘해보이는 햄찌

Branch

큰 개발 프로젝트를 진행한다 가정해보자. 여러 개발 팀 혹은 팀원으로 나뉘어 진행할 것이다. 예를 들어, 머신러닝 개발 프로젝트를 진행하는 팀에서는 데이터를 전처리하고 저장을 하는 팀, 모델을 개발하는 팀, 모델을 서빙하는 팀이 있을 수 있다. 각 팀 안에서는 버그를 수정하거나 새로운 기능을 개발해야 하는 일이 많을 것이다. 각 팀별로 버전을 관리할 필요성이 있다. 이럴 때, 각 팀에서는 개발 프로젝트의 소스코드를 바탕으로 개발을 해나갸야할 것이다. 이후 개발이 완성되면 프로젝트에 병합을 시켜 새로운 버전을 생성하여 다른 팀원들과 충돌나지 않으면서 프로젝트를 진행할 수 있다.

​

브랜치(branch)는 프로젝트를 바탕으로 독립적으로 개발을 할 수 있는 저장소(작업영역)이다. 저장소를 처음 만들 때, 동시에 만들어지며 프로젝트 version을 관리하는 branch를 master branch라고 한다. 이후 기능 개발 시 master branch를 바탕으로 하거나 혹은 다른 branch를 바탕으로 또 다른 branch를 생성해 독립적으로 개발을 진행할 수 있다.

Head가 가리키는 branch가 버전을 따라간다.

 

Merge into current branch

master branch를 바탕으로 새로운 기능 개발 혹은 버그를 고친다고 할 때 새로운 branch를 만들어 진행한다. 이후 개발을 다 마치고 이를 master branch에 병합하여 새로운 버전을 만들고자 한다. 이 때 우리는 merge into current branch를 활용한다. merge into current branch를 통해 master branch에 해당 기능 branch를 병합한다. 이후 필요하지 않은 branch는 제거(delete)할 수 있다.

---

A가 B를 병합하건, B가 A를 병합하건 간에 병합된 merge commit의 내용은 완전히 같다.

A가 B를 병합하면 A가 새로 병합된 merge commit의 버전을 따라가고,

B가 A를 병합하면 B가 새로 병합된 merge commit의 버전을 따라가게 된다.

​

Co-working

동료들과 함께 같은 저장소(repository)를 바라보고 개발을 진행하고 있는 상황을 한번 재현해보자. 김왼손씨와 이오른씨 같은 저장소(repository)에 작업을 했다고 가정하자. 김왼손씨는 오후에 약속이 있어서 아침 일찍 출근한 뒤 열심히 개발을 진행하고 개발 내용들을 각각 add하여 commit으로 나누어 저장한 후 원격 저장소에 push한 후 퇴근했다. 이오른씨는 느긋하게 하루를 시작하려 오후에 출근해 김왼손씨와 같이 여러 파일을 수정하고 commit한 후 원격 저장소에 push하면, 원격저장소는 오른씨의 push를 "reject" 시킨다. 그 이유는, 왼손씨가 개발한 내용들이 오른씨의 개발 내역에는 포함되어 있지 않기 때문이다. 이대로 push가 진행된다면 자칫 왼손씨가 개발한 부분에 오른씨의 내용이 곂치게 되면서(overwriting) 덮어써져 날아가 버릴 것이 분명하다.

​

오른씨는 앞서 배웠던 "pull" 기능을 통해서 원격 저장소에 새롭게 추가된 개발 내역을 현재 개발하고 있는 지역 저장소로 끌어 올 수 있다. 또한 "pull"은 단계적으로 적용이 가능하다(pull = fetch, 다운로드 + merge, 합치기). fetch를 사용해서 원격 저장소의 "변경 내용"을 다운로드 받고, merge를 사용해서 해당 변경 내용을 현재 지역 저장소로 반영하는 절차를 거치게 된다.

​

Conflict

협업 진행 중에 같은 파일의 같은 줄을 수정했다면, 충돌은 피할 수 없다. 원격 저장소의 내용을 내려 받았을 때, 충돌이 발생한 경우 세 가지 경우 중 하나를 선택하여 다시 commit해서 통합된 버전을 만들면 된다.

​

1. 원격 저장소의 코드를 수용 (남이 만든 코드를 반영, Accept Incoming Change)
2. 지역 저장소의 코드를 수용 (내가 만든 코드를 반영, Accept Current Change)
3. 두 가지를 모두 반영하는 경우 (두 가지를 다 고려하여 수정, Accept Both Changes)

​

Pull request

개발할 준비가 다 돼서 master branch에 질서정연하게 push만 하면 된다. 하지만 개발 내용들이 잘 작동하지 않거나 검토가 필요하여 바로 반영하기가 어려울 때, pull request를 활용하면 된다. Pull request란 직접 master branch에 push하는 것이 아닌 master branch로부터 새로운 branch를 만든 다음 개발 내역을 해당 브랜치에 적용하고, 그 내용이 master에 반영되기 전 검토를 해달라는 요청을 보내 팀원들과 리뷰를 마친 후 반영하는 방식이다.

​

코드를 작업하면서 생겼던 conflict들이 pull request에서도 발생할 수 있다. 바로 같은 파일을 수정한 2개의 branch가 순서대로 merge되는 상황이 그렇다. 앞에서 봤던 왼손씨와 오른씨의 개발 과정에서 예시를 들자면, 왼손씨가 a.py를 수정하고 "left"라는 branch에 push한 후 PR을 만들었다. 하지만 오른씨도 a.py를 수정하여 "right"라는 branch를 만들어 PR을 주었다. 이 때 먼저 왼손씨의 코드를 리뷰하고 master branch에 "left" branch가 merge되는 순간, "right" branch에서 conflict가 발생하게 된다. 충돌이 발생한 경우, 최신화된 master branch를 "right" branch에 pull한 다음 다시 push하면 해결할 수 있다.