깃 플로우 이해하기

브랜치 종류는 크게 아래와 같다.

 

1. master
2. develop
3. feature
4. release

• 실제 개발은 develop 브랜치에서 진행된다.

 

• 그리고 develop 자체에서 커밋 내역을 만드는 것이 아니라 feature 브랜치에서 커밋을 만들고 이를 develop 에서 병합하는 식으로 커밋이 이루어진다.

 

• 별거 아닌 버그 픽스나 기능 추가는 그냥 develop에서 빠르게 반영한 후 커밋한다.

 

• 즉, develop 에서 왠만하면 커밋이 발생하지 않지만 발생할 수 있으므로 feature 브랜치에서 작업을 할 때는 항상 develop 브랜치의 변경 사항을 pull 해와야 한다.

 

• 개발이 어느 정도 완료되고 이를 배포하는 시점에서는 Release 라는 이름으로 시작하는 브랜치를 만든다.

 

• 해당 릴리즈에서 발생하는 버그나 수정사항들은 그 릴리즈 브랜치 안에서 커밋을 통해 작업한다. 그리고 커밋이 있을 때마다 작업 내역을 develop 브랜치에 merge 한다.

 

• Release 에서 모든 테스트가 끝나면 Master 브랜치에 그 Release 브랜치를 병합한다.

 

• 깃의 태그 기능을 통해 마스터 브랜치에 버전을 달아놓는다. 태그를 통해 간편하게 마스터 브랜치의 해당 버전에 해당하는 커밋에 바로 접근할 수 있도록 한다.

 

• 이제 마스터 브랜치의 내용을 서버에 배포하거나 사용자가 다운로드 할 수 있는 파일로 빌드한다.

 

• 이런 식으로 마스터 브랜치에는 실제 고객에게 배포되는 코드들만이 담긴 커밋들만 모여 있게 합한다.

 

• 정말 정말 급하게 작업해야 하는 버그 픽스를 핫픽스라고 부르며, 이는 핫픽스라는 이름의 브랜치에서 작업 후 마스터에 바로 병합시킨다. 물론 디벨롭 브랜치에도 내용을 바로 반영시켜야 한다. 이 핫픽스 브랜치는 가장 최신의 디벨롭 브랜치에서 분기되어 생성된다.

 

• 릴리즈 브랜치는 이후에도 디벨롭 브랜치와의 병합을 계속 해나가면서 실제 배포 단계에서 마스터 브랜치와 병합하는 것을 반복한다.