git> git flow / trunk-based 브랜치 전략

개발자 10명이서 브랜치를 대충 아무렇게나 만들면 개발과정이 매우 복잡해지고 추적도 어려워서

git branch 깔끔하게 만들도록 도와주는 방법론같은게 있습니다. 

git flow, github flow, gitlab flow, trunk-based 등 다양한 것들이 있습니다.  

 

이런걸 적용하면

1. 브랜치관리가 쉬워지고 

2. 팀원이 아무리 많아도 개발절차가 매끄러워집니다. 

그래서 프로젝트 리드하는 사람들이 알면 좋습니다. 

시키는 것만 하는 코딩노예들은 몰라도 됩니다. 

 

 

 

안정적인 운영이 필요하면 git flow 

 

님들이 만드는 프로그램이 항상 안정적인 release를 해야한다면 (예를 들면 게임개발)

git flow 전략을 쓰면 됩니다. 

 

git flow 전략은 크게 5개 브랜치를 운영하는데 

- main 브랜치

- develop 브랜치 (개발용)

- feature 브랜치 (develop에 기능추가용)

- hotfix 브랜치 (main 브랜치 버그해결용)

- 가끔 release 브랜치 (develop 브랜치를 main 브랜치에 합치기 전에 최종 테스트용)

를 운영합니다. 

 

 

이론만 설명하면 노잼이라 게임개발을 예시로 들어봅시다. 

이제부터 여러분은 게임개발 팀장입니다. 

지금까지는 대충 주먹구구식으로 협업해서 0.9버전까지 만들어놨다고 칩시다. 

근데 1.0 버전부터는 신기능도 많고 해서 제대로 개발을 진행하고 싶은겁니다.

그래서 이번엔 git flow를 도입해서 개발을 진행해봅시다. 

 

 

 

 

 

 

1. develop 브랜치부터 생성합니다. 

 

신기능 개발해서 바로 main브랜치에 합칠 것입니까?

그래도 되겠지만 신입 개발자들을 믿을 수 없습니다. 

 

일단 실험용 프로젝트 사본을 만들고 거기다가 먼저 개발해봅시다. 

그러기 위해 main 브랜치에 있던 기존 프로젝트를 복사한 develop 브랜치를 생성합니다. 

이제 모든 개발은 develop 브랜치에서 진행하라고 팀원들에게 전파합니다. 

 

 

 

 

 

 

 

 

2. 신기능개발은 feature 브랜치에서 진행

 

신기능을 만들고 싶으면 develop 브랜치를 복사한 feature 브랜치에서 각각 개발합니다. 

feature/guild 브랜치 만들어서 길드기능 만들고 

feature/friend 브랜치 만들어서 친구기능 만들고 하면 됩니다. 

(브랜치 작명할 때 여러 단어가 필요하면 보통 대시나 / 기호 씁니다)

 

- 완성되면 develop 브랜치에 merge 합니다.

- 중요한 내용이 아니면 squash and merge도 괜찮습니다. 

 

 

 

 

 

 

 

 

3. 신버전 출시 준비는 release 브랜치

 

develop에서 만든 2개 기능들이 완성된 것 같습니다.

이걸 바로 main 브랜치에 합치기엔 또 불안하기 때문에

develop -> release 브랜치 이렇게 프로젝트를 복사한 다음 출시준비를 합니다. 

 

- 여기서 테스트나 QA같은거 진행하면 됩니다. 

- 버그를 발견하면 알아서 임시 브랜치 만들어서 수정하거나 합니다.

- release/1.0 이런 식으로 이쁘게 브랜치 이름을 짓는 경우가 많습니다.

 

완성된 것 같으면 main 브랜치로 merge 합니다. 그리고 그거 유저들에게 배포하면 됩니다. 

개발은 계속 진행되어야하니 완성본은 develop 브랜치에도 merge 해줍시다. 

 

 

 

 

 

 

4. hotfix 브랜치

1.0 버전에서 갑자기 골드 무한복사 버그를 발견했습니다. 

