#14 Gitのブランチについて

Gitのブランチ機能は、ソースコード管理において非常に強力で柔軟なツールです。

プロジェクトの開発を効果的に進めるためには、ブランチの理解と活用が欠かせません。

本ページでは、Gitブランチの基本から高度な操作方法まで、包括的に解説します。

ブランチをマスターすることで、チームでの協働作業や個人プロジェクトの管理が格段に向上します。

それでは、ブランチの世界へ踏み出しましょう。

ブランチ（branch）とは

Gitのブランチ（branch）とは、プロジェクトの開発を並行して進めるための機能です。

ブランチを使用することで、メインのコードベースを維持しながら新機能の開発やバグ修正を独立して行うことができます。

ブランチの基本概念 は、既存のコードベースから分岐し、新たな変更を安全かつ整理された方法で導入することを可能にする点です。

例えば、新しい機能の開発を行う場合、まず新しいブランチを作成します。

このブランチ上で作業を行うことで、メインのブランチ（通常はmasterまたはmainと呼ばれます）に影響を与えることなく開発を進めることができます。

開発が完了したら、そのブランチをメインのブランチにマージ(merge)することで、新しい機能を取り込むことができます。

ブランチのメリット

1. 独立した開発環境

ブランチを利用することで、開発者は他の人の作業に影響を与えることなく、自分のタスクに集中できます。

これは特に大規模なチームや複雑なプロジェクトで有効です。

例えば、新しい機能を開発する際には新しいブランチを作成し、他の開発者が同時に別の機能やバグ修正を行っていても、干渉し合うことはありません。

2. 効率的なチーム開発

複数の開発者が同時に異なるブランチで作業することで、作業の平行化が可能になります。

これにより、プロジェクト全体の生産性が向上します。

また、プルリクエストを通じて変更をマージする際に、他のプログラマーに作成したコードを見てもらえるレビューやフィードバックが行われるため、コードの品質も向上します。

3. 簡単なマージ

ブランチを使えば、作業が完了したら変更をメインのコードベースに簡単にマージできます。

これにより、安定したリリースサイクルを維持しつつ、新機能や修正を迅速に統合できます。

例えば、リリース前にすべての機能ブランチを一度にマージすることで、バージョン管理が効率的に行えます。

4. バグ修正の迅速化

バグ修正や緊急の変更を迅速に行うために、バグ修正専用のブランチを作成し、修正が完了次第メインブランチに統合できます。

これにより、クリティカルなバグが発生した場合でも、影響を最小限に抑えた迅速な対応が可能です。

5. 非常に軽量

ブランチは非常に軽量で、作成や切り替えが迅速に行えます。

Gitではブランチはメタデータとして管理されるため、ディスクスペースやメモリの使用量が少なく、効率的にブランチを操作できます。

これにより、開発者は気軽にブランチを作成して、実験的なコードや新しいアイデアを試すことができます。

ブランチのデメリット

1. コンフリクトの発生

複数の開発者が同時に異なるブランチで作業していると、マージ時にコンフリクトが発生することがあります。

コンフリクトの解消には手間がかかり、場合によっては変更の再確認が必要になるため、時間と労力がかかります。

2. ブランチの管理が複雑

多くのブランチが存在する場合、その管理が難しくなることがあります。

特に長期間にわたって複数のブランチが維持されると、どのブランチが最新のものであるかを把握するのが難しくなります。

3. 過剰なブランチの生成

必要以上に多くのブランチを作成すると、リポジトリが複雑化し、作業の進行状況を追跡するのが困難になります。

また、不要になったブランチの削除を怠ると、リポジトリが散らかりがちです。

4. 統合テストの手間

ブランチごとに変更が加えられるため、統合テストの実施が必要になります。

特に大規模なプロジェクトでは、複数のブランチを統合する際に、すべての変更が正常に動作することを確認するためのテストが不可欠です。

ブランチの操作

Gitのブランチ機能は、ソフトウェア開発におけるバージョン管理とコラボレーションに欠かせない重要なツールです。

このセクションでは、ブランチの操作に関連する主要なコマンドを一つ一つ丁寧に紹介します。

これにより、Gitを使った効率的なプロジェクト管理と開発が可能になります。

Gitのブランチ操作をマスターし、プロジェクトの管理がよりスムーズになることを目指しましょう。

git branchコマンド

