Git Branching

1. 브랜치 전략 세우기​

다양한 직업과 교육 배경을 가진 팀원들이 함께 일할 때, 워크플로우에 대한 상반된 접근법이 있을 수 있습니다. 혼란스러운 개발 경험을 막기 위해 리더는 단일 브랜치 전략을 파악하고 널리 소통해야 합니다. 브랜치 워크플로우를 결정하는 것은 팀 규모, 경험 수준, 확장 요구사항 및 업계 제한과 같은 몇 가지 요인에 따라 달라집니다. 팀들이 정해진 워크플로우를 따르기로 선택할 수도 있지만, 특정 요구에 따라 맞춤화된 워크플로우를 만들 수도 있습니다. 어떤 전략을 선택하든 팀에게 워크플로우를 전달하고 필요한 경우 교육을 제공하는 것이 중요합니다.

협업에 미치는 영향​

모든 사람이 동일한 워크플로우에서 조화롭게 작업할 경우 코드를 덮어쓰거나 마스터를 손상시킬 위험이 줄어 듭니다. 게다가, 모든 사람들이 개발 및 배포 프로세스에 익숙하기 때문에, 팀원들은 서로의 작업에 쉽게 기여할 수 있습니다. 명확하고 간결한 브랜치 전략은 새로운 코드를 병합하고 프로젝트를 진전시키는 리듬을 설정한다. 이러한 적응감은 팀원들이 회의를 준비하고 마감일과 작업량을 관리하는 데 도움이 됩니다.

중앙 집중식 워크플로우​

중앙 집중화된 워크플로우에서는 단일 저장소와 마스터 브랜치를 사용합니다. 팀들은 다른 브랜치를 개발용으로 사용하지 않기 때문에 변경사항을 덮어쓸 위험이 큽니다.

이러한 유형의 워크플로우에는 공동 작업 흐름이 없지만, 좋은 커뮤니케이션을 사용하는 소규모 팀(개발자 5명 미만)에서 잘 작동하여 두 개발자가 동일한 코드를 동시에 작업하려고 하지 않도록 할 수 있습니다.

Feature branching​

Feature branching이란 추가해야 하는 각 기능에 대해 새 분기를 만드는 것을 의미합니다. 기능에 대해 작업을 수행해야 하는 모든 사용자는 기능 브랜치에 커밋합니다.

feature branch는 더 큰 코드 리뷰, 푸시 규칙, 코드 승인자, 더 광범위한 테스트 세트가 필요하기 때문에 다양한 팀을 연결합니다.

GitFlow​

GitFlow는 Feature branch의 극단적인 버전입니다. GitFlow로 개발하면 마스터 브랜치와 별도의 개발 브랜치뿐만 아니라 Feature, Release, Hotfix를 지원하는 분기가 존재합니다. Develop 브랜치에서 개발되고, Release 브랜치로 이동하며, Master 브랜치로 병합됩니다.

feature branching과 마찬가지로 팀들을 연결합니다.

👍 GitLab Flow(Task-branch development) 👏​

GitLab Flow는 이러한 개발 유형의 예로 기능 중심 개발 및 Feature 브랜치와 이슈 추적을 결합한 것이 특징입니다. GitLab Flow는 별도의 전용 브랜치를 사용하여 스테이징, 사전 프로덕션, 프로덕션과 같은 여러 환경을 프로비저닝하여 다운스트림 흐름을 커밋하여 모든 환경에서 모든 것이 테스트되었음을 보장합니다.

태스크 브랜치 개발은 팀원들이 요구사항을 작은 덩어리로 분해하고 태스크 브랜치를 통해 빠른 속도로 전달되도록 합니다. 이러한 유형의 워크플로우에는 코드 스니펫, 코드 리뷰 및 단위 테스트와 같은 협업 방식을 포함합니다. 게다가, 만약 테스트가 실패하면, 팀원들이 함께 작업하여 무엇이 잘못되었는지 확인할 수 있습니다.

2. 자주 그리고 작은 변경 사항을 만들어라​

팀들은 이용 가능한 크고 거의 완성된 프로젝트가 있을 때에만 커밋할 수 있고, 완벽함이 배포의 전제조건이라고 믿습니다. 그러나, 더 작은 단계를 밟지 않고 더 단순한 기능을 제공함으로써, 팀은 잘못된 기능에 대한 작업을 하거나 잘못된 방향으로 가는 데 시간을 할애할 위험이 있습니다. 비즈니스 가치를 전달하고 고객의 요구를 충족시킬 목적으로 소프트웨어를 개발하는 가장 효과적인 방법은 작업 세트인 테스트와 코드가 있을 때마다 커밋하는 것입니다. 프로젝트를 작은 단계로 단순화하는 방법을 찾은 다음 더 큰 목표를 달성하기 위해 자주 커밋해야 합니다.

협업에 미치는 영향​

잦은 커밋 문화는 모든 사람들이 코드 저장소를 볼 수 있기 때문에 팀 동료들이 어떤 작업을 하고 있는지 알 수 있도록 합니다. Feature 브랜치나 Merge Request로 작업을 공유하면 동료가 작업을 복제하는 것을 방지 할 수 있으므로 리뷰 준비가 되지 않은 경우에도 Feature 브랜치에 자주 푸쉬 해야 합니다. 완료되기 전에 작업을 공유하면 토론과 피드백을 쉽게 할 수 있으므로 리뷰 전에 코드를 개선하는 데 도움이 될 수 있습니다.

개별 커밋으로 작업을 세분화하면 나중에 코드를 리뷰할 개발자 및 기타 팀(예: 품질 및 보안)에게 컨텍스트가 제공됩니다. 더 작은 커밋은 기능이 어떻게 개발되었는지 명확하게 식별되어 특정 시점으로 쉽게 롤백하거나 관련 없는 여러 변경사항을 되돌리지 않고 하나의 코드 변경 사항을 되돌릴 수 있습니다.