그런 급한 것들은 main 브랜치에서 hotfix 이런 브랜치 하나 만들어서 바로바로 버그수정하면 됩니다. 

 

- 수정이 완료되면 main 브랜치에 직접 merge 하면 됩니다. 

- 당연히 develop 브랜치에도 merge 해줘야합니다. 

 

이제 유저들에겐 "잡다한 버그 수정" 공지만 올리고 점검보상 쪼금 주면 됩니다. 

게임 뿐만 아니라 웹이나 앱도 비슷하게 운영할 수 있습니다. 

 

 

 

 

 

▲ 쓸데없이 다 합친 이쁜 그림 

출처링크 안남기고 개인 블로그에 글과 그림 그대로 복사해가는 나쁜 사람들이 많습니다. 

그래서 오늘은 워터마크를 박아봤습니다. 

 

 

 

 

 

 

 

Q. 꼭 저거 따라해야하나요?

물론 git flow 이런거 단점도 있습니다.

최근 continuous delivery 이런거 한 때 유행이었는데 그런거 할 땐 적합하지 않을 수 있습니다. 

그래서 맨날 남들이 하는거 앵무새처럼 따라할 생각하지 말고 본인 마음대로 변형해서 쓰십시오. 

예를 들면 release 브랜치 쓰지 않고 바로 main 브랜치에 merge 해서 배포하거나 그래도 됩니다. 

그 선택에 합당한 이유와 근거가 있으면 됩니다. 물론 책임도 져야합니다.

근데 책임은 언제나 전가 가능  

 

 

 

 

 

 

Trunk-based 전략 

 

님들이 만드는게 코드짠걸 바로 대중에 배포를 해도 상관없는 프로그램이면

그리고 크게 대격변 업데이트를 안하는 안정적인 프로그램이면 

굳이 많은 브랜치를 만들 필요가 없습니다. 

그냥 main 브랜치와 기능추가용 feature 브랜치만 운영하면 됩니다. 

이게 trunk-based 전략입니다.

github flow도 이거랑 비슷합니다. 

 

 

 

 

1. 기능추가, 버그픽스가 필요하면 main 브랜치에서 새로운 브랜치를 하나 만들어서 코드짭니다.

브랜치마다 작명 잘하는게 중요합니다. 

 

2. 기능이 완성되었으면 main 브랜치에 합칩니다.

이제 브랜치 쓸데없으니 삭제합니다.

 

3. main 브랜치에 있는 코드를 필요할 때 마다 유저들에게 배포합니다.

 

 

 

- trunk-based 개발의 장점은 코드를 한 브랜치에서만 관리하기 때문에 편리합니다. 

- 크게 개발해서 한 번에 merge 하는 것 보다 작은 단위로 merge 하는 것이 더 안전합니다. 

- 하지만 main 브랜치에 있는 코드가 뻑이나면 큰일나기 때문에 테스트나 코드리뷰를 자주해야합니다.

그래서 테스트를 자주하고 자동화해놓는 곳들이 제대로 사용가능합니다. 

 

 

 

 

 

 

결론

 

이미 어느정도 개발이 진척이 되었거나 프로 코딩전사들로 가득한 팀이면 trunk-based 이런거 쓰는게 훨씬 편리합니다.

최근 유행한 CI/CD 이런 식으로 개발하는 곳들도 trunk-based 개발방식을 적용합니다.  

출시된 버전의 안정성이 중요한 프로그램들, 아직 뼈대가 확실하지 않아 연구식으로 개발하는 프로그램들은 git flow가 적절할 수 있습니다. 

하지만 물론 정해진 것은 없고 직접 해보고 판단하는게 좋습니다.

 

 

 

 

 

 

Q. merge 할 때 어떤 방법 쓰는게 좋은가요?

기록을 남겨야하는 중요한 브랜치를 merge할 땐 3-way merge

기록을 남길 필요없는 쓸데없는 브랜치를 merge할 땐 squash, rebase 쓰면 됩니다. 

취향일 뿐이고 알아서합시다.