[Git] branch 관리: merge vs rebase

#Git

이건 개인 간의 호불호가 좀 있는 부분이다.

내가 한 작업을 메인 브랜치에 병합하거나, 다른 사람이 작업한 것을 내 작업으로 가져오려면 어떻게 해야 할까?
여기에는 크게 2가지의 방법이 있다.

일반 merge

git merge는 가장 기초적인 브랜치 결합 방법이다.

브랜치를 다른 브랜치와 결합하는 것 자체를 하나의 커밋으로 간주하고 생성한다.

기존 커밋들을 건드리거나 변조하지 않기 때문에 리스크가 적고 투명하다는 장점이 있다.

단점은... 커밋 히스토리가 지저분해질 수 있다는 것이다. 순수한 작업 내역과 별개로, 머지커밋이 섞여서 보이기 때문이다.

위 사진의 경우에는 그냥 작업단위 merge만 있어서 그나마 낫다.
merge를 써서 메인브랜치의 최신사항을 내 브랜치에 동기화하는 빈도가 높아진다면 진짜 더러워질 수 있다.

그래서 저런 머지 범벅을 꺼리는 경우에는, rebase를 이용하는 것을 선호한다. 머지커밋을 쌓지 않고 선형적으로 커밋 히스토리를 관리하는 것이다.

마치 한 사람이 단일 브랜치에 다 push한것처럼.

그리고 이 rebase란 것은 커밋 히스토리를 조작하고 변조하는 종류의 명령이다.

만약 다른 사람의 작업을 내 브랜치로 가져오고 싶다면, 혹은 최신사항을 동기화하고 싶다면 "git rebase origin/브랜치"의 명령을 사용할 수 있다.

그러면 머지커밋을 쌓지 않고 내가 작업한 커밋을 최신으로 미뤄서 재생성해버린다!
커밋 해시도 바뀌기 때문에 사실상 커밋을 다시 쓰는 것이나 다름 없긴 하지만, 커밋이 지저분하게 남지는 않는다는 장점이 있다.

내가 작업한 결과물을 메인 브랜치에 머지할 때도 rebase merge를 사용할 수 있다.
이러면 머지커밋을 쌓지 않고 커밋 자체를 메인 브랜치에 쑤셔넣어버린다.

단, 이러면 해당 작업 단위의 히스토리를 알기가 어려워서 커밋메세지에 추적 가능한 이슈 번호 등을 적는 것이 권장된다.

squash merge는 rebase merge와 원리는 거의 같다. 그냥 커밋들을 단일커밋으로 뭉개서 넣는게 다를 뿐이다.

단점

rebase가 정말 깔끔하고 좋긴 한데, 커밋해시가 변조된다는 것이 끔찍한 부작용으로 돌아올 때도 있다.

작업한 브랜치가 일회성 브랜치라면, 그냥 rebase merge를 해버리고 브랜치를 파괴하면 아무 문제가 없다.

근데 생명주기가 있는 브랜치끼리 rebase를 남발하면 문제가 좀 생길 수도 있다.
커밋을 다시 만드는 것이라서, 실제로는 같은 커밋이지만 다르다고 판단돼서 곤란한 충돌이 발생할 수 있기 때문이다.

이럴때는 그냥 merge를 써서라도 커밋을 유지해서 동질성을 보존해야 한다.

아무튼 내 경우에는 rebase를 기본으로 쓰되, 필요한 경우에만 merge를 쓰는 것이 좋다고 생각한다.