Git Flow

처음에는 git flow를 따라서 브랜치를 관리하는 이유가 잘 이해 되지 않았는데,

혼자서 프론트엔드 파트를 담당하고 개발하면서 하나하나 불편한 점을 느끼며 필요성을 배우게 되었다

git flow branch

1. master

   마스터 브랜치를 사용하는 이유는 지금 현재 배포되어 있는 부분이 어디까지 작업된 코드인지 알수 있다.

   에러를 고치고, 기능을 추가하고, QA 들어온걸 해결하고, 테스트를 하다보면 한번에 한가지의 일만 할 수 있는 근무환경이 제공되는 일은 별로 없는거 같다.

   누군가 관리를 해주는게 아니고 내가 나를 관리해야 되다보니
   작업 내용이 뒤섞여 어디까지 적용되었는지 파악해야 되는 일이 있게 되기 마련이다.

   예를 들면 저번에 내가 발견한 에러를 수정했는데 그 내용이 QA 문서에 추가되었다.
   내가 제대로 수정을 안했나?;; 테스트까지 진행 했는데… 라는 생각이 들때 master 브랜치를 확인해서

   배포된 버전에 수정한 내용이 적용되었는지 한번에 알수 있다.

   또 staging에 있는 코드가 실제 배포가 되었는지도 master브랜치를 보고 확인할 수 있다.

2. staging

   보통 평소에는 master 브랜치와 거의 동일한 코드다. 배포하기 직전의 코드를 넣어두고, 배포 시점이 되면 master에 적용한다.

   이렇게 하면서 테스트가 완료된 코드를 개발하는 코드와 분리 할 수 있게 된다.

   또 마스터 브랜치의 코드와 비교해서 staging에서 hotfix를 생성할지, master에서 hotfix를 생성할지 결정 할 수 있어서 좋다.

   이러면 master와 staging이 헷깔릴수 있지 않을까 생각할 수 있는데 hotfix는 말그대로 빨리 고쳐서 배포해야 되는 오류를 잡는거라 보통 작업하고 바로 배포하게 된다.

   그러면 master에서 작업을 했어도 staging에 merge를 해서 컨플릭트를 해결하든 맞춰야 되고,

   staging에서 작업을 했어도 배포했기 때문에 master에 merge를 해서 배포 버전을 맞춰야 된다.

3. dev

   개발한 feature 들을 모아서 테스트 할 수 있는 브랜치로 파일만 다르다면 여러 브랜치를 생성해서 브랜치를 옮겨다니면서 작업을 해도 된다. 그리고 작업이 완료(에러가 뜨지 않게 까지 작업해야 됨)되면 dev로 pr을 올려서 merge해서 테스트를 하면 된다.

4. feature/something

   기능별로 계속 브랜치를 생성해서 작업 해준다.

   로컬에서 dev로 보내지 않고 origin으로 푸시를 한다음에 pr을 올리는 식으로 작업해주면 좋다.

   push 를 하기 전에는 dev브랜치를 rebase로 땡겨와 기능별로 커밋을 모아주면 커밋을 관리하기 용이하다.

   dev 브랜치로 merge 했으면 원격에 있는 브랜치를 삭제한다
   로컬에도 dev를 pull 받아 최신화를 해주고, 로컬에 있는 브랜치도 삭제한다.

   이렇게 하다보면 옛날에 생성한 브랜치가 작업이 완료된 브랜치인지 고민할 필요도 없어지고 브랜치가 쌓여 github와 local이 지저분해지는것을 방지할 수 있다.

5. hotfix/something

   필요할 때마다 master 또는 staging에서 생성해 최우선으로 작업해서 merge한다.

   작업을 하게 되면 다른 작업물과 컨플릭트가 날 가능성이 다분하기 때문에 꼭 수정 코드가 머리속에 있을때 모든 브랜치를 맞춰주는것이 좋다.