https://www.youtube.com/watch?v=EzcF6RX8RrQ

https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/

Git flow란

Git flow는 브랜치를 어떻게 운용할지에 대한 좋은 사례다. 이러한 사례를 운영할 수 있는 프로그램을 의미하기도 하지만, 여기서는 사례를 의미한다.

마스터는 언제나 실행 가능한 상태를 유지한다. 실행 가능한 상태를 만들어 가는 과정은 develop 브랜치에서 작업한다. 출시 준비를 위해 사용하는 것이 release 브랜치다. release에 만들어진 브랜치는 언젠가 develop으로 병합해야 한다. 잘 작동하는 을 확인했다면 릴리즈에서 마스터로 병합한다. 이때 일반적인 병합을 하지 않고 머지 커밋을 남기는 방식으로 머지한다.

(master) git merge --no-ff relase/0.2

커밋메시지를 의도적으로 만든다. 릴리즈와 병합했다는 것을 커밋 로그상 의도적으로 남기는 것이 git flow의 목적이다.

구조와 흐름

가장 중심이 되는 브런치는 master랑 develop 브런치이며, 이 두 개 브런치는 무조건 있어야 한다. 이름은 바뀔 수 있다만 웬만해서는 변경하지 않고 진행하도록 하자. Git도 Production에서 사용하는 브런치는 master를 사용하게 되니 관련된 부분을 변경하면 새로운 사람이 왔을때 스터디 커브가 존재할 수 있다.

머지된 feature, release, hotfix 브런치는 삭제하도록 한다.

Feature 브런치

• 브런치 나오는 곳 : develop
• 브런치가 들어가는 곳 : develop
• 이름 지정 : master, develop, release-*, hotfix-*를 제외한 어떤 것이든 가능.

새로운 기능을 추가하는 브런치이다.
feature브런치는 origin에는 반영하지 않고, 개발자의 repo에만 존재하도록 한다.

여기서 머지를 할 때, --no-ff 옵션을 이용하여 브런치에서 머지가 되었음을 git 기록에 남겨두도록 한다. 이렇게 되면 나중에 히스토리 관리가 어려워지는 부분이 존재한다고 한다만… 그것을 확인할 수 있는 방법들은 많으니 뭐…

Release 브런치

• 브랜치 나오는 곳 : develop
• 브랜치가 들어가는 곳 : develop, master
• 이름 지정 : release-*

새로운 Production 릴리즈를 위한 브런치이다.
지금까지 한 기능을 묶어 develop 브런치에서 release 브런치를 따내고, develop 브런치에서는 다음번 릴리즈에서 사용할 기능을 추가한다.
release 브런치에서는 버그 픽스에 대한 부분만 커밋하고, 릴리즈가 준비되었다고 생각하면 master로 머지를 진행한다. (이때도 --no-ff 옵션을 이용하여 머지하였음을 남긴다.)
master로 머지 후 tag 명령을 이용하여 릴리즈 버전에 대해 명시를 하고, -s 나 -u <key> 옵션을 이용하여 머지한 사람의 정보를 남겨두도록 한다. 그런 뒤 develop 브런치로 머지하여, release 브런치에서 수정된 내용이 develop 브런치에 반영한다.

Hotfix 브랜치

• 브랜치 나오는 곳 : master
• 브랜치가 들어가는 곳 : develop, master
• 이름 지정 : hotfix-*

Production에서 발생한 버그들은 전부 여기로… 수정 끝나면, develop, master 브런치에 반영하고, master에 다가는 tag 를 추가해준다.
만약 release 브런치가 존재한다면, release 브런치에 hotfix 브런치를 머지하여 릴리즈 될 때 반영이 될 수 있도록 한다.

장점

• 명령어가 나와있다.
• 웬만한 에디터와 IDE에는 플러그인으로 존재한다.

단점

• 브런치가 많아 복잡하다.
• 안 쓰는 브런치가 있다. 그리고 몇몇 브런치는 애매한 포지션이다.

Github Flow

Scott chacon은 GitHub Flow에서 Git flow가 좋은 방식이긴 하지만 GitHub에서 사용하기에는 복잡하다 여겨 사용하지 않고 GitHub Flow라는 내용으로 사용을 하고 있다고 한다. 그리고 자동화의 개념이 들어가 있다는 점. 자동화가 안되어있는 곳에서는 수동으로 관련 작업을 진행하면 된다.

흐름이 단순한 만큼 룰도 단순하다. master 브런치에 대한 role만 정확하다면 나머지 브런치들에는 관여를 하지 않는다. 그리고 pull request 기능을 사용하도록 권장을 한다.

특징

