[Git] Git branch 전략 (Git flow보다 중요한 것은.. Code Review)

💡 본 문서는 Git branch 전략에 대해 정리해놓은 글입니다.
단순히 branch를 만들고 관리하는 법에 대해서도 다루지만, branch를 통한 버전관리에 더욱 초점을 맞추었으니 참고 부탁드립니다.

Git branch

1. Git branch 생성

# git branch 생성
git branch develop

# 해당 branch로 이동
git checkout develop

# add, commit 후 해당 브렌치에 push하기
git add .
git commit -m "comment"
git push origin develop

git branch 생성 및 해당 branch로 이동을 한번에!

git checkout -b develop

2. Git branch 삭제

# git branch 삭제
git branch -d develop

 

Git Branch 전략들

1. gitflow

gitflow에는 5가지 브랜치가 존재합니다.

• master(main) : 기준이 되는 브랜치로 제품을 배포하는 브랜치
• develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 Merge
• feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 Merge
• release : 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기위한 브랜치
• hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치

master와 develop가 중요한 매인 브랜치이고 나머지는 필요에 의해서 운영하는 브랜치입니다. branch를 merge할 때, 항상 -no-ff 옵션을 붙여 branch에 대한 기록이 사라지는 것을 방지하는 것이 좋습니다.

gitflow 과정

1. master 브랜치에서 develop 브랜치를 분기합니다.
2. 개발자들은 develop 브랜치에 자유롭게 커밋을 합니다.
3. 기능 구현이 있는 경우 develop 브랜치에서 feature/* 브랜치를 분기합니다.
4. 배포를 준비하기 위해 develop 브랜치에서 release/* 브랜치를 분기합니다.
5. 테스트를 진행하면서 발생하는 버그 수정은 release/* 브랜치에 직접 반영합니다.
6. 테스트가 완료되면 release 브랜치를 master와 develop에 merge합니다.

2. github flow

Git-flow가 Github에서 사용하기에는 복잡하다고 나온 브랜치 전략입니다. hotfix 브랜치나 feature 브랜치를 구분하지 않으며, master로 merge할 때마다 배포를 진행합니다. master로 merge할 때, pull request를 생성해야 하며 review를 받고 merge를 진행합니다. CI와 배포가 자동화되어있는 프로젝트에 유용합니다.

github flow 과정

1. master 브랜치는 어떤 때든 배포가 가능합니다.
   • master 브랜치는 항상 최신 상태며, stable 상태로 product에 배포되는 브랜치
   • 이 브랜치에 대해서는 merge하기 전에 충분히 테스트를 해야하며, 엄격한 role과 함께 사용합니다.
     • 테스트는 로컬에서 하는 것이 아니라 브랜치를 push 하고 Jenkins로 테스트합니다.
2. master에서 새로운일을 시작하기 위해 브랜치를 만든다면, 이름을 명확히 작성합니다.
   • 브랜치는 항상 master 브랜치에서 만듭니다.
   • Git-flow와는 다르게 feature 브랜치나 develop 브랜치가 존재하지 않습니다.
   • 새로운 기능을 추가하거나, 버그를 해결하기 위한 브랜치 이름을 잘 결정해야하며, 어떤 일을 하고 있는지 커밋메시지를 명확하게 작성해야 합니다.
3. 원격지 브랜치로 수시로 push 합니다.
   • Git-flow와 상반되는 방식.
   • 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해줍니다.
   • 이는 하드웨어에 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아서 작업할 수 있도록 해줍니다.
4. 피드백이나 도움이 필요할 때, 그리고 merge 준비가 완료되었을 때는 pull request를 생성합니다.
   • pull request는 코드 리뷰를 도와주는 시스템
     • 이것을 이용해 자신의 코드를 공유하고, 리뷰받아 개선합니다.
5. 기능에 대한 리뷰와 논의가 끝난 후 master로 merge한다
   • 곧장 product로 반영이될 기능이므로, 이해관계가 연결된 사람들과 충분한 논의 이후 반영하도록 합니다
     • 물론 CI도 통과해야한다!
6. master로 merge되고 push 되었을 때는, 즉시 배포되어야 합니다
   
   • master로 merge가 일어나면 CD를 통해 자동으로 배포가 되도록 설정해놓습니다.

3. Fork와 Pull Request

오픈소스 기여를 하거나 규모가 있는 개발을 할 경우, 브랜치 보다는 Fork와 Pull requests를 활용하여 구현을 합니다. Fork는 브랜치와 비슷하지만 프로젝트를 통째로 외부로 복제해서 개발을 하는 방식입니다. 개발을 해서 브랜치처럼 Merge를 바로 하는 것이 아니라 Pull requests로 머지 요청을 보내면 프로젝트 관리자가 Pull requests된 코드를 보고 적절하다 싶으면 그때 그 기능을 붙히는 식으로 개발을 진행합니다.

 

저희 팀이 사용하는 Git Branch 전략..?

브랜치 전략은 다양하기에 정답이란 존재하지 않지만, 다양한 방법을 알면 활용하기 좋기에 저희 팀이 사용하는 브렌치 전략을 공유하자면...?

• 현재 gitflow와 github flow를 혼합하여 사용하고 있습니다.
• 저희는 feature 브렌치에서 기능을 개발 후 develop으로 Pull Request를 보내고 review를 받을 후 merge를 진행합니다.
• 이후 배포할 버전에 대해서는 develop에서 main으로 merge하여 배포하고 있습니다. 

물론, 특정 브렌치 전략을 사용해서 개발하자라고 처음부터 정해진 것을 아니었지만, 이번에 찾아보니 두가지 전략을 혼합하여 사용하고 있었네요. 이렇게 Branch를 관리하면서 중요하다고 느낀 것은?

• 브렌치 하나의 기능을 명확히 하자!
• pull request를 요청하여 코드리뷰를 받고 개선하자!

정리하자면...?  제가 느끼기에 브렌치 전략은 너무 다양하여 어떤 전략을 사용해도 무방하지만, 브렌치 하나의 기능을 명확히 하고 짧은 주기로 pull request를 보내 코드리뷰를 받는 전략을 선택하는 것이 좋을 것 같네요.

긴 글 읽어주셔서 감사합니다.

참고

• [우아한형제들] 우린 Git-flow를 사용하고 있어요: https://techblog.woowahan.com/2553/
• git branching strategies: https://faun.pub/git-branching-strategies-in-2022-83938c5784d8 
• [velog] Git branch 전략: https://velog.io/@kw2577/Git-branch-%EC%A0%84%EB%9E%B5