하나의 브랜치로만 작업을 하는 일

김민지·2022년 9월 30일

백엔드로드맵

목록 보기

5/13

서론

이론을 배울땐 git branch전략을 썼었다. 그런데 이 회사에서는 단일브랜치에서만 commit하고 있는 것이다
일단 나는 이렇게 브랜치가 하나라면 배포시에 불편할거라고 생각했다.
따로 배포 브랜치가 만들어져있다면, 그 브랜치에 나온 것들만 보면 되는데 단일브랜치에서 배포브랜치, 아직 개발중인 브랜치가 섞여있게 된다면
굉장히 혼란스러울 것 같았다.
그런데 이 프로젝트는 아직 개발중인 프로젝트라서 괜찮댄다
왜 개발중인 프로젝트면 괜찮은걸까? 왜 괜찮은지도 모르겠고, 하나의 브랜치로만 작업하면 안되는 이유에 내가 제대로 대답을 못하는 것 같아서 글을 파본다.

본론

하나의 브랜치로만 작업을 하게 되면.. 그 브랜치에 문제가 생겼을 경우 모든 작업이 stop된다.
충돌이 나면 매번 merge를 거쳐야하는데 그때마다 소스 담당자를 불러와서 같이 토론한 다음 merge를 해야할테니 굉장히 불편

브랜치 전략

git flow

웹에서는 사용하지 않는다고 해서 일단 생략

git-flow: 웹에서 사용하지 않는 이유

Git Flow는 명시적으로 버전관리가 필요한 이를 테면, 스마트폰 어플리케이션, 오픈소스 라이브러리/프레임워크 등의 프로젝트에 적합하다.
웹 어플리케이션은 특성상 사용자는 항상 최신의 단일 버전만을 사용하게된다. 여러 버전을 병렬적으로 지원할 필요가 없는 것이다. 또한 웹 어플리케이션은 하루에 몇번이고 릴리즈될 수 있다. 이런 특성상 웹 어플리케이션 개발에 Git Flow는 다소 적합하지 않다.

git-hub flow

Main 브랜치

항상 Stable한 상태여야 한다. 이때, Stable하다는 것은 Main의 모든 커밋은 언제 배포하든 문제 없어야하고, 언제든 브랜치를 새로 만들어도 문제가 없어야 한다. Main 브랜치의 모든 커밋은 빌드가 되고, 테스트를 통과해야한다. 이것이 Github Flow가 강제하는 유일한 사항이다.

Topic 브랜치

새로운 기능을 개발할 때에는 Topic 브랜치를 Main 브랜치로부터 생성한다. Git Flow의 Feature 브랜치와 동일한 역할을 한다. 또한 별도로 Hotfix 브랜치를 관리하지 않으며, 버그 수정도 Topic 브랜치에서 진행한다.
이때, Topic 브랜치의 이름은 기능을 설명하는 명확한 이름으로 네이밍 해야한다. 예를 들면, user-content-cache-key, submodules-init-task, redis2-transition 등이 있다.
Github-flow 전략은 기능 개발, 버그 픽스 등 어떤 이유로든 새로운 브랜치를 생성하는 것으로 시작된다.
단, 이때 체계적인 분류 없이 브랜치 하나에 의존하게 되기 때문에 브랜치 이름을 통해 의도를 명확하게 드러내는 것이 매우 중요하다.

Topic 브랜치의 커밋은 기능이 완성되지 않았더라도 꾸준히 Push 한다. 노트북 분실, 작업 컴퓨터의 고장등의 위험으로 코드가 유실되는 것을 막아준다. 이것보다 더 중요한 이유는 꾸준히 Push 함으로써 구성원 모두가 끊임없이 커뮤니케이션 할 수 있게 해준다.
Github에서는 PR(Pull Request)라는 유용한 기능이 존재한다. 개발자는 기능을 개발하는 중 언제든 상관없이 PR을 개설할 수 있다. 심지어 코드의 변경이 없더라도 스크린샷, 아이디어를 공유하고 싶을 때에도 PR을 개설한다. 개발자들은 개설된 PR에서 토론을 하고, 코드의 특정 라인을 선택해 코멘트를 남겨 코드리뷰를 주고 받는다.
토론과 리뷰가 끝났으면, 다른 사람들의 동의(Approve)를 얻고 Main 브랜치에 자신의 Topic 브랜치를 머지한다. 단, 이때 Topic 브랜치는 자동화된 CI 빌드를 통과해야 머지가 가능하다.