[git] squash 병합 후 pull request시 이전 병합된 커밋이 보이는 오류 해결 전략

Create a merge commit

A - B ------------- BC123 [master]
     \            /
      C1 - C2 - C3 [feature]

B를 base로 하는 feature 브랜치에서 C1,C2,C3 커밋을 생성 후 Create a merge commit 실행 시

C1,C2,C3을 참조하는 BC123이 생성되고 BC123을 통해 C1,C2,C3가 master에 추가된다.BC123은

master,feature 2개의 parent를 가진다.

A - B ------------- BC123 - C45 [master]
     \              /    /
       C1 - C2 - C3 - C4 - C5 [feature]

C4,C5커밋이 feature에 추가되었을때 BC123커밋은 C3,B 2개의 parent를 가지고 있기에 C4,C5가

C3이후 추가되었음을 알 수 있는 히스토리가 있다. 따라서 feature브랜치에 C4,C5커밋을 추가로 생성 후

풀리퀘스트를 생성 시 Git은 마스터에 없는 C4,C5커밋만 보여준다.

A - B ------------- BC123 [master]
     \
      C1 - C2 - C3 [feature]

B를 base로 하는 feature 브랜치에서 C1,C2,C3 커밋을 생성 후 Squash and merge를 실행 시 C1,C2,C3

을 하나의 BC123커밋으로 마스터 브랜치에 생성한다. BC123커밋의 1개의 부모 B만 존재한다.

A - B ------------- BC123 - C45 [master]
     \
      C1 - C2 - C3 - C4 - C5 [feature]

C4,C5커밋이 feature에 추가되었을때 BC123커밋은 B 1개의 parent를 가지고 있기에 C4,C5가

C3이후 추가되었음을 알 수 있는 히스토리가 없다. 따라서 feature브랜치에 C4,C5커밋을 추가로 생성 후

풀리퀘스트를 생성 시 Git은 C1~C5의 커밋을 전부 보여준다.하지만 git은 브랜치간 중복된 내용을 잘 처리하기에 실제로 커밋된 내용은 C4,C5뿐이다.

squash & merge는 간단하고 히스토리를 합쳐 깔끔하게 처리할 수 있지만 merging이 git에게 히스토리등 더 많은 정보를 제공한다.
squash & merge시 feature브랜치 삭제 후 master로 부터 새로운 브랜치를 생성해야 풀리퀘스트 시 병합된 커밋 내용을 중복적으로 보여주지 않는다.
따라서 dev ⇒ master브랜치 병합시 dev브랜치는 삭제할 수 없기에 merging or rebase 방식의 병합이 필요하다.

참조