【Git】ブランチとチーム開発での運用コマンド

ブランチとは

履歴の流れを分岐して記録していくためのもの。分岐したブランチは他のブランチの影響を受けないため、同じリポジトリ（変更履歴をためておく倉庫）内で複数の変更を同時に進めることができる。

具体的には、チームで同じプロジェクトで作業する場合、それぞれが自分の作業用のブランチを作成する。これによって、他の人の作業とは独立して自分の変更を行うことができる。また、作業がひと段落したら、自分のブランチを他のブランチに結合することができる。これをマージと呼び、別々に進めていた作業を1つのブランチに結合することができる。

ブランチの運用

統合ブランチ

いつでもリリースできるようにしておくためのブランチ。
通常、mainブランチを統合ブランチにするが、開発中はリリースできる状態でないことが多いので、developブランチをmainブランチ下に作成し統合ブランチとすることもある。
スクールでは、developブランチを結合ブランチとする。

トピックブランチ

機能追加やバグ修正など、タスクに関する作業を行うためのブランチ。 複数の課題に関する作業を行うときは、その数だけトピックブランチが作成される。ブランチ名は、「何の作業をしているか」 を分かるようにしておくこと。
トピックブランチは安定したブランチから分岐させ作成し、作業が完了したら統合ブランチに取り込む。

まとめ

今回のチーム開発のブランチを、机に例えるならば以下のような感じ。

• mainブランチ：展示用の机
  お客さんに公開用の完成品を置く机。

• 統合ブランチ（developブランチ）：一度合わせる机
  各作業者が作業したものをひとつにまとめ、まとめたものをチェックする机。

• トピックブランチ：個人の作業机
  各作業者が個別に作業をするための机。作業者は、統合ブランチに持ってい行く前に、自分で作ったもののチェックをする。

ブランチの結合

結合方法は以下の2つある。

マージ（Merge）:

• ブランチの変更履歴を統合する。
• 変更履歴が保持され、マージコミットが作成される。
• 分岐した変更履歴が明確になり、変更内容を追跡しやすくなる。
• 複数の人が共同作業を行う際に使用される。

リベース（Rebase）:

• ブランチのベースを移動させ、変更履歴を再適用する。
• 変更履歴が変更され、直線的な変更履歴を作成することができる。
• 変更履歴を整理して見やすくすることができる。
• 個人の作業ブランチで使用されることが多い。

運用例

統合ブランチとトピックブランチを使用した例。
例えば、機能追加をするトピックブランチで作業を行っているときに、バグの修正を行う場合。

統合ブランチは機能追加をはじめる前の状態なので、ここから新たにバグ修正用のトピックブランチをつくることで、機能追加とは独立して作業を始めることができる。

完成したバグ修正の内容は、元の統合ブランチに取り込む。。

元のブランチに戻って機能追加の作業の続きができる。

ただ、作業の続きを行うには今のバグ修正、コミットMの内容が必要になった。MergeとRebaseどちらも使えるが、今回はRebaseを使用。

Merge vs Rebase

Merge（マージ）の利点:

• 変更履歴が保持されるため、変更内容の追跡やバグの特定がしやすくなる。
• マージコミットが作成されるため、作業の履歴が明確になる。
• 複数の作業ブランチの変更を統合するのに適している。

Mergeの注意点:

• マージコミットが増えるため、履歴が複雑になることがある。
• ブランチの分岐が残るため、ブランチの履歴が複数残る可能性がある。

Rebase（リベース）の利点:

• 変更履歴が整理され、直線的な変更履歴が作成される。
• リベース先の最新状態に作業内容を取り込むため、衝突の可能性が低くなる。
• 履歴がすっきりして見やすくなる。

Rebaseの注意点:

• 変更履歴が書き換えられるため、他の開発者との共同作業時には注意が必要。
• 履歴の書き換えが行われるため、変更内容の追跡やバグ特定がやや難しくなる場合がある。

一般的には、統合ブランチに取り込む前の作業ブランチであるトピックブランチでのrebaseが推奨される。これにより、作業内容が直線的な履歴として残り、マージコミットの増加を抑えることができる。ただし、他の開発者が同じブランチを利用している場合には注意が必要であり、リベースは既にプッシュしたコミットに対して実行するため、他の開発者との調整や連絡が重要。

よって重要なのは、チームメンバーとの相談や合意を得ながら、どちらの方法でいくか決めるこ*と。

このように、コミットMの内容を取り込み、機能追加の続きを進められる。
ブランチをうまく使えば、異なる作業を並行して進めることができる！

ブランチの運用コマンド

統合ブランチの作成・移動手順

今回の実装はdevelopブランチを統合ブランチとする。

コマンド	説明
git checkout -b develop	developブランチを作成し、そのブランチに移動
git branch	ブランチ一覧を表示
git commit --allow-empty -m "Empty commit"	空のコミットを作成
git push origin develop	作成したdevelopブランチをリモートリポジトリにpush

統合ブランチの反映手順

コマンド	説明
git checkout -b develop	developブランチを作成し、そのブランチに移動
git pull origin develop	リモートの最新の変更を取得してローカルに反映

トピックブランチを切る手順（新しい作業ブランチの作成）

トピックブランチの作成

コマンド	説明
git checkout develop	developブランチに移動。新しいトピックブランチを作成する前に、ベースとなるブランチに移動。ここではdevelopブランチをベースにする。
git checkout -b トピックブランチ名	トピックブランチ名で指定した名前の新しいブランチを作成し、そのブランチに移動。トピックブランチの名前は作業内容や目的に合わせて適切なものを付ける。

トピックブランチでの作業実施。

トピックブランチをリモートに反映

コマンド	説明
git status	現在のリポジトリの状態を表示。変更がある場合、どのファイルが変更されたかやステージングされているかなどの情報が表示される。
git add -A	変更された全てのファイルをステージングエリアに追加。-Aオプションは変更のある全てのファイルを対象にする。
git commit -m "コミットメッセージ"	変更をコミット。
git push origin トピックブランチ名	ローカルのブランチをリモートリポジトリにプッシュする。トピックブランチ名はプッシュするブランチの名前をいれる。

統合ブランチ・トピックブランチの反映手順

プルリクエストをマージした後、統合ブランチにトピックブランチの変更を反映させる手順。

コマンド	説明
git checkout develop	developブランチに移動。
git branch	現在のブランチとブランチ一覧を表示。
git pull origin develop	リモートのdevelopブランチから最新の変更を取得。動作確認をする。
git checkout 自分の作業ブランチ	自分の作業ブランチに移動。
git merge origin/develop	リモートのdevelopブランチを作業ブランチにマージする。
git push origin 自分の作業ブランチ	自分の作業ブランチの変更をリモートにプッシュ。

開発チーム全員がpushすると、GithubのNetworkで全員が横並びになる！それを確認したらまた作業の繰り返し！

---

今日から実装開始！前倒しできるように楽しみながら頑張ろう！