간단한 프로젝트에서 쓰기 좋은 Git Branch (Git Workflow) 전략

어디까지나 학부생 글쓴이의 관점에서 생각된 내용입니다. 반박과 질문 환영입니다.

---

목차

이번 학기 "소프트웨어개발실무"라는 과목을 수강하면서 개발에 대한 Best Practice를 고민해 보게 되었다.

이 수업을 들으면서 조사한 내용 중 실제로 당장 프로젝트에 적용해 볼 만한 내용들이 있었고, 이 내용들을 정리해 하나의 케이스로써 팀원들에게 "이런 방식으로 해보면 어떨까요~??"라고 말해보는 것도 좋을 것 같아 작성을 해보게 되었다.

---

Base

주로 Git Workflow 방식에 대해 찾아보면 Git Flow, Github Flow, Gitlab Flow 3가지 방식이 나온다.
꼭 branch 전략을 이런 case로 가져갈 필요는 없지만, 나름의 고민을 해보면서 아래와 같은 점들은 꼭 지켜져야 될 것 같다고 생각하였다.
 
1. branch들은 각 정확한 목적에 맞게 운영되어야 한다.

• Git Flow 방식은 5개의 branch들을 운용하는데 개인적으로는 release branch 목적성이 너무 아쉬웠다. develop에서 next release를 담당하고 main에서 release를 한 후 버전을 관리하면, 굳이 release branch를 둘 필요가 있을까? 라는 생각을 하게 되었다. (이렇게 느끼는건 내 지식이 모자라서 일 수도 있다.)
• 당시 어떤 주기나 기준으로 develop에서 main으로 코드를 옮길건가에 대한 기준이 없다보니, develop  branch는 그저 main branch를 가기 위해 한번 더 거쳐야 되는 불필요한 요소가 되어있었다. 명확하지 않은 기준은 branch의 낭비로 이어진다

2. End-User에게 배포되기전 테스트를 할 수 있어야 한다.

• 유저한테 배포된 프로그램에서 에러가 터진다면 이는 말못할 사고다. 100% 이런일이 안일어나지는 않을테니 hotfix라는 개념이 있겠지만, 그래도 에러가 일어나는 상황을 자체적으로 줄이려는 노력은 해야하지 않을까?

---

Recommend

나는 이런저런 경험 끝에 간단한 프로젝트를 사람들과 하기에는 release branch를 뺀 Git Flow 전략 (no release Git Flow)이 괜찮다고 생각했다.

위 사진은 내가 발표때 간단하게 그려본 구상도이다.
 
우선 branch 구성은 다음과 같다.

• hotfix: 버그 발생 시 긴급하게 수정을 하는 branch
• main: 결과물을 release 하는 branch
• develop: next release를 준비하는 branch
• feature: 기능 개발용 branch

그리고 개인적으로 추가적인 기능을 조금씩 붙였다.
 
큰 틀은 다음과 같다.
1. main에서 기초적인 세팅이 끝났다면 이를 develop으로 pull 해온다.
2. 각 기능을 개발하기 위해, 사용하는 branch naming rule에 따라 develop에서 feature branch로 쪼갠다.
3. A기능이 완성이 되었다면 develop으로 PR을 날린다.
4. develop은 일정 기준(milestone, WBS의 epic or story 단위 등)에 따라 main에 merge 한다.
5. release된 코드에서 문제가 발생한다면 hotfix로 코드를 pull 한뒤 수정후 main에 다시 merge 한다.
 
PR과 Merge에 대한 각 세부사항은 적지 않았는데 큰 틀만 보면 위와 같이 쓰면 좋을 것 같다.
 
release branch를 넣지 않은 이유는 위에서 언급했듯이 굳이 간단한 프로젝트에서 사용할때, release처럼 잘 사용되지 않고 다른 브랜치에서 release의 역할을 잘 쪼개서 수행할 수 있을 것이라 생각했기 때문이다.
 
