Git Workflow for Small Teams (Keep It Simple)

지난 화요일, 나는 한 주니어 개발자가 그들의 기능 브랜치가 머지되지 않는 이유를 알아내기 위해 사십오 분을 소모하는 것을 보았다. 범인은? 네 가지 서로 다른 브랜치 유형, 의무적인 리베이스 프로토콜, 그리고 이해하려면 플로우차트가 필요한 머지 전략이 포함된 우리 팀의 지나치게 복잡한 Git 워크플로우였다. 나는 12년 동안 엔지니어링 팀을 이끌어 왔고, 확신할 수 있다: 대부분의 작은 팀은 필요하지 않은 Git 복잡성에 빠져 있다.

저는 사라 첸이며, 지난 10년 동안 세 개의 다른 스타트업에서 개발 팀을 구축하고 확장하는 데 힘써왔습니다. 저는 다섯 명의 개발자가 오백 명의 엔지니어가 있는 조직을 위해 설계된 워크플로우를 사용하는 것을 보았습니다. 저는 뛰어난 프로그래머들이 실제 작업에 아무런 도움도 주지 않는 분기 전략을 탐색하는 데 몇 시간을 낭비하는 것을 지켜보았습니다. 그리고 소규모 팀을 위한 Git 워크플로우에 대해서는—두 명에서 열 명의 개발자라고 가정해봅시다—단순성이 단지 바람직한 것이 아니라는 것을 배웠습니다. 이는 기능을 배포하는 것과 혼란을 초래하는 것의 차이를 만듭니다.

아무도 말해주지 않는 사실: Git은 엄청나게 강력합니다. 이는 또한 지나치게 복잡하게 만드는 것이 매우 쉽다는 것을 의미합니다. 인터넷에는 Git-flow, GitHub flow, GitLab flow, 모개 발전 방식, 그리고 다른 전략에 대한 많은 글들이 있습니다. 그들 중 다수는 여러분이 갖고 있지 않은 문제들을 해결하고 있습니다. 저는 여러분에게 복잡한 기업 수준의 오버헤드 없이도 팀을 생산적이고 행복하게 유지하는 Git 워크플로우를 보여주겠습니다.

대부분의 Git 워크플로우가 작은 팀에서 실패하는 이유

무엇이 효과적인지 dive하기 전에, 무엇이 효과적이지 않은지 이야기해봅시다. 저는 develop 브랜치, release 브랜치, hotfix 브랜치 및 feature 브랜치를 사용한 팀으로부터 코드 베이스를 물려받았습니다. 주간 릴리스를 가진 SaaS 제품에서 네 명의 개발자로 구성된 팀에게는 이는 지나치게 복잡한 것이었습니다.

복잡한 워크플로의 문제는 잘못된 것이어서가 아니라—규모에서 발생하는 문제를 해결하고 있기에 문제입니다. Git-flow는 2010년 Vincent Driessen에 의해 특정 맥락을 위해 만들어졌습니다: 여러 생산 버전을 동시에 관리하고 긴 릴리스 주기와 광범위한 핫픽스 관리를 필요로 하는 팀. 여러분이 한 개의 생산 환경에 지속적으로 배포하는 소규모 팀이라면 Git-flow의 모든 오버헤드만 지고 있는 것입니다.

작년, 저는 비슷한 크기와 기술 수준의 두 팀으로 실험을 했습니다. 팀 A는 제가 설명할 단순화된 워크플로를 사용했습니다. 팀 B는 표준 Git-flow를 사용했습니다. 3개월 동안, 팀 A는 23% 더 많은 기능을 배포했으며 분기별 조사에서 가시적으로 낮은 좌절감을 보고했습니다. 그 차이는 재능이나 노력 때문이 아니라 마찰 때문이었습니다. 각 추가 브랜치 유형, 각 추가 머지 단계, 각 복잡한 리베이스 작업은 인지 부담을 더하고 팀의 속도를 늦춥니다.

