Pro git - 3.4

Pro git - 브랜치 워크플로

• 브랜치를 만들고 Merge 하는 것을 어디에 써먹을지 배워보자.

1. Long-Running 브랜치

• Git은 꼼꼼하게 3-way Merge를 사용하기 때문에 장기간에 걸쳐서 한 브랜치를 다른 브랜치와 여러 번 Merge 하는 것이 쉬운 편이다.
• 그래서 개발 과정에서 필요한 용도에 따라 브랜치를 만들어 두고 계속 사용할 수 있다.
• 그리고 정기적으로 브랜치를 다른 브랜치로 Merge 한다.
• 이런 접근법에 따라서 Git 개발자가 많이 선호하는 워크플로가 하나 있다.
• 배포했거나 배포할 코드만 master 브랜치에 Merge 해서 안정 버전의 코드만 master 브랜치에 둔다.
• 개발을 진행하고 안정화하는 브랜치는 develop 이나 next 라는 이름으로 추가로 만들어 사용한다.
• 이 브랜치는 언젠가 안정 상태가 되겠지만, 항상 안정 상태를 유지해야 하는 것이 아니다.
• 테스트를 거쳐서 안정적이라고 판단되면 master 브랜치에 Merge 한다.
• 토픽 브랜치(iss53 브랜치 같은)에도 똑같이 테스트해서 안정적이면 그때 Merge 한다.
• 개발 브랜치는 공격적으로 히스토리를 만들어 나아가고 안정 브랜치는 이미 만든 히스토리를 뒤따르며 나아간다.

• 코드를 여러 단계로 나누어 안정성을 높여가며 운영할 수 있다.

• 프로젝트 규모가 크면 proposed 혹은 pu (proposed updates)라는 이름의 브랜치를 만들고 next 나 master 브랜치에 아직 Merge 할 준비가 되지 않은 것을 일단 Merge 시킨다.

• 중요한 개념은 브랜치를 이용해 여러 단계에 걸쳐서 안정화해 나아가면서 충분히 안정화가 됐을 때 안정 브랜치로 Merge 한다는 점이다.

• 다시 말해서 Long-Running의 브랜치가 여러 개일 필요는 없지만 정말 유용하다는 점이다.

2. 토픽 브랜치

• 토픽 브랜치는 어떤 한 가지 주제나 작업을 위해 만든 짧은 호흡의 브랜치다.
• 앞서 사용한 iss53 이나 hotfix 브랜치가 토픽 브랜치다.
• 보통 주제별로 브랜치를 만들고 각각은 독립돼 있기 때문에 매우 쉽게 컨텍스트 사이를 옮겨 다닐 수 있다.
• 묶음별로 나눠서 일하면 내용별로 검토하기에도, 테스트하기에도 더 편하다.
• 각 작업을 하루든 한 달이든 유지하다가 master 브랜치에 Merge 할 시점이 되면 순서에 관계없이 그때 Merge 하면 된다.

2.1 예제

• master 브랜치를 checkout 한 상태에서 어떤 작업을 한다고 해보자.
• 한 이슈를 처리하기 위해서 iss91 브랜치를 만들고 해당 작업을 한다.
• 같은 이슈를 다른 방법으로 해결해보고 싶을 때도 있다.
• iss91v2 브랜치를 만들고 다른 방법을 시도해 본다.
• 확신할 수 없는 아이디어를 적용해보기 위해 다시 master 브랜치로 되돌아가서 dumbidea 브랜치를 하나 더 만든다.
• 아래는 위에 히스토리를 그림으로 표현한 것이다.

• 이때, 이슈를 처리했던 방법 중 두 번째 방법인 iss91v2 브랜치가 괜찮아서 적용하기로 결정했다.
• dumbidea 브랜치도 적용하기로 했다.
• iss91 브랜치는 버리고 다른 두 브랜치를 Merge 하면 아래 그림과 같이 된다.

• 지금까지 한 작업은 전부 로컬에서만 처리한다는 것을 꼭 기억하자.
• 로컬 저장소에서만 브랜치를 만들고 Merge 했으며 서버와 통신을 주고받는 일은 없었다.