Git 협업 방법론 비교 및 Git flow에 대하여

Git 협업 방법론

개발자들이 git을 협업 툴로 사용하면서 협업 방법론들이 자연스럽게 생겨났고 현재는 다음의 4가지로 나눌 수 있습니다.

1. 😓 Centralized Workflow

현재 채택하고 있는 방식. 하나의 브랜치(master)에서 모든 개발이 이루어집니다. 이는 단순하지만 다음의 단점을 가집니다.

• 하나의 브랜치에서 모든 작업이 이루어지므로 Conflict 확률이 높다. (실제로 경험한 사항)
• 기능상 여러 버전을 구분하지 않기에(hotfix, release 등...) 서비스 배포 이후 관리가 어렵고 master 브랜치가 더러워질 확률이 높다.

2. 😮‍💨 Feature Branch Workflow

master 브랜치에서 뻗어나가는 feature 브랜치를 만들어 개발하고 master 브랜치에 합치는 방법론입니다.

일단 브랜치를 분리하는 방법론이고 초기 개발시에는 나쁘지 않은 방법이나 이미 런칭된 서비스인 경우 다음의 단점을 가지고 있습니다.

• 처음부터 명확히 feature를 구분하지 않을 경우 결국 사람 당 1개 브랜치를 만들게 될 확률이 높고 결국 feature 브랜치 명명 기준이 모두 달라 혼란이 올 수 있다. (conflict가 일어날 확률이 높아짐)

3. 😵‍💫 Forking Workflow

과거 잠깐 테스트했던 방법론. 대표(중앙)저장소가 있고 모든 개발자들은 이 대표 저장소를 fork하여 자신의 원격 저장소를 만듭니다. 작업은 모두 자신이 fork한 저장소에서 진행되고 대표 저장소에 merge 요청을 할 땐 pull request를 보냅니다.

Forking workflow를 사용할 경우 각자 개인 원격 저장소에서 관리하다가 필요할 경우에만 Pull request를 보내 중앙 원격 저장소에서 합쳐지기에 개인 로컬 환경에서 다양한 테스트를 해볼 수 있다는 장점이 있습니다만 여전히 단점도 존재합니다.

• 작업 상황을 자주(짧은 주기로) 리뷰하기가 쉽지 않다. → 통일된 관리가 어렵다.
  forking workflow는 자신의 원격 저장소에서 주로 작업하다보니 서로 작업하는 내용을 모니터링하기가 어렵게 된다. pull request를 자주 하기엔 번거롭고 최소 2~3일, 길게는 몇 주 주기로 pull request를 하게 되기 때문에 어쩔 수 없이 리뷰하는 주기가 길어집니다.

Forking Workflow 또한 유명한 방법론중 하나이지만 팀원들이 모두(대다수) git의 기본 기능(commit, push, pull, rebase 등)에 익숙하고, 프로젝트 단위가 매우 크며 개인이 독립된 기능을 자유롭게 개발할 경우에 추천한다고 합니다.

4. 🥰 Git flow Workflow

master, develop 브랜치는 사라지지 않는 기본 브랜치이고 나머지 feature, release, hotfix는 필요할 때 만들었다가 삭제하는 형식의 방법론입니다.

Git flow Workflow에서 브랜치는 다음과 같이 운영됩니다.

• master(항상 유지): 제품으로 바로 출시되는 브랜치 (완벽한 상태의, 언제나 출시 가능한 상태를 유지하는 브랜치)
• develop(항상 유지): 다음 출시 버전을 개발하는 브랜치
• feature(일시적): 특정 기능을 개발하는 브랜치
• release(일시적): 이번 출시 버전을 준비(QA 수정, bug fix 등)하는 브랜치 → tag로 관리
• hotfix: 출시 버전(master)에서 발생한 버그를 바로 수정하는 브랜치 → 수정 후 바로 배포

기존의 문제점은 한 브랜치에서 개발서버와 실서버를 모두 배포하는 구조이기 때문에 개발서버에 테스트하기 위해서는 필연적으로 main 브랜치에서 테스트 해야하고 개발서버에 반영된 코드가 실서버에 반영이 되면 안되는 경우에는 다시 코드를 롤백했어야 했습니다. 이는 결국 하나의 브랜치에서 모든것을 관리하기 때문에 발생된 문제입니다.

💁‍♂️ 기본적인 git flow

