[Sourcetree + gitflow] 사용법 전략 

대부분의 회사에서 Git을 사용할 경우 Git Flow를 따릅니다.
그러다보니 귀찮을때가 많습니다.
단적인 예로 release 브랜치 작업이 끝난후 다음과 같은 작업이 진행됩니다.

• develop 브랜치로 스위칭 -> release 브랜치를 merge
• master 브랜치로 스위칭 -> release 브랜치를 merge
• master 브랜치에 tag 추가
• release 브랜치 삭제

이런 작은 행위들이 크진 않지만 막상 할때마다 귀찮습니다.

그래서, 이제부터 적용 사항을 적어보려고 합니다.

1. 현재 최신 버전은 소스트리 4.0이다.

    Source Tree 홈페이지: https://www.sourcetreeapp.com/

2. 설치하면 gitflow가 자동으로 설치 되어 있다.

    저장소 -> Git flow / Hg flow -> 메뉴 적용.

3. 아래와 같이 gitflow 단축 메뉴를 꺼내면 편리하게 사용 가능 하다.

4. 처음에 "깃 플로우" 버튼을 누르고 바로 확인을 누르면 기본 전략을 따라가게 된다.

5. develop 브랜치를 한번 푸시한다.

6. 이후 릴리즈, 핫픽스, 기능 브렌치를 적절하게 사용한다.

    아래 이미지는 깃플로우 브렌치 전략이다.

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

구조와 흐름

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

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

Feature 브런치

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

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

여기서 머지를 할 때, --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에는 플러그인으로 존재한다.

단점

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

참고

• A successful Git branching model - Vincent Driessen
• git-flow cheatsheet
• nvie/gitflw
• gifflow, 쉬운 git brunch 관리 - 개발왕 김코딩
• git 브랜칭 전략과 git flow - 꿀벌개발일지

GitHub Flow

GitLab Flow