[GIT] - 브랜치

글의 참고

- https://backlog.com/git-tutorial/kr/stepup/stepup1_5.html

- https://www.gitkraken.com/learn/git/best-practices/git-branch-strategy#github-flow-branch-strategy

- http://scottchacon.com/2011/08/31/github-flow.html

- https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

- https://nvie.com/posts/a-successful-git-branching-model/

---

글의 전제

- 밑줄로 작성된 글은 강조 표시를 의미한다.

- 그림 출처는 항시 그림 아래에 표시했다.

---

글의 내용

- Git 브랜치 전략

 

" 흔히 사용하는 깃 브랜치 전략으로는 `Git flow`, `Github flow`, `Gitlab flow` 3가지 방법이 있는 듯 하다. 이 글에서는 먼저 `Git flow` 브랜치 전략에 대해 알아본다. 

https://nvie.com/posts/a-successful-git-branching-model/

 

" `Git flow` 에서는 브랜치를 크게 2개로 나눈다.

1. Main Branches : Master 와 Develop 으로 나뉘어져 있다. 메인 브랜치들의 핵심은 `infinite lifetime branches` 라는 것이다.
 
2. Supporting Branches : Feature, Release, Hotfix 로 나뉘어져 있다. 서포팅 브랜치들의 핵심은 `finite lifetime branches` 라는 것이다.

 

 

1. Master 

" relase branch 에서 테스트를 모두 통과하여 안정화가 되면, version number 를 tagged 하고 master branch 에 merge 된다. 즉, master branch 는 가장 안정화된 버전이며, 배포가 가능한 버전(`production-ready`)을 의미한다. master branch 는 일반적으로 `origin/master` 브랜치라고 생각하면 되고, 여기서 `HEAD`가 가리키는 버전이 `production-ready` 이라고 생각하면 된다. 

 

2. Develop

" 기능 개발 흐름을 이끌어 가는 브랜치라고 보면 된다. 모든 개발자들은 자신이 맡은 기능들을 구현하기 위해 develop branch 에서 분기한 feature branch 를 만든다. 이 feature branch 는 로컬로만 존재하는 브랜치다. 기능 구현이 끝나면, develop branch 에 merge 해서 다른 사람들이 구현한 내용들과 함께 종합 테스트를 진행해야 한다. 젠킨스 데일리 빌드는 이 브랜치로 돌린다. 일반적으로, `origin/develop` 브랜치를 develop branch 라고 생각하면 된다.

 

3. Feature(Topic)

" 새로운 기능을 만들어야 할 때, develop branch 에서 분기해서 만드는 브랜치다. 이 브랜치는 결국 새로운 기능이 완료되면 develop branch 로 머지되어 사라지는 브랜치다. 즉, 새로운 기능이 개발되고 있는 동안에만 유지되는 브랜치다. 네이밍은 `master`, `develop`, `release-*`, `hotfix-*`만 피해서 사용하면 된다. feature branch에서 가장 중요한 내용은 develop branch 에서 분기되서 develop branch 에 merge 된다는 점이다.

 

4. Release

" develop branch 에서 새로운 릴리즈 시점이 되면 분기시키는 브랜치다. release branch 에서는 새로운 기능 추가는 금지되고, 버그 수정과 실제 릴리즈가 될 때 같이 발행해야 하는 메타 데이터(버전 넘버, 빌드 날짜 등)를 준비한다.

 

5. Hotfix

" 핫픽스 브랜치는 마스터 브랜치에서, 즉, `live production` 버전에서 문제가 발생해서 해당 이슈를 해결하기 위해 마스터 브랜치에서 분기되는 브랜치를 의미한다.

 

 

- Git-flow 에서 Release 와 Master 브랜치를 나눈 이유

 

" Git-flow 에서 release branch 는 모든 feature branch 들이 develop branch 에 merge 가 되면, develop branch 에서 안정성 테스트 및 버그 수정을 위해서 별도로 떼어내는 브랜치를 의미한다. 그렇다면, master branch 와 차이가 뭘까? master branch 는 안정성 테스트와 버그 수정까지 끝나서 완전히 배포가 가능한 브랜치를 의미한다. 즉, 개발자들은 release branch 에서 열심히 테스트를 진행해서 버그를 수정하고, 이제 진짜 문제가 없다싶으면, 해당 release branch 를 master branch 에 merge 한다. 이와 동시에, release branch 를 rebase 해서 develop branch 를 새롭게 따낸다.

 