1. master 브랜치에 git tag 0.1 을 입력해 태그(버전)을 명시한다.
2. git checkout -b develop 을 입력해 develop 브랜치를 생성함과 동시에 해당 브랜치로 이동한다.
3. develop 브랜치에서 작업을 쭉 진행한다.
4. 기능 개선 및 작업이 모두 끝나면 release를 위해 git checkout -b release/0.2 를 입력해 출시를 위한 브랜치를 만든다.
5. release 브랜치에서 출시 직전에 발견한 버그 사항이라던지 부가적인 기능 추가를 한다.
6. release 브랜치에서 작업이 모두 끝나면 develop 브랜치로 병합을 한다. (동기화) git checkout develop(develop 브랜치로 이동) => git merge release/0.2 (release 브랜치를 develop 브랜치로 병합)
7. develop 브랜치에 병합된 내용을 개발 서버에 올려보고 문제가 없다면 release/0.2 브랜치를 master 브랜치로 병합한다.
   => git checkout master => git merge --no-ff release/0.2 (패스트포워드를 막기 위해 의도적으로 커밋 메세지를 남기기 위한 커맨드이다.)
8. master 브랜치에 새로운 버전이 출시됐으므로 git tag 0.2를 통해 새로운 버전을 명시한다.
9. master 브랜치로 병합과 버전 과정이 모두 끝났다면 git branch -d release/0.2를 입력해 릴리즈 브랜치를 삭제한다.

🤷🏼‍♂️ 두 가지 기능을 동시에 개발하는 git flow

금방 끝나는 기능, 오래 걸리는 기능 두 가지 기능을 동시에 개발하는 예시.

1. develop 브랜치에서 git branch feature/short, git branch feature/long을 입력해 두 가지 브랜치를 생성한다.
2. feature/short 브랜치로 이동해 작업을 진행한다. 동시에 feature/long 브랜치로도 이동해 동시에 다른 작업을 진행한다.
3. feature/short 브랜치 작업이 먼저 끝나면, develop 브랜치로 이동해 feature/short 브랜치를 병합한다.
   git checkout develop => git merge --no-ff feature/short
4. develop 브랜치에 feature 브랜치의 병합이 완료되면 feature/short 브랜치는 필요가 없으므로 삭제한다. git branch -d feature/short
5. 새로운 기능이 develop 브랜치에 추가 됐으므로 출시를 준비하기 위해 git checkout release/1.0 브랜치를 만든다.
6. 릴리즈 단계에서 생기는 자잘한 문제들을 해당 브랜치에서 수정한다.
7. 수정이 완료되면 develop 브랜치에 release/1.0 브랜치를 병합하고, 개발 서버 테스트 후 문제가 없다면 release/1.0 브랜치를 master 브랜치로 병합한다.(문제가 생기면 다시 release/1.0 브랜치로 돌아가 수정 작업을 진행하고 다시 develop 브랜치에 병합)
8. master 브랜치에 새로운 버전이 출시됐으므로 git tag 1.0를 통해 새로운 버전을 명시한다.
9. master 브랜치로 병합과 버전 과정이 모두 끝났다면 git branch -d release/0.2를 입력해 릴리즈 브랜치를 삭제한다.

😱 만약 잘 개발하다가 심각한 버그를 수정해야 할 경우 git flow

기존 버전 (master)에서 코드를 수정하고 바로 배포해야하는 경우

1. master 브랜치에서 git checkout -b hotfixes/1.1 을 통해 핫픽스를 위한 브랜치를 만들고 버전은 1.1로 명시한다.
2. hotfixes/1.1 브랜치에서 버그를 모두 수정했으면 커밋을 하고 먼저 develop 브랜치와 병합한다. (동기화) git checkout develop => git merge --no-ff hotfixes/1.1
3. 마찬가지로 master 브랜치와도 병합을 해준다. git checkout master => git merge --no-ff hotfixes/1.1
4. master 브랜치에 새로운 버전이 출시됐으므로 git tag 1.1를 통해 새로운 버전을 명시한다.
5. master 브랜치로 병합과 버전 과정이 모두 끝났다면 git branch -d hotfixes/1.1를 입력해 핫픽스 브랜치를 삭제한다.

develop 브랜치를 master 브랜치로 최종 병합하는 형태가 아닌, release 브랜치에서 master 브랜치로 병합하는 형태

feature나 release 브랜치에서 작업된 사항들은 자주자주 develop 브랜치에 merge 시켜주는것이 conflict를 막는데 아주 큰 도움이 됩니다.

[번외] tag version은 어떻게 관리하는가?

아래는 예시입니다. 꼭 적용할 필요는 없으나 좋은 것 같아 공유합니다.