2021 07 06

2021-07-06

GIT 브랜치 전략

• 왜 필요하지? - 어디서 에러가 터졌지? - 찾기도 어려움 - 기적적으로 찾아도 이후 개발한 신규 기능 배포 어려워!

• 새로운 기능의 개발 - 메인 하나만 두고 있었어 - 최신 기능 "Feature Branch"

  > git branch feature/new-function
  > git checkout feature/new-function
  

  - 에러 제보 "Hotfix Branch"

  > git checkout -b hotfix/server-error
  

  - 작업 통합 후 푸시

  > git checkout main
  > git merge hotfix/server-error
  > git push
  

• 태그 관리 - 메인에 버전 명시하고 싶어!

  > git tag -a v0.1 -m "최초 배포 버전"
  > git tag -a v0.1.1 1e2098 -m "지난 커밋의 해시값에 태그 붙임"
  > git show v0.1 
  > git push origin v0.1:v0.1
  

    - 버전 명시하면 release note 작성 가능
  

• 깃 브랜치 전략 정하기 - git-flow, github-flow - 브랜치 역할, 규칙 정하기 - 커밋 메시지 포맷 정하기

  main: 주 브랜치
  feature: 신규 기능 개발
  hotfix: 에러 수정
  release: 배포 브랜치
  

현업 깃 플로우 전략

• 참고: https://techblog.woowahan.com/2553/
• Git Repository 구성 - Upstream Remote Repository (최종 서비스가 공유) - Origin Remote Repository (각 개발자 별로) - Local Repository (각 개발자 별로) - 미션 코드 PR 날리는 구조랑 비슷한데?

• Git-flow 전략 살펴보기 - master: 제품으로 출시될 브랜치 - release에서 넘어온 커밋 기준 태그 붙여서 머지 - develop: 다음 출시 버전 개발 브랜치 - master에서 파생한 개발 브랜치 - 상시로 버그 수정한 커밋 - feature: 기능 개발 브랜치 - develop에서 파생해 새로운 기능 추가 작업 - 기능 개발이 완료되었다면 develop으로 머지 - release: 이번 출시 버전 준비 브랜치 - 기능 개발이 완료된 develop에서 파생 - QA를 위함 - 다 하면 master와 develop으로 머지 - hotfix: 출시 버전에서 발생한 버그 수정 브랜치