rebase - 1
개요
현재 진행 중인 프로젝트에서는 기본적으로 브랜치 두개에 개발용 브랜치를 그때그때 만들어서 쓰다 지우길 반복하는 방식으로 개발하고 있습니다. 기본 브랜치는 깃허브와 연동된 시크릿 키가 포함되지 않은 것 하나, 다른 하나는 AWS Elastic Beanstalk 연동용 브랜치 두 개를 사용하고 있습니다. merge할 때마다 시크릿 키가 충돌이 일어나서 고생했었는데 rebase를 통해 이 문제를 해결할 수 있었습니다. 이 글에서는 rebase가 뭔진 아주 간단히 알아보겠습ㄴ디ㅏ.
rebase란?
rebase는 말 그대로 base를 다시 만드는 것입니다. 다음과 같은 git flow가 있다고 가정합시다.
(위가 branch1, 아래가 branch2이다)
merge를 하는 경우 다음과 같은 방식으로 이루어집니다.
git checkout branch1
git merge branch2
merge한 새 커밋이 만들어지고, 충돌이 일어난 경우 이를 직접 수정하여 새로 만드는 방식입니다.
merge를 하는 경우 다음과 같은 방식으로 이루어집니다.
git checkout branch1
git merge branch2

그러나 rebase는 다음과 같은 방식으로 이루어집니다.
git checkout branch2
git rebase branch1
여기까지 진행된 상태에서는 branch1은 C3-1을 branch2는 C3-2를 가리키고 있습니다. 그러나 merge와 다른 점은 branch2의 base가 C2가 아닌 C3-1이 되었다는 것입니다. branch2의 base를 1의 것으로 맞추어버린 셈입니다. 그래서 이름이 rebase가 된 것이죠. fast-forward-merge를 통해 두 브랜치를 모두 C3-2에 맞추었다면 둘 중 하나를 지워도 무방합니다. 깔끔하죠.
활용
rebase는 merge에 비해 여러 장점을 가지고 있습니다. 우선 깔끔하다는 점입니다. 여러 가지가 뻗어 복잡한 flow를 한 줄로 깔끔하게 정리할 수 있습니다. 또한 여러 feature 개발을 동시에 진행 중일 경우 merge보다 굉장히 쉽게 feature 통합이 가능합니다. 저 같은 경우도 매번 시크릿 키가 충돌나던 부분이 rebase를 통해 정리한 이후로 충돌이 나지 않습니다. 여러모로 매우 편리한 기능이라고 할 수 있습니다. rebase는 사실 이것보다 훨씬 더 심오하고 복잡하지만 제가 그것을 글로 정리할 만큼에는 부족하기도 하고, 너무 길어지기도 하므로 다음에 그 부분을 작성해 보도록 하겠습니다.
참조
https://junwoo45.github.io/2019-10-23-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
Author And Source
이 문제에 관하여(rebase - 1), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@maintain0404/git-rebase-1저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)