git-flow를 이해하고 브랜치를 관리하자

개요

---

 

 Git은 굉장히 편리하고 강력한 도구지만 회사 또는 팀 프로젝트에서 협업하면서 사용하다 보면 무분별하게 브런치가 생겨나거나 비효율적으로 관리되는 경우가 생긴다. 또한 개별적으로 개발한 브런치들을 병합(Merage)할 때 충돌(Conflict)이 발생하기도 한다.

여러 사람이 Git을 통해 협업을 하려면 질서(공통된 사용 규칙)가 필요하다.

Git-flow는 이러한 목적으로 고안된 Git의 사용 규칙이며 방법론이다.

 

Git

---

Git이란?

Git flow을 이야기하기 전에 우선  Git이 무엇인지 알아보자.

• Git은 SW 개발에 활용되는 대표적인 분산 버전 관리 도구이다.
• Git은 리눅스 커널을 최초로 개발한 리누스  베네딕트 토발즈(스웨덴어: Linus Benedict Torvalds)가 다른 리눅스 개발자들과 2005년 개발하였다.
• SW 개발 과정에서 개발자는 수없이 소스코드를 수정과 삭제하는 과정을 반복한다. 
• Git 은 소스코드를 체계적으로 관리할 수 있는 SW 개발 도구다.
• 누구나 다른 사람이 만든 리눅스 소스코드를 자신의 컴퓨터에 내려받아 수정하고 업로드할 수 있으며 어떤 코드를 수정하고 기록했는지 추적할 수 있다.
• Git 이전에도 소스코드를 공유하는 SW 개발 도구는 여럿 있었지만 토발즈는 이전 도구가 모두 확장성이 부족하다고 생각했고 여러 명이 동시에 사용하기에는 적합하지 않다고 생각했다.
• 그리고 1000명 이상이 동시에 사용해도 괜찮을 만큼 시스템이 안정적이고 빠른 수행 속도를 가지는데 중점을 두고 Git을 개발하게 되었다.  

---

Git의 기본 개념

Git을 사용하려면 몇 가지 개념을 이해해야 된다. 

• commit
• branch
• merge
• clone | fatch | pull | push

---

 

Git-flow

---

Git-flow의 개념도

◎ 출처: http://dogfeet.github.io/articles/2011/a-successful-git-branching-model.html

---

Git-flow의 브랜치 종류

• master: 기준이 되는 브랜치로 제품을 배포하는 브랜치이다.  모든 변경사항이 결국 master로 merge 되어야 한다.
• develop: 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능을 합친다(Merge)
• feature: 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 합친다
• release: 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기 위한 브랜치이다.
• hotfix: master 브랜치로 배포를 했는데 버그가 생겼을 때 긴급 수정하는 브랜치입니다.

---

Git-flow의 워크플로우

1. 처음으로 master 브랜치를 만들고 시작한다
2. 그리고 동일한 내용의 develop 브랜치를  만든다. 개발자들은 이 develop 브랜치에서 개발을 진행한다.
3. 개발을 진행할 때 회원가입, 장바구니 등의 기능 구현이 필요할 경우 A개발자는 develop 브랜치에서 feature 브랜치를 하나 생성해서 회원가입 기능을 구현하고 B개발자도 develop 브랜치에서 feature 브랜치를 하나 생성해서 장바구니 기능을 구현한다.
4. 완료된 feature 브랜치는 검토를 거쳐 다시 develop 브랜치에 합친다.(Merge)
5. 모든 기능이 완료되면 develop 브랜치를 release 브랜치로 만든다. 그리고 QA(품질검사)를 하면서 보완점을 보완하고 버그를 해결한다.
6. 완료되면 이제 release 브랜치를 master 브랜치와 develop 브랜치로 보낸다. 
7. Master 브랜치에서 버전을 추가하기 위해 태그를 생성하고 실제 환경에 배포를 한다.
8. 배포 후 미처 발견하지 못한 버그가 있을 경우 hotfixes 브랜치를 만들어 긴급 수정 후 태그를 생성하고 바로 수정 배포를 한다.(master 브랜치에 반영된 hotfixes의 브랜치는 develop 브랜치에도 함께 반영한다)

마치며

---

규칙을 만들어도 지키지 않으면 무의미하다.

규칙이 모든 경우에 통용될 수는 없다.(예외사항은 항상 존재한다.)

Git-flow는 완벽하진 않지만 훌륭한 방법이다.

Git-flow는 법칙이 아니고 방법론이다. 결국 최종 목표는 상황에 맞게 개선하여 효율적인 협업을 이루어가는 것이다.

 

▣ 추천 링크, 포스팅 글

---

http://dogfeet.github.io/articles/2011/a-successful-git-branching-model.html

#dogfeet - A successful git branching model

https://k39335.tistory.com/82

[Git] Gitflow로 branch를 관리하자!!

 

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

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

https://ux.stories.pe.kr/183

Git Flow 개념 이해하기

 

https://gist.github.com/ihoneymon/a28138ee5309c73e94f9

git 을 기반으로 git-flow를 사용하여 애플리케이션 배포버전을 관리하자.

 

https://hellowoori.tistory.com/56

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