Git 기능 브랜치 워크플로

이것은 main을 기반으로 하는 new-feature라는 브랜치를 체크아웃하고, -b 플래그는 Git에게 브랜치가 이미 존재하지 않으면 만들도록 지시합니다.

이 명령은 new-feature을 중앙 리포지토리(오리진)에 푸시하고 -u 플래그는 이를 원격 추적 브랜치로 추가합니다. 추적 브랜치를 설정한 후 매개 변수 없이 git push를 호출하여 new-feature 브랜치를 중앙 리포지토리에 자동으로 푸시할 수 있습니다. 새로운 기능 브랜치에 대한 피드백을 받으려면 Bitbucket Cloud 또는 Bitbucket Data Center와 같은 리포지토리 관리 솔루션에서 풀리퀘스트를 만듭니다. 여기에서 검토자를 추가하고 병합하기 전에 모든 것이 문제가 없는지 확인할 수 있습니다.

다른 팀원이 리포지토리를 변경한 경우 병합하기 전에 병합 충돌을 해결해야 할 수 있습니다. 풀리퀘스트가 승인되고 충돌이 없으면 main 브랜치에 코드를 추가할 수 있습니다. Bitbucket의 풀리퀘스트에서 병합합니다.

브랜치는 기능 개발을 분리하는 것 외에도 풀리퀘스트를 통해 변경 사항을 의논할 수 있게 해줍니다. 누군가 어떤 기능을 완료하면 그 기능을 main에 즉시 병합하지 않습니다. 대신 기능 브랜치를 중앙 서버로 푸시하고 추가된 내용을 main에 병합하도록 요청하는 풀리퀘스트를 제출합니다. 이렇게 하면 변경 사항이 메인 코드베이스의 일부가 되기 전에 다른 개발자들이 검토할 기회를 갖게 됩니다.

코드 검토는 풀리퀘스트의 주요 이점이지만 사실은 코드에 대해 이야기를 나눌 수 있는 일반적인 방법입니다. 풀리퀘스트를 특정 브랜치에 대한 전용 의논으로 생각할 수 있습니다. 따라서 개발 프로세스에서 훨씬 더 일찍부터 사용할 수도 있습니다. 예를 들어, 개발자가 특정 기능에 대해 도움이 필요하면 풀리퀘스트를 제출하기만 하면 됩니다. 그러면 이해 관계자들은 자동으로 알림을 받고 관련 커밋 바로 옆에서 질문을 볼 수 있습니다.

풀리퀘스트가 수락되면 기능을 게시하는 실제 작업은 중앙 워크플로에서와 거의 동일합니다. 먼저 로컬 main이 업스트림 main과 동기화되었는지 확인해야 합니다. 그런 다음 기능 브랜치를 main에 병합하고 업데이트된 main을 다시 중앙 리포지토리로 푸시합니다.

풀리퀘스트는 Bitbucket Cloud 같은 소스 코드 관리 솔루션으로 제공될 수 있습니다.

Mary는 기능 개발을 시작하기 전에 작업을 하기 위한 분리된 브랜치가 필요합니다. 그녀는 다음 명령을 통해 새 브랜치를 요청할 수 있습니다.

이것은 main을 기반으로 하는 marys-feature라는 브랜치를 체크아웃하고, -b 플래그는 Git에게 브랜치가 이미 존재하지 않으면 만들도록 지시합니다. Mary는 이 브랜치에서 일반적인 방식으로 변경 사항을 편집, 스테이징 및 커밋하여 필요한 만큼 최대한 많은 커밋으로 기능을 구축합니다.

Mary는 오전 시간 동안 기능에 몇 가지 커밋을 추가합니다. 점심을 먹으러 가기 전에 기능 브랜치를 중앙 리포지토리에 푸시하는 것이 좋습니다. 이것은 편리한 백업 역할을 하지만 Mary가 다른 개발자들과 공동 작업하는 경우 해당 개발자들은 Mary의 초기 커밋에 대한 액세스 권한을 갖게 됩니다.

이 명령은 marys-feature를 중앙 리포지토리(오리진)에 푸시하고 -u 플래그는 이를 원격 추적 브랜치로 추가합니다. 추적 브랜치를 설정한 후 Mary는 매개 변수 없이 git push를 호출하여 기능을 푸시할 수 있습니다.

