Git PR merge 전략

보통은 default가 Create a merge commit 이기 때문에 아무 생각없이 이 방식으로 머지했으나, 저 옆에 화살표를 눌러보면, 2가지의 옵션이 더 있다!

1. Create a merge commit
2. Squash and merge
3. Rebase and merge

이렇게 3가지 정도의 Git PR merge 전략이 있다고 할 수 있다. 각 전략의 장단점을 한번 알아보자!

1. Create a merge commit

develop -> feature/store, feature/benefit, feature/do
이런 상황에서 각 브랜치가 전부 develop에 머지가 되었을 때?

• 각 브랜치의 commit들이 뒤섞이게 됨 (시간 순서대로 기록이 되어서)
• 또 'Merge' 로그는 머지 순서대로 기록이 됨

결국, commit들의 순서와 merge의 순서가 완전히 달라져 버림!

장점

• PR이 머지된 시점을 Merge 로그로 알 수 있음

단점

• (비교적) 지저분한 히스토리 관리
  - 불필요한 혹은 보기 싫은 merge commit이 main 브랜치에 생성
  • linear 하지 않은 히스토리

2. Squash and merge

squash : 으깨다, 으끄러지다

merge가 된 순서대로 기록이 됨
merge가 된 PR의 commit들이 합쳐져서 (squashed) 기록이 됨
세세한 commit들이 합쳐져서 하나의 commit으로 남음

장점

• (비교적) 쉽고 편한 히스토리 관리

단점

• 하나의 commit만 roll-back 하고 싶어도 단위가 너무 커져서 대공사가 되어버림..

3. Rebase and merge

merge가 된 순서대로 기록이 됨 (각각의 commit도 PR이 머지된 순서대로)
'Merge' 로그는 남지 않음
rebase로 인해, merge 이후 로그를 보면 하나의 브랜치에서 작업한 것과 같은 로그
따라서, 작은 단위의 roll-back도 가능!

장점

• 깔끔한 히스토리 관리
  - linear한 히스토리 (다른 PR 사이의 commit 로그가 섞이지 않으니까)

단점

• 히스토리 관리를 위한 추가 리소스가 필요할 수도 있음
  - commit들이 연속적으로 남는 형태다보니까, 언제 어떤 시점에 기능이 추가가 됐는지 파악하기 어려울 수 있음
  - base 브랜치를 항상 최신화해주어야 함

    git checkout feature/store
    git rebase develop

• commit마다 conflict 해결이 필요 (번거로움)

특이한 점

• Rebase and merge (Github) !== git rebase

Rebase and merge (Github)
원래 이전에 있었던 commit도 새로운 commit(hash)로 들어오게 됨

git rebase
원래 이전에 있었던 commit은 이전의 commit(hash)로 들어오게 됨

The rebase and merge behavior on GitHub deviates slightly from git rebase. Rebase and merge on GitHub will always update the committer information and create new commit SHAs, whereas git rebase outside of GitHub does not change the committer information when the rebase happens on top of an ancestor commit. For more information about git rebase, see git-rebase in the Git documentation.

참고하면 좋을 사실!

1. 어떤 전략을 default로 할건지 레포 setting 탭에서 정할 수 있다!

If you have linear history requirement enabled on any protected branch, you must enable squashing or rebasing.

만약 linear하게 히스토리를 관리하고 싶다면, squashing이나 rebasing 전략을 enable 시켜라!!

• Default message로 어떤 commit 메시지를 남길지 고를 수 있음

2. 이런 옵션도 있었네?! base 브랜치 상황 파악할 수 있는

3. under construction 대신 Draft PR?
   현재 아직 작업중이고, 아직 리뷰가 필요한 상태가 아니다!
   단, 이 기능은 private 레포에서는 사용할 수 없음.

생각해볼만한 점

현재 일하는 방식

develop
	release/v.X.X.X
		feature/manbogi
		feature/team-league
		feature/race

(거의) 모든 merge를 create a merge commit 방식으로.

다음과 같이 해보면 어떨까?

1. feature/manbogi-1 > feature/manbogi
   • 하나하나의 commit 보다는 PR 하나의 단위가 더 의미있음
   • squash and merge

2. feature/manbogi > release/v.X.X.X
   • manbogi 작업을 했다 뿐 아니라, 그 안에서 어떤 작업들을 했었는지 필요
   • 해당 release에서 어떤 것이 언제 merge 되었는지 확인 필요
   • 이미 이전 단계에서 commit들이 한번 합쳐졌기 때문에, 히스토리 관리 괜찮지 않나?
   • create a merge commit

여기서 하나 더 제안해보자면, 특히 QA 이슈 대응을 할 때에
fix/manbogi-issue-gina-1, ... fix/manbogi-issue-gina-11, ...
브랜치 관리가 잘 안되고 있는듯한 느낌이 든다.

• feature/manbogi > fix/manbogi-qa를 새로 만들어서 여기에 create a merge commit
• commit 하나하나가 의미있기 때문에 (qa 브랜치 기준으로는)

3. release/v.X.X.X > develop
   • 히스토리 관리가 그렇게 중요하진 않음
   • 모든 commit이 남을 필요가 있을까? (PR 단위로만 남아도 괜찮을지도?)
   • create a merge commit

rebase and merge는 개인적으로 신경써줘야할게 너~무 많은 느낌!
(하지만... github에서 제공해주는 옵션들을 잘 찾아보면 괜찮나..?)
나중에 여유가 생기고, 모두가 rebase 및 PR, commit에 대한 단위 얼라인이 된다면 써볼 수도 있지 않을까 기대도 됨!

참고한 링크

• https://inmoonlight.github.io/2021/07/11/Git-merge-strategy/
• https://seosh817.tistory.com/240

Feedback

• feature > release : rebase & merge 로 해보면 좋지 않을까?
  만약 어떤 feature가 못나가게 됐을때 쉽게 roll-back이 가능해서!
• 대규모 conflict : 이럴때는...?
• conflict는 어떻게 나는거지?
• github rebase & merge에서 하면 어떻게 conflict 처리해주는걸까?