Git Workflow Best Practices for Teams - cod-ai.com

삼 년 전, 나는 포춘 500대 기업의 수석 개발자가 존재하지 않아야 할 병합 충돌을 해결하는 데 네 시간을 사용하는 것을 보았다. 그 원인? 합의된 워크플로우 없이 직접 master에 커밋하는 12명의 엔지니어 팀. 그 사건 하나로 회사는 대략 2,400달러의 개발자 시간을 잃었고, 이는 고립된 사례가 아니었다. 나는 마커스 첸이고, 지난 11년 동안 DevOps 아키텍트로 일하며 험난한 스타트업부터 대기업까지 다양한 팀들이 개발 워크플로우를 최적화하도록 도와왔다. 내가 배운 것은 Git 자체는 복잡하지 않다는 것이다—팀이 그것을 사용하는 방식이 그들이 얼마나 빠르게 배포하는지를 결정한다는 점이다.

고성능 엔지니어링 팀과 지속적으로 화재 상황을 처리하는 팀의 차이는 종종 그들의 Git 워크플로우로 귀결된다. GitLab이 실시한 2023년 조사에 따르면, 잘 정의된 Git 워크플로우를 가진 팀은 46% 더 자주 배포하고 60% 더 적은 생산 incident을 경험한다. 그럼에도 불구하고 내가 상담하는 대부분의 팀은 여전히 준비 없이 Git을 단순한 백업 시스템처럼 사용하고 있다.

왜 당신의 Git 워크플로우가 당신이 생각하는 것보다 더 중요한가

한 장면을 그려보겠다. 2019년, 나는 핀테크 스타트업에 최초의 DevOps 직원으로 합류했다. 그들은 8명의 개발자가 있었고, 모두 재능이 뛰어나지만 모두 좌절감을 느끼고 있었다. 그들의 배포 빈도는 주 2회에서 3주에 한 번으로 떨어졌다. 코드 리뷰는 며칠이 걸렸다. 핫픽스는 악몽이었다. 그들의 Git 기록을 조사했을 때, 나는 근본 원인을 발견했다: 그들은 전혀 워크플로우가 없었다.

개발자들은 "fix-thing"과 "johns-updates" 같은 이름의 브랜치를 만들고 있었다. 일부 커밋은 바로 master로 갔고, 다른 커밋은 몇 주 동안 브랜치에 남아 있었다. 코드 리뷰를 위한 명확한 프로세스가 없었고, 커밋 메시지를 위한 표준도 없었으며, Git 작업에 대한 자동화도 전혀 없었다. 저장소에서 발생하는 일들을 파악하는 데 필요한 인지 부담이 매일 몇 시간을 소모하고 있었다.

사람들이 간과하는 점은 이렇다: Git 워크플로우는 단순한 버전 관리가 아니다. 그것은 의사소통, 조정, 아이디어에서 생산으로 코드가 이동하는 방법에 대한 공동의 정신 모델을 만드는 것이다. 올바르게 수행되면, 당신의 Git 워크플로우는 개발자들이 혼란을 관리하는 대신 코드 작성에 집중하게 하는 보이지 않는 인프라가 된다.

그 영향은 측정할 수 있다. 그 핀테크 스타트업에서 구조화된 워크플로우를 구현한 후, 우리는 배포 빈도가 한 달 이내에 주 2회로 돌아오고 결국 6개월 이내에 매일 배포에 도달하는 것을 보았다. 코드 리뷰 시간은 평균 3.2일에서 8시간으로 줄어들었다. 개발자 만족도 점수는 34포인트 상승했다. 그리고 여기서 중요한 점은: 우리는 더 많은 사람을 고용하거나 기술 스택을 변경하지 않았다. 우리는 단지 Git 사용 방법에 대해 합의했을 뿐이다.

팀에 적합한 워크플로 모델 선택하기

모든 팀에 적합한 Git 워크플로는 없으며, 그렇지 않다고 말하는 사람은 무언가를 팔고 있는 것이다. 내 경력 동안, 나는 모든 주요 워크플로우 모델의 변형을 구현해왔고, 각각의 모델마다 그 자리가 있다. 핵심은 팀의 규모, 출시 주기, 위험 감수성에 맞춰 워크플로우를 맞추는 것이다.

