[Git] Merge 별 차이

공부하게 된 계기

협업을 다시 진행하면서 팀 컨벤션을 일치시키려고 노력한다.
자유 분방하게 작성하여 여러명이 작성한 것이 티나는(?) 과거의 버릇을 고치고 후에 봐도 무슨 코드를 작성했는지 알 수 있도록 틀을 정하고 있었다.

하지만 Git 브랜치 규칙에서 해당 규칙을 추가하니 본래 뜨던 merge가 아닌 Squash and Merge 라는 옵션이 뜨게 되었고 해당 Merge들의 차이점을 알아보고 작성해보려고 한다.

기본 전제
Master 에는 a-> b-> c 가있고
새로운 my-part 에는 d-> e-> f가있다.

Merge 규칙 별 차이

Merge

기본 merge

$ git checkout master
$ git merge my-part

해당처럼 master branch 에 작성했던 커밋 d-> e-> f가 차례로 추가 되었다.
그리고 merge 메세지 역시 뜬다.

결론 (master)
a->b->c->d->e->f->merge message

Squash and Merge

feature 브랜치의 커밋내역을 합쳐서 깔끔하게 만들기 위해 사용

$ git checkout master
$ git merge --squash my-part
$ git commit -m "DEF"

결론(master)
a->b->c->"DEF" 라고 적혀진 3개가 합쳐진 1개의 커밋

Rebase and Merge

Merge 방식과 비슷하지만 합쳐지지 않고 각각 master에 추가된다.
(하나하나가 개별적으로 가서 순서대로 합쳐지는 형식)

$ git checkout my-part
$ git rebase master
$ git checkout master
$ git merge my-branch

Merge와 다르게 통합이 안되기 때문에 Merge 메세지는 볼 수 없다.

결론(master)
a->b->c->d->e->f

Merge 방법 사용 팁

꼭 한가지 방법만을 전체적으로 사용할 필요는 없습니다.
Git flow

1. develop - feature : Squash and Merge

• 기능별로 묶어서 develop에서 독자적 관리 가능
• feature 은 어차피 삭제되어서 직접 연관해서 관리할 필요 없음

2. master - develop : Rebase and Merge

• 개발환경에서 운영환경으로 갈때는 보통 새로운 커밋을 생성할 필요가 없기 때문
• 에러가 있으면 hotfix 브랜치사용

3. hotfix - develop: Merge or Squash and Merge

• 커밋 히스토리의 필요여부에 따라 다를것 같다.

결론

Merge라는 방법은 같지만 누군가에게 보여주거나 이후에 변경점을 찾을 때 깔끔하게 보이는 방법은 다른 것같다.

하지만 무조건적인 깔끔함보다는 해당 merge 의 차이점을 알고 필요한 변경점을 유지하면서 깔끔하게 유지하는 것이 좋을 듯하다.

현재 토이프로젝트는 develop 와 main으로 이루어져있으니 오늘 배운 것을 참고하여 Squash and Merge 와 Rebase and Merge 를 활용해야겠다.

Reference

https://meetup.nhncloud.com/posts/122
https://im-developer.tistory.com/182
https://blog.jetbrains.com/space/2023/04/18/space-git-flow/