git branch コマンドは、Gitでブランチを管理するための基本的なコマンドです。

このコマンドを使用することで、新しいブランチの作成、既存のブランチの表示、ブランチの削除、ブランチの名前変更など、さまざまな操作が可能です。

基本的な使用方法を以下に挙げていきます。

新しいブランチの作成

git branch 

コマンドを実行すると、新しいブランチが作成されますが、この時点ではまだ新しいブランチに切り替わっていません。

ブランチはローカル環境ごとに作成できるため、ローカルで作成したブランチは他の環境では使用できません。

ブランチ名は簡潔で説明的にすることが重要で、 スペースや特殊文字の使用を避け、ハイフンやスラッシュを使用するのが一般的です。

ブランチの一覧表示

git branchコマンドを引数なしで実行すると、リポジトリの全てのローカルブランチが一覧表示されます。

# ローカルリポジトリを全て表示させる
git branch

＃ リモートリポジトリも含めて全てのリポジトリを表示させる
git branch -a

現在作業しているブランチには、アスタリスク（*）が付けられます。

リモートリポジトリのブランチを表示させる場合は以下のコマンドを使用します。

git branch -r

リモートリポジトリに存在するブランチは通常、origin/branch-name の形式で表示されます。

ブランチの削除

指定したブランチを削除する場合は以下のコマンドを使用します。

git branch -d 

# 強制的にブランチを削除する

git branch -D 

git branch -dは安全に削除できるブランチのみを削除します。つまりmergeしていない場合などは削除が拒否されます。

git branch -Dは強制的にブランチを削除するため、重要な変更があった場合などは注意して行なってください。

ただし、このコマンドはローカルリポジトリのブランチの削除ですので、リモートブランチにあるブランチを削除しない限り、そのブランチはリモートリポジトリに残ります。

そのため、ブランチを残しておきたい場合などは、リモートブランチを削除せずに残しておくことで、後から必要になったときに再利用することができます。

ブランチ名の修正

ブランチの名前を編集も可能です。以下のコマンドを使用します。

# 現在のブランチ名を修正する場合
git branch -m <新しいブランチ名>

＃ 特定のブランチ名を修正する場合git branch -m <古いブランチ名><新しいブランチ名>

# mはmoveのm

この時、リモートリポジトリにプッシュ済みのブランチ名を変更した場合、リモートでの名前変更も必要です。

git switchコマンド

git switch コマンドは、Gitでブランチを切り替えるためのコマンドです。

これを使用することで、作業中のブランチを変更したり、新しいブランチを作成しながら切り替えたりすることができます。

ブランチの切り替え

既存のブランチに切り替えるには、以下のコマンドを使用します。

git switch 

# mainブランチに切り替え

git switch main

作業中の変更が未コミットの状態でブランチを切り替える場合、変更内容が失われる可能性があります。

変更内容を保存（コミット）してからブランチを切り替えるようにしましょう。

新しいブランチを作成して切り替え

新しいブランチを作成してすぐにそのブランチに切り替えるには、以下のコマンドを使用します。

# 新しいブランチを作成して切り替える
git switch -c 

これにより、新しいブランチが作成され、すぐにそのブランチ上で作業を開始することができます。

新しいブランチを作成して切り替える場合、現在のブランチから新しいブランチが派生します。

git statusコマンド

git status コマンドは、現在のブランチの状態を表示するための基本的なコマンドです。

このコマンドを使用することで、コミットされていない変更や新しく追加されたファイル、削除されたファイルなどを確認できます。

git status

git status コマンドの出力には、以下の情報が含まれます。

• ブランチ情報: 現在作業しているブランチの名前と、リモートブランチとの差異。
• ステージングエリアの変更: ステージングエリアに追加された変更内容。
• 作業ディレクトリの変更: ステージングエリアに追加されていない変更内容。
• 未追跡のファイル: Gitでまだ追跡されていない新しいファイル。

$ git status
On branch feature/new-feature
Your branch is up to date with 'origin/feature/new-feature'.

