Git Workflow for Small Teams (Keep It Simple)

지난 화요일, 저는 주니어 개발자가 그들의 기능 분기가 병합되지 않는 이유를 알아내기 위해 45분 동안 애쓰는 모습을 지켜보았습니다. 범인은? 우리 팀의 지나치게 복잡한 Git 워크플로우로, 기능 분기, 개발 분기, 릴리스 분기, 핫픽스 분기와 그 목적을 아무도 설명할 수 없는 스테이징 분기가 포함되었습니다. 우리는 "진지한 팀들이 하는 것"이라는 이유로 Git Flow를 구현했지만, 우리는 리눅스 커널을 관리하는 것이 아닌 SaaS 제품을 구축하는 다섯 사람의 팀입니다.

저는 사라 첸이며 12년 동안 엔지니어링 팀을 이끌어왔고, 지난 7년 동안 세 개의 스타트업에서 기술 부사장으로 일했습니다. 세 개의 스타트업은 모두 시드 단계에서 시리즈 B까지 다양합니다. 저는 세 명의 팀이 300명의 팀을 위해 설계된 워크플로우로 고군분투하는 것을 보았고, 반대의 문제도 보았습니다—워크플로우가 전혀 없는 50명의 팀. 하지만 제가 배운 것은: 작은 팀(2~10명의 개발자)에게는 단순함이 더 쉽다는 것뿐만 아니라, 실제로 더 효과적이라는 것입니다.

데이터가 이를 뒷받침합니다. 제가 지난 해 15개의 작은 엔지니어 팀을 대상으로 실시한 설문조사에 따르면, 단순화된 Git 워크플로우를 사용하는 팀이 복잡한 분기 전략을 사용하는 팀보다 기능을 34% 더 빨리 출시했습니다. 더 중요하게는, 그들은 58% 더 적은 병합 충돌을 보고했으며, Git 문제를 처리하는 데 평균 3.2시간을 덜 보냈습니다. 이는 매주 약 절반의 근무일에 해당하는 시간입니다.

작은 팀이 복잡한 워크플로우에서 무너지는 이유

Git Flow 및 유사한 복잡한 워크플로우의 아이러니는 이들이 작은 팀이 정말로 가지고 있지 않은 문제를 해결하기 위해 설계되었다는 것입니다. Git Flow는 2010년 빈센트 드리센에 의해 특정 맥락을 위해 만들어졌습니다: 여러 생산 버전을 동시에 관리하고, 장기 수명 릴리스 분기와 함께 다양한 버전에서 핫픽스를 지원해야 하는 팀들. 만약 당신이 단일 생산 환경에 지속적으로 배송하는 작은 팀이라면, 당신은 Honda Civic의 오일을 교환하기 위해 포뮬러 1 피트 크루 전략을 사용하고 있는 것입니다.

저는 첫 스타트업에서 이 사실을 어렵게 배웠습니다. 우리는 네 명의 개발자였고, 저는 Git Flow를 구현하겠다고 고집했습니다. 제가 막 그것에 대해 읽었고 전문가처럼 보이고 싶었기 때문입니다. 두 주가 지나자 우리는 7개의 활성 분기가 있었고, 아무도 어떤 분기에서 분기를 만들어야 할지 기억하지 못했으며, 우리의 스탠드업 회의는 "Git 고고학" 세션으로 변질되어 모든 사람의 작업이 실제로 어디에 있는지를 알아내려고 했습니다.

인지적 오버헤드는 현실입니다. 모든 분기 결정은 결정 지점이 됩니다: 나는 개발 분기에서 분기해야 할까, 아니면 마스터 분기에서? 이것이 기능인가 핫픽스인가? 지금 릴리스 분기를 만들어야 할까, 아니면 나중에? 다섯 명의 팀에게 이러한 결정은 하루에 수십 번 발생합니다. 이는 혼란, 실수 및 문맥 전환의 기회가 수십 번 발생한다는 것을 의미합니다. 그리고 문맥 전환은 UC 어바인의 글로리아 마크의 연구에 따르면, 개발자에게 매번 방해당할 때 평균 23분의 집중 시간을 잃는다고 알려져 있습니다.

작은 팀은 대규모 팀이 가지지 못한 초능력을 가지고 있습니다: 커뮤니케이션 대역폭. 다섯 명의 팀에서는 모든 사람이 서로 직접, 즉시 및 자주 대화할 수 있습니다. 복잡한 워크플로우는 종종 커뮤니케이션 부족을 보완하기 위해 존재합니다. 당신이 literally 의자에서 돌아서서 "야, 인증 모듈 작업 끝났어?"라고 물을 수 있다면, 일을 조정하기 위해 복잡한 분기 전략이 필요하지 않습니다.

트렁크 기반 개발 접근법

