✅ 브랜치 워크플로
🔹Long-Running 브랜치
Git은 꼼꼼하게 3-way 병합을 사용하기 때문에 장기간에 걸쳐 한 브랜치를 다른 브랜치와 여러 번 병합하는 것이 비교적 간편합니다. 이로 인해 개발 과정에서 필요에 따라 브랜치를 생성하고 계속해서 사용할 수 있습니다. 또한 정기적으로 브랜치를 다른 브랜치로 병합합니다.
이러한 접근 방식을 따르는 Git 개발자들 사이에서는 특정 용도에 맞는 브랜치를 유지하고, 안정 버전의 코드만 master 브랜치에 병합하여 보관하는 워크플로우가 많이 선호됩니다. 개발을 진행하고 안정화하는 브랜치는 develop이나 next와 같은 이름으로 추가로 생성하여 사용합니다. 이러한 브랜치는 언젠가 안정 상태에 도달할 것입니다. 하지만 항상 안정 상태를 유지해야 하는 것은 아닙니다. 테스트를 거쳐 안정적이라고 판단되면 해당 브랜치를 master 브랜치로 병합합니다. 이와 마찬가지로 토픽 브랜치(앞서 언급한 iss53와 같은 단기적인 작업을 위한 브랜치)에도 동일한 워크플로우를 적용할 수 있습니다. 해당 토픽을 처리하고 테스트하여 버그가 없고 안정적이라고 판단되면 그때 병합합니다.
사실 우리가 얘기하는 것은 실제로 커밋을 가리키는 포인터에 관한 이야기입니다. 커밋 포인터를 만들고 수정하고 분리하며 병합하는 방식에 대한 이야기입니다. 개발 브랜치는 적극적으로 히스토리를 생성하고 전진하며, 안정 브랜치는 이미 생성된 히스토리를 따라가며 전진합니다.
🔹토픽 브랜치
토픽 브랜치는 프로젝트의 규모와 상관없이 유용합니다. 토픽 브랜치는 특정 주제나 작업을 위해 만들어지는 단기적인 브랜치입니다. 다른 버전 관리 시스템에서는 이러한 브랜치 개념을 찾아보기 힘들 수 있습니다. 다른 버전 관리 도구에서는 브랜치를 만드는 것에 많은 비용이 들 수 있습니다. 그러나 Git에서는 브랜치를 만들고 병합하고 삭제하는 것이 매우 일상적인 작업입니다.
이전에 사용한 iss53 브랜치나 hotfix 브랜치는 토픽 브랜치의 예시입니다. 우리는 새로운 브랜치를 만들고 일부 커밋을 진행한 후 master 브랜치에 다시 병합하고 브랜치를 삭제했습니다. 주제별로 브랜치를 만들고 각각 독립적으로 작업하기 때문에 컨텍스트 사이를 쉽게 전환할 수 있습니다. 작업을 묶음 단위로 나누어 진행하면 내용을 검토하고 테스트하기도 더 편리합니다. 각 작업은 몇 시간이건 몇 달이건 유지한 후 master 브랜치에 병합할 시점이 되면 순서에 구애받지 않고 병합하면 됩니다.
master 브랜치에서 어떤 작업을 수행한다고 가정해봅시다. 특정 이슈를 처리하기 위해 iss91 브랜치를 생성하고 해당 작업을 진행합니다. 같은 이슈를 다른 방법으로 해결해보고 싶을 때도 있습니다. 그래서 iss91v2 브랜치를 생성하고 다른 방법을 시도합니다. 확신이 서지 않는 아이디어를 적용해보기 위해 다시 master 브랜치로 돌아가서 dumbidea 브랜치를 추가로 생성합니다. 지금까지 언급한 커밋 히스토리는 아래 그림과 같습니다.
- 토픽 브랜치
이슈를 처리했던 방법 중 두 번째 방법인 iss91v2 브랜치가 괜찮아서 적용하기로 결정했습니다. 그리고 아이디어를 확신할 수 없었던 dumbidea 브랜치를 같이 일하는 다른 개발자에게 보여줬더니 썩 괜찮다는 반응을 얻었습니다. iss91 브랜치는 (C5, C6 커밋도 함께) 버리고 다른 두 브랜치를 Merge 하면 아래 그림과 같이 됩니다.
- dumbidea 와 iss91v2 브랜치를 Merge 하고 난 후의 모습
🏷️이미지 출처 및 참고한 사이트
Uploaded by N2T