Git 형상관리 잘하는 법

1. 하나의 브랜치 전략 수립

   • 다양한 전문 분야 지식 있는 팀원이 함께 일하면 워크플로 접근방식 상충될 수 있음
   • 이를 방지하기 위해 리더는 하나의 브랜치 전략 세워 모두에게 전파해야 함
   • 브랜치 워크플로 결정은 팀 규모, 경험 수준, 확장 요구도, 업무 제한 사항 등 여러 요소 따라 달라질 수 있음
   • 개발팀은 이미 정해진 워크플로 따라갈 수 있지만 팀 요구사항에 맞춰 워크플로 만들 수 있음
   • 워크플로가 포함하는 내용
     • 중앙 집중식 워크플로: 하나의 저장소와 하나의 마스터 브랜치 있음. 변경사항 덮어쓸 위험 있음
     • 기능 브랜치: 새로운 기능 추가할 때마다 새로운 브랜치 만듦. 해당 feature 브랜치에 기능 관련 커밋
     • Git Flow: 기능 브랜치 극단적 형태. Git Flow 사용한 개발에 마스터와 별도 개발 브랜치 있음. 기능, 릴리즈, 핫픽스 브랜치 지원. 개발 브랜치에서 개발 수행, 릴리즈 브랜치로 이동, 마스터 브랜치로 merge 됨
     • 태스크-브랜치 개발: GitLab Flow는 개발 유형의 예. 기능 중심 개발, feature 브랜치를 이슈 추적과 결합한 형태. GitLab Flow는 별도 전용 브랜치 사용해 스테이징, 운영 테스트, 운영 같은 여러 환경 유지 관리. 커밋되는 변경사항이 모든 환경에 걸쳐 테스트되도록 함
   • 협업에 미치는 효과:
     • 모두가 동일한 워크플로에서 조화 이룰 때 코드 덮어쓰거나 마스터 브랜치 망칠 일 줄어듦
     • 모든 작업자가 개발, 배포 프로세스에 익숙해 팀 구성원이 서로의 작업에 쉽게 기여함
     • 명확하고 간결한 브랜치 전략은 새로운 코드 merge, 프로젝트 발전시키는 선순환으로 이어짐
     • 이러한 환경은 팀 구성원이 회의 주선, 마감일과 작업량 관리하는 데 도움이 됨
     • 각 워크플로가 협업에 미치는 영향
       • 중앙 집중식 워크플로: 두명의 개발자가 동일한 코드를 동시 중복해서 작업하지 않도록 의사소통 잘할 수 있는 소규모 팀(개발자 5명 미만)에게 효과적
       • 기능 브랜치와 GitFlow: 더 많은 코드 리뷰, 푸시 규칙, 코드 승인자, 더 광범위한 테스트가 필요해 다양한 팀 연결
       • 태스크-브랜치 개발: 팀 구성원이 요구사항을 태스크 브랜치로 전달되는 작은 기능의 덩어리로 분해하도록 함. 이 워크플로는 코드 스니펫, 코드 리뷰, 단위 테스트 같은 협업 사례 포함함. 테스트가 실패하면 팀원이 협력해 무엇이 잘못됐는지 확인

2. 작은 단위로 자주 커밋

   • 완성도 우선시하면 프로젝트가 거의 완성됐을 때만 대규모 커밋할 수 있음
   • 간단한 기능 검증과 작은 단계 건너뛰면 잘못된 기능 개발, 엉뚱한 방향성으로 시간 소비할 수 있음
   • 동작 가능한 테스트와 코드 있을 때마다 커밋
   • 프로젝트를 작은 단계로 단순화, 잦은 커밋으로 큰 목표 달성하는 방법 찾아야 함
   • 협업에 미치는 영향:
     • 자주 커밋하는 문화 갖춰지면 모두가 코드 저장소에 가시성 가져 다른 팀원이 무엇을 하는지 쉽게 알 수 있음
     • 기능 브랜치 또는 merge request에서 작업물 공유하면 다른 팀원의 중복 작업 막을 수 있음
     • 아직 검토 준비가 되지 않았더라도 기능 브랜치로 자주 푸시해야 함
     • 완료되기 전에 작업 공유하면 토론, 피드백이 활성화돼 코드 리뷰 이전에도 품질 개선할 수 있음
     • 작업을 여러 개 커밋으로 나누면 개발자와 다른 팀이 향후 코드 검토할 때 유용한 정보로 활용할 수 있음
     • 기능이 어떻게 개발됐는지 커밋별로 명확하게 식별할 수 있음
     • 관련없는 변경 이력은 그대로 두고, 원하는 특정 시점으로 롤백, 특정 코드 변경사항만 선택적으로 되돌림

