한줄 요약 : Rebase를 잘 활용하면 SourceTree의 History를 깔끔하게 관리할 수 있다.
Merge의 문제점
여러 사람이 동시에 작업한 경우에 History가 복잡해진다.
사람이 많아지면 많아질수록 그 정도가 매우매우 심해진다.
실제 내역...
Branch가 어떻게 나뉘고 합쳐졌는지 알아보기 매우 힘들어졌다.
의미 있는 History를 위해서는 Rebase를 시기적절하게 사용해 줄 필요가 있다.
Merge와 Rebase의 차이
이렇게 커밋 2를 분기로 해서 master / testBranch가 나뉘었다. testBranch를 master에 merge해주면?
우리가 일반적으로 아는 것처럼 커밋이 새로 생기면서 합쳐지는 것을 볼 수 있다.
그렇다면 Rebase의 경우에는?
Rebase는 이름 그대로 작업의 Base를 해당 지점으로 옮겨주는 것이다. 여기서는 Rebase로 지정해준 커밋4 뒤에서 작업한 것 처럼 표시된다.
예시
백문이 불여일견.
다음과 같이 커밋1 → 커밋6순으로 진행된 상황에서, 이 브랜치들을 깔끔하게 합쳐보자.
먼저 클라팀의 커밋1, 커밋6 작업 2개를 main에 merge 시킨다고 해보자.
클라팀이 main에 합쳐졌다.
여기서 서버팀, 아트팀 또한 main에 merge 해버리면…?
벌써 부터 History가 꼬이기 시작한다.
따라서 깔끔한 History 관리를 위해 Rebase를 사용할 필요가 있다.
먼저 서버팀의 커밋2, 커밋3을 main에 Rebase 해주자.
Rebase 순서는 다음과 같다.
[A 브랜치]를 [B 브랜치]에 Rebase 하고싶다면
A 브랜치로 이동후 B 브랜치 우클릭 → Rebase(재병합)을 해줘야한다.
지금의 경우에는 [서버팀] 브랜치를 [main] 브랜치로 합쳐야 하므로,
[서버팀] 브랜치로 이동후 [main]을 우클릭 - 재배치(Rebase)를 눌러주면 된다.
서버팀의 커밋2, 커밋3이 main뒤에 깔끔하게 붙었다. 이제 merge해주면 서버팀 브랜치 병합은 끝이난다.
merge해줄 때, 상단 Merge(병합) 탭에 들어가면 다음과 같은 화면이 나온다.
그 후 merge할 브랜치를 선택하고, Create a commit even if merge resolved via fast-forward(fast-forward가 가능해도 새 커밋으로 생성)을 누르면, Rebase한 곳에서 branch를 생성해 작업 후 Merege한 것 처럼 보인다.
branch가 겹치지 않고 깔끔하게 나누어졌다!!! 이전 꼬였던 branch보다 알아보기 훨씬 쉬워졌다.
이렇게 새 커밋 생성을 통해 merge를 이용하면 깔끔한 2줄의 branch들로 프로젝트를 관리할 수 있다.
또한, 새 커밋 생성을 하지 않고도 main branch로 이동한 후 가져올 branch를 우클릭 - merge(병합)로 바로 합쳐줄 수도 있다.
아트팀은 한번에 합쳐보겠다.
똑같이 아트팀 브랜치로 이동후, main에 rebase해준다.
그 뒤에 main으로 이동 후 아트팀 브랜치를 merge 해 온다.
안 쓰는 클라팀, 서버팀, 아트팀 브랜치를 모두 지워 주면 완성. 내친김에 push도 해보자.
깔끔한 Branch에 저절로 기분이 좋아진다.
주의점
커밋 시간이 Rebase를 했을 때 기준으로 바뀐다.
따라서 소스 트리상의 작업 시간이 실제 작업시간과 맞지 않을 수 있다.