소규모 팀은 대규모 조직과 다른 제약이 있습니다. 전담 릴리스 관리자가 없을 수도 있습니다. 여러 생산 버전을 지원할 필요가 없을 것입니다. 개발자들은 여러 역할을 수행하고 자주 문맥을 전환합니다. 귀하의 워크플로는 이러한 현실을 반영해야 하며, 이를 방해해서는 안 됩니다. 다섯 명의 팀이 Google과 동일한 Git 전략을 사용하고 있는 것을 보면, 그들이 오늘 소유한 문제보다는 언젠가 가질 수 있는 문제를 최적화하고 있음을 알 수 있습니다.

복잡성의 비용은 시간이 지남에 따라 누적됩니다. 매일 10분씩 불필요하게 복잡한 Git 워크플로를 탐색하는 개발자는 매년 40시간 이상의 시간—하루 종일 한 주—를 브랜치 관리에 소모합니다. 팀 전체에 이를 곱하면 매년 몇 주의 생산성이 손실된 것입니다. 이는 더 간단한 워크플로에서는 존재하지 않을 머지 충돌을 해결하는 데 소모되는 시간이나, 어떤 브랜치에 머지하는지 기억하는 데 소모되는 정신적 에너지를 고려하지 않은 것입니다.

두 개의 브랜치 철학: 메인과 기능

제가 이끌었던 모든 소규모 팀에서 효과를 본 워크플로는 다음과 같습니다: 두 가지 유형의 브랜치, 그것뿐입니다. 메인(또는 오래된 레포지토리와 함께 작업하는 경우 마스터)과 기능 브랜치입니다. 그게 전부입니다. develop 브랜치, release 브랜치, hotfix 브랜치는 없습니다. 단지 메인과 기능만 있습니다.

Git은 엄청나게 강력하며, 따라서 지나치게 복잡하게 만드는 것이 매우 쉽습니다. 대부분의 팀은 그들이 갖고 있지 않은 문제를 해결하고 있습니다.

귀하의 메인 브랜치는 생산을 나타냅니다. 메인에 있는 것은 언제든지 배포 가능해야 합니다. 이는 협상할 수 없는 것입니다. 만약 메인이 배포할 수 없다면, 귀하의 워크플로는 실패한 것입니다. 이 단일 원칙은 복잡성을 엄청나게 줄입니다. 왜냐하면 귀하는 항상 명확한 목표를 향해 작업하고 있으므로, 귀하의 코드를 메인에 안전하게 머지할 수 있는 상태로 만들기 위해 작업하고 있기 때문입니다.

기능 브랜치는 모든 작업이 이루어지는 곳입니다. 새 기능을 시작하나요? 메인에서 브랜치를 만듭니다. 버그를 수정하나요? 메인에서 브랜치를 만듭니다. 코드를 리팩토링하나요? 메인에서 브랜치를 만듭니다. 패턴은 일관되고 예측 가능합니다. 어떤 브랜치에서 브랜치를 생성할지, 어떤 브랜치에 머지할지에 대한 결정 트리가 없습니다. 모든 기능 브랜치는 동일한 생애 주기를 가지고 있습니다: 메인에서 브랜치 생성, 작업 수행, 메인으로 다시 머지.

기능 브랜치는 간단한 규칙으로 명명합니다: 유형/짧은 설명. 예를 들어: feature/user-authentication, bugfix/login-redirect, refactor/api-client. 유형 접두사는 어떤 종류의 작업이 이루어지고 있는지를 즉시 알 수 있게 해줍니다. 내가 브랜치 목록을 보았을 때 더 직관적이지 않다고 생각하지 않는 것은 티켓 번호(feature/JIRA-1234)를 사용하는 팀들을 보아왔습니다. 당신은 자신의 브랜치를 스캔하고 무엇이 작업되고 있는지를 즉시 파악할 수 있어야 합니다.