"Git 워크플로우는 단순한 버전 관리가 아니라, 인지 부담을 줄이고, 병렬 개발을 가능하게 하며, 팀이 코드를 배포하는 방법에 대한 공동의 언어를 만드는 것이다."

지속적인 배포를 위해 작업하는 소규모 팀(2-5명 개발자)에게는 보통 간소화된 트렁크 기반 개발 접근 방식을 추천한다. 개발자들은 몇 시간 또는 많아야 며칠 동안 유지되는 단기 기능 브랜치에서 작업한 후, 검토 후 바로 메인에 병합한다. 이는 코드베이스를 신선하게 유지하고 병합 충돌을 극적으로 줄인다. 나는 4명 팀과 SaaS 분석 플랫폼을 구축할 때 이를 성공적으로 사용했고, 우리는 평균 4시간 브랜치 수명을 유지하며 하루에 3-4회 배포했다.

중간 규모 팀(6-20명 개발자)은 종종 GitHub Flow나 유사한 풀 리퀘스트 기반 워크플로우의 이점을 누릴 수 있다. 이는 여러 개의 장기 유지 브랜치의 복잡함 없이 코드 리뷰와 테스트에 대한 더 많은 구조를 추가한다. 14명의 개발자가 있는 헬스케어 기술 회사에서 우리는 GitHub Flow에 변형을 주어 모든 풀 리퀘스트에 두 개의 승인이 필요하고 15분의 자동화된 테스트를 통과해야 했다. 이는 우리가 HIPAA 준수를 위한 안전성을 확보하면서 브랜치 생성에서 생산까지의 평균 시간을 2일로 유지할 수 있게 했다.

더 큰 팀이나 예정된 릴리스를 갖고 있는 경우 Git Flow나 사용자 정의 변형이 필요할 수 있다. 나는 45명의 개발자가 있는 전자상거래 회사에서 2주마다 출시하는 팀과 함께 일했다. 우리는 개발, 릴리스, 마스터 브랜치를 포함한 수정된 Git Flow를 사용하고 모든 작업에 기능 브랜치를 추가했다. 예, 더 복잡했지만, 여러 팀 간 협조 작업을 조정하고 안정적인 출시 일정 유지에 필요한 통제를 제공했다.

내가 보는 최악의 실수는 팀이 블로그 게시물에서 워크플로우를 그대로 적용하는 것이다. 200명 규모의 구글 팀에 잘 맞는 워크플로우가 8명 스타트업에게는 과하면 과한 것이거나 불충분할 수 있다. 간단하게 시작하고, 중요한 것을 측정하라(배포 빈도, 리드 타임, 변경 실패율), 그리고 이론적인 문제를 기반으로 하지 않고 실질적인 문제점을 기준으로 워크플로우를 발전시켜라.

실제로 작동하는 브랜치 명명 규칙

이것은 사소하게 들릴 수 있지만, 일관되지 않은 브랜치 명명은 내가 접하는 상위 세 가지 워크플로우 문제 중 하나이다. 저장소에 "test", "new-feature", "fix", "johns-branch", "URGENT-FIX-DO-NOT-DELETE"와 같은 이름의 브랜치가 있다면, 시작하기도 전에 이미 패배한 것이다.

좋은 브랜치 명명 규칙은 여러 용도로 사용된다: 저장소를 탐색 가능하게 하고, 자동화를 가능하게 하며, 의도를 전달한다. 내가 수십 번의 구현을 통해 다듬은 시스템은: type/ticket-description이다. 예를 들어: "feature/AUTH-123-oauth-integration" 또는 "bugfix/PROD-456-payment-timeout."

유형 접두사(기능, 버그 수정, 핫픽스, 리팩토링, 문서)는 당신과 당신의 도구가 브랜치의 목적을 즉시 이해할 수 있도록 한다. 티켓 번호는 코드를 프로젝트 관리 시스템과 연결하여 추적 가능성을 만든다. 설명은 브랜치를 사람 읽기에 적합하도록 만든다. 이 간단한 패턴은 내가 함께 작업했던 모든 팀에서 수많은 시간의 혼란을 구했다.

한 회사에서는 자동화와 함께 이를 한층 더 발전시켰다. 우리의 CI 시스템은 브랜치 접두사에 따라 다른 테스트 슈트를 자동으로 적용했다—기능 브랜치는 전체 슈트를 실행하고, 버그 수정 브랜치는 목표 테스트를 실행하며, 문서 브랜치는...