들어가며
git에 대한 지식이 아직 많이 부족하다고 느껴, git과 gitHub로 협업하는 방식에 대해서 공부했다. 마침 소프트웨어공학 수업에서 git merge에 대해 공부하고 있어서 정리해보고 싶었다.
준비
먼저 git init 후에 f.txt 파일을 생성하고 최초의 커밋을 생성했다.
$ mkdir gitDemo $ cd gitDemo $ git init $ touch f.txt $ git add . $ git commit -m "f created"
보통 master 브랜치는 배포를 하기 때문에, 작업을 여기서 수행하지는 않는다. 새로운 브랜치 develop을 만들고, 거기서 작업을 수행할 것이다.
브랜치를 만들고 파일을 수정한다.(작업을 수행한다.)
$ git branch develop $ git checkout develop $ vim f.txt //f를 적당히 수정 후 저장(작업 수행) $ git add . $ git commit -m "f modified on develop"
이렇게 develop 브랜치에서 작업을 수행한다. (실제 상황이라면 커밋도 더 많고 실제 시간도 더 흘렀을 것이다.)
develop 브랜치에서 원하는 작업을 다 수행하고, 배포를 하고 싶어졌다. 그렇다면 master 브랜치에 merge를 해줘야하는데, 이때 두가지 경우의 수가 있고, 사용가능한 방법이 다르다.
1. develop 브랜치가 시작된 커밋(f created)부터 현재까지 master 브랜치에 아무런 변화가 없었다.
Fast-Foward 방식
이 경우에는 간단하게 master 브랜치에 합병할 수 있다. 이때 사용하는 merge 방식을 Fast-Foward 방식이라고 부른다.
2. develop 브랜치가 시작된 커밋부터 현재 사이에 master 브랜치에 새로운 커밋이 생겼다.
이 경우가 문제다. 협업을 하며 내가 무언가를 개발하는 사이에 다른 개발자가 master 브랜치에 커밋을 한것이다. 이 경우에는 Fast-Foward 방식을 사용할 수 없다. 대신 두가지 방법이 있다.
Squash & merge 방식
이 방식은 develop 브랜치의 모든 변경 사항을 하나의 커밋으로 합쳐서(squash) master에 merge하는 방식이다.
장점은 develop 브랜치의 자잘한 커밋들을 모두 하나로 합치기 때문에 로그가 깔끔하게 남는다.
단점은 모든 커밋이 하나로 합쳐지기 때문에 문제가 발생하거나 기존 커밋을 확인하기 어렵다.
Rebase & merge 방식
이 방식은 develop 브랜치의 모든 커밋을 master 브랜치에 그대로 올리는 방식이다. develop 브랜치의 시작점(base)를 master의 가장 최신 커밋으로 바꾸기(re) 때문에 Rebase라고 불린다.
장점과 단점은 Squash & merge 방식과 정반대다.
로그가 길게 남기 때문에 나중에 모든 커밋을 확인할 수 있고, 때문에 지저분해질 수 있다.
세가지 방식을 알았으니 이제 실제로 한번 해보자.
Fast-Foward
master 브랜치에 다른 변경사항은 없기 때문에 바로 merge 하자.
$ git checkout master $ git merge develop
너무나 간단하게 merge가 끝나버렸다. master 브랜치는 이제 develop 브랜치의 커밋이 업데이트 되었다. 이후에 develop 브랜치를 삭제할지 아니면 계속 사용할지는 선택하면 될 것 같다.
Squash & Merge
Squash & Merge를 위해 master 브랜치에 변화를 줘보자. master 브랜치에서 파일을 수정하자.
$ git checkout master $ vim f.txt //f를 적당히 수정 후 저장(작업 수행) $ git add . $ git commit -m "f modified on master"
난 이 상황이 너무 무서웠다. 기존 merge가 제대로 작동을 안해서 버벅였다. 한번 Squash & Merge를 사용해보자.$ git checkout master $ git merge --squash develop
그랬더니 이런 메시지가 떴다. 이렇게 뜬다면 아래 내용을 실행하고, 아니라면 squash 커밋하는 부분부터 실행하면 된다.
자동병합에 실패했을 경우
자동 병합이 실패한 것인데, f.txt에 들어가면,
이렇게 파일이 바뀌어있다.
<<<<<<<master 부터 =======까지는 합병의 기준이 되는 브랜치의 내용이고, 그 후로는 합병할 브랜치의 내용이다. 이를 잘 수정해서 원하는 결과물을 만들자.
이렇게 파일을 잘 수정해주고, 이제 Squash할 커밋을 치면 된다.
$ git add . $ git commit -m "sqaush merge"
이렇게 squash & merge가 잘 되었다. 이후에 develop 브랜치는 삭제하거나 그대로 유지하면 된다.
Rebase & Merge
Squash & Merge와 똑같은 상황을 만들어 주었다.
이 상황에서 Rebase를 해야 한다.$ git checkout develop $ git rebase master $ git checkout master $ git merge develop
이렇게 develop의 커밋들이 잘 rebase되어 master 브랜치에 올라가 있는 것을 볼 수 있다.
정리
이렇게 세가지 Merge를 모두 사용해보았는데, 각각 어디에 사용해야 할까? 먼저 Squash랑 Merge의 방식을 설명하면서 master 브랜치에 새로운 커밋이 생겼을 경우 사용할 수 있다고 말했지만, 사실 새로운 커밋이 없어도 사용가능하다.
정답은 없겠지만 난 두가지 경우로 정립하려고 한다.
Rebase & Merge
= 커밋내역을 다 유지하고 싶은 경우
= 하나하나의 커밋들이 중요한 경우
= Develop 브랜치 같이 굵직한 브랜치는 해당 방법을 사용한다.Squash & Merge
= 커밋내역을 없애고 깔끔하게 만들고 싶은 경우
= 하나하나의 커밋들이 중요하지 않은 경우
= feature 브랜치 같이 작은 기능 추가하는 브랜치는 해당 방법을 사용한다.
Fast-Foward는 사용하지 않는 것이 좋을 것 같다.
이 글은 다음 글들을 많이 참고했다.
https://velog.io/@marksen/Git-Branch%EC%99%80-Merge
https://hudi.blog/git-merge-squash-rebase/
