Git - rebase 하는 법 (어떤 상황에서 rebase를 사용하나?)

개발경력이 적은 것에 비해 상대적으로 git을 많이 다루어봤다고 생각하고 있었지만,

최근에 되서야 의미만 알고 있던 rebase를 프로젝트에서 필요하게 되었던 적이 생겼습니다.

 

rebase가 무엇인지 모르시는 분께서는 먼저 아래 git 사이트에서 rebase를 이해하시고 오길 바랍니다.

 

https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-Rebase-%ED%95%98%EA%B8%B0

Git - Rebase 하기

 

※ 참고로 해당 포스팅은 rebase를 사용할 만하였던 개인적인 상황에 대해서 담고 있습니다.

 

  Before Rebase

위 사진을 보시면 master branch와 중간에 머지를 한 번 했는데, 1번 브렌치가 머지한 커밋에서 시작하지 않고 그대로 이어가고 있습니다.

 

이럴 경우 커밋의 히스토리가 서로 일치하지 않아서 꼬일 위험이 있습니다. 하지만 저의 경우, 병합 이후에는 작업 테스트를 할 수 없는 상황이라 테스트를 할 수 있는 이전 커밋에서 특정 스크립트만 바꾸는 작업을 하여 1번과 같이 커밋을 진행한 것입니다.

 

병합과 관련없는 특정 스크립트만 건드린다면 후에 cherry pick으로 충분히 작업을 가져다 붙힐 수 있기에 저렇게 하였는데, 저 1번 브렌치의 커밋들을 저는 병합 이후 작업인 3번 브렌치의 작업에 갖다 붙힐 생각이었습니다.

 

사진을 보면 1번 브렌치의 커밋이 2개죠? 막상 cherry pick를 할 커밋이 몇 개 없으면 상관 없겠지만, 10개가 넘어가기 시작하면 일일히 cherry pick 하는 것도 꽤 버거울 거라고 생각됩니다... ㅡㅡ

 

이렇게 cherry pick 과정이 많아져서 브렌치의 규모가 커질 때 rebase를 사용하면 좋겠구나! 라고 생각했어요.

 

'1번 branch' rebase onto '3번 branch'

rebase를 사용하면 사진의 빨간색 표시되어있는 공통적인 히스토리 이후의 1번 브렌치의 작업들을 3번 브렌치에 추가해줄 수 있기 때문에 만약 지금처럼 커밋이 2개가 아니라 몇십개가 되었다면 더 효율적인 rebase가 될 수 있었겠지요.

 

저는 rebase를 개념만 알고 있었지 막상 이렇게 필요한 상황이 닥친 적은 크게 없었기에 이번 상황을 맞닥뜨리면서 rebase의 소중함을 처음으로 느끼게 되었어요.

 

저렇게 병합 후에도 병합 이전의 커밋에서 이어나가는 상황을 최대한 안만들려고 하는 습관이 있기도 하고, 그럴 일도 크게 없었지만, 이번 경우에서는 병합 이후에 변경된 사항들 때문에 작업중인 코드를 테스트 할 수 없었기 때문에 어쩔 수 없이 위와 같은 상황이 나올 수 있음을 깨달았다는게 중요한 것 같아요.

 

저의 경우에는 개발경력이 별로 되지 않기에 이러한 간단한 상황에서 rebase를 사용하였지만, 실제 경력자분들은 어떤 상황에서 꼭 rebase가 필요할지도 궁금하네요.

 

부족한 것이 있거나 잘못된 부분이 있다면 댓글로 남겨주시면 감사하겠습니다!