서비스가 여러 프로젝트와 연관되고 다수의 사람들이 기능 개발에 참여하게 되면 아래와 같은 Git Commit Graph를 만나기 시작합니다.
여러 프로젝트와 연관된 서비스의 git commit history
이 중에서 쉽게 적용해 볼 수 있는 것이 Merge 방식을 변경하는 것입니다.
팀 내에 적용 중인 Merge 규칙이 없었기에 나라도 일관되게 Merge를 하고자 MR(Merge Request)이 develop branch로 Merge 될 때 squash merge를 적용하기로 했습니다.
github PR 에서는 3가지 머지 방법을 제공합니다. (Create a merge commit, Squash and merge, Rebase and merge)
rebase merge 방식을 먼저 적용해보았지만 프로젝트의 단위가 크다는 팀의 특성상 Commit 자체를 정리하는 방식이 필요했습니다.
squash merge란?
개발과정에서 생성된 여러개의 commit들을 merge시에 하나로 묶어 1개 commit만을 남기는 병합 방식을 말합니다. 각각의 commit들이 보관되지 않기 때문에 코드리뷰 전이나, history 관리가 중요한 프로젝트에서는 주의해야 합니다.
필자는 평소에 git cli + intellij 조합을 사용하고 가끔 SourceTree를 사용하고 있어서, 이 글에서는 각각의 도구에서 squash merge를 하는 방법을 알아보겠습니다.
1. Git Cli
git init
touch README.md
git add README.md
git commit -m "add README.md"
git checkout -b feature/A
touch featureA.java
git add featureA.java
git commit -m "add featureA.java"
vim featureA.java
git add featureA.java
git commit -m "modify featureA.java"
git checkout master
git merge --squash feature/A
feature/A branch 에서 2개의 커밋을 생성 후 master branch 에서 squash merge하는 방식입니다.
2. Intellij
master branch 에서 동일한 작업으로 feature/B branch를 생성해준 뒤 VCS > Git > Merge Changes… 기능을 사용합니다.
3. SourceTree
지금 진행하고 있는 예제에서는 fast-forward merge가 일어나기 때문에 SourceTree에서 squash merge를 하기 위해서는 merge 후에 commit message를 rebase로 정리해줘야 합니다.
하위 요소 대화식 재배치(rebase -i)를 통해서 필요한 commit 메시지만 남기고 수정하는 방식으로 squash merge를 적용해볼 수 있습니다.
마무리
간단하게 각각이 도구로 squash merge 하는 방법을 알아보았습니다만, 한가지 신경쓰이는 것은 Graph가 이동해오지 않는다는 점입니다. 필자는 아래의 순서로 Merge를 진행합니다.
- MR 등록, 코드리뷰 시작
- 리뷰 완료
- git cli 방식의 Squash Merge
- MR close
MR merge가 아니라 close를 하는 이유는 Graph가 연결되지 않아서 gitlab의 MR 상에서는 merge된 상태가 아니기 때문입니다.
다음번에는 Graph가 연결되면서, MR 상에서의 comment도 유지되는 방법에 대해서 알아보겠습니다.