[협업] 협업을 위한 Git Flow 설정하기

 

 

 

 

들어가며

Git 커밋 컨벤션을 정리한 글에 이어, 협업에 필요한 내용들을 계속해서 정리하고 있습니다. 개인적으로 저는 git 때문에 어려움을 겪었던 적이 많습니다. git 설정을 잘못해서 기존 작업물들이 다 날아갔던 경험, 예전 작업 상태로 되돌리고 싶어도, 어떻게 되돌리는 줄 몰라서 헤맸던 경험, 브랜치를 사용하지 않아서, 굉장히 좋지 못한 코드를 계속해서 올렸던 경험 등 git flow를 알았더라면 생기지 않았을 경험들이 많습니다. 앞으로 저와 함께 하는 팀원들은 저와 같은 경험을 하지 않도록 하고 싶어 글을 적습니다. 앞으로 저와 함께 협업하는 팀원분들에게 도움이 되고 싶습니다. 

 

 

 

 

---

 

 

 

 

Git Flow란?

Git-Flow를 설명하기 전에, Git 브랜치 전략에 대해 짧게 설명드리겠습니다. 만약 혼자 개발을 한다면, 개인의 스타일로 Git을 사용합니다. 하지만 다양한 개발자와 협업을 한다면, 서로 규칙을 정해서 Git을 사용하게 됩니다. 이를 Git 브랜치 전략이라고 부릅니다. 최근 Git-Flow, GitHub-Flow가 많이 사용되고 있는데, 저는 Git-Flow에 대해 소개하고자 합니다.

 

Git-Flow는 대표적인 브랜칭(branching) 전략 중 하나로 2010년 Vicent Driessen는 Git 작업 절차에 대해 소개합니다. Git-Flow는 브랜치를 크게 4가지로 나누어 개발하는 전략입니다. Git Flow 전략에는 master와 develop이라는 항상 존재하는 메인 브랜치(Main branch)가 있고, feature-*, hotfix-*, release-*라는 필요에 따라 생성하는 브랜치가 있습니다. 물론, 이후 improvement-*, bugfix-등 프로젝트에 따라 다양한 브랜치 모델이 추가되었습니다. 가장 중심이 되는 브랜치는 master와 develop 브랜치이며, merge된 feature, release, hotfix 브랜치는 삭제하도록 합니다. 그렇다면 이제 각각의 브랜치에 대해 소개하고, 어떻게 활용할 수 있는지 알아보겠습니다.

 

 

 

 

메인 브랜치란?

메인 브랜치는 master 브랜치와 develop 브랜치 두 종류를 말합니다.

 

 

master 브랜치는 배포 가능한 상태만을 관리하는 브랜치를 말하며, develop브랜치는 다음에 배포할 것을 개발하는 브랜치입니다. 즉 develop 브랜치는 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행합니다.

 

 

---

 

 

보조 브랜치란?

보조 브랜치는 피처 브랜치(feature branch) 또는 토픽 브랜치(topic branch)를 말합니다.

 

master 브랜치에서 develop 브랜치를 만들었고, develop 브랜치에서 다시 feature 브랜치를 나눠 작업을 하고 있는 것을 그림을 통해 알 수 있습니다. 피처 또는 토픽 브랜치는 기능을 개발하는 브랜치입니다. develop 브랜치에는 기존에 잘 작동하는 개발코드가 담겨있으며, 보조 브랜치는 새로 변경될 개발코드를 분리하고 각각 보존하는 역할을 합니다. 즉 보조 브랜치는 기능을 다 완성할 때까지 유지하고, 다 완성되면 develop 브랜치로 merge 하고 결과가 좋지 못하면 버리는 방향을 취합니다. 보조 브랜치는 보통 개발자 저장소에만 있는 브랜치고, origin에는 push하지 않습니다.

 

만약 feature 브랜치를 사용한다면, feature/#이슈번호 와 같은 형태로 브랜치를 관리합니다. 

 

 

 

 

---

 

 

 

 

 

릴리즈 브랜치(release branch)란?

릴리즈 브랜치는 배포를 위한 최종적인 버그 수정 등의 개발을 수행하는 브랜치를 말합니다.  

 

 

develop 브랜치에 버전에 포함되는 기능이 merge 되었다면 QA를 위해 develop 브랜치에서부터 release 브랜치를 생성합니다. 배포 가능한 상태가 되면 master 브랜치로 병합시키고, 출시된 master 브랜치에 버전 태그(ex, v1.0, v0.2)를 추가합니다. release 브랜치에서 기능을 점검하며 발견한 버그 수정 사항은 develop 브랜치에도 적용해줘야 합니다. 그러므로 배포 완료 후 develop 브랜치에 대해서도 merge 작업을 수행합니다. 

 

 

 

 

 

---

 

 

 

 

핫픽스 브랜치(hotfix branch)란?

핫픽스 브랜치는 배포한 버전에서 긴급하게 수정할 필요가 있을 때 master 브랜치에서 분리하는 브랜치를 말합니다.  

 

 

