협업을 위한 Git-Flow 전략 [GIT]

협업(Collaboration)을 위한 'Git-Flow' 전략

 우리는 깃과 깃허브를 원격 저장소로서의 기능, 동시에 버전관리와 백업, 나아가 '협업'을 위한 툴임을 앞선 글들을 통해 알 수 있었다. 그렇다면 본격적으로 이 협업을 위한 효과적인 Git-flow 전략을 한 번 살펴보자. 이 전략은 다른 말로는 Branch 전략이라고도 하는데, 여러 명의 개발자가 1개의 저장소를 사용하는 환경에서 효과적으로 저장소를 사용하기 위해 나온 개념이다.

 이번엔 GitKraken이라는 GUI를 활용해 GIT 명령어를 활용한 업로드보다 쉽고 간단한 Git-flow 전략을 작성해보려 한다. (아래의 핵심 키워드들과 함께!)

 

- Branch

- Push (+commit)

- Pull Request (+review)

- Merge

Git-Flow?

'Branch'

---

 Git-flow에 대해 알기 위해선 우선 Branch라는 개념에 대해 알아야 한다. Branch는 우리나라 말로 '나뭇가지' 혹은 '분기'라고 하는데, 아래 그림이 그 개념을 가장 잘 나타낸 듯해 가져와봤다. 

Branch (Master, Develop, release, feature, hotfix)

# Main branch

 우선 프로젝트의 가장 핵심 줄기인 'Main(Master) branch'부터 알아보자. 이 메인 브랜치는 프로젝트의 시작과 끝에 남아있는 가장 핵심 브랜치로, 쉽게 나무의 중심 기둥이라고 이해하면 된다. 이 메인 브랜치 내부에도 Master와 Develop 브랜치가 있는데, 두 브랜치 모두 Main이라고 이해해도 무관하다(Github-flow).

1. Master : 제품으로 '출시(launch)'하기 위한 브랜치(혹은 제품으로 출시할 수 있는 브랜치)로, 최초 분기점이자 동시에 최종 합병점이다.
2. Develop : 메인 브랜치 중에서 '개발(develop)'을 위한 브랜치로, 해당 브랜치에서 feature와 release 브랜치가 분기되고 병합된다. 

# Sub branch

 다음은 제품이 출시되고 수정됨에 따라 계속해서 새로 생겨나기도 하고, 사라지기도 하는 'Sub branch'가 있다. 이 서브 브랜치는 큰 프로젝트(기둥) 중간 중간 추가되고, 수정됨에 따라 지속적으로 생성되는 일종의 나뭇가지, 분기점이다. 간단하게 Main branch에서 분기되어 개별 기능을 개발하고 완료되면 다시 Main branch로 합병되면서 사라지는 이 Sub 브랜치들을 알아보자.

1. feature : develop 브랜치(= Main branch)에서 분기되어 '개별 기능을 개발'하는 브랜치이다. 
2. release : 기능 개발이 완료되어 출시 버전을 준비하는 브랜치이다. feature와 동일한 기능을 하지만, 주석이라던지 파일을 다운받으면서 놓친 부분(.gitignore, readme)등을 정리하는 작업을 담당한다. 
3. hotfix : 출시 버전에서 발생한 버그를 (긴급하게) 수정하는 브랜치로, Develop 브랜치에서 분기되지 않고 Master 브랜치에서 분기된다. 

'GUI' (GitKraken)

---

최근 나오는 Git client (GUI)는 위 Git-flow 전략을 대부분 지원한다. 깃에서 필요한 여러 명령어를 버튼으로 대체해서 쉽고 빠르게 원격저장소로 옮겨주는 역할을 한다. 그래서 GitKraken 과 같은 GUI 툴들은 알아두면 편하다. 

main : master/develop, sub : feature, release, hotfix

최종 main(master) 브랜치에 합병(merge)

 

그렇다면 "Merge는 또 뭐고, Pull-Request는 뭔데?"에 대한 내용은 다음 글부터...

 

 

 

 

해당 글은 GIT을 다룬 이전 글들의 다음 버전임을 말씀드립니다. 이해가 되지 않는다면 이전 글들을 참고해주세요~!!