브랜치 전략

github-flow

master브랜치에 대한 규칙만 명확히 지켜진다면 나머지 브랜치에 대해서는 자유로운 생성흐름.

• -master브랜치는 언제든 배포가 가능한 상태로, 항상 최신의 stable한 상태이어야 함. -> 충분한 테스트 후 merge되어야 함.
  -master에서부터 다른 브랜치들이 만들어진다. 때문에 각 브랜치의 역할을 알 수 있게 명확한 이름으로 이름을 작성한다.
  -pull request후 리뷰와 논의가 끝난 후 master로 merge.

• -원격지 브랜치로 수시로 push해 다른 사람이 확인할 수 있도록하고, backup의 용도로 사용.

git-flow

기본적으로 아래의 5가지의 브랜치를 구성하며 개발,운영을 진행하는 방식.
feature>develop>release>hotfix>master

master : 라이브 서버에 배포되어 실운영하는 브랜치.
develop : 다음 출시 버전을 대비해 개발하는 브랜치.

feature : 추가 기능 개발 브랜치. develop 브랜치에 merge된다.
release : 다음 버전 출시를 준비하는 브랜치. develop 브랜치를 release 브랜치로 옮긴 후 테스트를 진행하고 master 브랜치로 합친다.
hotfix : master 브랜치에서 발생한 버그를 수정하는 브랜치.

• master과 develop는 메인 브랜치로 일반적으로 항시 유지된다.
  release브랜치는 테스트 후 master로 merge되고 일반적으로 사라진다.
  hotfix는 master에서 문제가 생기면 해결을 위해 만드는 브랜치로 해결되면 merge되고 사라진다.

• feature 브랜치는 기능개발이 완료되면 develop에 합쳐져 사라진다.

ex) feature브랜치에서 일부의 기능을 구현하다 완료되면 develop로 merge. -> develop에 출시를 고려할만큼의 기능들이 모이면 release브랜치로 옮겨 테스트,수정. -> release에서 충분히 안정적인 운영이 가능할만큼 테스트되었다면 master로 merge.

-처음에는 master와 develop 브랜치가 존재, develop 브랜치는 master에서부터 시작된 브랜치.
-develop 브랜치에서는 상시로 버그를 수정한 커밋들이 추가. 새로운 기능 추가 작업이 있는 경우 develop 브랜치에서 feature 브랜치를 생성.
-feature 브랜치는 언제나 develop 브랜치에서부터 시작해 기능 추가 작업이 완료되었다면 develop 브랜치로 다시 merge 됨.
-develop에 이번 버전에 포함되는 모든 기능이 merge 되었다면 QA를 하기 위해 develop 브랜치에서부터 release 브랜치를 생성. QA를 진행하면서 발생한 버그들은 release 브랜치에 수정됨. QA를 무사히 통과했다면 release 브랜치를 master와 develop 브랜치로 merge 합니다. 마지막으로 출시된 master 브랜치에서 버전 태그를 추가.

rebase

git에서 한 브랜치를 base로 여러 작업을 동시에 수행하면 병합시에 복잡한 충돌이 일어날 수 있다.

이 경우 위와 같이 동시에 진행했던 작업이 각 브랜치에 제대로 반영되지 못할 수 있다. 이 때 rebase를 이용할 수 있다.

기능을 merge할 때마다 타 브랜치에 rebase를 하면 위와 같이 conflict를 제어하며 브랜치들을 합쳐갈 수 있다.

ex

0. 초기상태

위와 같이 병렬적 잡업.

1. issue2를 master에 merge

$ git checkout master
Switched to branch 'master'
$ git merge issue2
Updating b2b23c4..8f7aa27
Fast-forward
 myfile.txt |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

2. issue3를 master에 merge하려하면 충돌이 일어남.-> issue3를 rebase함.

$ git checkout issue3
Switched to branch 'issue3'
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: pull 설명을 추가
Using index info to reconstruct a base tree...
<stdin>:13: new blank line at EOF.
+
warning: 1 ...

3. rebase과정에서 충돌이 일어나는 부분을 적절히 변경,rebase --continue

• 충돌부분 수정 후에는 rebase --continue issue3가 master보다 앞선 상태가 됨.

$ git add myfile.txt
$ git rebase --continue
Applying: pull 설명을 추가

4. issue3의 개발이 완료되면 일반적인 경우처럼 merge.

$ git checkout master
Switched to branch 'master'
$ git merge issue3

Reference

https://techblog.woowahan.com/2553/
https://subicura.com/git/guide/github-flow.html#github-flow-%E1%84%87%E1%85%A1%E1%86%BC%E1%84%89%E1%85%B5%E1%86%A8
https://backlog.com/git-tutorial/kr/stepup/stepup2_7.html