git-flowとは
まず、GItHub Flowと似たものにgit-flowがあります
git-flowとは数あるGitのブランチ戦略の1つで、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と同様にブランチ戦略の1つであり、その名の通りGitHubで利用されているフローです。
GitHub Guides
GitHub Flowではメインのmasterブランチと機能開発のためのfeatureブランチの2つのみのシンプルな構成になっています。
git-flowにはない特徴としては、Pull Requestを使うという点と、masterブランチは常にデプロイ可能という点があります。
(以下Pull Request=PR)
GitHub Flowの開発の流れ
- 開発リポジトリを、自分のアカウントへforkします
- masterブランチから、作業ブランチを切ります (ブランチの名前は自由です)
- ローカルで開発、コミットしてForkしたブランチへPushします
- 本家リポジトリへPRを出し、フィードバックを受けながら開発を進めます
- レビュワーに承認されたら、本家リポジトリへマージします
- デプロイ🎉
forkとは
forkとは、あるGitリポジトリを自分のリモートリポジトリにコピーしてくることです。
cloneが単純にローカルにリポジトリをコピーすることに対して、forkは本家のリポジトリへ貢献することが目的です。
fork元のリポジトリの変更を取り込む方法
forkしたものをcloneすると、fork元のリポジトリがどんどん更新されてしまいます。
その場合は以下のようにしてfork元のリポジトリの変更を取り込むことができます。
// 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
ただ、forkしてGitHub Flowを行っている場合は、masterからfeatureブランチを切り本家のmasterにPRを出すため、origin(自分)のリモートリポジトリのmasterはあまり使わないと思います。
Pull Requestとは
Pull Request(PR)とは、その名の通り「Pullして欲しいとお願いする(Request)こと」です。
git-flowのように自分でmasterブランチにマージするのではなく、「自分のリポジトリ(origin)のfeatureブランチで開発を行ったから、featureブランチをPullして本家(upstream)のmasterブランチにマージしてもらう」のがPull Requestになります。
pullはfetch & mergeのことなので、上記のfork元のリポジトリの変更を取り込む方法と同様に、ローカルを本家リポジトリ(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はmasterブランチと開発用のブランチだけ！
シンプルで覚えやすいですね、学習コストが低いのは大切です。
レビューしてもらえる
よく「WIP(作業中)でPRを育てる」なんて言いますが、PRを出して開発を進めるとレビュワーからのフィードバックをもらいやすく良いコードになっていきます。
ブランチ名を気にしなくて良い
※これはforkした時のみです
もし同一リポジトリで作業している場合はブランチ名が被ってはいけません。
開発メンバー同士で命名規則をしっかり決めていればいいですが、それも次第に面倒になってきます。
しかしforkしたリポジトリであれば、最終的にはPullしてマージされるだけなので、どんな名前をつけようが自由です🎉
ブランチ名で悩んでいる時間はコードを書く時間に回しましょう！
ブランチ名を気にしなくてもいいので共通認識がないメンバー同士でもリポジトリに貢献できます(OSS)