Changes to be committed:
(use "git restore --staged ..." to unstage)
new file:   example.txt

Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)
modified:   [README.md](http://readme.md/)

Untracked files:
(use "git add ..." to include in what will be committed)
newfile.txt

大人数で一つの物を作成するときはブランチを一つ作ったらpushまで行い、mergeはリモートで行うが、自分一人でブランチを作ることで、様々な修正や試すことが可能である。

また、ブランチはコミットして初めて枝分かれ状態になるため、頻繁にコミットしておかないと、元の状態に戻れなくなるかも。

ブランチをマージする(git merge)

Gitでブランチをマージするには、git mergeコマンドを使用します。マージは、2つの（またはそれ以上の）ブランチの変更を統合するプロセスです。

基本的な使用方法は次のとおりです：

git switch <マージ先のブランチ名>
git merge <マージするブランチ名>

まず、git switch（またはgit checkout）コマンドでマージ先のブランチに切り替えます。次に、git mergeコマンドでマージしたいブランチを指定します。

これにより、指定したブランチの変更が現在のブランチにマージされます。マージによって新たなコミットが作成され、そのコミットは両方のブランチの変更を含みます。

ただし、両方のブランチで同じファイルの同じ部分が変更されている場合、マージコンフリクトが発生する可能性があります。マージコンフリクトが発生した場合、手動で解決する必要があります。

マージコンフリクトを解決した後、またはマージコンフリクトが発生しなかった場合は、git commitコマンドを実行してマージを完了します。

git mergeのオプションについて

git mergeコマンドにはいくつかのオプションがあり、マージの挙動をカスタマイズすることができます。

• -commit、-no-commit：マージを実行し、結果をコミットします。このオプションは-no-commitを上書きするために使用できます。-no-commitを使用すると、マージを実行し、マージコミットを作成する直前で停止します。これにより、ユーザーはマージ結果を検査し、さらに調整する機会が得られます¹²。
• -edit、e、-no-edit：成功したマージのコミット前にエディタを起動し、自動生成されたマージメッセージをさらに編集します。これにより、ユーザーはマージを説明し、正当化することができます。-no-editオプションは、自動生成されたメッセージを受け入れるために使用できます（一般的には推奨されません）¹²。
• -log、-no-log：マージされる実際のコミットから最大の一行説明をログメッセージに追加します。-no-logを使用すると、マージされる実際のコミットの一行説明はリストされません¹²。
• -ff：可能な場合は、マージをファストフォワードとして解決します（マージされたブランチと一致するようにブランチポインタを更新するだけで、マージコミットは作成しません）。不可能な場合（マージされる履歴が現在の履歴の子孫でない場合）、マージコミットを作成します¹²。
• -no-ff：すべてのケースでマージコミットを作成します。つまり、マージがファストフォワードとして解決できる場合でも、マージコミットを作成します¹²。
• S []、-gpg-sign [=]、-no-gpg-sign：結果となるマージコミットにGPG署名を行います¹²。

以上がgit mergeの主要なオプションの一部です。より詳細な情報や他のオプションについては、公式のGitドキュメンテーションを参照してください。

マージには４種類ある

1. Already up-to-date いわゆるローカルとリモートが同じだったので、mergeする必要はありませんでした！という結果
2. Fast Forward ローカルのリポジトリがリモートのリポジトリよりも古い情報になっていた場合の結果 そのままローカルリポジトリが更新される 作業を行う前にpullした場合は多くの場合に発生する
3. Auto merge いわゆる普通のマージで、修正変更などの作業後にコミットした後で、他の人がリモートリポジトリを更新していた場合に発生する この場合はコンフリクトがない場合のみ、ローカルリポジトリが自動的に最新の状態へと更新される。
4. Conflict 両方の環境で同じファイルの同じ箇所を変更した場合に発生。 コンピュータではどちらの情報が正しいのかを判断できないため、必ず人の手によって修正する必要がある

リベースについて

リベースは、ブランチのベースとなる基点（コミット）を別の基点に変更する操作です。

具体的には、あるブランチの変更履歴を他のブランチの上に再適用することで、より整然とした履歴を作成することができます。

リベースを使うことで、複雑なコミット履歴をシンプルで分かりやすいものにすることができます。

これにより、コードの変更履歴が直線的になり、他の開発者が変更を追跡しやすくなります。

また、マージコミットを避けることができ、クリーンな履歴を保つことができます。

例えば以下のようなブランチが形成されている場合を考えてみてください。

A---B---C---D (mainブランチ)
\
E---F---G (featureブランチ)

この場合をリベースすると以下のようにすることができます。

A---B---C---D---E'---F'---G' (featureブランチ)

リベースは、履歴をクリーンで分かりやすく保ち、最新の変更を取り込むために非常に有効なツールです。

リベースのメリット

クリーンな履歴

長期間続くプロジェクトでは、複数の開発者が頻繁にマージを行うことで履歴が非常に複雑になります。

リベースを使用することで、コードの履歴が直線的で読みやすくなるため、後からプロジェクトの変更履歴を確認する際に便利です。

一貫したコードベース

マージコミットが多いと、バグの追跡が難しくなることがあります。

リベースを行うことで、バグ修正がどのブランチから来たのかが明確になり、デバッグが容易になります。

またシンプルな履歴は、コードレビューを行う際にも役立ちます。

変更が明確に示され、不要なマージコミットがないため、レビューが迅速に行えます。

リベースを行うことで、最新のコードベースに基づいて作業を続けることができ、古い変更との衝突を減らせます。

プロジェクトの管理

特に大規模なプロジェクトやチームでは、リベースを使って定期的に最新の変更を統合することで、チーム全体の作業が同期しやすくなります。

これにより、衝突の可能性を減らし、効率的なコラボレーションが可能になります。

コンフリクトが発生した場合、リベース中に解消することで、最終的な統合がスムーズになります。

リポジトリのブランチの履歴を整理する(git rebase)

git rebaseは、Gitリポジトリのブランチの履歴を整理するためのコマンドです。具体的には、一連のコミットを新しいベースに適用し直すことで、ブランチの履歴を直線的に保つことができます。

基本的な使用方法は次のとおりです：

git rebase <ベースとなるブランチ名>

ここで、<ベースとなるブランチ名>は新しいベースとなるブランチの名前を指します。このコマンドを実行すると、現在のブランチの各コミットが、指定したブランチの最新のコミットの上に一つずつ適用されます。

ただし、同じファイルの同じ部分が変更されている場合、リベース中にコンフリクトが発生する可能性があります。コンフリクトが発生した場合、手動で解決する必要があります。

コンフリクトを解決した後、またはコンフリクトが発生しなかった場合は、git rebase --continueコマンドを実行してリベースを続行します。

git rebaseは非常に強力なツールですが、リポジトリの履歴を書き換える可能性があるため、慎重に使用する必要があります。特に、他の人と共有しているブランチに対してgit rebaseを実行すると、混乱を招く可能性があります。

リモートトラッキングブランチについて

ローカルにあるリモートブランチ（リモートトラッキングブランチとも呼ばれます）を削除するには、git branch -r -d <リモート名>/<ブランチ名>コマンドを使用します³。ここで、<リモート名>はリモートリポジトリの名前（通常はorigin）、<ブランチ名>は削除したいブランチの名前を指します。

例えば、originリモートのfeatureブランチを削除するには、次のように実行します：

git branch -r -d origin/feature

ただし、このコマンドはローカルのリモートトラッキングブランチを削除するだけで、リモートリポジトリ自体のブランチは削除されません。リモートリポジトリのブランチを削除するには、git push <リモート名> --delete <ブランチ名>コマンドを使用します⁴。

また、ローカルのリモートトラッキングブランチがリモートリポジトリと同期していない場合（例えば、リモートリポジトリのブランチが削除されているが、ローカルのリモートトラッキングブランチがまだ存在する場合など）、git fetch --prune <リモート名>コマンドを使用すると、存在しないリモートブランチをローカルから削除することができます²。

以上がローカルにあるリモートブランチを削除する基本的な方法です。

リモートトラッキングブランチを削除しても、通常は問題ありません。リモートトラッキングブランチは、ローカルリポジトリにおけるリモートブランチの参照であり、それ自体にはコードや変更履歴は含まれていません。したがって、これらのブランチを削除しても、コードや変更履歴が失われることはありません。

ただし、リモートトラッキングブランチを削除すると、そのブランチの最新の状態を追跡する能力が失われます。そのため、再度そのブランチの状態を追跡したい場合は、git fetchやgit pullを使ってリモートブランチを再度フェッチする必要があります。

また、リモートトラッキングブランチを削除すると、それに関連するローカルブランチのアップストリーム設定も失われます。したがって、ローカルブランチがリモートブランチを追跡するように設定されている場合、その設定も再度行う必要があります。

以上のような点を考慮に入れて、リモートトラッキングブランチの削除を行ってください。

次章：#15 テーブルの作成とテーブル定義、マイグレート に進む