깃 플로우에 대해서 살펴보겠습니다.
🪶 Git Flow를 따른 브랜치 전략 예시
➡️ 먼저 예시를 통해서 깃 플로우에 대해서 살펴보겠습니다.
위 그림에서 확인할 수 있듯이 크게 develop, master 브랜치가 있습니다.
- master branch: 배포가 이미 되었거나 배포될 예정인 소스가 담기 브랜치, master branch에서는 배포가 될 때 tag를 달아주는 식으로 관리를 합니다.
- develop branch: 실제 개발이 진행되는 브랜치, 여러 개발자가 함께 공유를 하면서 개발을 하게 되는 브랜치입니다.
- feature branch : develop branch에서 기능별로 개발이 이루어 지는 브랜치, 실질적으로 기능별로 개발자가 작업을 하게 되는 브랜치입니다.
- hotfixs branch : 배포 버전에 생긴 문제로 긴급한 수정이 필요할 때 개발이 진행되는 브랜치
현재 배포 중인 master branch에서
- release branch : 내부적으로 배포할 준비가 되었다고 생각되는 소스가 저장되는 브랜치
➕ Git Flow를 이용한 새로운 기능 추가
- develop branch에서 feature/branch_name의 이름을 가진 branch를 생성합니다.
- feature/branch_name 에서 작업을 진행합니다.
- feature/branch_name를 develop branch에 merge하기 위해서 Pull Request 생성합니다.
- 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 제목을 적었습니다.
- [PR][branch_type] 제목
- [PR] 제목
PR 내용은 관련된 이슈와 작업 내용을 작성해주었습니다.
Reference
https://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html
https://lhy.kr/git-workflow
