[Git] Git branch 전략 (부제: branch 병합 방법 merge, rebase, squash)

git을 사용해 버전을 관리하고, 여러 팀원들이 함께 작업을 하려면 branch 관리를 잘 하는 것이 중요하다.

개인 repositoy라면 커밋에 문제가 생기거나 브랜치가 잘못됐을 때 도저히 안되면 마음대로 삭제하거나 수정할 수 있지만,

함께 작업하던 repository는 마음대로 수정하기가 어렵다.

 

그래서 처음부터 명확한 git branch 전략을 세우고, 다 같이 잘 지켜나가는 것이 중요하다.

오늘은 git-flow를 활용한 우리 팀의 전략과, 그 전략이 실제로 어떻게 적용되는지를 기록해보고자 한다.

 

git flow를 검색해보면 가장 많이 나오는 이미지가 다음 이미지가 아닐까 싶다.

우리는 이를 활용해 main(master), production, release, develop, feature 브랜치를 사용하기로 했다.

각 브랜치의 용도는 다음과 같다.

• main: 최종 완성 코드를 관리하는 브랜치
• product: 배포 준비가 완료된 코드를 관리하는 브랜치
• release: 목표했던 기능 개발이 완료되면 배포 준비를 하는 브랜치. 테스트를 수행하며 문제가 생기면 release에서 수정 후 dev 브랜치로 병합
• develop: 현재 개발 진행중인 브랜치로, 팀원 모두의 작업 결과물을 합치는 브랜치
• feature: 특정 기능을 개발하기 위한 브랜치

 

 

 

그렇다면, 이 전략을 이용해 코드를 어떻게 관리할 수 있을지 직접 확인해보자.

진행해야하는 업무 목록은 다음과 같이 설정했다.(GitHub issue 활용)

 

순차적으로 코드 작업을 진행하는 경우

진행 업무: #1 프로젝트 개요 작성

 

1) 커밋 생성

먼저 github repository를 생성하고 README.md 파일을 생성했다.

이슈 1번에 대한 기능 구현이므로 컨벤션에 따라 develop 브랜치에서 feat/1 브랜치를 생성한다.

(이 부분은 아래와 같이 github issue에서 바로 진행할수도 있다. 이 때 branch source에 유의하자.)

 

이후에 feat/1 브랜치에서 제목 추가, 내용 추가를 각각 커밋했다.

 

2) push, develop로 PR, merge

그리고 feat/1 브랜치로 push 하고, development <- feat/1 로 pr 요청을 한다.

pr 검토가 끝나면 merge 하는데 이 때 create a merge commit 이 아닌 Rebase and merge를 한다.

 

이 때 rebase를 하는 이유는, 우리의 커밋 이력을 development 브랜치에 깨끗하게 옮기고 싶어서였다.

create a merge commit을 하게 되면 아래 사진처럼 기존의 커밋 이력과 함께 merge 되는 커밋이 추가 된다.

 

언제 어떤 PR을 머지했는지 알 수 있다는 장점이 있기는 하지만, 우리 프로젝트에서는 작업한 커밋 이력만 남기고 싶어서 rebase and merge를 하기로 했다. 아래 사진처럼 feat/1 브랜치에 있던 커밋 내용이 develop 브랜치로 그대로 옮겨와졌다. (그 외에 추가 커밋은 생성되지 않는다.)

 

3) develop -> release -> product -> main

모든 검토가 완료되었다고 가정하고, main 브랜치까지 병합한다.

develop 브랜치에서 release 브랜치를 생성하고, 테스트를 진행한다.

release 브랜치에 문제가 없다면 product 브랜치로 PR을 보내 merge한다.

release -> product 브랜치로 merge 할 때에는 squash and merge한다.

 

Squash and merge는 기존 커밋 이력을 하나로 합치는 방식이다.

product는 배포를 준비하는 마지막 브랜치이므로, 세부 커밋 이력이 필요 없다. 따라서 squash 방식을 사용한다.

Squash 방식을 사용하면 다음과 같이 하나의 커밋으로 Merge되고, 세부 내용은 나타나지 않는다.

 

마지막으로 최종 배포 준비가 완료되면 product -> main 으로 PR을 보내 merge한다.

이 때 PR의 제목은 release v1.0.0과 같이 몇 번째 release 버전인지 나타낸다.

merge 할 때에는 rebase로 병합한다.

(현재 컨벤션은 위에 기재된 내용과 같은데, 직접 테스트를 해보니 PR 제목을 넣고자 한다면 release -> product 일 때 PR 제목을 release v1.0.0 처럼 관리하는 것이 맞을 것 같다. 이 부분은 추후 팀 프로젝트를 하며 확인해봐야할 것 같다.)

 

4) 작업을 완료한 feat, release 브랜치를 삭제한다.

feat 브랜치는 merge가 되면 바로 삭제해도 무관하다. (현재 팀 컨벤션으로 그렇게 작업을 하고 있다.)

github의 insights - network를 보면 브랜치 상태를 볼 수 있다.

아직 작업 이력이 많지 않아 비교하기는 어렵지만, 아래와 같이 깔끔하게 정리되어있는것을 확인할 수 있다.

 

 

+ 팀원들과 git으로 작업을 하다가 에러가 발생했을 때 어떻게 조치할 수 있을지도 다뤄보고자 했으나, 시간상 이유로 추가하지 못했다.🥲

향후 기회가 되면 해당 내용도 정리할 예정이다.

 

참고자료

우아한 기술블로그: 우린 Git-flow를 사용하고 있어요