git 활용(rebase, squash)방법

현재 우리 회사는 git flow라는 방법론을 통해 branch를 분리하여 개발하고 있다. git flow는 총 5가지의 브랜치를 분리해서 운영한다.
•    master: production브랜치 실사용자들에게 배포됨
•    release: 배포를 하기전 즉 production을 배포하기전에 QA를 하기위한 브랜치.
•    develop: 개발 브랜치 개발자들이 feature브랜치에서 개발, 작업한 기능들을 여기에다 merge시킴
•    feature: 개발자들이 develop에서 feature브랜치를 분리시켜 작업하는 곳
•    hotfix: master 브랜치에서 배포를 하고 서버를 돌리던 중 버그가 생겼을때 긴급 수정할때 사용하는 브랜치(master에서 브랜치를 땀)

 

Rebase & Merge

 

이러한 브랜치들이 존재하고 우리 개발자들이 rebase나 merge할 시 가장 많이 충돌이 날 수 있는 부분이 develop과 feature간의 상호작용에서 일어난다. 
우선 git을 아마 사용해본 사람이라면 branch를 따서 개발을 하는 것 까지는 수월하게 할 수 있으므로 생략하겠다.

그림1. 현재 기존 사용중인 develop에 feature를 따서 개발할 때의 가지모습.
현재 우리는 develop에서 test-1, test-2와 같이 feacture branch를 따서 개발을 진행한다. 그 후 scm에서 pull request를 하고 허가(빌드 성공)가 나게 되면 merge를 통해서 병합한다.
이때 merge만 하게 된다면  아래와 같이 가지가 표현 될 것 이다.

그림2. merge  전.

이런 식으로 가지가 변경되는데 지금은 적은 가지를 가지고 있어 보기에 편하지만 개발인원이 많아지면 많아질수록 복잡해진다. 
 

 그림4. merge만 했을때 복잡한 가지.

 

이러면 추 후에 기록을 찾을 때 매우 찾기 불편해지며 이는 협업 및 생산성이 떨어진다. 그래서 rebase즉 타겟을 하는 base를 기반으로 재구성을 하여 브런치 가지를 깔끔하게 하는 방법이 있다.
여기서 rebase에 관해 간단히 설명하자면

그림5. rebase후 merge(fast-forward)를 통해 깔끔한 브런치 생성 

이런 방법(rebase)를 통해 깔끔한 가지를 만들어 기록 추적을 편하게 할 수 있는 장점이 생긴다. 

 

 

Squash

 

개발자들이 develop에서 브런치를 딴 후 개발을 끝 마치면 develop브런치에 자신이 한 브런치를 rebase and merge한다. 위에서 말한 rebase를 한 후 merge를 하게 된다면 깃의 가지이력이 깔끔해지는 것을 알 수 있다.

그렇지만 이때 feature브랜치에 여러 커밋이 있다면 커밋 수면큼 develop에 커밋이 늘어나게 된다.

 

현재 배달의 민족을 운영중인 우아한 형제들에서는 깃의 커밋 이력을 한 기능당 1개를 권장하고 있으며 이를 추종하는 회사들도 많이 존재한다. 하지만 개발을 하게 되면 한 브런치(기능)에 여러 커밋을 넣는 상황이 많이 생긴다.

이를테면 pull reqeust를 한 후 코드리뷰를 하게 되면 코드를 변경하고 변경한 코드를 또 리팩토링, 수정하여 커밋을 해야한다. (-amend를 통해 변경할 수 도 있다.) 

 

이런 행위를 한 후 develop에 머지를 하게 되면 한 기능에 여러 커밋이 들어 갈 수 밖에 없다. 이런 것들을 깔끔하게 하기 위해 squash라는 기능을 이용한다. 

그림6. 비슷한 커밋들이 많음

 

그림6과 같이 feature/test-1에 비슷한 커밋들을  지금 알려주는 squash 기능을 통해 하나로 합친 후 리베이스를 하게 되면 커밋내역이 더욱 깔끔해진다. 그 외에도 리베이스를 하거나 머지를 할 때 충돌이나는 부분을 많이 줄여줄 수 있다.

 

먼저 squash는 개념이고 따로 명령어가 있진 않다. 

그림7. squash를 시작하는 명령어 

그림8. squash진행과정   

 

git rebase -i HEAD~3을 통해 1~3번째까지의 커밋을 합친다는 명령어이다. 이를 입력 한 후 pick에서 합칠 커밋들 중 하나를 제외한 모든 커밋을 pick→(squash)로 변경한 후 wq!로 저장하면 새로운 커밋내역을 입력하라는 vi창이뜬다 설정후 wq!하면 

squash가 끝이난다.

그림9. squash가 끝이난 브런치

그림9처럼 squash가 끝나게 되면 커밋명령어가 매우 간단해지며 이를 rebase 후 merge를 하게 되면 develop브런치에 매우 간결하게 딱 한 기능의 커밋만 남게 된다. 이는 추후에 브런치 추적을 할 필요도 없어질만큼 간결해진다.

 

현재 유니콘 팀에서는 rebase and merge 방법을 권장하고 있으나 잘 지켜지지 않는다. 그 이유 중 하나는 rebase를 잘 못하게 되면 위험한 상황이 놓인다고 생각하기 때문인데.

나 또한 rebase를 하면서 잘못된 상황을 겪었기 때문에 이 글을 통해 실수를 예방하자.

참고
https://techblog.woowahan.com/2553/      (우아한형제들의 git-flow 이용방식)