GitHub Flow란 무엇입니까?

git-flow

우선, git-flow는 GitHub Flow와 비슷합니다.
git-flow는 많은 Git 지점 전략 중의 하나로 A successful Git branching model를 바탕으로 한다.
다음은git-flow의 유명한 그림입니다.

( https://nvie.com/posts/a-successful-git-branching-model/ )master의 주요 지점, 개발용develop지점, 그리고 각 기능feature지점과 긴급용hotfix지점이 있는데 이 지점을 분리하여 개발하고 발표한다.

GitHub Flow란 무엇입니까?

GitHub Flow도 git-flow와 마찬가지로 분기 전략 중의 하나로 말 그대로 GitHub가 사용하는 절차이다.
GitHub Guides
GitHub Flow는 주요 master 지점과 기능 개발 feature 지점 등 두 가지 간단한 구성만 있습니다.
git-flow가 없는 특징은 Pull Request를 사용하면 마스터 지점은 항상 배치할 수 있다는 것이다.
(이하 Pull Request=PR)

GitHub Flow 개발 프로세스

계정에 저장소 fork 개발

master 지점에서 작업 지점을 분리합니다(지점의 이름은 자유입니다)

로컬 개발, 제출 및 제출된 지점으로 전송

본 자료고에 홍보를 하고 피드백을 받으면서 개발

트랜시버에 의해 승인된 후 본 저장소에 통합

배포🎉

포크가 뭐예요?

fork는 Git 저장소를 자신의 원격 저장소로 복사하는 것을 말한다.
clone이 로컬에서 메모리 라이브러리를 간단하게 복제하는 것에 비해fork의 목적은 본가의 메모리 라이브러리에 기여하는 것이다.

원본 저장소 변경 내용 캡처 방법

포크의 물건을 clone하면 포크의 원래 저장소가 계속 업데이트됩니다.
이 경우 다음과 같은 방법으로 원본 저장소의 변경 사항을 캡처할 수 있습니다.

// upstreamという名前でfork元のリモートリポジトリを登録
$ git remote add upstream fork元のリポジトリURL

// upstreamのmasterブランチの変更分をローカルに持ってくる
$ git fetch upstream master

// ローカルに持ってきたmasterの変更分をローカルのmasterに反映
$ git merge upstream/master

// もしforkして作成した自分のリポジトリに反映したい場合(originは自分のリモートリポジトリ)
$ git push origin master

하지만 포크가 GitHub Flow를 진행하면 마스터에서 피처링 지점을 차단하고 본가의 마스터에게 홍보하기 위해 오리진(자신)의 원격 저장소인 마스터는 잘 사용하지 않는다고 생각합니다.

당김 요청이 뭐예요?

PR(Pull Request)은 말 그대로 Pull(Request)을 요청합니다.
Pull Request는git-flow처럼 master 지점에 스스로 합병하는 것이 아니라 "자신의 저장소(origin)의 feature 지점에서 개발을 했기 때문에 feature 지점을 본가(upstream)의 master 지점에 합병하는 것"이라고 합니다.
pull은fetch&merge이기 때문에 상기 포크 원시 저장소를 가져와 변경하는 방법과 같이 로컬을 본 저장소(upstream)로 대체할 수 있습니다. 아래와 같습니다.

// ローカル = upstream と考えると、PRは以下のような操作

// 自分のリポジトリ(origin)で開発しているfeatureブランチの変更分を持ってくる
$ git fetch origin feature

// featureの変更分を本家リポジトリのmasterにマージ
$ git merge origin/feature

GitHub Flow 뭐가 좋아요?

"많이 봤는데 GitHub Flow는 뭐가 좋을까요?"이 가능하다, ~할 수 있다,...
GitHub Flow의 3가지 장점

간단했어

git-flow에는 hotfix, develop, release 등 다양한 지점이 있지만 GitHub Flow는 마스터 지점과 개발용 지점만 있습니다!
간단하고 기억하기 쉬워요. 학습 원가가 낮은 것이 중요해요.

논평할 수 있다

흔히 "WIP(업무중)에서 PR을 키운다"고 말하지만 PR을 제안해 개발하면 트랜지스터에서 피드백을 받기 쉬워 좋은 코드가 된다.

지점의 이름을 신경 쓰지 마세요.

※ 포크일 때
동일한 저장소에서 작업하는 경우에는 브랜치 이름을 덮어쓸 수 없습니다.
개발 구성원 간에 명명 규칙을 잘 결정하면 좋겠지만, 그것도 점점 번거로워진다.
하지만 포크의 저장소라면 결국 끌려들어가 합쳐지기 때문에 어떤 이름을 지어도 자유롭다🎉
지점 이름을 고민하는 시간은 코드를 쓰는 시간으로 넘어갑시다!
지점 이름을 신경 쓰지 않기 때문에 공감대가 없는 구성원이라도 저장소에 기여할 수 있다(OSS)

참고 자료

https://nvie.com/posts/a-successful-git-branching-model/

https://guides.github.com/introduction/flow/