형상 관리 모범 사례

브랜치 전략

: 브랜치 워크플로우의 결정은 팀 규모, 경험 수준, 확장에 대한 요구도 및 업무적인 제한 사항을 비롯한 여러 가지 요소에 따라 달라질 수 있다

 

- 중앙 집중식 워크플로우

: 하나의 저장소와 하나의 마스터 브랜치가 있는 형태

: 팀은 개발 시 다른 브랜치를 사용하지 않으므로 변경 사항을 덮어쓸 위험이 높다

 

- 기능(feature) 브랜치

: 새로운 기능을 추가할때마다 새로운 브랜치를 만드는 방법

: 기능에 대해 작업자들은 feature 브랜치에 커밋

 

- GitFlow

: 기능 브랜치의 극단적인 형태

: 마스터와 별도의 개발 (develop), 기능, 릴리즈, 핫픽스 브랜치가 존재

: 개발 브랜치에서 개발이 수행되고 마스터 및 릴리즈 브랜치로 병합

 

- 태스트-브랜치 개발

: 기능 중심 개발 및 기능 브랜치를 이슈 추적과 결합한 형태

: 팀 구성원들이 요구사항을 task 브랜치를 통해 전달되는 작은 기능의 덩어리로 분리하여 작업

: 별도의 전용 브랜치를 사용하여 스테이징, 테스트 및 운영과 같은 어려 환경을 유지 관리

: 커밋되는 변경사항이 모든 환경에 걸쳐 테스트 되도록 보장

 

 

 

 

 

 

작은 단위로 자주 커밋하기

: 커밋을 작은 기능 단위로 쪼개어 롤백과 작업사항 추적을 쉽게 함

: 코드를 검토할 때 커밋 별로 명확한 식별이 가능

 

 

 

 

 

상세한 커밋 메시지 작성

: 커밋 메시지는 커밋 내용뿐만 아니라 개발자의 의도를 반영해야한다

: 커밋 메시지를 통해 변경이 발생한 이유를 설명할 수 있어야하기 때문

: 최대한 상세하고 이해하기 쉽게 작성

 

 

 

 

 

 

브랜치를 사용하여 개발

: master 브랜치의 상태를 복제한 브랜치에서 개발을 수행

: 메인 코드 베이스에 영향을 주지 않고 코드를 변경하는 것이 목적

: 코드가 준비되었을대만 master 브랜치에 병합

 

 

 

 

 

정기적인 코드리뷰 수행

: 검증할 코드가 생기면 peer review를 통해 코드를 확인

: 지속적인 개선을 보장하고 불안정한 코드를 방지

 

- 리뷰어의 행동

: 어떤 변경이 필요한지 설명 (버그 수정, UX 개선, 기존 코드 리팩토링)

: 사소한 개선 사항이 보이는 경우 Not Blocking 이라는 접두어로 주석 달아주기

: 대안을 제공하되 개발자가 이를 고려했다고 가정

: 문제를 해결하는 과정에서도 코드를 단순화 시킬 수 있는 방법을 찾아야함

 

 

 

 

 

 

 

 

Reference

형상관리 모범사례\:\ Git 형상관리 이렇게 하세요!