이 접근 방식의 장점은 그 예측 가능성입니다. 팀에 새로 합류한 개발자는 약 5분 만에 전체 Git 워크플로를 이해할 수 있습니다. 암기해야 할 복잡한 브랜칭 다이어그램도 없고, 기억해야 할 특별한 경우도 없습니다. 메인에서 브랜치 생성, 작업 수행, 메인으로 머지. 이 단순성은 생산성에 누적 효과를 줍니다. 워크플로가 단순하면 개발자는 프로세스에 덜 정신 에너지를 소모하고 실제 문제 해결에 더 많은 에너지를 쏟을 수 있습니다.

한 가지 자주 묻는 질문: 완공하는 데 몇 주가 걸리는 장기적인 기능은 어떻게 하나요? 이를 위해 develop 브랜치가 필요하지 않나요? 아닙니다. 기능 플래그가 필요합니다. 기능이 사용자에게 준비되지 않았다면, 플래그 뒤에 숨기십시오. 이를 통해 코드 통합을 지속적으로 유지하면서 기능이 언제 가시화될지에 대한 제어를 유지할 수 있습니다. 나는 기능 플래그가 더 우아하게 해결하는 문제를 풀기 위해 정교한 브랜칭 전략을 만드는 팀을 보아왔습니다.

풀 리퀘스트: 품질 게이트

모든 기능 브랜치는 풀 리퀘스트를 통해 메인에 머지됩니다. 예외는 없습니다. 당신이 CTO이건 단 한 줄의 변경이건 상관없습니다. 풀 리퀘스트는 단순한 코드 리뷰에 관한 것이 아니라, 코드가 생산에 들어가기 전에 의도적인 결정을 만드는 순간에 관한 것입니다.

여기에는 제가 수년간 실험을 통해 다듬어온 풀 리퀘스트 템플릿이 있습니다. 길지 않은 이유는 긴 템플릿은 제대로 작성되는 경우가 없기 때문입니다. 모든 풀 리퀘스트에는 무슨 변화가 있었는지, 왜 변화가 있었는지, 어떻게 테스트할 수 있는지를 간략하게 설명해야 합니다. 그게 전부입니다. 세 부분, 각 부분은 보통 세 문장에서 다섯 문장 정도입니다. 이 공간에서 변경 사항을 설명할 수 없다면, 아마도 변경 사항이 너무 크다는 것입니다.

코드 리뷰에 대해 저는 간단한 규칙을 따릅니다: 모든 풀 리퀘스트는 머지되기 전에 최소한 하나의 승인 필요하지만, 그것을 승인하는 사람은 발생하는 문제에 대한 책임을 공유합니다. 이는 올바른 인센티브 구조를 만듭니다. 리뷰어들은 단순히 스탬프를 찍는 것이 아니라 공동 서명하는 것이기 때문에 그들의 역할을 진지하게 받아들입니다. 동시에, 우리는 소규모 팀이므로 서로를 신뢰하므로 하나의 승인으로 충분합니다. 두 개 또는 세 개의 승인을 요구하는 것은 50명의 팀에 적합할 수 있지만, 5명의 팀에겐 단지 일을 지체하게 만들 뿐입니다.

저는 다양한 리뷰 턴어라운드 시간 기대치를 실험했습니다. 가장 잘 작동하는 것은: 리뷰어는 업무 시간 중에 4시간 이내에 피드백을 제공해야 합니다. 집중적인 리뷰 시간이 4시간이 아니라, 최소한 풀 리퀘스트를 인지하고 초기 피드백을 제공하는 데 4시간입니다. 이를 통해 코드가 이동하게 하면서 즉각적인 응답에 대한 기대를 만들지 않습니다. 누군가가 철저한 리뷰를 위한 시간이 더 필요하다면, 그들은 그렇게 의견을 남기고, 저자는 나중에 자세한 피드백을 받을 것임을 알게 됩니다.

우리 코드 품질을 극적으로 향상시킨 한 가지 관행: 풀 리퀘스트 작성자가 승인 후 자신이 작성한 코드를 머지해야 합니다. 이는 작은 세부사항처럼 보일 수 있지만, 행동을 변화시킵니다. 머지 버튼을 클릭할 사람이 자신인 것을 알면, 변경 사항에 대해 더 신중해집니다. 당신은