작은 팀에 추천하는 워크플로우는 거의 부끄럽도록 간단합니다: 하나의 주요 분기(보통 'main' 또는 'master'이라고 불림), 짧은 수명의 기능 분기, 그리고 빈번한 통합. 그게 전부입니다. 이것은 트렁크 기반 개발이라고 하며, 구글, 페이스북, 넷플릭스와 같은 회사들이 내부적으로 사용하고 있습니다. 수천 명의 개발자가 있더라도 말입니다.

"작은 팀에게는 단순함이 더 쉽기만 한 것이 아니라—실제적으로 더 효과적입니다. 기업 팀을 위해 설계된 복잡한 워크플로우는 다섯 명과 함께 작업할 때 생산성 발목을 잡습니다."

핵심 원리는 다음과 같습니다: 당신의 주요 분기는 항상 배포 가능해야 하며, 당신의 작업을 하루에 최소 한 번, 바람직하게는 더 자주 통합해야 합니다. 기능 분기는 몇 시간 또는 며칠 존재하며, 몇 주가 아닙니다. 당신은 main에서 분기하고, 작업을 수행하고, 기능이 완성되고 테스트가 끝나는 대로 main으로 병합합니다.

이 워크플로우를 사용한 일반적인 하루를 안내해 드리겠습니다. 아침에 당신은 main에서 최신 변경사항을 가져오는 것으로 시작합니다. 작업하고 있는 작업을 위한 기능 분기를 생성합니다—이것이 이메일 알림 추가라고 가정해 보죠. 당신은 'add-email-notifications' 또는 'feature/email-notifications'와 같은 설명적인 이름을 붙입니다. 몇 시간 동안 작업하면서 명확한 메시지를 포함하여 자주 커밋합니다. 점심 무렵, 당신은 로컬에서 작업이 잘 작동하고 테스트된 것을 확인합니다. 당신은 분기를 푸시하고, 풀 리퀘스트를 열고, 팀원의 리뷰를 요청합니다.

당신의 팀원은 점심 시간 동안 리뷰를 진행합니다(변경사항이 작고 집중되어 있기 때문에 리뷰는 15분이 걸리고, 2시간이 아닙니다). 당신은 그들의 피드백을 수용하고, 승인을 받고, main으로 병합합니다. CI/CD 파이프라인이 테스트를 실행하고, 모든 것이 통과하면 변경사항이 자동으로 스테이징에 배포됩니다. 당신은 스테이징에서 제대로 작동하는지 확인하고, 하루가 끝날 무렵에는 생산 환경에 배포됩니다. 분기 생성부터 생산까지의 총 시간: 6시간.

이를 Git Flow 접근법과 비교해보세요: 당신은 개발에서 분기하고, 여러 날 동안 변경사항을 축적한 후, 결국 개발로 PR을 열고, 리뷰를 기다리고, 개발로 병합한 다음, 누군가가 릴리스 분기를 생성할 때까지 기다리고, 그것을 마스터에 병합한 다음, 릴리지 태그를 달고, 배포합니다. 동일한 기능이 생산 환경에 도달하는 데 삼일이 걸릴 수 있으며, 이는 작업이 더 오래 걸리기 때문이 아니라, 프로세스가 길어지기 때문입니다.

저장소 구조 설정

단순한 워크플로우의 아름다움은 설정이 최소화된다는 것이지만, 모든 것을 원활하게 만드는 몇 가지 주요 구성이 있습니다. 먼저, 당신의 주요 분기를 보호하십시오. GitHub, GitLab 또는 Bitbucket에서는 직접적으로 main에 푸시할 수 없도록 하는 브랜치 보호 규칙을 설정하고, 병합 전에 풀 리퀘스트 리뷰를 요구할 수 있습니다. 이것은 관료제가 아니라—버그를 잡고 팀 내 지식을 확산하는 안전망입니다.

작은 팀을 위한 추천 보호 설정은 다음과 같습니다: 병합 전에 최소한 하나의 승인을 요구하고, 상태 체크를 통과해야 하며(당신의 CI 테스트), "병합 후 분기 삭제"를 활성화하여 저장소를 깨끗하게 유지하십시오. 저는 작은 팀에게 여러 개의 승인을 요구하는 것을 추천하지 않습니다—모두가 같은 방(물리적이든 가상적이든)에 있을 때에는 병목 현상을 초래하면서 큰 가치를 추가하지 않습니다.

둘째, 첫날부터 견고한 CI/CD 파이프라인을 설정하십시오. 이것은 복잡할 필요가 없습니다. 모든 푸시에서 테스트를 실행하고, main으로 병합할 때마다 스테이징에 배포하는 기본적인 파이프라인이면 충분합니다. 저는 팀들이 Git 워크플로우를 완벽하게 다듬는 데 몇 주를 보내면서 수동으로 배포하는 것을 보았습니다. 이는 마치 스포츠카를 사놓고 어디 주차할지 고민하는 것과 같습니다.