기능 분기 워크플로 살펴보기
기능 분기 워크플로의 핵심 개념은 모든 기능 개발이 기본 분기 대신 전용 분기에서 발생해야 한다는 점입니다.
캡슐화를 사용하면 여러 개발자가 기본 코드베이스를 방해하지 않고 특정 기능에 대한 작업을 쉽게 진행할 수 있습니다. 이는 기본 분기에 손상된 코드가 포함되지 않는다는 의미이기도 하며, 연속 통합 환경에 큰 이점으로 작용합니다.
기능 개발을 캡슐화하면 끌어오기 요청도 사용할 수 있습니다. 이 요청은 분기에 대한 논의를 시작하는 방법입니다. 이를 통해 기능이 공식 프로젝트에 통합되기 전에 다른 개발자가 해당 기능에서 로그아웃할 수 있습니다. 또는 기능 중간에 멈춘 경우 동료의 제안을 요청하는 끌어오기 요청을 열 수 있습니다.
끌어오기 요청을 사용하면 팀이 서로의 작업에 대해 아주 쉽게 댓글을 달 수 있습니다. 또한 기능 분기는 중앙 리포지토리로 푸시될 수 있고 푸시되어야 합니다. 공식 코드를 건드리지 않고 다른 개발자와 기능을 공유할 수 있습니다.
기본이 유일한 "특수" 분기이므로, 중앙 리포지토리에 여러 기능 분기를 저장해도 문제가 되지 않습니다. 이는 모든 사람의 로컬 커밋을 백업하는 편리한 방법이기도 합니다.
릴리스 분기 워크플로
기능 분기 워크플로 외에도 Git 분기 워크플로에서 일반적으로 사용되는 또 다른 전략은 릴리스 분기 전략입니다. 이 전략에는 릴리스를 준비하기 위한 전용 분기의 생성이 포함됩니다. 릴리스 분기는 일반적으로 안정적인 기능 분기에서 생성되므로 철저히 테스트되고 검증된 코드만 포함됩니다. 릴리스 분기가 생성되면 배포용 코드베이스를 준비하기 위해 추가 테스트, 버그 수정, 안정화 작업을 거칩니다. 릴리스 분기를 통해 진행 중인 기능 개발에서 릴리스 관련 활동을 격리할 수 있으므로 향후 릴리스를 마무리하고 다듬을 수 있는 제어된 환경이 제공됩니다. 릴리스 분기에 필요한 모든 조정 및 확인이 완료된 후 팀의 릴리스 프로세스에 따라 기본 분기에 병합되거나 프로덕션에 바로 배포됩니다. 릴리스 분기 전략은 팀이 지속적인 개발을 위해 안정적인 기본 분기를 유지하면서 릴리스 활동 조정의 복잡성을 관리하는 데 도움이 됩니다.
트렁크 기반 개발 워크플로
트렁크 기반 개발 워크플로는 중앙 리포지토리를 가정하며, 기본은 공식 프로젝트 기록을 나타냅니다. 개발자는 로컬 기본 분기에 직접 커밋하는 대신, 새 기능에 대한 작업을 시작할 때마다 새 분기를 만듭니다. 기능 분기의 이름은 new-banner-images 또는 bug-91처럼 설명이 포함되어 있어야 합니다. 이렇게 하면 각 분기의 목적을 분명하고 확실하게 나타낼 수 있습니다.
Git은 기본과 기능 분기를 기술적으로 구분하지 않으므로, 개발자가 기능 분기에 대한 변경 내용을 편집하고 스테이징 및 커밋할 수 있습니다.
분기 만들기
프로젝트에서 작업할 때 진행 중인 다양한 기능이나 아이디어를 언제라도 사용하게 될 것입니다. 일부는 사용할 준비가 되고 있고, 나머지는 그렇지 않습니다. 분기는 이 워크플로를 관리하는 데 도움이 됩니다. 프로젝트에서 분기를 만들 때 새로운 아이디어를 시도해 볼 수 있는 환경을 만듭니다.
릴리스 분기 워크플로를 따르는 팀은 새로운 기능 또는 수정을 위한 분기를 만드는 것 외에도 특히 릴리스 준비를 위한 전용 분기 또한 만듭니다. 이러한 릴리스 분기는 철저하게 테스트되고 검증된 코드를 포함하도록 일반적으로 안정적인 기능 분기에서 파생됩니다. 릴리스 분기가 생성되면 배포용 코드베이스를 준비하기 위해 추가 테스트, 버그 수정, 안정화 작업을 거칩니다.
커밋 추가
분기를 만들었으면 이제 변경할 시간입니다. 파일을 추가, 편집하거나 삭제할 때마다 커밋을 만들어 분기에 추가합니다.
커밋 추가는 기능 분기에서 작업할 때 진행 상황을 추적합니다.
또한 커밋은 다른 사람이 수행한 작업과 그 이유를 이해하기 위해 팔로우할 수 있는 투명한 작업 기록을 만듭니다.
각 커밋에는 특정 내용을 변경한 이유를 설명하는, 연관된 커밋 메시지가 있습니다.
그뿐 아니라 각 커밋은 별도의 변경 단위로 간주됩니다. 이로 인해 버그가 발견되거나 방향을 바꾸기로 결정한 경우 변경 내용을 롤백할 수 있습니다.
커밋 메시지는 특히 Git에서 변경 내용을 추적한 후 서버에 푸시되면 이를 커밋으로 표시하기 때문에 반드시 필요합니다.
명확한 커밋 메시지를 작성하면 다른 사람이 더 쉽게 함께 팔로우하고 피드백을 제공할 수 있습니다.
끌어오기 요청 열기
끌어오기 요청에서 커밋에 대한 논의가 시작됩니다. 기본 Git 리포지토리와 긴밀하게 통합되어 있으므로, 요청을 수락하면 병합되는 변경 내용을 누구나 정확하게 볼 수 있습니다.
다음과 같은 경우 개발 프로세스 중에 언제든지 끌어오기 요청을 열 수 있습니다.
- 코드는 거의 또는 전혀 없지만 일부 스크린샷이나 일반적인 아이디어를 공유하려는 경우.
- 무엇을 해야 할지 몰라서 도움이나 조언이 필요한 경우.
- 다른 사람이 자신의 작업을 검토할 수 있도록 준비된 경우.
끌어오기 요청 메시지에서 @mention 시스템을 사용하면 특정한 사람이나 팀이 복도 끝에 있든, 10시간의 시차가 있는 곳에 있든 상관없이 이들로부터 피드백을 요청할 수 있습니다.
끌어오기 요청은 프로젝트에 기여하고 공유 리포지토리에 대한 변경 내용을 관리하는 데 도움이 됩니다.
포크 및 끌어오기 모델을 사용하는 경우 끌어오기 요청은 프로젝트 유지 관리자가 고려하기를 바라는 변경 사항을 알리는 방법이기도 합니다.
공유 리포지토리 모델을 사용하는 경우, 끌어오기 요청은 기본 분기에 병합되기 전에 제안된 변경 내용에 대한 코드 검토와 대화를 시작하는 데 도움이 됩니다.
코드 논의 및 검토
끌어오기 요청이 열리면 변경 내용을 검토하는 사람 또는 팀이 질문을 하거나 댓글을 달 수 있습니다.
코딩 스타일이 프로젝트 지침과 일치하지 않거나 변경 내용에 단위 테스트가 없을 수도 있고, 모든 내용이 훌륭해 보이고 속성이 적절할 수도 있습니다.
끌어오기 요청은 이 유형의 대화를 장려하고 캡처하도록 설계되었습니다.
또한 커밋에 대한 토론과 피드백을 고려하여 분기에 계속 푸시할 수 있습니다.
여러분이 무언가 잊었다는 댓글을 달았거나, 코드에 버그가 있는 경우 분기에서 수정하고 변경 내용을 푸시할 수 있다고 가정해 보세요.
Git은 통합된 끌어오기 요청 보기에서 받을 수 있는 새 커밋과 피드백을 표시합니다.
끌어오기 요청 댓글은 Markdown으로 작성되므로 이미지와 이모지, 미리 서식이 지정된 텍스트 블록 및 다른 간단한 서식을 사용할 수 있습니다.
배포
Git을 사용하면 기본에 병합하기 전 환경에 있는 분기에서 배포하여 최종 테스트를 할 수 있습니다.
끌어오기 요청을 검토하고 분기가 테스트를 통과하면 변경 내용을 배포하여 확인할 수 있습니다. 분기에서 문제가 발생하는 경우 기존 기본을 배포하여 롤백할 수 있습니다.
병합
변경 내용을 확인했으므로 코드를 기본 분기에 병합할 때입니다.
병합되면 끌어오기 요청에서 코드에 대한 이전 변경 내용을 담은 기록을 유지합니다. 이는 검색할 수 있기 때문에 누구든지 시간을 거슬러 올라가 결정을 내린 이유와 방법을 알아볼 수 있습니다.
특정 키워드를 끌어오기 요청의 텍스트에 통합하면 코드와 문제를 연결할 수 있습니다. 끌어오기 요청이 병합되면 관련 문제도 닫을 수 있습니다.
이 워크플로는 비즈니스 도메인 기능 집합에 초점을 맞춘 분기를 구성하고 추적하는 데 도움이 됩니다.
Git Forking 워크플로와 Gitflow 워크플로 같은 다른 Git 워크플로는 리포지터리 중심으로, Git 기능 분기 워크플로를 사용해 분기 모델을 관리할 수 있습니다.