• release 브런치가 명확하지 않은 시스템에서 사용에 맞게 되어있다.

• 여기에는 GitHub의 서비스 특성상. 릴리즈라는 개념이 없는 서비스를 진행하고 있어서 그런 것으로 보이며, 웹 서비스들이 릴리즈라는 개념이 없이지고 있으니 사용하기 편할 것으로 보인다.

• hotfix와 가장 작은 기능을 구분하지 않는다. 어차피 둘 다 개발자가 수정해야 되는 일중에 하나이다. 단지 우선순위가 어디가 높냐라는 단계이다.

그럼 어떻게 사용할 것인가?

1. master 브런치는 어떤 때든 배포가 가능하다.

master 브런치는 항상 최신의 상태이며, stable 상태로 Product에 배포되는 브런치이다. 그리고 이 브런치에 대해서는 엄격한 role를 주어 사용한다.

2. 새로운 일을 시작하기 위해 브런치를 master에서 딴다면 이름은 어떤 일을 하는지 명확하게 작성한다.

git flow 와는 다르게 feature 브런치나 develop 브런치가 존재하지 않는다. 그렇기에 새로운 기능을 추가하거나 버그를 해결하기 위한 브런치의 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해주도록 하자. Github 페이지에서 보면 어떤 일들이 진행되고 있는지를 확인하기 쉽게 말이다.

3. 원격지 브런치로 수시로 push를 한다.

git flow 와 가장 상반되는 방식이다. 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다.
이 방법의 좋은 점은 하드웨어에 문제가 발생하여 작업하던 부분이 없어지더라도 원격지에 있는 소스를 받아서 작업을 할 수 있도록 해준다.

4. 피드백이나 도움이 필요할 때, 그리고 머징 준비가 완료되었을 때는 pull request를 생성한다.

pull request 는 코드 리뷰를 도와주는 시스템이다.
그렇기에 이것을 이용하여 자신의 코드를 공유하고, 리뷰를 받을 수 있도록 한다. 물론 머지가 준비 완료되어 master 브런치로 반영을 요구하여도 된다.

5. 기능에 대한 리뷰와 사인이 끝난 후 master로 머지한다.

곧장 product로 반영이될 기능이기에 이해관계가 연결된 사람들과 충분한 논의 이후 반영하도록 한다.

6. master로 머지되고 푸시되었을 때는 즉시 배포되어야 한다.

GitHub Flow의 핵심인듯한 master로 머지가 일어나면 hubot을 이용하여 자동으로 배포가 되도록 설정해놓는다.

장점

• 브런치 전략이 단순하다.
• 처음 git을 접하는 사람에게 정말 좋은 시스템이 된다.
• Github 사이트에서 제공하는 기능을 모두 사용하여 작업을 진행한다.
• 코드 리뷰를 자연스럽게 사용할 수 있다.
• CI가 필수적이며, 배포는 자동으로 진행할 수 있다.
• Github가 작업을 할 때 이렇게 작업하고 있다.

단점

• CI와 배포 자동화가 되어있지 않은 시스템에서는 사람이 관련된 업무를 진행한다.
• 많은 것들이 올라오기 시작하면… 그때부터는 헬이…
• 너무 간단하니… 이거 단점이 있나 싶다…

GitLab Flow

Github에서 말하는 flow는 너무나도 간단하여 배포, 환경 구성, 릴리즈, 통합에 대한 이슈를 남겨둔 것이 많았다. 그것을 보안하기 위해 GitLab에서 관련 내용들을 추가적으로 덧붙여 설명한 것을 일컫는다.

Production branch with GitLab flow

production 브런치가 존재하여 커밋한 내용들을 일방적으로 디플로이를 하는 형태. GitHub에서 브런치 하나를 더 구성하여 사용하는 이것도 조금은 간단한 구성이다.
이렇게 구성하면 배포 자동화가 되어있 지않은 구성에서 어떻게 배포를 진행할 것인가에 대한 내용을 담았다. 물론 이걸로 부족하여 다음의 것도 추가되었다.

Environment branches with GitLab flow

master와 production 사이에 pre-production을 두어 개발한 내용을 곧장 반영하지 않고 시간을 두고 반영을 하는 것을 말한다. Staging을위한 공간을 만드는 거지…

Release branches with GitLab flow

release한 브런치를 두고서 보안상 문제가 발생한 것이나 백 포트를 위해서 작업을 할 경우, cherry-pick을 이용해서 작업을 진행할 수 도 있다. 아니면 해당 릴리즈에서 발생하는 버그들을 묶어서 수정하는 방식으로 작업한다. 일반적으로 말하는 ‘upstream first’ 정책이다.