Post
Git workflow 전략 도입
회사에서 최근 들어오는 프로젝트 중 Git으로 형상관리하는 곳이 대부분이다.
프로젝트 리더 분들이 SVN에 익숙해서 그런지 이전 프로젝트에서는 계속 SVN을 고집했지만,
이제는 Git을 도입하게 되었다.
유지보수 담당자는 보통 1명이기 때문에 SVN을 쓰던 Git을 쓰던 어차피 혼자 작업하기 때문에
크게 충돌이나, 다른 걸 신경쓸 필요는 없다.
하지만, 여러명이 작업하는걸 기준으로 해야 하고, 하자보수, 유지보수,추가개발 팀이 같이 작업하다 보니
생각보다 충돌이 너무 많이 일어나서 Git Workflow를 도입하자고 제안하였고, 아래처럼 구성해 보았다.
기본 구조
개인/작업 branch => dev branch => staging branch => main Branch
*staging을 체크아웃 할지, dev를 체크아웃할지 고민했는데, 팀원들이 Git에 많이 익숙하지 않기 때문에
staging의 경우 cherry-pick으로 운영 배포할 커밋만 올라가기 때문에 dev와 싱크가 맞지 않다. 충돌 해결 작업이 복잡해질 수 있어 branch를 새로 만들 때에는 dev로 하기로 결정했다.
1.개인 브랜치 기능 개발
git checkout dev
git pull origin dev
git checkout -b [개인브랜치]
git push origin [개인브랜치]
# 작업 후 커밋
git commit -m “[번호] 제목”
git push origin [개인브랜치]
2.작업 완료 후 dev 머지
git checkout dev
git pull origin dev
git merge --squash [개인브랜치] (여러 커밋 하나로 모으는 작업 => 반드시 merge 후 git commit 수동 작성 필요, commit 빼먹으면 push해도 dev반영 안됨)
git commit -m “[번호] 제목”
git push origin dev
=> 모든 기능은 dev 브랜치로 통합 합니다. 이후 jenkins빌드로 개발계 테스트
3.운영 반영할 부분만 staging에 cherry-pick (커밋 A,B,C…)
git checkout staging
git pull origin staging
git cherry-pick 커밋A해시
git cherry-pick 커밋C해시
git push origin staging
=>dev에서 운영에 필요한 커밋만 선별해서 staging으로 가져오는데, 이 부분은 각 개인이 작업한 부분을 올려야 합니다. (커밋 해시 확인 : git log --oneline dev)
=>push 전에 로컬 환경에서 실행이 가능하다면 staging 브랜치를 checkout 하고, 운영 DB를 바라본 채로 빌드가 동작하는지만 테스트
4.운영 배포 시, main에 staging을 반영
git checkout main
git pull origin main
git rebase staging
git push origin main
=============================================
[개인브랜치/feature-x] [개인브랜치/feature-y] …
↓ ↓
└──────── dev ────────┘
↓ (선택적 cherry-pick)
[staging] ← 운영에 올릴 커밋만
↓
[main] ← 운영 배포 대상
=============================================
깃 관련해서 연습하려면 이곳에서 하면 된다.아직 회사에서 PR까진 하지 않기 때문에 여기서 익숙해지고 진행하는걸로 !!
https://learngitbranching.js.org/?locale=ko
[Learn Git Branching
An interactive Git visualization tool to educate and challenge!
learngitbranching.js.org](https://learngitbranching.js.org/?locale=ko)
댓글