[Git] Git-flow와 Github-flow 차이점

📌 Git-flow

Master(Main) - 제품으로 출시되는 Branch, Production의 개념을 내포하고 있다.
Develop - 다음 출시 버전을 개발하는 Branch
Feature - 기능을 개발하는 Branch, 주로 이 브랜치에서 개발을 한다.
Release - 이번 출시 버전을 준비하는 Branch, QA를 진행하는 브랜치이다.
Hotfix - 출시 버전에서 발생한 버그를 수정하는 Branch

1. 처음에 Master(Main)와 Develop 생성
2. 새로운 추가 작업은 Develop에서 Feature Branch 생성
3. Feature는 Develop으로 Merge(이때 Develop이 최신 상태인지 확인해야함)
4. QA를 위해서 Develop에서 Release Branch 생성
5. QA에서 발생한 버그는 Release에서 수정
6. QA가 끝나면 Release에서 Develop / Master(Main)으로 각각 Merge
7. Hotfix는 Master에서 시작하여 수정 후 Master / Develop에 Merge

Git-Flow가 유용하긴 하지만 너무 많은 브랜치를 사용하는 점, 그에 따라 안쓰는 브랜치가 생기고 브랜치 마다 포지션이 애매해질 수 있기 때문에 이러한 점을 보완해 좀 더 간소화 된 브랜칭 전략이 나왔는데 그것이 GitHub-Flow이다.

📌 Github-flow

Git-Flow가 복잡하기에 이를 좀 더 간소화시킨 방식으로 Scott chacon이 Github에서 좀 더 편리하게 사용하기 위해 만든 브랜칭 전략이다. 자동화 개념이 포함되어 있으며 Master(Main) Branch에 대한 role만 정확하다면 나머지 Branch들에는 관여를 하지 않는다. 그리고 Pull Request 기능의 사용을 권장한다.

1. Master Branch의 어느것이든 배포가 가능하다.
master 브랜치는 항상 최신 상태며, stable 상태로 product에 배포되는 브랜치
이 브랜치에 대해서는 엄격한 role과 함께 사용한다
merge하기 전에 충분히 테스트를 해야한다. 테스트는 로컬에서 하는 것이 아니라 브랜치를 push 하고 Jenkins로 테스트 한다

2. 새로운 일을 시작하기 위해 Branch를 Master에서 딴다면 이름은 어떤 작업인지 명확하게 명시한다.
브랜치는 항상 master 브랜치에서 만든다
Git-flow와는 다르게 feature 브랜치나 develop 브랜치가 존재하지 않음
새로운 기능을 추가하거나, 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해주도록 하자 커밋메시지를 명확하게 작성하자

3. Local Branch에 수시로 커밋하고 이 내용을 원격 Branch에 수시로 Push한다.
Git-flow와 상반되는 방식
항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다
이는 하드웨어에 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아서 작업할 수 있도록 해준다

4. 피드백이나 도움이 필요할 때 혹은 자신의 Branch가 merge할 준비가 되었다면, PR을 생성하여 공유한다.
pull request는 코드 리뷰를 도와주는 시스템
이것을 이용해 자신의 코드를 공유하고, 리뷰받자
merge 준비가 완료되었다면 master 브랜치로 반영을 요구하자

5. PR 리뷰 후에는 다른 사람의 동의를 얻고 Master에 Merge한다.
곧장 product로 반영이될 기능이므로, 이해관계가 연결된 사람들과 충분한 논의 이후 반영하도록 한다
물론 CI도 통과해야한다!

6. Master Branch로 Merge나 Push가 이루어지면 즉시 배포해야한다.
GitHub-flow의 핵심
master로 merge가 일어나면 자동으로 배포가 되도록 설정해놓는다.