GitHubハンズオン 第3回 ～ブランチ運用法編～
本記事は、GitHubハンズオンの第3回の資料です！
過去の記事を読んでいることを前提としていますので、ご注意ください。
GitHubハンズオンシリーズ
- GitHubハンズオン 第1回 〜個人開発編〜
- GitHubハンズオン 第2回 〜共同開発編〜
- GitHubハンズオン 第3回 ～ブランチ運用法編～ ← 本記事
- GitHubハンズオン 第4回 ～いろいろ取り消し編～
- GitHubハンズオン 第5回 ～無視リスト編～
- GitHubハンズオン 第6回 ～巨大ファイル編～
リポジトリの準備
第1回ハンズオン で作成した GitPractice リポジトリを今回も使います！
もし、リポジトリを削除してしまった方は、再作成をお願いします！
Forkを開き、フェッチ＆チェックアウトして、mainブランチを最新にしてください。
ブランチ運用法
ブランチの使い方には色んな流派がありますが、ここでは有名な GitHub Flow を紹介します！
GitHub Flow
GitHubでは、数千人規模のプログラマーが、1つのリポジトリで共同開発することもよくあります。
そんな状況でも、混乱が発生しないように編み出されたブランチ運用法が、 GitHub Flow です。
以下のルールを守って、ブランチを運用します。
- mainブランチからtopicブランチを生やす。
- mainブランチは常にリリース可能な状態にしておく。
- topicブランチはこまめにプッシュする。
（厳密には、PullRequestを利用したコードレビューもGitHub Flowのルールに含まれますが、今回のハンズオンではPullRequestを扱いませんので、説明は省略いたします。）
mainブランチからtopicブランチを生やす
何か作業をするときは、mainブランチからtopicブランチを生やします。
mainブランチ上で作業しないようにしましょう！
あくまで、mainブランチはtopicブランチをマージするときだけ進みます。
topicブランチ命名例
topicブランチの名前は、なんのためのブランチなのか説明する内容にしておきましょう！
たとえば、 ボタン機能を追加 した場合、以下のような命名案があります。
- topic/作業名
- 例: topic/add-button
- 作業種別/作業名
- 例: feature/add-button
- ここでの作業種別とは、以下のようなものです。
- feature : 機能開発
- fix : バグ修正
- 作業者名/作業名
- 例: segur/add-button
- 作業者名/課題番号/作業名
- 例: segur/123/add-button
- ここでの課題番号とは、課題管理ツール（GitHub Issue, JIRA等）で発行される番号のことです。
/ と - の違いは後ほど説明します！
単語の区切りは - が一般的ですが、 _ や大文字区切りでも、Gitは動作します。
mainブランチは常にリリース可能な状態にしておく
他のメンバーが安心してmainブランチを利用するために、動作が不安定になるtopicブランチを、mainブランチにマージしてはいけません。
たとえば、実行するとエラーが発生する状態のtopicブランチをAさんが作ったとして、それをmainブランチにマージしてしまうと、Bさんがそのmainブランチを利用するときにエラーが発生してしまいます。
Bさんからすると、なぜエラーが発生するのかを調査する必要があり、ムダな時間をとられてしまいます。
動作が不安定なtopicブランチをmainブランチにマージしてはいけません。
- ✅: UnityAssetを導入し、動作確認せずに、topicブランチにコミットする。
- ❌: UnityAssetを導入し、動作確認せずに、topicブランチにコミットし、それをmainブランチにマージする。
- ✅: UnityAssetを導入し、topicブランチにコミットする。動作確認をしたところ、エラーが見つかったので、修正してから、mainブランチにマージする。
topicブランチは定期的にPushする
チーム開発では、作業の共有が重要になります。
Aさんがtopicブランチを1週間に1回プッシュすれば、Bさんはその内容を1週間に1回確認できます。
Aさんがtopicブランチを毎日プッシュすれば、Bさんはその内容を毎日確認できます。
情報共有をこまめにするほうが、ブランチが競合したり、作業が重複することを避けることができます。
なるべく毎日プッシュするようにしましょう！
ブランチ用語
GitHub Flow ≠ Git Flow
ブランチ運用法について調べると、Git Flowという用語を見かけますが、これはGitHub Flowとは別の流派です！
名前が似ているのでご注意ください。
Git Flowは、GitHub Flowにdevelopブランチを追加するアイデアです。
topicブランチ = featureブランチ
ブランチについて調べると、featureブランチという用語を見かけますが、これはtopicブランチの別名です。
- GitHub Flowでは、topicブランチ
- Git Flowでは、featureブランチ
と呼ぶ慣習があります。
日本語だと、機能ブランチ・支流・枝などと呼ぶ人もいます。
mainブランチ = masterブランチ
ブランチについて調べると、masterブランチという用語を見かけますが、これはmainブランチの昔の名称です。
masterには「奴隷の主人」という意味があり、人権問題の観点からセンシティブなので、あまり使われなくなりました。
https://www.publickey1.jp/blog/20/githubmainmastermain.html
日本語だと、統合ブランチ・本流・幹などと呼ぶ人もいます。
ブランチの整理
ブランチ名にスラッシュを入れる
自分の名前/update-read-me というブランチを作って、READMEの内容を変更し、コミットしてください。
Forkの左側の Branches を見ると、自分の名前のフォルダーができています。
ブランチ名に / を入れると、Forkがフォルダーとして表示してくれるためです！
ブランチが大量にあると、フォルダーで整理した方が、見通しがよくなるので、積極的に使っていきましょう！
- はフォルダーにはならないので、使い分けていきましょう！
さいごに
今回はここまでです！おつかれさまでした！
次回はいろいろ取り消し編です！引き続きこちらも実践していただけると嬉しいです！
本記事作成にあたり、以下の記事を参考にさせていただきました。ありがとうございました！