Git Workflow Best Practices for Teams - txt1.ai

Marcus Chen, 12년간 분산 개발 팀을 이끌어온 C 시리즈 SaaS 스타트업의 엔지니어링 매니저

삼년 전, 저는 우리 엔지니어링 팀이 병합 충돌, 잃어버린 코드, 배포 재앙의 무게에 거의 무너지는 모습을 보았습니다. 우리는 18개월 사이에 8명에서 45명의 엔지니어로 성장했고, 비공식적인 "메인에 커밋하라"는 접근 방식은 매주 약 23시간의 충돌 해결 비용을 초래하는 부담이 되었습니다. 분수령은 한 주니어 개발자가 결제 팀의 3일간 작업을 우연히 덮어쓴 제품 출시 중에 발생했습니다. 그 사건은 우리에게 180,000달러의 매출 지연 비용을 초래했고, Git 워크플로우가 단순한 기술적 세부 사항이 아니라 팀의 속도와 제품 신뢰성의 기초라는 귀중한 교훈을 주었습니다.

오늘날, 우리 팀은 3년 전보다 4.2배 빠르게 코드를 배포하며, 코드 통합 문제와 관련된 생산 사고는 89% 감소했습니다. 이 변화는 더 똑똑한 사람을 고용하거나 비싼 도구를 구매해서 이루어진 것이 아닙니다. 우리는 팀과 함께 확장되는 규율 있는 Git 워크플로우를 구현했기 때문입니다. , 저는 혼란에서 일관성으로 나아가기 위해 우리가 따랐던 정확한 관행, 패턴 및 원칙을 공유하겠습니다.

대부분의 팀이 Git 워크플로우를 잘못 이해하는 이유

제가 팀에서 자주 보는 근본적인 실수는 Git을 단순한 백업 시스템으로 취급하는 것입니다. 엔지니어링 팀과 상담할 때, 그들의 Git 사용의 60-70%가 팀 조정보다는 개별 개발자의 편의에 초점을 맞춘다는 것을 종종 발견합니다. 개발자들은 언제든지 느끼는 대로 커밋을 하며, 메시지는 "수정" 또는 "업데이트"와 같은 간단한 것들이고, 브랜치는 명확한 소유권이나 병합 전략 없이 몇 주 간 존재합니다.

이 접근 방식은 솔로 개발자나 아주 작은 팀에는 괜찮습니다. 그러나 5-7명의 활성 기여자가 상호 연결된 코드에서 작업할 때, 균열이 보이기 시작합니다. 저는 30개 이상의 서로 다른 엔지니어링 팀의 Git 기록을 분석했으며, 그 패턴은 일관적입니다: 명시적인 워크플로우 협의가 없는 팀은 적절한 워크플로우가 있으면 방지할 수 있는 통합 문제를 해결하는 데 개발 시간의 15-25%를 소비합니다.

문제는 Git이 매우 유연하다는 것에서 악화됩니다. 특정 패턴으로 강제하는 의견이 명확한 프레임워크와는 달리, Git은 당신에게 충분한 자유를 줍니다. 메인에 직접 커밋하거나 병합되지 않는 브랜치를 만들거나, 공유 브랜치에서 역사를 다시 작성하거나, 수십 개의 장기 기능 브랜치를 동시에 유지할 수 있습니다. Git은 당신을 막지 않지만, 당신의 팀 생산성은 영향을 받을 것입니다.

또 다른 중요한 문제는 Git 워크플로우와 배포 전략 간의 단절입니다. 저는 팀이 Git Flow와 같은 복잡한 브랜치 전략을 채택하는 것을 보았지만, 그들의 배포 파이프라인이 단일 진실의 출처를 기대한다는 점을 고려하지 않았습니다. 그 결과는 코드가 프로덕션으로 도달하는 방식과 실제로 일치하지 않는 복잡한 브랜치 관리입니다. 당신의 Git 워크플로우는 블로그 포스트의 이상적인 프로세스가 아니라 당신의 배포 현실을 반영해야 합니다.

Git에 성공하는 팀은 공통적으로 한 가지 특성을 가지고 있습니다: 그들은 자신의 워크플로에 대한 명시적인 결정을 내리고 그러한 결정을 명확하게 문서화했습니다. 그들은 단순히 Git을 사용하는 것이 아니라, 그들의 특정 팀 크기, 배포 빈도 및 위험 감수에 맞는 Git 전략을 설계했습니다. 이러한 의도성이 모든 차이를 만듭니다.

팀 규모에 맞는 올바른 브랜치 전략 선택하기

모든 브랜치 전략이 동등하게 만들어진 것은 아니며, "최고의" 전략은 팀의 맥락에 전적으로 의존합니다. 저는 다양한 팀에서 네 가지 다른 브랜치 전략을 구현했으며, 각각의 매력이 있습니다. 전략을 팀 규모 및 배포 주기에 맞추는 것에 대해 제가 배운 것을 정리해 드리겠습니다.

Git 워크플로우는 단순한 기술적 세부 사항이 아닙니다. 그것들은 팀의 속도와 제품 신뢰성의 기초입니다. 높은 성능을 내는 팀과 고군분투하는 팀의 차이는 종종 그들이 브랜치 전략을 얼마나 의도적으로 설계했는지에 달려 있습니다.

