Git Flow

Git 브랜치 전략 - Git Flow

대표적인 gitFlow 종류

• git flow
• github flow
• gitlab flow
  
  
  1. Git Flow

(사진 출처: https://www.youtube.com/watch?v=w2r0oLFtXAw)
git flow 는 총 5 종류의 브랜치를 활용합니다.

주의할 점은 master, develop 은 각 브랜치가 영구적으로 존재하지만, hotfix, release, feature 브랜치의 경우 필요할 때마다 브랜치를 만들고, 머지가 되면 삭제한다는 점입니다.

전체적인 merge 순서는 다음과 같습니다. (merge 할 때는 항상 —-no-ff 옵션을 붙입니다.)

1. master 브랜치 (main 브랜치)

소비자가 사용하는 제품이 존재하는 (배포될 코드가 있는) 브랜치입니다.

release 브랜치로부터 pull request 받습니다.

부모 브랜치: -

자손 브랜치 (분기해서 생성되는 브랜치): hotfix, develop

PR받는 브랜치 (pull request 받는 브랜치): release

PR나가는 브랜치 (pull request 보내는 브랜치): -

2. hotfix 브랜치

배포된 서비스에 대한 긴급 버그 수정을 진행하는 브랜치입니다.

hotfix 브랜치는 만들 때 hotfix-* (hotfix-1) 과 같은 형태로 이름을 지정해서 만듭니다.

수정이 완료되면, develop 과 master 브랜치 각각에 pr 을 날립니다.

부모 브랜치: master

자손 브랜치: -

PR받는 브랜치: -

PR나가는 브랜치: develop, master

3. release 브랜치

배포 전에 제품을 테스트 (QA, 품질검사) 하는 브랜치입니다.

release 브랜치는 만들 때 release-* (release-1) 과 같은 형태로 이름을 지정해서 만듭니다.

테스트가 정상적으로 완료되면, develop 과 master 브랜치 각각에 pr 을 날립니다. pr merge 가 완료되면, 브랜치를 삭제합니다.

부모 브랜치: develop

자손 브랜치: -

PR받는 브랜치: -

PR나가는 브랜치: develop, master

4. develop 브랜치

개발 단계의 코드가 있는 (개발의 중심) 브랜치입니다.

개발 자체는 feature 브랜치에서 진행하고, 기능 하나 구현이 완료되면 develop 브랜치로 pr 을 날립니다. 이러한 과정을 반복하면서 특정 단계까지 개발이 완료되면, develop 브랜치를 베이스로 해서 테스트를 위한 release 브랜치를 새롭게 만듭니다.

부모 브랜치: master

자손 브랜치: feature, release

PR받는 브랜치: feature

PR나가는 브랜치: -

5. feature 브랜치

특정한 기능 (단위 기능) 을 구현하는 브랜치입니다.

feature 브랜치는 만들 때 feature/* (feature/기능명) 과 같은 형태로 이름을 지정해서 만듭니다.

기능 구현이 완료되면, develop 브랜치로 pr 을 날립니다. merge 되면 브랜치는 삭제됩니다.

부모 브랜치: develop

자손 브랜치: -

PR받는 브랜치: -

PR나가는 브랜치: develop

Git Flow 는 다음과 같은 경우에 유용합니다.

• 큰 규모의 팀
• 퀄리티 보장이 중요한 프로덕트
• release 된 프로덕트에 대한 관리 사이클이 긴 경우

feature → develop → release → master

[2. Github Flow]

(사진 출처: https://www.youtube.com/watch?v=w2r0oLFtXAw)

Github Flow 는 딱 2가지 종류의 브랜치만 사용합니다.

Git Flow 는 큰 규모의 팀 + 안정성이 매우 중요한 서비스에서 사용하면 좋지만, 작은 규모의 팀 + 빠른 개발과 업데이트가 중요한 서비스에서는 오히려 비효율적으로 작용합니다.

그렇기 때문에 Github Flow 는 단 2개의 브랜치만을 사용하며, 배포용 브랜치인 master, 각 단위 기능 구현을 위한 브랜치인 feature 로 구성됩니다. feature 브랜치는 merge 후에 삭제됩니다.

1. master 브랜치 (main 브랜치)

소비자가 사용하는 제품이 존재하는 (배포될 코드가 있는) 브랜치입니다. (해당 브랜치는 push 를 받으면 자동으로 실제 서비스로 배포되도록 설정되어있습니다.)

feature 브랜치에서 단위 기능 구현이 완료될 때마다 pull request 를 받습니다. (여기서 해당 브랜치를 merge 하기 전에 테스트를 진행합니다.)

부모 브랜치: -

자손 브랜치 (분기해서 생성되는 브랜치): feature

PR받는 브랜치 (pull request 받는 브랜치): feature

PR나가는 브랜치 (pull request 보내는 브랜치): -

2. feature 브랜치

특정한 기능 (단위 기능) 을 구현하는 브랜치입니다.

feature 브랜치는 만들 때 git flow 보다 더 구체적으로, 명확하게 작업명을 작성해서 만듭니다. (단순히 feature/* 가 아니라 버그 해결인지, 기능 추가인지 등을 명확히 명시)

기능 구현이 완료되면, master 브랜치로 pr 을 날립니다. merge 되면 브랜치는 삭제됩니다.

부모 브랜치: master

자손 브랜치 (분기해서 생성되는 브랜치): -

PR받는 브랜치 (pull request 받는 브랜치): -

PR나가는 브랜치 (pull request 보내는 브랜치): master

Github Flow 는 다음과 같은 경우에 유용합니다.

• 작은 규모의 팀
• release 된 프로덕트에 대한 관리 사이클이 짧은 경우 (업데이트 주기가 짧은 경우)
• 빠른 배포와 관리가 필요한 경우

[3. Gitlab Flow]

Gitlab Flow 는 4종류의 브랜치를 사용합니다.

github flow 는 테스트를 위한 브랜치가 없고, 배포용 브랜치가 따로 없기 때문에 큰 규모의 서비스에는 적합하지 않습니다. 그래서 github flow 의 단순함과 git flow 의 체계적인 관리를 합쳐서 절충적으로 git 을 활용하는 방식이 바로 gitlab flow 입니다.

pre-production 브랜치가 테스트를 담당하고, master 브랜치가 개발용 브랜치로 역할합니다. feature 브랜치는 다른 flow 와 마찬가지로 merge 되면 삭제됩니다.

1. production 브랜치

소비자가 사용하는 제품이 존재하는 (배포될 코드가 있는) 브랜치입니다.

pre-production 브랜치로부터 pull request 받습니다.

부모 브랜치: master

자손 브랜치 (분기해서 생성되는 브랜치): -

PR받는 브랜치 (pull request 받는 브랜치): pre-production

PR나가는 브랜치 (pull request 보내는 브랜치): -

2. pre-production 브랜치

배포 전에 제품을 테스트 (QA, 품질검사) 하는 브랜치입니다.

테스트가 정상적으로 완료되면, production 과 master 에 각각 pr 을 날립니다.

부모 브랜치: master

자손 브랜치: -

PR받는 브랜치: master

PR나가는 브랜치: production, master

3. master 브랜치 (main 브랜치)

개발 단계의 코드가 있는 (개발의 중심) 브랜치입니다.

개발 자체는 feature 브랜치에서 진행하고, 기능 하나 구현이 완료되면 master 브랜치가 pr 을 받습니다. 이러한 과정을 반복하면서 특정 단계까지 개발이 완료되면, pre-production 으로 pr 을 날립니다.

부모 브랜치: -

자손 브랜치: feature

PR받는 브랜치: feature, pre-production

PR나가는 브랜치: pre-production

4. feature 브랜치

특정한 기능 (단위 기능) 을 구현하는 브랜치입니다.

브랜치명은 github flow 처럼 자세하게 작성합니다.

기능 구현이 완료되면, master 브랜치로 pr 을 날립니다. merge 되면 브랜치는 삭제됩니다.

부모 브랜치: master

자손 브랜치: -

PR받는 브랜치: -

PR나가는 브랜치: master

Gitlab Flow 는 다음과 같은 경우에 유용합니다.

• 중간 규모의 팀
• 퀄리티 보장이 중요한 프로덕트
• 빠른 배포와 관리가 필요한 경우

Fast-Forward

만약, 아래와 같은 상태에서 main 브랜치에서 develop 브랜치 merge를 시도하게 되면

git merge develop

즉, 새로운 commit 이 생기는 것이 아니라, 그냥 main 브랜치에 develop 브랜치의 commit 기록이 병합되면서 아래와 같은 형태로 커밋 기록이 만들어지는 것을 fast-forward 라고 합니다.

만약 아까처럼 줄기가 나눠진 형태로 커밋 기록을 남기고 싶다면? 아래와 같이 --no-ff 를 붙여서 merge 명령어를 입력하면 됩니다. (non fast forward 의 약자입니다.)

git merge develop --no-ff

Fast-forward 개념이 중요한 이유는, 커밋 기록 (히스토리) 을 어떻게 관리할지 정할 때 사용되기 때문입니다. 만약 하나의 줄기로 관리를 하고자 한다면 아래에서 배울 rebase 와 함께 fast-forward 형태로 병합을 진행시키면 되고, 브랜치의 줄기를 남기고자 한다면 non fast-forward 형태로 병합을 진행시키면 되는 것입니다. 어떻게 관리할지는 팀에서 정하기 나름이지만, 보통은 non fast-forward 형태로 병합을 진행해서, 브랜치 작업을 확인할 수 있도록 기록을 남기는 경우가 많은 것 같습니다.

git Rebase

rebase 는 특정 브랜치를 base (기준) 로 놓고, 커밋 이력을 정렬하겠다는 명령어입니다.
만약 아래와 같은 형태로 브랜치가 나뉘어져있다면

main 에서 rebase develop 을 실행할 경우, 아래처럼 develop 의 커밋 이력을 base 로 해서, 거기에 이어서 main 의 커밋 이력이 정렬되게 됩니다. (이어지는 main 의 커밋 이력은 이전과 동일해보이지만, 정확히는 이전과 다른 커밋 이력입니다.)
즉, merge (non fast-forward) 와 같이 줄기가 나뉘지 않고, 아래처럼 하나의 줄기로 커밋 이력이 정렬되게 되는 것입니다.

💡 rebase 는 정확히 말하면 병합을 위한 것이 아니라, 커밋 히스토리를 정렬하기 위한 명령어입니다. 이미 병합이 된 브랜치가 있더라도, 거기서 rebase 를 하면 커밋 히스토리를 다시 정렬할 수 있습니다.

💡 rebase 는 커밋 이력을 단순히 관리하고 싶을 때 사용하는 명령어이고, merge 는 변경 이력을 모두 남기고 싶을 때 사용하는 명령어입니다. 실제로는 커밋 이력을 남기는 것이 굉장히 중요하기 때문에, rebase 는 fork 시에 원본 프로젝트에 맞게 (동기화해서) 변경 이력을 관리하고자 하는 특수한 상황에서만 사용하고, 보통은 merge 만을 사용합니다.

fork 로 프로젝트 가져왔을때 merge conflict 해결방법

코드를 수정 후

add .
git rebase --continue

실행하면 된다.

• 만약 merge conflict 가 발생한 상황에서 rebase 를 취소하고 싶다면,

git rebase --abort 

를 입력하면 됩니다.