#10 branch 전략 - git flow / trunk-based

- branch를 너도 나도 만들어서 아무렇게나 사용하면 개발 과정이 복잡해지고 추적도 어렵다.
- 이런 문제를 방지하기 위해 git branch를 깔끔하게 만들도록 도와주는 방법론이 여러개 있다.
- git flow, github flow, gitlab flow, trunk-based 등이 그것이다.
- 이러한 방법론을 적용하면 branch 관리가 쉬워지고 협업 인원이 아무리 많아도 개발 절차가 매끄러워진다.
- 특히 PL, PM 직책이 알면 좋다.

---

● git flow : 안정적인 운영이 필요할 때

- 현재 만들고 있는 프로그램이 항상 안정적인 release를 해야한다면(ex. 게임 개발) git flow 전략을 사용하면 된다.
- git flow 전략은 크게 5개의 branch를 운영한다.

1. main branch
2. develop branch(개발용)
3. feature branch(develop branch에 기능 추가용)
4. hotfix branch(main branch 버그 해결용)
5. release branch(develop branch를 main branch에 합치기 전에 최종 테스트용)

- 게임 개발을 예시로 들어보자
- 현재 초절정 인기 게임 '호박고구마 호.박.고.구.마'를 한창 서비스 하고 있다고 해보자
- 지금까지는 영기 엄마 텃밭 덕분에 주먹구구식으로 협업해도 0.9 version까지는 잘 굴러가도록 만들어 놓았다.
- 하지만 1.0 version부터는 신기능도 많아지고 해서 제대로 된 전략을 가지고 개발을 진행하고 싶은것이다.
- 여기서 git flow 전략을 도입해 볼 것이다.

출처 - https://www.youtube.com/watch?v=vgyvy-Jhxjw&t=60s

 

1. develop branch 부터 생성

출처 - 코딩애플 매우쉽게 알려주는 git & github

- 신기능을 개발해서 바로 main branch에 합치는 것은 있을 수 없는 일이다.
- 새로 작성한 코드는 믿을 수가 없는 이세계의 존재이다.
- 그렇기에 일단 실험용 프로젝트 사본을 만든 후 해당 사본에서 먼저 개발을 해보자.
- 이를 위해 main branch에 있던 기존 프로젝트를 복사한 develop branch를 생성한다.
- 이제부터 모든 개발은 develop branch에서 진행하라고 전체 인원에게 전파해야한다.

 

2. 신기능 개발은 feature branch에서

출처 - 코딩애플 매우쉽게 알려주는 git & github

- 신기능을 만들고 싶으면 develop branch를 복사한 feature branch에서 각각 개발한다.

- 냅다 develop branch에서 바로 개발하는게 아니다.
- feature/guild branch를 만들어 길드기능을 만들고
- feature/friend branch를 만들어 친구 기능을 만드는 식으로 진행하면 된다.
- branch를 작명할 때 여러 단어가 필요하면 보통 '-' or '/' 기호를 사용한다.
- 기능이 완성되면 develop branch에 merge 한다.
- 그닥 중요한 내용의 기능이 아니면 squash and merge 해도 괜찮다.

 

3. 신버전 출시 준비는 release branch

출처 - 코딩애플 매우쉽게 알려주는 git & github

- develop branch에서 만든 2개의 기능들이 완성됐다.
- 근데 이걸 또 바로 main branch에 합치기에는 불안하기 때문에 develop branch → release branch 이렇게 프로젝트를 복사한 다음 출시 준비를 한다.
- 생성된 release branch에서 테스트나 QA 등을 진행하면 된다. 도중에 버그나 문제를 발견하면 임시 branch 만들어서 수정하면 된다.  cf) release/1.0 과 같이 branch 이름을 짓는 경우가 많다.
- 완성된 것 같으면 main branch로 merge 한다. 그리고 유저들에게 배포하면 된다.
- 배포 후에도 개발은 계속 해야하니 release branch 내용을 develop branch에도 반영해준다.(merge 한다.)

 

4. hotfix branch

출처 - 코딩애플 매우쉽게 알려주는 git & github

- 유저들에거 배포한 1.0 version에서 갑자기 밤고구마 무한복사 버그를 발견했다.
- 이렇게 급한 것들은 main branch에서 hotfix branch를 하나 만들어서 바로 버그를 수정하면 된다.
- 수정이 완료되면 main branch에 직접 merge 한다.
- 당연히 develop branch에도 hotfix branch를 merge 해줘야한다.

 

1~4번을 다 합친 그림

출처 - 코딩애플 매우쉽게 알려주는 git & github

- git flow는 continuous delivery에는 적합하지 않을 수 있다. 
- 전략을 그대로 따라하려고 하지 말고 상황에 맞게 알맞게 변형해서 사용하자
ex) release branch 쓰지 않고 바로 main branch에 merge 해서 배포

---

● Trunk-based 전략 

출처 - 코딩애플 매우쉽게 알려주는 git & github

- 작성한 코드를 바로 배포해도 상관없는 프로그램이거나 큰 업데이트가 없는 안정적인 프로그램이면 굳이 많은 branch를 만들어야 하는 git flow 전략을 사용할 필요가 없다.
- 간단하게 main branch와 기능 추가용 feature branch 만 운영해도 된다.
- 이것이 바로 trunk-based 전략이다.(github flow도 이와 비슷)

1. 기능 추가 or 버그 픽스가 필요하면 main branch에서 새로운 branch를 하나 만들어 코드를 짠다.
1-1. branch 마다 작명 잘 하는게 중요
2. 기능이 완성되었으면 main branch에 합친다.
3. merge 된 branch는 쓸데 없으니 삭제한다.
4. main branch에 있는 코드를 필요할 때 마다 유저들에게 배포한다.

- trunk-based 전략은 코드를 하나의 branch에서만 관리하기 때문에 편리하다는 장점이 있다.
- 또한 큰 덩어리를 개발해서 한 번에 merge 하는 것 보다는 작은 단위로 merge 하는 것이 더 안전하다.
- 그러나 main branch에 있는 코드에 문제가 발생하면 큰일나기 때문에 테스트나 코드리뷰를 자주해야한다.

결론
- 출시된 버전의 안정성이 중요한 프로그램, 뼈대가 확실하지 않아 연구식으로 개발하는 프로그램들은 git flow가 적절
- 이미 어느정도 개발이 되었거나 어느 정도 실력이 되는 팀이면 trunk-based 전략을 쓰는게 더 편리
- CI/CD 식으로 개발하는 곳들도 trunk-based 개발 방식을 적용한다.

Q. merge 할 때 어떤 방법을 쓰는게 좋은가?
- 기록을 남겨야하는 중요한 branch를 merge 할 때는 3-way merge
- 기록을 남길 필요없는 branch를 merge 할 때는 squash, rebase를 쓰면 된다.