또한 develop 에서 main으로의 코드를 어떤 기준이 release해도 될 시점인가? 를 명확하게 하는 것이 좋은 branch rule을 만드는데 필요하다.

---

More

막상 branch 전략에 대해서만 쓰고 나니까 조금 글이 허전해서 아래는 시행착오와 추가적인 룰 도입에 대한 생각을 써보려고 한다.
여기서 부터는 안 읽어도 좋다.
 

시행착오

우선 나는 여태 다른사람들과 개발을 하면서 어느정도의 개발 지식을 가지고 있는 사람들과 프로젝트를 진행하다보니, 그런 사람들 사이에서는 이런 방식이 바이블 마냥 사용되고 있으니까 나도 무작정 사용을 했었던 것 같다.
 
하지만 개발을 처음 접하는 사람들에게 바이블을 들이미니까 왜 그런방식을 사용해야 하지? 하는 질문이 돌아왔고 깊게 들어가는 질문에 나는 명확한 답변을 주지 못했다. 그렇다 보니 나의 의견을 제대로 피력할 수 없었고 뭔가 나사가 하나쯤 빠진 branch 전략을 사용해 보면서 왜 이런 방식을 사용하지 않는지에 대해 배워야 했다.
 

no release Git Flow를 사용한다면 코드리뷰는 어디서 이뤄지는게 좋을까?

결론적으로, 내가 생각하는 리뷰 타이밍은 feature → develop이 적당하다고 생각한다.
 
처음에 우리팀은 conflict에 대해서 엄청 보수적이여서 feature에서 기능이 완전히 개발되기 전에 develop에 코드를 올리는 방향으로 진행하였다. (즉, develop → main으로 갈때 리뷰를 진행하였다.)
하지만 이런 방식으로 진행을 한다면, develop에 많은 코드들이 쌓이게 되고 리뷰를 달때 코드작성자를 파악해 일일히 알려줘야 하며 comment가 중구난방으로 뒤섞인다.
 
우리가 진행했던 프로젝트가 dependency가 많은 일들이였긴 했지만 다음과 같은 방향은 좋지 않았다.
conflict를 두려워 하지 않고 처리 하려는 능동적인 자세가 필요했는데, 조금 어떻게든 일어나지 않게 하기 위해 보수적이였던 것 같다.
 
이후 feature → develop으로 리뷰 타이밍을 옮기게 되었고 git action으로 ci/cd를 구성하는 것과 더불어 reivew를 하는 것도 잘 진행 되었던 것 같다. 그리고 크게 conflict가 날 것도 없었다.
 
추가적으로 리뷰는 몇명이서 해야하는가, 어떤 인원이 리뷰해주느냐에 따른 리뷰 퀄리티도 고려해보면 좋을 것 같다.
 

hotfix는 굳이 있어야 할까?

release branch의 존재여부를 고민하면서 hotfix에 대한 여부도 한번 고려해보았다.
결론적으로 hotfix는 필요하다고 생각했다.
 
왜냐?
hotfix는 거의 main으로 코드가 올라간 뒤 문제가 터졌을때 사용하게 된다.
그런데 이 상황에서 hotfix branch가 없다고 해보자? 그럼 어디서 문제를 해결할 것인가?
main또는 develop에서 이 문제를 해결해야 할 것이다.
그렇다고 main에서 코드를 즉각 수정한다는 것은 또 다른 문제를 일으킬 부담이 크기 때문에 제거하고 develop에서 수정한다고 해보자.
develop에서 문제를 해결중에 있는데 누군가 feature에서 develop으로 PR을 날린다고 해보자 그럼 또 골치 아파진다.
이러한 문제를 막고 원활한 개발을 위해서 hotfix 브랜치는 있어야 한다고 판단을 하게 되었다.

---

auto-merge, 리뷰어 자동 지정 등등 적고 싶은게 많았지만 다른 경험들은 차후 다른 글에서 작성 해보도록 하겠다.