git flow를 알게된 이후에 브랜칭 전략은 면접을 위해서 이기도 하지만 실무에서 반드시 알아야 하는 부분이기 때문에, 자연스럽게 github flow에 대해 알아보게 되었다.
Github Flow는 상대적으로 가볍고 단순한 워크 플로우로서, 여러 개의 버전 관리가 필요 없는 소규모 프로젝트에 더 적합하다.
github flow의 전체적인 플로우와 함께 git flow와의 차이점을 정리해보려 한다.
일단, github flow에는 develop, release 및 hotfix 브랜치가 없다.
master 브랜치와 feature 브랜치만을 사용하기 때문에, 작업 순서 위주로 작성할 예정이다.
1. 브랜치 생성
- 작업할 feature 브랜치는 master 브랜치에서 생성된다.
- 브랜치를 생성함으로써 master 브랜치에 영향을 주지 않고, 작업 내용을 수정하거나 새로운 작업이 가능해진다.
- 브랜치명은 구체적으로 지어야 동료들이 작업 현황을 이해하는데 도움이 된다.
2. 수정 작업 및 커밋
- 수정 작업 후에는 commit이 이루어지고, 이때 commit 메세지의 내용 역시 구체적이어야 한다. 작업 내용과 그 원인 등이 포함되면 동료 뿐만 아니라 미래의 자신도 이해하기 쉽기 때문이다.
- 하나의 커밋에는 하나의 작업만 포함시키는 것이 이상적이다. 여러 작업을 하나의 커밋에 모두 포함시키면 향후 변경 사항을 되돌리거나 수정하기 위해 더 많은 비용이 들기 때문이다.
3. PR 생성 및 리뷰 반영
- PR은 많은 사람들이 협업하면서 더 나은 결과를 도출할 수 있도록 고안된 방법으로서, merge 전 승인이 필요할 정도로 중요한 단계이다.
- PR을 통해 동료들에게 리뷰를 요청하거나 함께 논의할 수 있다.
- 필요 시 Branch protection setting을 통해 특정 조건을 통해 merge를 제한할 수도 있다.
(예: 최소 승인 개수 또는 특정 팀의 승인 등)
4. 머지
- PR이 최종 승인되면 master 브랜치로 merge 할 수 있다.
- 만약 conflict가 발생하면 merge 전 해결한다.
- PR 내용과 관련 코멘트들은 이후까지 유지되므로 구체적으로 정리되는 것이 좋고, 핵심 키워드 등을 활용하는 것도 방법이다.
5. 브랜치 삭제
- merge 후에는 해당 브랜치를 삭제한다.
- 해당 브랜치를 삭제하는 것이 작업 완료를 공유함과 동시에 향후 예기치 못한 재사용을 방지하는데 도움이 된다.
- PR 내용과 commit 히스토리는 삭제되지 않기 때문에 향후 필요 시에 확인하거나 복구할 수 있다.
github flow는 git flow와는 확실히 다르다.
git flow는 더 많은 사람들이 더 다양한 상황에서 협업할 수 있도록 긴급 작업부터 장기간 작업을 위해 브랜치가 세분화되어 있다.
반면에, git flow는 작업 브랜치 수가 적고 프로세스가 단순한 편이기 때문에 짧은 주기의 배포가 필요한 제품에 적합하다. 또한 그렇기 때문에 더 적은 규모의 프로젝트에 어울린다.
이제와 생각해보니 부트캠프에서 팀 프로젝트를 진행할 당시에 작업했던 방식이 Github flow였던 것 같다.
그때도 PR에 피드백이 많아서 수정사항이 길어지면 프로젝트 기간 안에 작업을 완료할 수 있을지에 대한 스트레스가 있었고, 팀내 작업 내용 공유가 미비했던 점이 있었던 걸로 기억한다.
계속 느끼는 거지만 개발자로 일하는 건 개발 능력 외에도 협업을 위해서 소통 방식이 굉장히 중요할 것 같다.
개발 능력 못지않게 이러한 협업 방식을 미리 공부해 보거나, 다양한 툴을 사용해 보는 것 역시 게을리하지 않으면 안 되겠다는 생각이 든다.