3. 상세한 커밋 메시지 작성

   • 커밋 메시지는 커밋 내용 뿐만 아니라 개발자 의도 반영해야 함
   • 커밋 메시지로 변경 발생한 이유 설명해야 함
   • 좋은 커밋 메시지 예: “사용자 화면의 중복 코드 줄이기 위해 템플릿 결합함”
   • 커밋 메시지에 담긴 ‘변경’, ‘개선’, ‘수정’, ‘재구성’ 같은 단어는 유용한 정보 아님
   • 협업에 미치는 영향:
     • 상세한 커밋 메시지는 투명성 높이고, 진행상황 가시성 제공해 팀원과 고객, 미래 기여자가 개발 프로세스 이해하도록 도움
     • 코드 리뷰 수행할 때 커밋 메시지는 반복된 절차 따르고 릴리즈, 협의, 요구사항 변경 이후 나타난 변화 확인하는 데 도움됨
     • 자세한 커밋 메시지는 QA와 보안팀이 코드 검사할 때 문제 영역 식별하고, 특정 변경 사항 되돌리도록 도와줌
     • 커밋 메시지를 자세하게 작성하면 다른 팀원 중복 작업 막고, 작업 지연 최소화해 프로젝트 진척률 안정적으로 이끌 수 있음

4. 브랜치 사용해 개발

   • 브랜치에서 개발하는 건 특정 브랜치에서 현시점 상태 복제해 작업하는 것과 같음
   • 브랜치 사용하면 메인 코드베이스에 영향 주지 않고 코드 변경할 수 있음
   • 변경 이력은 브랜치 내에서 관리됨
   • 코드 준비되면 코드를 마스터 브랜치에 merge 할 수 있음
   • 브랜치에서 코딩하면 개발에 더 체계적 방식으로 접근할 수 있음
   • 개발 중인 초안을 안정적 테스트 거친 마스터 코드와 분리해 별도 관리할 수 있음
   • 협업에 미치는 영향:
     • 구성원이 복잡한 문제 해결 위한 혁신적 해결책과 실험 시도할 수 있게 함
     • 개발팀은 마스터 브랜치에 영향 줄 것이란 불안감에서 벗어나 창의적 도전할 수 있음
     • 마스터 브랜치에 merge하기 전에 솔루션의 정상 작동 검증 위해 협업할 수 있음
     • 운영, QA, 보안팀은 배포 전에 코드 검토, 모든 구성원이 릴리즈 전에 아이디어 제시, 잠재 문제를 논의할 기회 보장함

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

   • 지속적 개선 보장, 불안정한 코드 방지
   • 검토할 코드 생기면 프로젝트를 잘 아는 동료, 팀원, 업무 영역 전문가에게 코드 리뷰 요청해야 함
   • 코드 리뷰 수행할 때 유의사항:
     • 어떤 변경이 필요한지 설명
     • 대안 제공하되 개발자가 이를 이미 고려했다고 가정해야 함
     • 문제 해결 과정에서도 코드 단순화할 방법 찾아야 함
   • 협업에 미치는 효과:
     • 코드 리뷰는 문제 해결과 구현 관련해 다른 의견 제시
     • 버그, 로직 문제 또는 잠재적 코너 케이스 찾는 다른 눈 됨
     • 어려운 이슈 헤쳐 나가며 릴리즈 향해 달려갈 때 발생할 문제 완화
     • 문제 해결방안 검토, 의견 제시, 팀원 협력 통한 리뷰 가능
     • 다양한 코딩 방법, 워크플로 노하우, 새로운 문제 해결 방식 배울 수 있음