Git Flow 톺아보기

holim0·2021년 3월 12일
2

깃 플로우에 대해서 살펴보겠습니다.



🪶 Git Flow를 따른 브랜치 전략 예시

➡️ 먼저 예시를 통해서 깃 플로우에 대해서 살펴보겠습니다.

위 그림에서 확인할 수 있듯이 크게 develop, master 브랜치가 있습니다.

  • master branch: 배포가 이미 되었거나 배포될 예정인 소스가 담기 브랜치, master branch에서는 배포가 될 때 tag를 달아주는 식으로 관리를 합니다.

  • develop branch: 실제 개발이 진행되는 브랜치, 여러 개발자가 함께 공유를 하면서 개발을 하게 되는 브랜치입니다.

  • feature branch : develop branch에서 기능별로 개발이 이루어 지는 브랜치, 실질적으로 기능별로 개발자가 작업을 하게 되는 브랜치입니다.

  • hotfixs branch : 배포 버전에 생긴 문제로 긴급한 수정이 필요할 때 개발이 진행되는 브랜치

현재 배포 중인 master branch에서

  • release branch : 내부적으로 배포할 준비가 되었다고 생각되는 소스가 저장되는 브랜치

➕ Git Flow를 이용한 새로운 기능 추가

  1. **develop branch**에서 _feature/branch_name_의 이름을 가진 branch를 생성합니다.

  2. feature/branch_name 에서 작업을 진행합니다.

  3. _feature/branch_name_를 **develop branch**에 merge하기 위해서 Pull Request 생성합니다.

  4. **develop branch**에 merge합니다.



💻 나의 실제 작업 방식

  • 기본적으로 깃 플로우 방식을 따릅니다.

  • 각 개인의 develop 브랜치에서 기능(feature)별로 브랜치를 생성해 작업을 합니다.

우선 작업을 할 때 구현해야될 **기능(feature)**이 어떤 것이 있는지 정리하고 이를 바탕으로 **기능(feature)**별로 이슈를 생성해줍니다.

아래 그림은 제가 프로젝트를 하면서 생성한 이슈의 예시입니다. 프로젝트를 처음 설계 할 때 이슈를 다 생성하고 그 이슈를 따라서 브랜치를 따서 작업을 하는 방식으로 개발을 하고 있습니다.

그리고 Pull Request를 올릴 때 아래 그림과 같이 관련 이슈를 적어주고 작업 내용을 적어줍니다.

이렇게 적어주게 되면 각 Pull Request에 어떤 작업을 했고 어떤 이슈와 관련되어 있는지 바로 확인을 할 수 있게 됩니다.

각 **기능(feature)**별로 브랜치를 작업할 때 커밋 단위를 나눠주는 것도 중요합니다.

저는 최대한 각 기능에 파생되는 세부 기능을 나누고 이 세부 기능에 따라서 커밋 단위를 결정합니다. (사실 제일 어려운거 같습니다..🤣)

💡 Pull Request 단위나 Commit의 단위는 각자 속한 팀별로 상의를 하고 정해 나가는 것이 가장 좋을꺼 같습니다.



고민해봐야 할 사항 🤔

➡️ 개발은 협업을 통해 이루어집니다. 그렇기 때문에 다른 사람이 자신의 작업 내용을 봤을 때 명확하게 전달되는 것이 중요하다고 생각합니다.

코드뿐 만 아니라 브랜치 이름, commit 메세지, Pull Request에 대한 모든 것이 협업을 할 때 명확해야 됩니다.

🪵 브랜치

✅ git flow 방식의 work flow를 따르게 된다면 master, develop, hotfixes, feature, realse branch가 존재 할 것이고 이는 각각 branch type이라고 할 수 있습니다.

여러 branch naming convention이 존재하고 이는 팀원들과 합의해서 결정해 나가야 합니다.

대표적인 convention에 대해서 살펴보겠습니다.

  • branch_type / issue_number / 간략한 설명
  • branch_type / issue_number
  • branch_type / 간략한 설명
  • 작업자 이름 / issue_number
  • 작업자 이름 / issue_number / 간략한 설명
  • 작업자 이름 / branch_type / 간략한 설명
  • issue#issue_number

뭐가 더 좋다고는 말하기 어려울꺼 같습니다. 팀원들과 같이 합의하여 맞춰나가는 것이 제일 좋은 방법인 거 같습니다.


✉️ commit 메세지

✅ 커밋 메세지를 작성할 때도 여러가지 convention이 존재합니다.

저는 주로 현재 브랜치에 해당되는 이슈 번호와 커밋 내용을 적는 방식으로 했습니다.

[#이슈 번호] 커밋 내용

[예시]

이렇게 작성하면 해당 이슈에 커밋 로그가 찍혀 tracking 하는 데 좋습니다. 또한 커밋 메세지에 Gitmoji를 이용해서 한 눈에 봤을 때 직관적으로 이해를 할 수 있도록 작성할 수 있습니다.


📲 Pull Request

✅ PR 제목은 확실하게 정해져 있지 않습니다. 간략하지만 핵심을 잘 담을 수 있게 제목을 작성하면 됩니다.

저는 지금까지 다음과 같은 형태로 PR 제목을 적었습니다.

  1. [PR] [branch_type] 제목
  2. [PR] 제목

PR 내용은 관련된 이슈와 작업 내용을 작성해주었습니다.


Reference

https://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html
https://lhy.kr/git-workflow

profile
매일 조금씩 성장하고 있는 개발자입니다.

0개의 댓글