3. 커밋 메시지 기술하기​

커밋 메시지는 커밋의 내용만이 아니라 의도를 반영해야 한다. 커밋에서 변경 사항을 쉽게 볼 수 있기 때문에 커밋 메시지에는 변경된 이유를 설명해야 합니다.

팀 간의 일관성을 보장하고 혼란과 잘못된 의사소통을 줄이기 위해 커밋 메시지 규칙(commit message convention)을 설정하는 것이 중요합니다.

좋은 커밋 메시지의 예는 다음과 같다. "사용자 뷰에서 중복 코드를 줄이기 위해 템플릿 결합"

"변경(change)", "개선(improve)", "수정(fix)" 및 "리팩터(refactor)"라는 단어는 커밋 메시지에 많은 정보를 추가하지 않습니다.

예를 들어, "XML 생성 개선"은 "XML 생성 시 특수 문자는 적절히 이스케이프로 처리"로 작성하는 것이 좋습니다.

협업에 미치는 영향​

커밋 메시지 기술하기는 팀 구성원, 고객 및 미래의 기여자가 개발 과정을 이해할 수 있도록 투명성을 배양하고 진행 상황에 대한 통찰력을 제공합니다.

코드 리뷰를 수행할 때, 커밋 메시지는 팀 구성원이 이터레이션(iteration)을 따르고 릴리즈, 토론 또는 요구사항의 변경 이후 어떤 변경이 이루어졌는지 결정하는 데 도움이 됩니다.

또한 세부적인 커밋 메시지는 품질 및 보안 팀이 코드를 검사할 때 문제 영역을 식별하고 특정 변경 사항을 되돌리는 데 도움이 된다. 게다가, 개발자들이 세부적인 커밋 메시지를 작성할 때, 그것은 동료들이 일을 복제하는 것을 방지하고, 지연을 제한하고, 프로젝트가 더 안정적으로 진행되도록 도울 수 있다.

4. 브랜치를 이용하여 개발하기​

브랜치에서 개발하는 것은 현재 상태에서 특정 브랜치, 일반적으로 마스터 분기의 스냅샷을 생성하는 것과 같습니다.

브랜치를 이용하여 팀원들은 주요 코드베이스에 영향을 주지 않고 변경할 수 있습니다. 변경 내역은 한 브랜치에서 추적될 것입니다. 코드가 준비되면 마스터 브랜치로 머지할 수 있습니다.

브랜치에서의 코딩은 개발에 대한 보다 체계적인 접근을 가능하게 하며, 마스터 브랜치에서 안정적이고 이미 테스트된 코드로부터 분기된 초안으로 작업을 할 수 있습니다.

협업에 미치는 영향​

브랜치에서의 코딩은 팀원들이 문제에 대한 해결법을 실험하고 찾을 수 있도록 합니다.

팀은 마스터 브랜치를 불안정하게 만드는 두려움 없이 창의적일 수 있다. 또한, 팀 구성원은 솔루션을 마스터 브랜치에 머지하기 전에 솔루션이 잘 작동하는지 확인하기 위한 협업을 할 수 있습니다. 운영, 품질 및 보안 팀은 코드를 배포하기 전에 코드를 검토할 수 있으며, 모든 사람이 아이디어를 논의하고 배포하기 전에 잠재적인 문제를 발견할 수 있는 기회와 가시성을 확보할 수 있습니다.

5. 정기적인 코드 리뷰 수행​

정기적인 코드 검토 문화를 구현하면 지속적인 개선이 보장되고 불안정한 코드가 발생하지 않는다. 모든 팀원들은 누군가 자신의 코드를 검토하고 제안을 하는 것을 환영해야 한다. 검토해야 할 코드가 있는 즉시 팀 구성원은 프로젝트에 익숙한 개인, 같은 팀의 구성원 또는 도메인 전문가에게 코드 리뷰를 할당해야 합니다.

팀 구성원은 코드 리뷰를 수행할 때 다음을 수행해야 한다.

  • 어떤 변경이 필요한지 설명(예: 버그 수정, 사용자 경험 개선, 기존 코드 리팩터링)
  • 작지만 필수가 아닌 개선 사항이 있는 경우 "Not blocking:" 주석을 접두사로 추가하여 제안이 선택 사항이며 즉시 또는 다른 이터레이션(iteration)에서 해결될 수 있음을 작성자가 이해하도록 돕습니다.
  • 대체 구현을 제공하되 작성자가 이미 검토했다고 가정하십시오(예: "여기서 사용자 정의 유효성 검사기를 사용하는 것에 대해 어떻게 생각하십니까?").
  • 반복 횟수를 줄이기 위해 철저히 하라.
  • 문제를 해결하는 동안 코드를 단순화하는 방법을 식별하십시오.

협업에 미치는 영향​

코드 리뷰는 솔루션과 구현에 대한 제2의 의견과 버그, 논리 문제 또는 드러난 엣지 케이스를 찾는 추가적인 시각으로 역할을 합니다. 코드 리뷰는 부담스러운 이슈를 안고 릴리즈 될 때 문제를 완화하는 데 도움이 됩니다. 해결책을 검토하고 제안사항을 제시하면 팀 구성원이 함께 검토할 수 있습니다.

팀 동료들은 코드 리뷰를 통해 협력함으로써 혁신과 효율성을 높이고 지식 사일로를 줄이는 다양한 코딩 방법, 워크플로우 기술, 문제에 접근하는 새로운 방법을 배웁니다.

GitLab 원문 보기