GIT

소규모 팀의 협업을 위한 git + github workflow

양찬우 2021. 10. 20. 18:06
728x90

현재 진행 중인 프로젝트에서 프론트엔드 담당으로 참여 중이다. 합류 초기 협업을 위한 Git workflow가 설정되어 있지 않다는 것을 확인하고 원만한 협업을 위해 git workflow 문서를 작성했다. 기본 골자는 처음 팀 프로젝트를 시작했을 때부터 참고했던 우아한 형제들 기술 블로그의 git-flow에서 가져왔으며, 이후 몇 달 간의 실제 프로젝트 진행 후 문서를 보완해야 한다고 느껴서 몇 가지 규칙을 현 상황에 맞춰 수정 및 보완했다.  

 

현재 우리 팀의 상황은 아래와 같다.   

  • 팀원 수가 2~10명 이하인 소규모 팀 
  • JIRA 등 다른 협업용 툴을 사용하지 않거나 엄격히 활용하지 않음 
  • Git에 익숙하지 않은 팀원이 다수 존재 
  • 개발 초기라서 잦은 배포가 필요함 
  • Git + Github 원격 저장소 사용
  • PR, 리뷰, 이슈, 댓글 등 알림을 SLACK 연동하여 사용 
  • 개발문서 정리, 진행상황 확인용 칸반 차트, 일정관리 용으로 Notion 사용 

만약 위와 비슷한 상황에서 하나의 git workflow가 없다면, 이 문서를 참고해서 협업 규칙을 정하는 것도 도움이 될 것 같다.

git workflow 시각적 전개도

브랜치 정의

  • main: 제품으로 출시될 수 있는 브랜치
  • develop : 다음 출시 버전을 개발하는 브랜치
  • feature : 기능을 개발하는 브랜치
  • release : 이번 출시 버전을 준비하는 브랜치
  • hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치

브랜치 사용규칙

  1. 하나의 기능은 되도록 하나의 커밋으로 합니다.
  2. 커밋 그래프는 최대한 단순하게 가져갑니다.
  3. 서로 공유하는 브랜치의 커밋 그래프는 함부로 변경하지 않습니다.
  4. 리뷰어에게 꼭 리뷰를 받습니다.
  5. 자신의 Pull Request는 스스로 merge 합니다.

브랜치 생성규칙

* 주의, <특정이름> 브랜치가 있다면 <특정이름>/<추가> 브랜치를 생성할 수 없다. 예를 들어 Release 브랜치가 원격저장소에 존재한다면, Release/0.1.1 브랜치를 생성할 수 없다. 하위 브랜치가 필요한 경우 (ex, feature,release,hotfix 등) 상위 브랜치 명만으로 브랜치를 생성하면 안된다.  

 

  1. main → 하나의 master(main) 브랜치만 사용, 배포 시 Tag 및 업데이트 내용 추가 작성, 추가 생성하지 않는다.
  2. develop → 하나의 develop 브랜치만 사용, 추가 생성하지 않는다. 
  3. release → 배포 버전 명으로 생성 (ex,release_1.3 ), 해당 버전 배포 전까지만 사용
  4. feature → 해당 feature 업무 담당자가 최신 버전의 develop에서 feature/<기능명>으로 생성
  5. hotfix → hotfix/<내용>으로 생성

커밋 메세지 규칙

  • 유의미한 코드 단위 / 기능 완료 시에 커밋
  • 커밋 메세지 작성 예시
$ git commit -m "Add facebook Oauth 
- 페이스북 API 연결 파일 작성 
- 헤더 로그인 모달 및 메인 로그인 옵션에 추가
"
  • 첫 줄에 커밋 제목 작성, 추가 설명이 필요한 경우 줄 바꿈 후 여러 줄에 내역 작성
  • 커밋 메세지 첫 시작은 아래 5단어 (첫 글자 대문자)
    • Fix : 버그 수정, 에러 해결 등
    • Add : 파일 추가 / 기능 및 함수 추가
    • Delete : 파일 삭제
    • Refactor : 기존 파일 개선/보완
    • Move : 파일 위치 변경 / 이름 변경 등 실제 코드 내용 변경 없을 시

상황 별 Git 조작 순서 및 방법

git에 익숙하지 않은 팀원들을 위해 작성한 git command 및 조작 방법이다. 

  • 새로운 feature 개발: 최신 develop의 변경사항을 local에 반영시킨 후, 새로운 브랜치를 생성하여 작업한다.
    1. $ git checkout develop : develop 브랜치로 checkout
    2. $ git pull : develop 브랜치의 최신 변경사항을 로컬로 가져온다. 
    3. $ git checkout -b <feature branch 명> :명령어를 통해 브랜치 생성 후 checkout한다
    4. 코드작성
    5. $ git add <file 명>: git add . 를 통해 모든 파일을 staging area에 추가할 수 있다. 
    6. $ git commit -m "커밋메세지" 
    7. $ git push origin <feature branch>: origin(원격 저장소)의 feature branch로 로컬 변경 내역을 push
    8. github에서 develop branch <- feature branch 방향으로  Pull Request 진행
    9. 리뷰가 종료되고 모두 Approve 된다면 Merge한다. 
  • 배포 후 hotfix가 필요할 때
    1. $ git checkout main : 현재 배포 중인 main 브랜치로 이동  
    2. $ git checkout -b <hotfix branch> : 핫픽스 브랜치 생성
    3. hotfix, 수정 코드 작성
    4. $ git add <file 명>: git add . 를 통해 모든 파일을 staging area에 추가할 수 있다. 
    5. $ git commit -m "커밋메세지" 
    6. $ git push origin <hotfix branch>
    7. github에서 develop branch <- hotfix branch 방향으로 Pull Request
    8. github에서 main branch <- hotfix branch 방향으로 Pull Request
    9. 각각 main과 develop으로의 PR 리뷰가 완료되면 Merge한다. 
  • release 준비
    1. 원격 저장소의 develop 브랜치에 이번 버전에 업데이트할 모든 feature가 머지되었는지 확인
    2. $ git checkout develop : 로컬 develop 브랜치 이동
    3. $ git pull : 원격 저장소의 변경사항을 로컬로 가져온다. 
    4. $ git checkout -b <release branch> : release 브랜치 생성
    5. release 브랜치에서 빌드 후 버그 유무 확인
      • 버그 확인 시 bugfix 후 add, commit, push -> develop브랜치에 PR 
    6. $ git push origin <release branch> 
    7. github에서 main branch <- release branch 방향으로 Pull Request
    8. github에서 develop branch <- release branch 방향으로 Pull Request
    9. 리뷰가 완료되면 배포사항을 Merge한다.
728x90
저작자표시 비영리