Close

Git 기능 브랜치 워크플로

기능 브랜치 워크플로의 핵심 개념은 모든 기능 개발이 main 브랜치가 아닌 전용 브랜치에서 이루어져야 한다는 것입니다. 이 캡슐화를 통해 여러 개발자가 메인 코드베이스를 방해하지 않고도 특정 기능을 대해 쉽게 작업할 수 있습니다. 또한 main 브랜치에 중단된 코드가 절대 포함되지 않는다는 뜻이기도 하며, 이것은 지속적 통합 환경에 큰 이점을 제공합니다.

기능 개발을 캡슐화하면 브랜치에 대한 의논을 시작하는 방법인 풀리퀘스트를 활용할 수도 있습니다. 풀리퀘스트는 기능이 공식 프로젝트에 통합되기 전에 다른 개발자에게 기능을 승인할 기회를 줍니다. 또는 기능 도중에 어려움에 부딪히는 경우 풀리퀘스트를 열면 동료들에게 제안을 요청할 수도 있습니다. 요점은 풀리퀘스트를 통해 팀이 서로의 작업에 의견을 제시하기가 매우 쉬워진다는 것입니다.

Git 기능 브랜치 워크플로는 다른 전반적인 Git 워크플로에서도 활용할 수 있는 구성 가능한 워크플로입니다. Git 워크플로 개요 페이지에서 다른 Git 워크플로에 대해 논의했습니다. Git 기능 브랜치 워크플로는 브랜칭 모델에 중점을 두고 있습니다. 즉, 브랜치를 관리하고 만들기 위한 안내 프레임워크입니다. 다른 워크플로는 리포지토리에 더 중점을 둡니다. Git 기능 브랜치 워크플로는 다른 워크플로에 통합할 수 있습니다. GitflowGit 포킹 워크플로는 일반적으로 브랜칭 모델에 있어서 Git 기능 브랜치 워크플로를 사용합니다.


작동 방식


기능 브랜치 워크플로는 중앙 리포지토리를 가정하고 main은 공식 프로젝트 기록을 나타냅니다. 개발자들은 로컬 main 브랜치에서 직접 커밋하는 대신 새 기능에 대한 작업을 시작할 때마다 새 브랜치를 만듭니다. 기능 브랜치에는 animated-menu-items 또는 issue-#1061와 같이 설명을 포함한 이름이 있어야 합니다. 브랜치마다 명확하고 집중된 목적을 부여하는 것이 목적입니다. Git은 main 브랜치와 기능 브랜치를 기술적으로 구분하지 않으므로 개발자들은 기능 브랜치를 편집하고 스테이징하고 변경 사항을 커밋할 수 있습니다.

또한 기능 브랜치는 중앙 리포지토리로 푸시될 수 있고 또 푸시되어야 합니다. 이렇게 하면 공식 코드를 건드리지 않고도 다른 개발자들과 기능을 공유할 수 있습니다. main이 유일한 “특별” 브랜치이기 때문에 중앙 리포지토리에 여러 기능 브랜치를 저장해도 문제가 되지 않습니다. 물론 이것은 모두의 로컬 커밋을 백업하는 편리한 방법이기도 합니다. 다음은 기능 브랜치의 수명 주기에 대해 살펴보겠습니다.

main 브랜치에서 시작

모든 기능 브랜치는 프로젝트의 최신 코드 상태를 기반으로 만들어집니다. 이 가이드에서는 기능 브랜치가 main 브랜치에서 유지 및 업데이트된다고 가정합니다.

콘솔 창
관련 자료

고급 Git 로그

Bitbucket 로고
솔루션 보기

Bitbucket Cloud에서 Git에 대해 알아보기

git checkout main
git fetch origin 
git reset --hard origin/main

리포지토리 생성

그러면 리포지토리가 main 브랜치로 전환되고, 최신 커밋을 풀하며, 리포지토리의 main 로컬 복사본을 최신 버전과 일치하도록 재설정합니다.

새 브랜치 만들기

작업 중인 기능이나 이슈마다 별도의 브랜치를 사용합니다. 브랜치를 만든 후에는 변경 사항이 해당 브랜치에 적용되도록 로컬에서 체크아웃합니다.

git checkout -b new-feature

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

변경 사항 업데이트, 추가, 커밋, 푸시

이 브랜치에서는 일반적인 방식으로 변경 사항을 편집, 스테이징 및 커밋하여 필요한 만큼 최대한 많은 커밋으로 기능을 구축합니다. Git을 사용할 때와 마찬가지로 기능에 대해 작업하고 커밋합니다. 준비가 되면 커밋을 푸시하고 Bitbucket에서 기능 브랜치를 업데이트합니다.

git status
git add <some-file>
git commit

기능 브랜치를 원격으로 푸시

기능 브랜치를 중앙 리포지토리로 푸시하는 것이 좋습니다. 이것은 다른 개발자들과 공동 작업할 때 편리한 백업 역할을 하며, 새 브랜치에 대한 커밋을 볼 수 있는 액세스 권한을 제공합니다.

git push -u origin new-feature

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

피드백 확인

이제 팀원들이 푸시된 커밋에 댓글을 추가하고 승인합니다. 로컬에서 댓글을 확인 및 커밋하며, 제안된 변경 사항을 Bitbucket에 푸시합니다. 업데이트는 풀리퀘스트에 나타납니다.

풀리퀘스트 병합

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

풀리퀘스트


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

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

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

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


다음은 기능 브랜칭 워크플로를 사용하는 시나리오 유형의 예시입니다. 한 팀이 새로운 기능 풀리퀘스트에 대해 코드를 검토하는 시나리오입니다. 이 모델을 사용할 수 있는 여러 가지 용도 중 하나에 해당합니다.

새 기능을 시작한 Mary

기능 브랜치 일러스트레이션

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

git checkout -b marys-feature main

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

git status
git add <some-file>
git commit

점심 식사를 하러 가는 Mary

중앙 리포지토리로 푸시

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

git push -u origin marys-feature

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

기능을 완료한 Mary

풀 리퀘스트

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

git push

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

풀리퀘스트를 받은 Bill

풀리퀘스트 검토 일러스트

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

변경 사항을 적용하는 Mary

풀리퀘스트 수정

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

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

기능을 게시한 Mary

게시 기능

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

git checkout main
git pull
git pull origin marys-feature
git push

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

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

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

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

요약


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

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

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

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


이 문서 공유
다음 토픽

여러분께 도움을 드릴 자료를 추천합니다.

이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.

도구로 가득한 벽을 사용하여 협업하는 사람들

Bitbucket 블로그

DevOps 일러스트레이션

DevOps 학습 경로

Atlassian 전문가와 함께 하는 Demo Den 기능 데모

Bitbucket Cloud가 Atlassian Open DevOps와 작동하는 방법

DevOps 뉴스레터 신청

Thank you for signing up