git branch 전략 + commit 기록 방법 선택하기

git branch 전략과 commit 방법은 이미 많은 레퍼런스가 존재합니다.
하지만 지금 내 환경에 적합한 전략을 선택하는 것은 조금 다른 이야기입니다.

이 글에서는 사이드 프로젝트를 진행하면서 내가 해본 선택 과정을 기록합니다.

GitHub - Our-Class-Bank/core-backend: [side-project] 우리반은행

 

배경

• github repository 에서 1인 백엔드 개발
• 프론트 개발은 별도의 repository 사용
• dev, prod 배포 환경 지원 필요

 

전략 선택 과정

1. 초기 전략

feature, dev, main 브랜치만 사용하는 약식 Git Flow 전략

1. local 에서 feature 단위로 완성된 기능을 remote feature 브랜치에 머지합니다.
2. remote feature 브랜치를 dev 에 머지합니다.
3. qa 가 끝나면 main 브랜치에 머지합니다.

github issue 번호 기반으로 commit 기록

이 방법으로 commit 이 어떤 github issue 와 연결되었는지 직관적으로 알 수 있었습니다.

하지만 큰 내용도 아닌 것을 매번 github issue 를 작성하는 게 귀찮았습니다.
그리고 1인 개발이기 때문에 커밋 이상으로 이슈 트래킹 할 일은 없을 것 같았습니다.

micro commit 관점에서 issue, pr 에 너무 많은 기록은 꽤 지저분해 보입니다.

 

2. commit 기록 방법 변경

feature, dev, main 브랜치만 사용하는 약식 Git Flow 전략

milestone 단위로 prefix 를 만들고, 중분류를 나누어 commit 기록

github issue 대신 노션 보드로 작업을 관리했습니다.
그리고 일정 기간 단위로 milestone 뭉쳤습니다.

notion 으로 작업 관리

 

하지만 dev 브랜치만으로는 프론트 qa 와 배포 관리가 힘든 상황이 생겼습니다.
qa 를 위한 브랜치가 한 개다 보니 qa 완료 기능과 아닌 기능을 분리하기 힘들었기 때문입니다.

 

3. release branch 도입

feature, dev, release, main 브랜치만 사용하는 약식 Git Flow 전략

1. local 에서 feature 단위로 완성된 기능을 remote feature 브랜치에 머지합니다.
2. remote feature 브랜치를 dev 에 머지합니다.
3. qa 가 끝나면 versioning 후 release 브랜치에 머지합니다.
4. 약속된 시간에 release 브랜치를 main 브랜치에 머지합니다.

milestone 단위로 prefix 를 만들고, 중분류를 나누어 commit 기록

 

하지만 feature 브랜치를 꼭 써야 되나?라는 생각이 들었습니다.
실무라면 특정 feature 만 테스트하거나 history, conflict 방지를 위해서라도 필요하지만, 1인 개발이다 보니 브랜치를 모두 컨트롤하는 게 어렵지 않았기 때문입니다.

 

4. feature branch 삭제

dev, release, main 브랜치만 사용하는 약식 Git Flow 전략

milestone 단위로 prefix 를 만들고, 중분류를 나누어 commit 기록

dev 브랜치에서 직접 개발을 진행하여 머지 회수를 줄였습니다.

 

마치며

v1.0.0 배포!

사실 1인 개발이라면 이런 전략들을 덜 고민해도 됩니다.
conflict 가 발생하더라도 그 commit 이 무엇이었는지 다 내 머릿속에 있을 테니까요.
혹자는 실무라면 여러 사람이 같이 일하고 그라운드 룰이 있기 때문에 이런 약식 전략은 별 의미가 없다고 말할 수도 있습니다.

저는 오히려 반대라고 생각합니다.

• 실무라고 할지라도 특정 프로젝트는 소수의 인원으로 진행할 수 있습니다.
• 신규 프로젝트를 셋업 하는 데는 컨텍스트를 이해하는 소수의 인원이 진행하는 것이 더 효율적일 수 있습니다.
• 그라운드 룰이 있을지라도 각 스쿼드는 독립적인 전략을 사용할 수 있습니다.

 

저는 모든 것을 실무라는 생각으로 지금에 최소이면서도 확장 가능한 선택을 하려고 노력합니다.
그래야만 실무에서 문제를 만났을 때 그 경험을 활용하여 더 좋은 선택을 할 수 있기 때문입니다.

어쩌면 실무는 더 극한일지도..?

 

참고자료

• https://hyeon9mak.github.io/git-branch-strategy/
• https://yozm.wishket.com/magazine/detail/1558/
• https://tech.mfort.co.kr/blog/2022-08-05-trunk-based-development/
• https://udacity.github.io/git-styleguide/

개인적으로 정리한 커밋