Merge
는 합병
이라는 뜻으로, 서로 다른 브랜치를 병합하여 작업한 내용을 합치는 것을 의미합니다.
예를 들어 feature
브랜치에서 구현 완료한 기능에 대한 코드를 develop
브랜치로 합치고 싶다면 Merge
를 이용하면 됩니다.
어라 그런데 머지를 하러 왔는데 종류가 3가지나 있네요..!
무슨 말일까요?
PR branch
와 base branch
의 변경 내용을 하나의 새로운 병합 커밋으로 합칩니다.base branch
에 추가되어 변경 내용을 별도로 추적할 수 있게 합니다.base branch
에 항상 추가되므로 변경 내용의 흐름을 추적하기 쉽습니다.PR
에 존재하는 모든 커밋
들을 1개의 commit
으로 결합하여 base branch
로 머지합니다.
많은 커밋 기록들을 하나의 커밋으로 묶어서 관리하기 위한 머지 전략입니다.
PR branch
의 변경 내용을base branch
위에 재배치(rebase) 합니다.PR branch
의 커밋들을 base branch
의 최신 커밋 위로 이동시키는 작업을 수행합니다.rebase
를 사용하면 PR branch
의 커밋 히스토리가 원본 브랜치로 통합되므로, 변경 내용의 흐름을 추적하기 어려울 수 있습니다.일련 변호(id)
를 가지고 있습니다.사실 글만으로 두 머지의 차이가 잘 이해가 되지 않으셨을 것이라 생각합니다.
그래서 어떤 블로그에서 괜찮은 비교 자료를 찾아 가져와봤습니다.
본인이 작업 중인 feature/b
브랜치와,
팀원이 작업하고 merge한 feature/a
브랜치가 있다고 가정합니다.
이 상황에서 제가 작업한 feature/b
를 develop
브랜치에 merge commit
했을 때와 rebase and merge
했을 때의 차이를 비교해보겠습니다.
Create a Merge Commit
은 일반적인 merge만 하는 경우를 의미하기 때문에
merge라고 부르겠습니다.
우선 merge
를 했을 경우입니다.
feature/b
의 변경사항을 develop
브랜치에 그대로 합쳐버립니다.
정말 극단적인 예시이지만 정말 많은 브랜치들이 계속해서 merge
되다보면
이렇게 지저분한 커밋 로그가 되어버립니다.
다음은 rebase and merge
를 한 경우입니다.
rebase
를 한 후 merge
하는 두 과정을 묶은 설정입니다.
우선 rebase
가 뭔지 이해해야겠지요.
위 이미지는 Master
브랜치에 Feat
브랜치를 Rebase
하는 경우 어떻게 동작되는 지 보여주는 이미지로 Rebase and merge
기능 중, 아직 merge
하지 않은 단계입니다!
PR branch
의 커밋들을 base branch
의 최신 커밋 위로 이동시키는 작업을 뜻하는 rebase
는 이렇게 동작합니다.
이제 좀 이해가 가시나요?
git checkout feature/b
git rebase develop
명령어도 그렇게 어렵지 않은데요.
위의 명령어를 통해 feature/b
브랜치를 develop
브랜치에 rebase
할 수 있습니다.
이제 다시 이미지를 보겠습니다.
feature/b
브랜치의 분기점이 분명 feature/a
와 같았지만 rebase and merge
를 하자 develop
브랜치의 마지막 변경사항에서 줄기가 새로 뻗어져 나온 뒤에 merge
되는 것을 확인할 수 있습니다.
이렇듯 실행시켰을 때, 어떤 브랜치 위에 변경사항을 새로 올려버려서 깔끔하게 커밋 로그를 관리하는 방법 중 하나가 바로 rebase
입니다.
저는 2개의 커밋을 하나의 커밋으로 합쳐서 관리하고자 Squash merge
를 진행해보겠습니다.
Squash and merge
선택
커밋 메세지
입력
종료된 이슈는 Close issue
로 닫아줍니다.
위와 같이 목표로 등록해둔 Issue
가 Close되자,
Projects
에 이슈의 상태가 Done
으로 변경되었고Milestone
이 100% complete 되었음을 확인할 수 있습니다.이번 시간에는 각 브랜치의 작업 내용을 합치는
합병(Merge)
에 대해 알아보았습니다.다음으로는
PR
,Issue
등의 생성을 더욱 편리하게 만들어줄
Github Template
에 대해 알아보겠습니다.