워크플로우

템플릿 워크플로우

# 템플릿 워크플로우
프로젝트 매니저: 이름

개발 사이트: url
개발 사이트 배포 브랜치: 브랜치 이름

라이브 사이트: url
라이브 사이트 배포 브랜치: 브랜치 이름

개발 티켓을 시작하는 브랜치: 브랜치 이름
핫픽스 티켓을 시작하는 브랜치: 브랜치 이름
작업 업데이트 시 사용 명령어: git 명령어
검토 후 작업 병합 시 사용 명령어: git 명령어

Reference

• 책/Git for teams(팀을 위한 git)/엠마 제인 호그빈 웨스트비 저/최병현 역/한빛미디어
• https://velog.io/@kim-jaemin420/Git-branch-naming

1. 2010년 Vicent Driessen의 Git Flow

브랜치 종류

• master
• develop
• featrue-*
• hotfix-*
• release-*
• improvement-*
• bugfix-

브랜치 분기 절차

1. master 브랜치에서 develop 브랜치를 분기합니다.
2. 개발자들은 develop 브랜치에 자유롭게 커밋을 합니다.
3. 기능 구현이 있는 경우 develop 브랜치에서 feature-* 브랜치를 분기합니다.
4. 배포를 준비하기 위해 develop 브랜치에서 release-* 브랜치를 분기합니다.
5. 테스트를 진행하면서 발생하는 버그 수정은 release-* 브랜치에 직접 반영합니다.
6. 테스트가 완료되면 release 브랜치를 master와 develop에 merge합니다.

이 flow는 배포 시기가 명확한 프로젝트에 특화되어 있습니다. 배포가 없을 때에는 개발자가 자유롭게 커밋을 진행하지만, 배포를 위해 release-* 브랜치가 만들어지면 집중적으로 버그 수정을 합니다. 이는 전통적인 방식의 개발 흐름에서는 문제가 없지만 지속적 통합/배포가 가능해진 요즘에는 오히려 문제를 일으킵니다. 배포 가능한 버전을 만들기 위한 사전 작업이 필요하기 때문이죠. 배포를 하려면 각 잡고 몰아치기를 해야 합니다.

2. 2011년 GitHub Flow

GitHub Flow는 커밋이나 feature- 브랜치에서 테스트를 완료하고
Pull Request와 Code Review를 거쳐 master 브랜치에 merge합니다.
따라서, release- 브랜치 없이도 항상 배포 가능한 상태를 유지 할 수 있게 됩니다

3. Git flow + GitHub flow

GitHub Flow처럼 개발자들이 지속적으로 브랜치를 merge 하지만,
통합 테스트가 완료된 커밋들만 선별적으로 배포를 할 수는 없을까요?
GitHub Flow에 staging 브랜치를 추가하고 interactive rebase를 이용해
develop 브랜치로부터 원하는 커밋들만 골라서 가져올 수 있습니다.

• develop : Pull Request를 거친 커밋들이 자유롭게 올라갑니다. 배포 보다는 기능 구현에 초점을 맞춘 브랜치이므로, 배포 주기에 구애받지 않고 커밋을 올릴 수 있습니다
• staging : 브랜치는 배포가 확정 된 커밋들이 있을 곳입니다. staging 브랜치는 지속적으로 유지됩니다. 따라서, 지속적 통합/배포 기능을 구축해두었다면 팀원 누구든 배포 가능한 빌드를 staging 빌드로 테스트 해 볼 수 있
• production : staging 브랜치에서 테스트가 완료되면, production 브랜치를 staging 브랜치로 merge하는 것만으로 배포가 완료됩니다.

4. Rebase를 활용한 Git Flow

develop 브랜치에서 feature/featureA 브랜치를 merge 합니다.
이 때 --squash 옵션을 주어 여러 커밋을 하나의 커밋으로 모아서 develop 브랜치에 새로 커밋을 만들어줍니다.
이렇게 하는 이유는 develop 브랜치에 한 feature 당 하나의 커밋, 한 bugfix 당 하나의 커밋을 유지하여
이후 staging 브랜치에 선택적으로 커밋을 옮길 때 수월하게 구분 할 수 있게 하기 위해서입니다.

개발은 배포로 인해 멈추어서는 안됩니다. develop 브랜치는 배포와 관계없이 지속적으로 PR이 올라오고 merge가 됩니다. 배포가 되기 위해 커밋들이 취합되는 브랜치는 바로 staging 브랜치입니다.

5. Git 사용할 때 알아두면 좋은 것들

1. Git GUI 보다 Git CLI를 이용합니다. Git CLI로 명령어를 직접 입력하며 작업을 하면 Git GUI 도구로 가려져있던 기능들까지 이해를 할 수 있습니다. Git GUI를 이용하는 것은 터미널에 명령어를 일일이 입력하지 않아도 되므로 편리하지만, 가능하다면 CLI로 동작 방식을 이해하고 사용하는 것이 좋습니다.
2. git pull 명령 대신,
   git fetch --prune과 git merge 명령 조합을 사용합니다.
   git pull은 내부적으로 git fetch와 git merge를 자동으로 처리해주는 shortcut입니다. 가급적이면 git fetch로 다른 작업자들의 작업 내용을 내려받은 후에 그래프 상황을 보며 merge를 해주는 것이 좋습니다.
3. 의존성 있는 PR은 최대한 지양해야 합니다.
   의존성이 있다면 하나의 PR로 갈 수 있을지를 먼저 의심하고,
   어쩔 수 없는 경우라면 반드시 후행 브랜치는 선행 브랜치와 함께 rebase 되어야 합니다.
4. bash-git-prompt와 같은 도구를 이용하여 터미널에서 git 상태를 빠르게 확인 할 수 있게 합니다.
   현재 어느 브랜치에서 작업중인지, staging 되어 있는 파일이 존재하는지, 충돌이 발생했는지 등을 빠르게 파악 할 수 있습니다.
5. pretty git log(https://coderwall.com/p/euwpig/a-better-git-log)를 이용하여 터미널에서 git commit graph를 시각적으로 확인 할 수 있게 합니다.
   터미널에서 커밋 그래프를 확인 할 때 반드시 필요한 도구입니다.
   공동 작업 중인 topic branch에 대한 rebase는 상대 작업자를 곤궁에 빠뜨릴 수 있습니다.
   rebase는 원래 있던 커밋을 없애고 새로운 커밋을 만드는 파괴적인 작업입니다.
   여러명이 작업중인 브랜치를 강제로 rebase 해버린다면 어떤 작업자는 이미 사라진 커밋 위에서 작업을 해야 할 수 있습니다.

Reference

• 지속적 통합/배포(CI/CD)를 위한 Git Workflow 전략 (https://blog.ull.im/engineering/2019/06/25/git-workflow-for-ci-cd.html)
• https://milooy.wordpress.com/2017/06/21/working-together-with-github-tutorial/