[TIL #54] Git Flow란?

Git을 사용했던 흐름

1. master에서 git clone
   새로운 branch를 파서 작업
   git add -> git commit -> git push -> pull request -> merge

2. merge 후
   master에서 git pull

• 새로운 branch파서 작업
• 기존 branch에서 계속 작업: 기존 branch가서 git merge master -> conflict 해결 후 계속 작업

👉 why conflict??

• 내가 pull받은 시점 이후에 달라진게 있을 때 (ex 다른사람이 merge)
• 그 해당하는 같은 줄에 다른 변경 내용이 들어와서!
  해결 => pull받고 branch 이동해서 git merge master

> Git Flow

Git Flow는 다양한 branch를 관리하고 통합하기 위한 전략 중 하나이다.
최근에는 Git Flow의 단점을 해소하기 위해 Github Flow, Gitlab Flow 등 다양한 전략이 있지만
가장 기본이 되는 Git Flow를 알아보겠다.

Git Flow의 주요 브랜치는 master와 develop이고

두 브랜치를 중심으로 feature, release와 필요에 따라 hotfixes 브랜치를 정의한다.

1. Master

master에는 최종 배포버전이 올라간다!
개발단계에 있는 코드들은 develop에서 합쳐진다.
devlop에서 새로운 브랜치를 파면 된다

👉기업협업때도 dev 브랜치 사용했던 경험!!
개발자님 : "master말고 dev로 pr날려주세요"

2. Develop

hotfix를 제외한 모든 변경내역이 출발하는 지점이다.
develop 브랜치의 코드가 안정화되고 배포할 준비가 되면 master를 통해 배포

📌 위코드 프로젝트는 실제로 서비스를 배포할게 아니어서
dev를 사용하지 않고 다이렉트로 master 이용

3. feature

기능을 개발하는 브랜치
다 완성되면 develop 브랜치로 병합한다.

• 브랜치가 생성되는 대상 : develop
• merge 대상: develop

4. release

정식 배포하기 전에 최종 확인 (버그 수정 등)

• 브랜치가 생성되는 대상 : develop
• merge 대상: develop, master

5. hotfix

배포 후 그 자리에서 "바로" 에러를 고쳐야 하는 상황
1분~5분만에 고쳐서 master에 바로 push

• 브랜치가 생성되는 대상 : master
• merge 대상 : develop, master

✅ 왜 항상 dev에서 branch를 파야하는지? 작업branch에서 branch를 파면 안되나?

작업branch에서 branch를 팔 수는 있다.

하지만 그 작업 branch는 아직 최종적으로 merge가 된게 아니어서
계속 수정사항이 발생하고 conflict가 계속 나므로
추가 branch를 파기에 좋지 않다.

최소한의 충돌로 모든것을 해결하기 위해 dev로부터 기준을 잡는것!

이렇게 git flow init이란 것을 사용하기도 한다.