" release 와 master 를 나눈 이유는 안정화된 코드 베이스를 별도로 뽑아내기 위해서다. 만약, master branch 가 없다면 각 release branch 에서 최종 버전이 안정화 버전이 된다. 그런데, 릴리즈 브랜치의 최종이라는 것을 어떻게 알 수 있을까? 예를 들어, release-1.0.2 브랜치가 6개월 동안 커밋 내용이 없다고 가정하자. 이걸 stable 버전이라 볼 수 있을까? 아직 모른다. 갑자기 하루 뒤에 커밋이 발생할 수 도 있다. 이렇게 release branch 만 있을 경우, stable 한 코드 버전에 대한 애매모호함이 존재하기 때문에, stable 한 버전은 master branch 로 분리시킨다.  

 

 

- GIt-flow 에서 Release 와 Develop 브랜치를 나눈 이유

 

" 기능이 추가되면, 버그는 증가한다. release branch 가 없고, develop branch 만 존재한다면, 하나의 브랜치에서 새로운 기능이 추가되면서 기존에 있던 기능에 대한 버그를 수정하고, 앞에 일이 계속 반복해서 일어나게 된다. 즉, 개발 브랜치만 존재할 경우에는 무한 루프에 빠진 것처럼 마스터 브랜치에 머지를 할 수 없는 상황이 될 가능성이 높아진다. release branch 는 새로운 기능에 대한 부분을 끊는 브랜치다. 즉, 새로운 기능은 develop branch 에서 이어나가고, release branch 에는 develop branch 에서 분기된 시점까지만 추가한 기능에 대한 안정성을 테스트하면 된다. 이렇게 해야 최종적으로 배포가 가능한 버전이 나올 수 있게 되는 것이다.

The "develop" branch is where new features are being developed and integrated. The "release" branch is a snapshot of the code at a specific point, allowing developers to focus on release-related activities without interference from ongoing development work...

 

 

- 주관적인 브랜치 사용

 

" 실무에서 git clone 시, Yocto 기반의 Linux 혹 Android Project 면 엄청난 시간이 걸린다. 용량이 orignal source 기준 기본 50G정도되고 최초 빌드시, object 파일들까지 만들어지면 그 용량은 진짜 말로 표현이 안된다. 그래서 원격 빌드 서버에서 작업을 할 때, 각 팀의 팀장님들께서는 프로젝트 폴더를 2개까지만 생성하게 해주신다... 이럴 때, branch를 만들면 최고다. 나는 주로 2 가지 용도로 branch를 사용한다.

1. 작업을 열심히 하다가 내가 작업한 프로젝트가 뭔가 꼬인 것이다. 그래서 소스를 수정하고 revision 돌리고 해도 답이 없는 것 같다. 그럴 때 어떻게 할까? 새로 소스를 받아서 빌드를 해본다. 그것도 50G의 양을!! 미친짓이다. 이럴 때 baseline 브랜치를 만들어 놓으면 딱이다(baseline 브랜치는 git-flow 에서 최신 master 브랜치를 기준으로 한다). 소스를 새로 받을 필요없이 baseline 브랜치를 하나 카피해서 새로운 브랜치를 만들면 된다.

 

" 내가 4년 동안 실무에서 개발하면서 많이 느끼는 거지만, Low-level 코딩을 할 수록 기술 습득에 관심이 없는 경우가 많다. App 및 Middleware 팀에서는 실제로 branch를 잘활용하고 있는거 같지만, 내가 속한 시스템 팀은 위와 같이 자신이 작업한 working directory가 꼬이면 소스를 새로 받고 다시 빌드한다. 그런데 임베디드 프로젝트는 최초 빌드에서 엄청난 양의 빌드를 해야하는 경우가 많다... 어쨋든 2번째 이유는 아래와 같다.

2. 만약 특정 버전부터 버그가 발생하는데 그걸 나중에 알았다고 치자. 예를 들어, 현재 최신 revision이 150인데 80~120사이에서 문제가 발생한 것 같다. 당연히 저 범위의 revision으로 돌아가서 빌드하고 해당 바이너리들에서 버그가 발생하는지 확인해야 한다(만약 jenkins를 통한 daily build 바이너리가 있다면 이럴 때 정말 좋다). 그런데 나는 현재 내가 작업하는 프로젝트를 오염시키고 싶지 않다. 즉, revision을 왔다리 갔다리 하고 싶지 않다. 이럴 때도 baseline branch를 새로 받아서, 특정 커밋 버전으로 revision을 세팅한 뒤 디버깅을 진행하는 용도로 사용한다.

 

" 그런데, 사실 특정 SW 리비전에 대한 이슈 트래킹은 개인적으로 Jenkins를 통한 Daily Build 이미지를 사용하는 것이 가장 편하다.