안녕하세요! 오늘은 저희 팀에서 브랜치 정책을 어떻게 수립했는지에 대해 이야기해보려고 합니다. 최근 SVN에서 GitHub으로 전환하면서 형상 관리에 대한 고민이 많았고, 고객사 사이트 소스 관리를 어떻게 해야 할지 많은 생각을 했어요.
특히 제가 대부분의 운영을 맡고 있었기 때문에, 형상 관리의 중요성을 깊이 느끼고 있습니다. 모든 개발 기록을 잘 남겨야 다음에 동일한 기능이 필요할 때 쉽게 활용할 수 있기 때문입니다!
GitHub을 활용한 브랜치 관리
저희 팀은 GitHub에서 main 브랜치와 develop 브랜치를 유지하기로 결정했습니다. 그러나 제품 소스와 고객사 사이트 소스를 따로 관리하다 보니 상황이 복잡해졌습니다.
- 제품 소스
- A 고객 사이트 소스
- B 고객 사이트 소스
- C 고객 사이트 소스
…
릴리즈 일정이 아직 멀었고, 고객사의 추가 개발 작업을 진행하고 있었기 때문에 고객사 사이트 소스에 대한 형상 관리 방안을 고민해보았습니다.
고객사 사이트 소스 - v1.0
이전에는 SVN을 사용하여 브랜치를 따로 만들 수 없었는데, GitHub에서는 브랜치를 자유롭게 생성할 수 있어 더 유연한 관리가 가능해졌습니다. 그래서 main과 develop 브랜치를 설정한 후, 고객의 추가 개발 사항을 위한 feature 브랜치를 생성했습니다.
- main: 운영에 반영된 최신 소스 브랜치
- develop: 개발이 완료되고 리뷰까지 끝난 후 운영에 반영할 준비가 된 브랜치
- feature 브랜치: 추가 개발 사항을 작업하기 위한 브랜치로, Jira 번호와 작업 이름을 붙여서 생성했습니다.
ex)[TASK-1234]-TASK설명-추가개발 - epic 브랜치: 고객사에서 여러 요구사항이 있을 경우, 에픽 단위로 태스크를 만들어 에픽 브랜치를 생성하고 그 하위에 여러 feature 브랜치를 나눔
문제점 발생!
그런데 몇 가지 문제점이 발생했습니다…
(commit들을 자세히 남기지 못하는 점 죄송합니다ㅠㅠ)
문제점 1. develop에서 feature 브랜치를 생성할 때, feature → develop → main으로 PR을 두 번 올려야 했습니다. 반복되는 이 작업이 너무 번거로웠어요.
문제점 2. develop 브랜치가 계속 남아 있게 되어, 다음 PR을 생성할 때 이전 commit들이 같이 껴들어가게 되었습니다.
문제점 3. epic → feature 브랜치를 생성했을 때, 여러 개발 사항이 epic 브랜치로 머지되면 개별 feature 브랜치에 대한 개별적인 이력을 파악하기 어려웠습니다. 다른 고객사에서도 동일한 추가 개발 요청이 많았기 때문에, 개발 내역을 잘 기록해두는 것이 중요했습니다.
고객사 사이트 소스 - v2.0
이러한 문제를 해결하기 위해 브랜치 정책을 변경했습니다.
브랜치 전략을 여러개 찾아봤는데, 고객사 사이트 소스에 적합한 브랜치 전략은 GitHub Flow라고 생각했어요.
참고 : [GIT] 📈 깃 브랜치 전략 정리 - Github Flow / Git Flow
develop 브랜치를 없애고, main → feature 브랜치만 생성
- 이를 통해 불필요한 PR을 한 번 더 하지 않아도 되었습니다.
개발이 완료된 후, feature → main으로 PR을 생성하고, 리뷰가 완료되면 feature 브랜치를 삭제
- 이렇게 하면 main 브랜치만 남아 깔끔하게 정리할 수 있고, 모든 개발 이력을 관리할 수 있게 됩니다.
- 다른 고객사에서도 동일한 기능을 원할 경우 cherry-pick을 통해 쉽게 패치할 수 있습니다.
PR 설명과 commit message를 잘 남기도록 강조했습니다.
- Jira Task 번호를 commit message에 남겨 이력을 쉽게 확인할 수 있도록 했습니다.
- PR 설명을 자세히 기재하여 PR만 봐도 어떤 기능인지, 어떤 의도로 개발했는지 알 수 있도록 했습니다.
이렇게 브랜치 정책을 변경하게 된 후 main브랜치에는 commit 이력이 많이 남게 되었는데요. 이 방법이 정답은 아니라고 생각합니다. 저는 여러 사이트를 운영하는 입장에서는 이력이 가장 중요하다고 생각하기 때문에 이러한 방법으로 브랜치 정책을 변경하게 되었고 현재 문제 없이 잘 관리하고 있어요!!
Jira에 설명을 적는 것도 중요하지만, 형상 관리에서 commit 내용이 어떤 개발이었고, 어디를 참조하면 되는지를 명확히 하는 것이 필요하다고 생각해요. 이 이력을 참고할 다른 개발자들이 있을테니까요!!
다음 글에서는 제품 소스 형상 관리에 대해 이야기 해 보겠습니다. 감사합니다~~!