하루에 여러 번 배포하는 1-5명의 개발자 팀에게는 트렁크 기반 개발이 거의 무적입니다. 이 접근 방식은 모든 사람이 매우 짧은 기간(일수가 아닌 시간) 동안 유지되는 하나의 메인 브랜치에서 작업하게 합니다. 저의 이전 스타트업에서, 우리 4인 팀은 트렁크 기반 개발을 사용했고 하루에 8-12번 배포했습니다. 우리의 기능 브랜치는 평균 3.2시간 동안 살아있다가 병합되었습니다. 이로 인해 놀라운 추진력이 생성되었고, 아이디어에서 프로덕션까지 같은 날에 이동했으며, 모든 사람의 변경 사항이 끊임없이 혼합되었기 때문에 통합 문제가 즉시 발견되었습니다.

트렁크 기반 개발이 작동하는 핵심은 기능 플래그입니다. 완성되지 않은 기능이 배포를 차단해서는 안 되므로, 불완전한 작업을 플래그 뒤에 숨깁니다. 우리는 처음에 간단한 환경 변수 시스템을 사용한 후, 확장하면서 LaunchDarkly로 전환했습니다. 이를 통해 우리는 기능 가시성을 독립적으로 제어하면서 코드를 지속적으로 병합할 수 있었습니다.

일일 또는 주간 배포 주기를 가진 6-20명의 개발자 팀은 GitHub Flow가 구조와 단순성의 적절한 균형을 제공합니다. 항상 배포 가능한 하나의 메인 브랜치를 유지하고, 새로운 작업을 위한 기능 브랜치를 생성하며, 검토 후 풀 리퀘스트를 통해 병합합니다. 이 방법은 우리가 10명의 엔지니어를 초과할 때 채택한 것입니다. 우리의 평균 기능 브랜치는 현재 2.1일 동안 존재하며, 매일 아침 10시에 스탠드업 후 배포됩니다.

GitHub Flow는 모두가 이해하기에 충분히 간단하지만 혼란을 방지하기에 충분히 구조적이기 때문에 작동합니다. 풀 리퀘스트는 품질 게이트가 되며, 모든 변경 사항은 병합 전에 검토, 테스트 및 논의됩니다. 우리는 결제 또는 인증 코드에 영향을 미치는 PR에 대해 두 번의 승인을 요구하며, 나머지 모든 사항에 대해 한 번의 승인을 요구합니다. 이 방법으로 우리는 지난 분기에 프로덕션에 도달했을 잠재적인 버그 127개를 잡을 수 있었습니다.

더 큰 팀(20명 이상의 개발자) 혹은 복잡한 출시 일정을 가진 팀의 경우, Git Flow는 필요한 구조를 제공합니다. 이 전략은 여러 개의 장기 유지 브랜치를 사용합니다: 프로덕션을 위한 메인, 통합을 위한 개발, 및 릴리즈와 핫픽스 브랜치입니다. 저는 45명 팀에서 엄격한 QA 주기로 월간 릴리스를 발송하기 위해 Git Flow를 구현했습니다. 작업량은 현실적입니다. 더 많은 브랜치를 관리하고 더 많은 병합 작업을 수행하지만, 이는 조율된 릴리스를 위한 필요한 통제를 제공합니다.

핵심 통찰력은 당신의 브랜치 전략이 당신의 배포 현실과 일치해야 한다는 것입니다. 지속적으로 배포한다면, 복잡한 브랜치는 순수한 과중입니다. 광범위한 QA가 있는 예약된 릴리스를 가진 경우에는 그 구조가 필요합니다. 그저 복잡해 보인다고 해서 전략을 따라 하지는 마십시오.

실제 도움 되는 커밋 메시지 기준

저는 예전에는 커밋 메시지가 그다지 중요하지 않다고 생각했습니다. 그러던 중 프로덕션 문제를 디버깅하기 위해 우리의 Git 기록을 읽으며 네 시간을 소비한 후, "수정", "업데이트", "변경"과 같은 메시지를 발견했습니다. 그 경험은 저를 커밋 메시지 광신자로 만들었습니다. 좋은 커밋 메시지는 코드와 함께 영원히 존재하는 문서이며, 검색 가능하고, 맥락을 제공하며, 디버깅 시에 가치가 큽니다.

Conventional Commits 사양은 제가 작업하는 모든 팀에서 제 기준이 되었습니다. 이것은 간단한 형식입니다: 유형(기능, 수정, 문서, 리팩토링, 테스트 등), 선택적 범위 및 설명입니다. 예를 들어: "기능(auth): Google 로그인을 위한 OAuth2 지원 추가" 또는 "수정(결제): 재시도 시 중복 청구 방지"와 같은 형식입니다. 이 구조는 커밋 기록을 스캔 가능하게 하고, 변경 로그 생성 및 의미론적 버전 관리를 위한 자동화 도구를 가능하게 합니다.

우리는 이를 커밋 메시지가 수용되기 전에 검증하는 Git 훅으로 시행합니다. 처음에는 개발자들이 추가 구조에 불만을 표출했지만, 2주 후에는 모든 이가 명확성을 높이 평가하게 되었습니다. 여섯 달 전 특정 변경 사항이 왜 이루어졌는지를 이해해야 할 필요가 있을 때, 우리는 "수정(결제)"를 검색하고 즉시 관련 커밋을 찾을 수 있었습니다. 이렇게 하여 우리는 코드 고고학에서 매주 약 6시간을 절약할 수 있었습니다.

커밋 본문은 변경 사항 뒤에 있는 "이유"를 설명하는 곳입니다. diff는 변경된 내용을 보여주고, 커밋 메시지는 왜 변경되었고 어떤 문제를 해결하는지를 설명해야 합니다. 저는 개발자들에게 티켓 번호를 포함하고 관련 논의에 링크할 것을 권장합니다.