버그를 잡는 사람이 일하는 동안에도 다른 사람들은 develop 브랜치에서 하던 일을 계속할 수 있습니다. 이 때 만든 hotfix 브랜치에서의 변경 사항은 develop 브랜치에도 merge 하여 문제가 되는 부분을 처리해줘야 합니다. 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

브랜치를 만드는 방법

만약 CLI로 브랜치를 만든다면 어떻게 브랜치를 만들 수 있는지 알아보겠습니다.

 

git branch 브랜치이름 (해당 브랜치가 존재하지 않는다면 브랜치를 새로 만듭니다.)
ex) git branch feature/#1

git checkout -b 브랜치 이름 (해당 브랜치가 존재하지 않는다면 브랜치를 새로 만들면서 바로 그 브랜치로 이동합니다.)
ex) git checkout -b feature/#1

git checkout 브랜치이름 (존재하는 브랜치가 있다면 그 브랜치로 이동합니다.)
ex) git checkout feature/#1

 

feature 브랜치를 생성할 때는 develop 브랜치에서부터 생성합니다. 그리고 꼭 브랜치를 생성하기 전에 develop 브랜치를 pull 받아야합니다. feature 브랜치는 아래와 같이 생성합니다.

 

ex) feature/login  (기능을 적습니다)

 

feature 브랜치는 작은 기능 단위로 쪼개서 최대 10개 미만의 커밋으로 구성되도록 합니다. 병합된 feature 브랜치는 로컬과 원격에서 삭제합니다. 삭제방법은 여기를 참고해주세요.

 

만약 feature/#1 브랜치에 작업이 끝나고, develop 브랜치에 merge 하기 위해서는 Pull Request를 보내야 합니다. 이 방법에 대해서 간단히 소개하겠습니다.

 

 

 

 

 

 

 

---

 

 

 

 

 

 

Pull Request 보내는 방법

Pull Request를 보내는 이유는 Merge 하기 전에 코드 리뷰를 하기 위해서입니다. 만약 feature/#1과 같은 기능 브랜치가 완성됐다면, develop 브랜치에 Pull Request를 보내야 합니다. 그 방법에 대해 알아보겠습니다. 

 

git add .
git commit -m "커밋 컨벤션 메시지" (ex: Feat: 추가 로그인 API 로직 구현)
git push origin 브랜치 이름 (ex: feature/#1)

 

위와 같이 브랜치에 커밋을 한 후에 Github Repository를 보면 아래와 같습니다.

 

그리고 Compare & pull request를 눌러보겠습니다. (만약 위와 같이 뜨지 않는다면 위의 보이는 Pull Request 버튼을 눌러 직접 들어가서 해도 똑같습니다.)

 

 

그러면 위와 같은 화면을 볼 수 있습니다. 여기서 중요하게 봐야 할 점은 위에 머지하는 브랜치와 머지되는 브랜치입니다. 위에는 develop <--- feature/#3와 같은 것을 볼 수 있습니다. 정리하면 feature/#3 브랜치를 develop 브랜치로 Merge를 하겠다는 뜻입니다.  (그리고 Able to merge라고 뜨는 것은 충돌이 나지 않고 Merge가 가능하다는 것입니다.)

 

문제가 없다면 아래의 Create pull request를 누르면 됩니다. 그리고 아래의 화면이 나올 때까지 계속 확인 버튼을 눌러줍시다.

 

 

 

 

그리고 위의 화면에서 오른쪽을 보면 Reviewer, Assignees 등을 지정해줄 수 있습니다. 여기서는 2개만 살펴보겠습니다. Reviewer는 말 그대로 코드 리뷰를 현재 내가 보낸 Pull Request에 대해 리뷰를 할 사람을 지정하는 것입니다. Assignees는 이 작업의 담당자를 지정하는 것 같습니다.

 

문제가 없다면 이번에도 Merge pull request 버튼을 눌러보겠습니다.

 

 

그리고 Confirm merge를 누르면 브랜치가 Merge가 됩니다. 그 후 쓰지 않는 branch는 Delete branch 버튼을 눌러서 브랜치를 삭제하면 됩니다.

 

 

 

 

 

 

---

 

 

 

 

 

 

마치며

지금까지 Git Flow에 대해서 알아봤습니다. Git Flow를 공부하면서, Git Flow에 활용해야 하는 Git 지식들을 정리해야 할 필요를 느꼈습니다. Git 명령어를 정리하면서, 곧 있을 협업에 대비해야겠다고 생각했습니다.

 

가끔 기본이 충실한 개발자란 무엇인가에 대한 고민을 하곤 합니다. 기본에도 다양한 종류가 있습니다. 하지만 Git을 잘 다룰 수 있을 때 어느 정도 기본이 있는 개발자가 됐다고 생각합니다.  기본이 충실한 개발자가 되고 싶습니다. 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

참고

우린 Git-flow를 사용하고 있어요 - 우아한형제들 기술 블로그

Git 브랜칭 전략 : Git-flow와 Github-flow

Praise-Whale/Praise_Server