開発未経験が書く Git-flow、GitHub-flowの便利なところ

この記事について

この記事は、開発未経験の人間がインプットした内容が書かれています。
実際に開発経験を積まないと身につかない、かといって疎かにしたら後々痛い目にあう、といったジレンマを少しでも解消するために、「頭の中を言語化し、解釈違いを指摘してもらう」という手段を取ることとしました。
気になる点がありましたらツッコミをいただけると嬉しいです。

記事の内容

Git-flowとGitHub-flowの良いところを、Gitのみで開発した場合と比較しまとめる。

インプット教材

git flowとgithub flowとは？その違いは？: https://qiita.com/mint__/items/bfc58589b5b1e0a1856a
Git-flowって何？: https://qiita.com/KosukeSone/items/514dd24828b485c69a05#1ローカルリポジトリにクローンを作成する
Git-flow ～Gitのブランチモデルを知る～ : https://tracpath.com/bootcamp/learning_git_git_flow.html#i
GitHub Flow ～GitHubを活用するブランチモデル～ : https://tracpath.com/bootcamp/learning_git_github_flow.html

開発環境

git version 2.21.0

例題

以下の作業を行う。

• 猫を愛でるテキストファイルcat_lover_said.txtを作成
• 文体がバラバラなので統一する作業をする
• 文末にある「頭おかしい」という表現が過激なため、マイルドにする。

Gitのみで作業した場合

Gitのみで作業した場合は以下の順番で作業することになる。ソースコードは割愛。

1. 中身が空のレポジトリをGitHubに作成し、ローカルリポジトリにクローンを生成。ユーザー名とアドレスを登録。
2. developブランチを切り、猫を愛でるテキストファイル"cat_lover_said.txt"を作成してPush
3. 文体を統一する作業ブランチfeature/unify_stylesを切り作業する。
4. 文章の末尾にある「頭おかしい」という文章を修正するため、hotfixブランチを切り修正する。Githubにも同名のファイルを作成。
5. 作業が完了したら、追跡できるようにようにしてPush。
6. hotfixをmasterにマージ。masterをPush。
7. hotfixを削除し、Githubの方も同時に削除。
8. masterをdevelopにマージしてdevelopをPush。
9. 文体のを統一する作業が終わっているのでPushしたいが、先にPullする必要があるのでPullしてから作業ブランチfeature/unify_stylesをGithubにも作成。
10. 作業ブランチfeature/unify_stylesをmasterにマージしてmasterをdevelopにマージ。
11. Pushして完了。

Git-flowで作業した場合

Git-flowには6種類のブランチがあらかじめ定義されている。
1. masterブランチ・・・Git作成時に自動で作成されるブランチ。直接コミットすることはなく、マージを行うだけ。このブランチの最新版が市場に公開される。
2. developブランチ・・・開発の中心となるブランチ。だが、実際の作業はここから枝分かれしたブランチで行い、作業完了後にdevelopブランチへマージする。masterブランチ同様、このブランチも直接コミットしないので注意。Git作成時、最初にmasterから切っておく。
3. featureブランチ・・・機能の追加や変更、バグの修正をするブランチ。一つの変更に対してひとつのfeatureブランチを切ること。ブランチの名称は作業の内容がわかるような名前にする。developブランチから切り、作業終了後にdevelopブランチへマージし、削除する。
4. releaseブランチ・・・製品をリリースするために使うブランチ。リリースに関連する作業をする（タグつけなど）。developブランチから切る。作業完了後にmasterとdevelopにマージし削除する。
5. hotfixブランチ・・・緊急な修正があった場合にmasterからこのブランチを切る。作業後にmasterとdevelopにマージし削除。
6. supportブランチ・・・プロジェクトによっては不要だが、旧サポートし続けなければならないプロジェクトではsupportブランチが必要。このブランチは旧バージョンの保守とリリースを行う。サポートが必要なバージョンのmasterのコミットから派生させ、サポート終了まで独立してバグ修正やリリースを行う。

作業開始