Mary는 점심 식사를 마치고 돌아와 기능을 완료합니다. main에 기능을 병합하기 전에 나머지 팀원에게 작업이 끝났음을 알리는 풀리퀘스트를 제출해야 합니다. 그러나 중앙 리포지토리에 가장 최근 커밋이 있는지부터 확인해야 합니다.

그런 다음 Mary는 main에 marys-feature를 병합하도록 요청하는 풀리퀘스트를 Git GUI에 제출하고 팀원들에게 자동으로 알림이 전송됩니다. 풀리퀘스트의 가장 큰 이점은 관련 커밋 바로 옆에 댓글이 표시되므로 특정 변경 집합에 대해 쉽게 질문할 수 있다는 것입니다.

Bill은 풀리퀘스트를 받고 marys-feature를 살펴봅니다. 그는 기능을 공식 프로젝트에 통합하기 전에 몇 가지 변경 사항을 적용하기로 결정하고 Bill과 Mary는 풀리퀘스트를 통해 몇 가지 의견을 주고받습니다.

Mary는 변경 사항을 적용하기 위해 기능의 첫 번째 반복을 만들 때와 똑같은 프로세스를 사용합니다. 편집, 스테이징 및 커밋하고 중앙 리포지토리에 업데이트를 푸시합니다. Mary의 모든 활동은 풀리퀘스트에 표시되며 그동안 Bill은 계속해서 댓글을 추가할 수 있습니다.

원하는 경우 Bill은 marys-feature를 로컬 리포지토리로 풀하여 직접 작업할 수도 있습니다. Bill이 추가한 모든 커밋은 풀리퀘스트에 표시됩니다.

Bill이 풀리퀘스트를 수락할 준비가 되면 누군가 기능을 안정적인 프로젝트에 병합해야 합니다. 이 작업은 Bill 또는 Mary가 수행할 수 있습니다.

이 프로세스로 인해 병합 커밋이 발생하는 경우가 많습니다. 기능과 나머지 코드베이스의 상징적 결합과도 같아서 병합 커밋을 좋아하는 개발자도 있습니다. 하지만 선형 기록을 좋아한다면 병합을 실행하기 전에 main의 팁으로 기능을 다시 지정하여 병합을 빨리 감기할 수 있습니다.

일부 GUI는 “수락” 버튼을 클릭함으로써 이러한 모든 명령을 실행하여 풀리퀘스트 수락 프로세스를 자동화합니다. 그렇지 않은 GUI라면 기능 브랜치가 main에 병합될 때 최소한 풀리퀘스트를 자동으로 종료할 수 있어야 합니다.

한편, John이 똑같은 일을 하고 있습니다.

Mary와 Bill이 marys-feature 작업을 수행하며 풀리퀘스트에서 논의하는 동안 John은 자신의 기능 브랜치에서 똑같은 일을 하고 있습니다. 기능을 별도의 브랜치로 분리하면 모두가 독립적으로 작업할 수 있지만 필요한 경우 다른 개발자들과 변경 사항을 공유하는 것은 여전히 간단합니다.

이 문서에서는 Git 기능 브랜치 워크플로에 대해 살펴봤습니다. 이 워크플로는 비즈니스 도메인 기능 집합에 초점을 맞춘 브랜치를 구성하고 추적하는 데 도움이 됩니다. Git 포킹 워크플로 및 Gitflow 워크플로와 같은 다른 Git 워크플로는 리포지토리에 중점을 두고 있으며 Git 기능 브랜치 워크플로를 활용하여 브랜칭 모델을 관리할 수 있습니다. 이 문서는 Git 기능 브랜치 워크플로를 구현하기 위한 전반적인 코드 예시와 가상 예시를 보여주었습니다. 기능 브랜치 워크플로와 관련된 몇 가지 주요 사항은 다음과 같습니다.

• 브랜칭 패턴에 초점 맞춤
• 다른 리포지토리 중심 워크플로에서 활용 가능
• 풀리퀘스트 및 병합 검토를 통해 팀원과의 공동 작업 촉진

기능 브랜치의 검토 및 병합 단계에서 git rebase를 활용하면 기능 병합에 대한 응집력 있는 Git 기록을 만들 수 있습니다. 기능 브랜칭 모델은 팀 환경 내에서 공동 작업을 촉진하는 훌륭한 도구입니다.

Gitflow 워크플로에 대한 포괄적인 자습서를 읽고 Git 워크플로에 대해 자세히 알아보세요.