Gitflow 워크플로우

 

 

Gitflow 워크플로우 설명

master, develop (feature), release, hotfix

master 가 주가 되며 CI 에 반영됨.

모든 기능 개발은 develop 브랜치 중심으로 수행됨.

어느정도 기능개발이 되면 release 를 위한 release/xxx 또는 release-xxx 와 같은 브랜치를 만듬.

여기서 release 를 위한 사이클이 시작되며 버그수정, 문서추가 등의 릴리즈를 위한 작업 외에는 추가 안함.

이와 동시에 develop 은 또 계속 진행.

release 가 브랜치가 완료되면 release v0.2 라하면 이것을 master 에 반영.

여기서 혹여나 버그가 생기면 hotfix 로 브랜치를 따서 버그 수정.

즉, hotfix 는 master 로 부터 따서 버그 수정하는 것임. 수정 후에는 master, release, develop 모두에 반영.

---

Develop

먼저 할 일은 master 브랜치를 기준으로 develop 브랜치를 만드는 것이다. 팀 구성원 중 한 명이 자신의 로컬 저장소에 빈 develop 브랜치를 만들고 중앙 저장소로 푸시하면 된다.

$ git branch develop

$ git push -u origin develop

master 브랜치는 축약된 프로젝트 이력만 담고 있는 반면, 이 개발 브랜치는 모든 개발 이력을 다 담을 것이다. 이제 팀 구성원들은 중앙 저장소를 복제하고, 중앙 저장소와 연결된 개발 브랜치를 만들어야 한다.

$ git clone ssh://user@host/path/to/repo.git

$ git checkout -b develop origin/develop

Feature

이 사례에서는 철이와 미애가 각자 맡은 기능을 개발할 기능 개발 브랜치를 만들고 서로 다른 기능을 개발한다고 가정한다. 다시 한 번 언급하지만, master를 베이스로 하지 않고, develop 브랜치를 기준으로 기능 개발 브랜치를 따야 한다.

$ git checkout -b some-feature develop

항상 하던대로 개발하고 변경 내용을 커밋한다.

$ git status

$ git add <some-file>

$ git commit

몇 번의 커밋 끝에, 미애는 맡은 기능 개발을 완료했다. 만약에 팀이 풀 리퀘스트를 하기로 약속했다면, 미애는 자신의 기능 브랜치를 develop 브랜치에 병합해 달라고 풀 리퀘스트를 보낼 수 있다. 풀 리퀘스트를 이용하지 않기로 했다면 다음과 같이 직접 develop 브랜치에 병합하고 중앙 저장소에 푸시하면 된다.

$ git pull origin develop

$ git checkout develop

$ git merge some-feature

$ git push

$ git branch -d some-feature

기능 브랜치를 병합하기 전에 반드시 로컬 develop 브랜치에 중앙 저장소의 변경 내용을 반영해서 최신 상태로 만들어야 한다. master에 직접 병합하지 않도록 주의해야 한다. 병합할 때 충돌이 발생하면 Centralized Workflow에서 본 바와 같이 해결한다.

Release

철이가 여전히 기능 개발에 몰두하고 있는 와중에, 미애는 첫 공식 릴리스를 준비하고 있다. 기능 개발과 마찬가지로 릴리스 과정을 캡슐화할 새로운 브랜치를 만들어야 한다. 이 과정에서 버전 번호를 부여한다.

$ git checkout -b release-0.1 develop

이 브랜치는 최종 테스트를 하거나, 문서를 수정하는 등 릴리스와 관련된 여러 가지 작업들을 처리하기 위한 격리 공간이다. 미애가 이 브랜치를 만든 이후에 develop 브랜치에 병합된 기능은 릴리스 대상에서 제외된다. 이번에 포함되지 않은 기능들은 다음 릴리스에 포함된다.

릴리스 준비가 끝나면, 릴리스 브랜치를 master와 develop 브랜치에 병합하고, 릴리스 브랜치는 삭제한다.

develop 브랜치에도 병합하는 이유는 릴리스를 준비하면서 개발 중인 다른 기능에 영향을 줄 수 있는 작업을 했을 수도 있기 때문이다. 미애의 팀이 코드 리뷰를 하는 규칙을 가지고 있다면, 병합을 요청하는 풀 리퀘스트를 보낼 수도 있다.

$ git checkout master

$ git merge release-0.1

$ git push

$ git checkout develop

$ git merge release-0.1

$ git push

$ git branch -d release-0.1

릴리스 브랜치는 기능 개발(develop)과 프로젝트의 공식 릴리스 사이의 가교 역할을 한다. master 브랜치에 병합할 때는 태그를 부여하는 것이 나중을 위해서 여러 모로 편리하다.

$ git tag -a 0.1 -m "Initial public release" master

$ git push --tags

Git은 저장소에 어떤 이벤트가 발생할 때 미리 짜 놓은 스크립트를 자동으로 실행할 수 있는 훅(hook) 기능을 가지고 있다. 중앙 저장소의 master 브랜치에 푸시하거나 태그를 푸시할 때, 자동으로 공개 릴리스를 빌드하는 훅을 거는 등의 자동화도 가능하다.

Hotfix

릴리스를 배포한 후에, 미애는 철이와 함께 다음 릴리스를 준비하기 위해 일상으로 돌아갔다. 그런데 사용자가 현재 릴리스에 버그가 있다고 보고해왔다. 버그를 해결 하기 위해 미애(또는 철이)는 작업하던 기능 개발을 잠시 미뤄두고, master 브랜치를 기준으로 유지 보수 브랜치를 만들고, 버그를 수정하고 커밋한다. 버그 수정이 끝나면 master 브랜치에 바로 병합한다.

$ git checkout -b issue-#001 master

버그 수정

$ git checkout master

$ git merge issue-#001

$ git push

릴리스 브랜치와 마찬가지로, 유지 보수 브랜치에서의 변경 사항은 개발 중인 기능에도 반영되어야 하므로 develop 브랜치에도 병합해야 한다. 병합이 끝나면 유지 보수 브랜치는 삭제해도 좋다.

$ git checkout develop

$ git merge issue-#001

$ git push

$ git branch -d issue-#001