혼자서 깃허브에 커밋한 경험은 있었지만, 팀으로 협업하면서 어떻게 깃을 사용하는지는 알지 못했다.
지금까지 경험한 깃 플로우에 대해 정리해보자.
Git Flow
다양한 branch를 효율적으로 관리하기 위한 전락으로,
Vincent Driessen이 2010년 처음 제안한 브랜치 관리 모델이다.
이 외에도 Github Flow, Gitlab Flow등 다양한 전략이 있지만 Git Flow 가 가장 대중적인 전략이다.
Git Flow에는 5가지 branch가 있다.
1. feature
새로운 기능을 개발하기 위해 생성되는 브랜치
댓글 기능을 추가한다면 feature/comment브랜치 생성후 해당 브랜치에서 댓글 관련 기능을 개발한다.
2. develop
master로 최종 merge 하기 전, 가장 최신의 코드들을 가지고 있는 브랜치다.
서비스의 신규 기능들을 우선 develop에서 전체적으로 합쳐본다고 생각하면 된다.
feature브랜치에서 댓글 관련 기능들을 모두 개발 완료한 후, develop 브랜치에 merge 시킴으로써 전체 서비스에 지장 없이 댓글 기능이 잘 작동하는지 확인한다.
3. release
develop 브랜치에 merge된 기능이 정상적으로 작동한다면 release 브랜치를 생성해 최종 배포 준비주우 발견된 버그에 대한 수정사항을 추가한다.
4. hotfix
이미 배포된 서비스에서 버그를 발견했다면 hotfix 브랜치를 생성해 디버깅한다.
버그 수정이 완료된 후 hotfix는 master와 develop 모두에 merge 시킨다.
5. master
최종적으로 배포할 최종 코드를 가진 브랜치로, 개발이 모두 완료되어 검증까지 거친 안정적인 코드들만 지니고 있다.
1. master와 개인 브랜치 분리해 푸시하기
master branch
master branch 업데이트
master 브랜치에서는 모두가 함께 공유할 사항들을 푸시한다.
예를 들면,
- eslint, prettier 초기세팅
- reset.css : css를 적용하기전 공통적으로 적용하는
margin: 0과 같은 속성값 초기화 세팅 - common.css: 공통적으로 적용할 속성, 혹은 색상 변수들 등
- 그 외 초기 세팅에 필요한 사항들
master branch 가져오기
그 뒤 git pull origin master로 로컬영역에 푸시된 원격저장소의 master 브랜치를 가져온다.
내 로컬 영역의 master 브랜치가 업데이트 된다.
만약 이후에 다른 팀원들이 새로 추가할 사항을 업데이트해 master 브랜치에 푸시했다면,
계속해서 git pull origin master로 가져와 내 로컬영역의 master 브랜치를 업데이트 해주면 된다.
master branch 수정하기
내가 master에서 팀원들과 공통적으로 적용할 사항들을 수정해야 한다면,
git pull origin master 후 수정사항을 master 브랜치에 그대로 푸시해주면 된다.
단, 팀원들과 협의가 잘 되어 있어야 한다.
personal branch
그 뒤 각자가 맡은 영역에 따라서 브랜치를 새로 생성한 뒤, git merge master로 업데이트된 master 브랜치의 코드를 개인 브랜치로 병합해준다.
개인 브랜치에서 작업한 내용은 그대로 git push origin personal branch로 개인 브랜치로 푸시한다.
깃 충돌
만약 업데이트 내역이 서로 달라 깃 충돌이 난다면, 깃에서 푸시를 거부한다.
이럴때는 직접 비교해 충돌한 부분을 수정해 맞춰준다음 git merge master해 다시 병합한 후 푸시해주면 된다.
Reference
