[Github 협업, 이것만은 알자] - Merge

pgmjun·2023년 10월 8일
3
post-thumbnail

Merge란?

Merge합병 이라는 뜻으로, 서로 다른 브랜치를 병합하여 작업한 내용을 합치는 것을 의미합니다.

예를 들어 feature 브랜치에서 구현 완료한 기능에 대한 코드를 develop 브랜치로 합치고 싶다면 Merge를 이용하면 됩니다.

어라 그런데 머지를 하러 왔는데 종류가 3가지나 있네요..!

무슨 말일까요?


🤔 Create a merge commit

  • 이 옵션을 선택하면 GitHub는 PR branchbase branch의 변경 내용을 하나의 새로운 병합 커밋으로 합칩니다.
  • 이 병합 커밋은 base branch에 추가되어 변경 내용을 별도로 추적할 수 있게 합니다.
  • 이 방법을 사용하면 변경 내용이 base branch에 항상 추가되므로 변경 내용의 흐름을 추적하기 쉽습니다.
  • 하지만 이렇게 병합하면 커밋 히스토리가 더 복잡해질 수 있고, 다수의 작은 병합 커밋이 쌓일 수 있습니다.

🤔 Squash and merge

PR에 존재하는 모든 커밋들을 1개의 commit으로 결합하여 base branch로 머지합니다.

많은 커밋 기록들을 하나의 커밋으로 묶어서 관리하기 위한 머지 전략입니다.


🤔 Rebase and merge

  • 이 옵션을 선택하면 GitHub는 PR branch의 변경 내용을base branch 위에 재배치(rebase) 합니다.
    즉, PR branch의 커밋들을 base branch의 최신 커밋 위로 이동시키는 작업을 수행합니다.
  • 이렇게 하면 커밋 히스토리가 더 선명하고 단순해질 수 있습니다.
  • 그러나 rebase를 사용하면 PR branch의 커밋 히스토리가 원본 브랜치로 통합되므로, 변경 내용의 흐름을 추적하기 어려울 수 있습니다.
  • 리베이스된 커밋들의 일련 번호가 바뀔 수 있으므로, 기존의 커밋 히스토리가 수정됩니다.
    • 모든 커밋들은 구분을 위한 일련 변호(id)를 가지고 있습니다.


🔑 Rebase and merge와 Create a Merge Commit의 차이

사실 글만으로 두 머지의 차이가 잘 이해가 되지 않으셨을 것이라 생각합니다.

그래서 어떤 블로그에서 괜찮은 비교 자료를 찾아 가져와봤습니다.

본인이 작업 중인 feature/b 브랜치와,
팀원이 작업하고 mergefeature/a 브랜치가 있다고 가정합니다.

이 상황에서 제가 작업한 feature/bdevelop 브랜치에 merge commit했을 때와 rebase and merge했을 때의 차이를 비교해보겠습니다.



💭 Create a Merge Commit

Create a Merge Commit은 일반적인 merge만 하는 경우를 의미하기 때문에
merge라고 부르겠습니다.

우선 merge를 했을 경우입니다.

feature/b의 변경사항을 develop 브랜치에 그대로 합쳐버립니다.


⚙️ Create a Merge Commit의 단점

정말 극단적인 예시이지만 정말 많은 브랜치들이 계속해서 merge되다보면
이렇게 지저분한 커밋 로그가 되어버립니다.



💭 Rebase and Merge

다음은 rebase and merge를 한 경우입니다.

rebase를 한 후 merge하는 두 과정을 묶은 설정입니다.


⚙️ Rebase 동작 구조 예시

우선 rebase가 뭔지 이해해야겠지요.

위 이미지는 Master 브랜치에 Feat 브랜치를 Rebase 하는 경우 어떻게 동작되는 지 보여주는 이미지로 Rebase and merge 기능 중, 아직 merge하지 않은 단계입니다!

PR branch의 커밋들을 base branch의 최신 커밋 위로 이동시키는 작업을 뜻하는 rebase는 이렇게 동작합니다.

이제 좀 이해가 가시나요?


⚙️ 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로 닫아줍니다.


⚙️ Projects와 Milestone 확인


위와 같이 목표로 등록해둔 IssueClose되자,

  • Projects에 이슈의 상태가 Done으로 변경되었고
  • Milestone100% complete 되었음을 확인할 수 있습니다.


✅ 다음으로

이번 시간에는 각 브랜치의 작업 내용을 합치는 합병(Merge)에 대해 알아보았습니다.

다음으로는 PR, Issue 등의 생성을 더욱 편리하게 만들어줄
Github Template에 대해 알아보겠습니다.

profile
하나씩 천천히 깊이있게 쌓아가는 백엔드 개발자 최승준입니다.

0개의 댓글