소규모 팀을 위한 Git 분기

다음은 제가 개인적으로 사용하고 오픈 소스 프로젝트와 제가 업무를 위해 운영하는 모든 소규모 팀 내에서 권장하는 방법입니다. 몇 가지 다른 이름으로 제공되는 주요 요소를 보았습니다. Short-Lived Feature Branch 흐름, GitHub flow (GitFlow와 혼동하지 말 것) 및 Feature Branch Workflow이 일부입니다. 수년에 걸쳐 여러 팀과 함께 이 모든 기능에서 마음에 드는 기능을 구현한 결과 약 5~12명으로 구성된 소규모 팀에 가장 적합한 결과 프로세스를 설명하겠습니다.

보호된 메인 브랜치

지속적인 전달을 지원하려면 어떤 사람도 master 분기에 대한 직접 푸시 권한이 없어야 합니다. GitHub에서 개발하는 경우 이 브랜치의 최신 태그는 배포될 때 배포됩니다create a release. 이는 매우 자주, 매우 자동화되어 있기를 바랍니다.

하나의 이슈, 하나의 브랜치, 하나의 PR

당신은 이미 향후 기능과 현재 버그를 문제로 추적하는 일을 훌륭하게 수행하고 있습니다(그렇죠?). 잠시 제쳐두자면 이슈는 메인 브랜치에 병합할 수 있고 아무 것도 손상시키지 않고 배포할 수 있는 잘 정의된 작업입니다. 새로운 기능, 버튼 구성 요소 업데이트 또는 버그 수정일 수 있습니다.


마스터의 이슈 브랜치 및 릴리스에 대한 저자의 그림.

문제당 수명이 짧은 분기는 결과 풀 요청이 너무 커지지 않도록 하여 취급하기 어렵고 신중하게 검토하기 어렵게 만듭니다. "단기"의 정의는 팀 또는 프로젝트의 개발 속도에 따라 다릅니다. 스타트업과 같은 상업용 앱을 제작하는 소규모 팀의 경우 이슈 브랜치 생성에서 PR까지의 시간은 아마도 일주일을 초과하지 않을 것입니다. OWASP WSTG과 같은 오픈 소스 프로젝트의 경우 자원 봉사자가 바쁜 일정에 따라 일하는 경우 기여자에 따라 지점이 몇 주에서 몇 달 동안 유지될 수 있습니다. 일반적으로 가능한 한 짧은 시간 안에 반복하도록 노력하십시오.

실제 모습은 다음과 같습니다. (#28) 사용자 설정 추가 페이지라는 문제의 경우 master에서 새 분기를 확인하십시오.

# Get all the latest work locally
git checkout master
git pull
# Start your new branch from master
git checkout -b 28/add-settings-page

문제를 해결하고 주기적으로 병합master하여 다른 충돌을 수정하고 방지합니다.

# Commit to your issue branch
git commit ...
# Get the latest work on master
git checkout master
git pull
# Return to your issue branch and merge in master
git checkout 28/add-settings-page
git merge master

master 에 병합하는 대신 리베이스를 사용하는 것이 좋습니다. 이것은 내 개인적인 취향이기도 하지만 사람들은 일반적으로 병합보다 리베이스가 작동하는 방식에 대해 머리를 감싸는 데 더 어려움을 겪는 것 같습니다. 대화식 리베이스는 혼란스러운 오류를 쉽게 도입할 수 있으며 다시 쓰기 기록은 처음부터 혼란스러울 수 있습니다. 일반적으로 개발자의 프로세스에서 인지 부하를 줄이는 것이 중요하므로 병합 전략을 사용하는 것이 좋습니다.

이슈 작업이 PR할 준비가 되면 master에 대한 요청을 엽니다. 자동화된 테스트가 실행됩니다. 팀원이 작업을 검토합니다(GitHub에 있는 경우 inline comments and suggestions 사용). 프로젝트에 따라 미리 보기 버전도 배포할 수 있습니다.

모든 것이 확인되면 PR이 병합되고 이슈가 종료되며 분기가 삭제됩니다.

청소해라

이 흐름을 약화시킬 수 있는 몇 가지 일반적인 함정은 다음과 같습니다.

다른 기능/이슈 분기에서 기능 분기를 생성합니다. 이것은 잘못된 조직과 우선 순위 지정의 결과입니다. 혼란스러운 충돌과 종속성을 피하려면 항상 최신 버전master을 분기하십시오.

문제 분기를 조금 더 오래 유지합니다. 이로 인해 검토하는 데 많은 시간과 정신적 노력이 필요한 범위 크립과 거대하고 혼란스러운 PR이 발생합니다. 닫으려는 하나의 문제에 대해 분기 범위를 엄격하게 유지합니다.

병합된 분기를 삭제하지 않습니다. 남겨둘 이유가 없습니다. 모든 작업은 master에 있습니다. 부실하거나 이미 병합된 분기를 제거하지 않으면 혼란이 발생하고 새 분기를 구분하는 것이 필요 이상으로 어려워질 수 있습니다.

이것이 당신이 사용할 프로세스처럼 들리거나 추가할 것이 있으면 의견에 알려주십시오!