[GitKraken] Rebase로 커밋 히스토리 깔끔하게 정리하기(3개 브랜치 연속으로 merge 시키기)
상황
브랜치 3개를 develop에 모두 merge해야 하는 상황이었고, Rebase를 이용하여 커밋 히스토리를 깔끔하게 만들고자 했다.
아래는 merge하기 전, GitKraken의 커밋 히스토리 상태이다.
브랜치 자체를 dev에 Rebase하는 건 간단하지만, 위 브랜치 B, C는 dev에서 생성한 것이 아니고 B는 A에서, C는 B에서 순차적으로 생성한 것이라 상황이 조금 복잡하다.
이렇게 여러 브랜치를 순차 생성한 상황일 때는 어떤 순서와 과정으로 dev에 merge해야 하는지 기록하기 위해 글을 작성하게 되었다.
⬇️ 브랜치를 Rebase하는 방법은 아래 포스팅에 써놓았다.
[GitKraken] 브랜치를 원격 develop에 Rebase 하는 방법
상황dev에서 feature 브랜치를 생성하여 작업 중이었는데, 팀원이 다른 브랜치를 dev에 merge 시킨 상황이다. 오래된 코드에서 계속 작업하는 것보다는 최근에 올라온 코드로 업데이트시키는 게 좋
suoop.tistory.com
과정
1. Merge 순서 정하기
dev에 merge하는 순서는 A -> B -> C 순을 추천한다.
C가 갖고 있는 코드는 A, B, C가 누적된 것이기 때문에, C부터 merge하게 되면 충돌하는 코드양이 많아진다.
그리고 A와 B에 있던 충돌까지 한 번에 해결해야하기 때문에, 브랜치를 나눈 의미도 없어진다.
따라서 A부터 merge하여 순차적으로 충돌을 해결하는 것이 좋다.
2. A를 Merge 하기
A를 dev에 merge시키면, origin/dev가 커밋 히스토리 맨 위로 올라오게 된다.
로컬 dev도 원격 dev로 업데이트 해준다.
3. B를 Rebase 하기
그 다음 B 브랜치로 이동한다.
[develop] 우클릭 - [Rebase refactor/order-response onto develop] 클릭한다.
*refactor/order-response 브랜치가 B 브랜치에 해당한다.
그러면 이렇게 B브랜치가 dev 앞에 위치하게 된다. 바로 Push를 해준다.
그러면 이렇게 B브랜치에 있던 커밋들이 dev 위로 깔끔하게 이동된다. Rebase 끝!
⬇️ B를 Rebase하지 않고 바로 dev에 merge해버리면, 이렇게 커밋 히스토리가 꼬여버리는 참사가 벌어질 수 있다.
그러나 꼭 Rebase하는 것이 정답은 아니다.
브랜치 병합에는 Merge, Squash & Merge, Rebase & Merge 등 다양한 방법이 있으므로, 상황에 따라 선택하는 것이 좋다.
이에 대해서는 추후 포스팅할 예정이다 !
4. B를 merge 하기
B를 Rebase 해줬으니 바로 dev에 merge 해준다.
방법은 A를 merge 했을 때와 똑같다.
이후에는 다음과 같이 진행해주면 된다. 방법은 위에서 했던 과정과 똑같다 !
5. C를 dev 기준 Rebase
6. C를 dev에 merge
결론
이렇게 3개의 브랜치를 순차적으로 Rebase & Merge 하게 되면 아래와 같이 커밋 히스토리가 깔끔해진다!
중요한 것은 'Merge하는 순서'다.
만약 내가 A - B - C 와 같이 브랜치를 연속적으로 생성한 상황이라면, 처음에 생성했던 브랜치(A)부터 merge 시켜야 한다.
최근에 생성한 브랜치(C)부터 merge하면 누적된 코드에서 한꺼번에 충돌이 일어나기 때문에, 이를 해결하기가 쉽지 않다.