• 空のレポジトリをGitHubに作成し、クローンを作りユーザー名とアドレスを登録。
• 作業ディレクトリでgit flow initを実行し初期化する。なんか色々聞かれるが全てEnterで実行で問題なし。Git-flowで定義している各ブランチが設定される。
• developでは作業を行わず、新しく作業ブランチを切る。作業ブランチはfeatureブランチと言われており、切るときはgit flow feature start branch_nameを実行。実行後、自動的にdevelopからブランチが切られる。
• "cat_lover_said.txt"を作成し、addとcommitする。
• git flow feature finish branch_nameでdevelopにマージする。
  • Git-flowでブランチを切る時には、startとfinishというコマンドを使う。 git flow feature start aaaでaaaという名のfeatureブランチがdevelopから自動で切られ、 git flow feature finish aaaでaaaという名のfeatureブランチがdevelopにマージされ、さらにマージ後に自動で消去してくれる。
• 作業が完了したのでPushしたいところだが、Git-flowにはreleaseブランチが必要である。先にgit flow release start branch_nameでreleaseブランチを作成。これも自動でdevelopから切られる。タグをつけるなど、何かしらのリリース処理をしたら、git flow release finish branch_nameでdevelopをマージしてから、masterへマージする。
• マージコミットのメッセージとは別にリリースタグの文章がかけるので「初回リリース」と入れておく。
• Pushする。developはリモートディクトリと連携していないので、連携する。
• 「頭おかしい」という表現を修正する作業ブランチhotfixを作成。修正後のバージョン1.1を名称にする。
• 作業が完了したら、git flow hotfix finish 1.1でmasterへマージ。
• pushする。
• unify_stylesブランチもすでに終っているのでhotfixの時と同じ流れでmasterへマージ、masterをdevelopへマージする。

Git-flowを使った場合のメリット

• git flow branch start(finish) branch_nameで自動でブランチを適切なブランチから切ってくれたり、マージしてくれる。
• 自動で作業が終わったブランチを削除してくれる。

GitHub-flowで作業した場合

GitHub-flowには2種類のブランチ（master, topic）しかない。6種類あるgit-flowのブランチの方が厳密であるが、手間が多くなりがち。厳密な区分けが必要ない場合はGitHubーflowを使った方が楽。また、git-flowでは特熱なイベントとしてdevelopとmasterの間にreleaseがあるが、GitHub-flowにはそれがないのでmasterへのマージにはgit-flow以上に細心の注意が必要である。

注意点

• 必ずmasterからtopic（作業ブランチ）を切る。masterでの作業はマージするのみ。
• ブランチは定期的にPushする。GitHub-flowはその名の通り、GitHubを介したコミュニケーションを推奨している。そのため、頻繁にコードレビューを行うことで仲間との情報共有を重視している。
• プルリクエストを活用し、積極的にコードレビューをしてもらう。
• コードレビューが通ったら速やかにマージする。他の開発者とマージで衝突が起こる可能性があるため。

作業開始

• ユーザー名とアドレスを作業ディレクトリに登録。
• GitHubにレポジトリを作成。この時、他に作業メンバーがいるときは追加する。
• リポジトリのクローンを作業ディレクトリに生成。
• 空のコミットを作ってGitHubにPush。
• topicブランチであるcreate-text-fileブランチを生成し、そこでcat_lover_saidを作成。addしてcommit。
• pushする。初回push時にGitHubへのログインパスワードを聞かれるので入力。
• GitHubのサイトからプルリクエストをしてコードレビューをしてもらう。
• OKが出たらマージする。GitHubからボタンクリックで簡単にできる。
• GitHubにあるcreate-text-fileブランチを削除する。これもGitHubにボタンがあり簡単にできる。作業ディレクトリのブランチは手動で削除する。
• 作業ディレクトリのmasterが古いままなのでPullして最新版にする。
• 「頭おかしい」という表現を修正するhotfixブランチを生成する。あとはcreate-text-fileブランチと同じ流れ。
• 文体を統一するunify_stylesブランチを生成。同じ流れで作業する。

GitHub-flowを使った場合のメリット

• 作業ディレクトリで行う作業とGitHubで行う作業がきっちり区分けされていてわかりやすい。
• 細かいブランチの設定が必要ない。
• 「ブランチを切る→作業する→push→レビューしてもらう（修正し再提出する）→マージする→作業ブランチを削除→Pull」という流れがわかりやすいので未経験者の私には一番理解が容易で実装しやすいと思った。