Branch Models

---

• Git Flow : 가장 많이 사용한다. 각 단계가 명확히 구분되어있다. 하지만, 복잡하다.
  • (hotfix) - main - (release) - develop - feature
  • main : 제품으로 출시될 수 있는 코드만 존재하는 브랜치이다.
  • develop : 다음 출시 버전을 개발하는 코드가 있는 브랜치이다.
  • hotfix : 출시 버전에서 발생한 버그나 긴급 수정사항들을 수정하는 브랜치이다.
  • release : 이번 출시 버전을 준비하는 브랜치이다.
  • feature : 기능을 개발하는 브랜치이다.
• Github Flow : Git Flow 다음으로 많이 사용한다. 브랜치 모델을 단순화시켰다. CI 의존성이 높다. 한 명이 실수하면 큰일 난다.
  • main - feature
• Gitlab Flow : deploy(배포), issue에 대한 대응이 가능하도록 보완하였다.
  • production - pre-production - main - feautre

Git Flow 전략

쉽게 Git Flow 사용하기(Window)

---

Git Flow Cheatsheet를 활용하면 Git Flow를 좀 더 쉽고 편하게 사용할 수 있다.
git bash에 Cygwin이 설치되어있어 다른 설치작업은 필요 없다.

혼자서 git flow 사용하기

1. git flow init을 입력하면 브랜치의 이름 규칙을 정할 수 있지만, 기본값을 사용하자!

2. git flow feature start (branch name) 을 입력하면 'develop' 브랜치에 기반한 새로운 feature 브랜치를 생성하고 전환된다.

   • 작업 후 브랜치를 병합하기 전에 꼭 git status 를 입력하여 커밋이 제대로 되었는지 확인해야 한다.
     만약 제대로 커밋을 하지 않는다면 커밋되지 않은 파일들이 브랜치를 넘나들수도 있다.
     그러므로 제대로 커밋 후 브랜치를 병합하거나 삭제해야 한다.

3. git flow feature finish (branch name) 을 입력하여 기능 개발을 완료한다. 자동으로 'develop' 브랜치에 병합하고 삭제 후 'develop' 브랜치로 전환된다.

   • Merge Commit Message는 넘어간다.

4. git flow release start (v0.0.0) 을 입력하여 릴리스를 시작한다.

   • v0.0.0
     • 첫 번째 자리는 메이저이다. 메이저는 0은 베타 버전 1은 정식버전을 나타낸다.
     • 두 번째 자리는 마이너이다. 마이너는 서브보다 큰 기능 개발을 하였을 때 숫자를 높인다.
     • 세 번째 자리는 서브이다. 서브는 버그 수정이나 자잘한 기능을 개발하였을 때 숫자를 높인다.
   • release 브랜치에서는 배포 준비나 큰 단위 테스트를 한다.

5. git flow release finish (v0.0.0) 을 입력하면 3번의 vim 창이 뜬다.

   • 첫 번째는 'main'에 들어가는 Merge Commit 메시지이다.
   • 두 번째는 위의 Merge Commit에 대한 라벨링이 들어간다. 이것을 릴리스 노트라고 한다. 릴리스 노트는 해당 버전에서 어떤 일이 일어났는지 설명하는 노트이다.
   • 세 번째는 'develop' 브랜치에 들어가는 Merge Commit 메시지이다.

6. 릴리스 작업이 완료된 후, 원격 저장소의 브랜치를 확인해보면 로컬 저장소에서만 'develop' 브랜치를 만들었기 때문에 'main' 브랜치만 있을 것이다. 그러므로 'develop' 브랜치에서 git push -u origin develop 를 입력해준다. 그다음 'main' 브랜치에서도 push 해준다.

   • 릴리즈 작업을 마무리하면서 커밋에 대한 라벨링을 해주었는데 이것을 tag라 한다.
   • tag : 사용자가 사용하게 될 커밋에 대한 설명이다.
   • tag도 git push --tags 를 입력하여 푸시해줘야 한다.
   • tag는 브랜치가 아닌 커밋에 종속된다.

---

팀 단위로 git flow 사용하기

1. 팀장이 Github에서 새로운 저장소를 생성한다.
2. 팀원들은 팀장이 만든 저장소를 Fork 한다.
   • Fork : 소프트웨어의 소스코드를 통째로 복사하여 독립적인 새로운 소프트웨어를 개발하는 것을 뜻한다.

팀원

1. fork 한 저장소를 내 PC에 clone 한다.
2. clone 한 저장소로 이동하여 git flow init 을 입력하여 git flow tool을 사용할 준비를 한다.
3. 팀장의 Github 저장소에 Issue 탭으로 이동하여 내가 어떤 것을 개발할 것인지 To Do List를 작성한다.
4. To Do List 작성 후에 'develop' 브랜치 위에서 혼자서 git flow를 사용하는 방식으로 기능 개발을 한다.
   • git flow feature start (branch name)
   • 기능 개발 -> git add -> git commit
   • git flow feature finish (branch name)
5. 기능 개발을 끝내고, 'develop' 브랜치에 병합까지 시켜주었다면 push 명령어를 사용해 fork 저장소에 올려준다.
   • 이때, develop 브랜치가 생성되고 push는 처음이기 때문에 git push -u origin develop 를 사용한다.
6. push까지 완료 후 Github 홈페이지(fork 저장소)로 이동하여 팀장의 저장소로 Pull Request 한다.
7. 그 후 팀장과의 피드백이 끝나고 팀장이 merge 하면 끝이 난다.

팀장

1. 메일로 Issue와 Pull Request 가 오면 Github에서 확인하여 코드를 살펴보고 잘못된 부분은 고치라 말해주고 피드백을 완료한 후 merge 하면 된다.
2. git pull origin develop을 입력하여 내 PC에 merge 한 내용을 가져온다.
3. 그 후 릴리스 작업이 필요하면 명령어를 사용하여 릴리스 작업을 해준다.
   • git flow release start (v0.0.0)
   • git flow release finish (v0.0.0)

다른 팀원들이 한 것을 가져올 때

• 팀장 저장소의 URL을 git remote add 를 사용하여 새로 만들어준다. 이때, remote명은 upstream 을 주로 사용한다.
• remote를 설정한 다음 git fetch upstream develop를 사용하여 다른 팀원들이 한 것을 모두 가져오거나 일부만 가져올 수 있다.
  • fetch를 사용하면 FETCH_HEAD 라는 임시 브랜치가 생성되는데, 이 임시 브랜치에 다른 팀원들이 한 것들이 저장되어있다.
• 고르는 작업이 완료 후, git merge FETCH_HEAD 를 입력하여 임시 브랜치의 작업물을 'develop' 브랜치에 가져온다.