前回の記事では git add と git commit を解説しました。

Gitでは次の流れで履歴を管理します。

編集
↓
git add
↓
git commit

これで履歴を保存できます。

しかし実際の開発では次のような問題が起きます。

新しい機能を作りたい
でも今のコードは壊したくない

この問題を解決するのが

ブランチ（branch）

です。

この記事では次の内容を解説します。

Gitブランチとは
なぜブランチが必要なのか
ブランチの基本コマンド
実務でのブランチ戦略

ブランチとは

開発を分岐させる仕組み

です。

Gitでは1つのプロジェクトに対して

複数の開発ライン

を作ることができます。

例

main
login-feature
payment-feature

それぞれが独立した開発ラインです。

なぜブランチが必要なのか

ブランチがない場合を考えてみましょう。

開発者A

ログイン機能開発

開発者B

決済機能開発

同じコードを直接編集すると

バグ
コンフリクト

が発生しやすくなります。

ブランチを使うと

main
 ├ login-feature
 └ payment-feature

のように分けて開発できます。

デフォルトブランチ

Gitには最初から

main

というブランチがあります。

これが

本番コード

になります。

通常の開発では

main

を直接編集することはありません。

新しいブランチを作る

ブランチを作るコマンド

git branch

例

git branch login-feature

これで

login-feature

ブランチが作成されます。

ブランチ一覧

git branch

例

main
login-feature

現在のブランチには

が表示されます。

例

* main
login-feature

ブランチを切り替える

ブランチを切り替えるコマンド

git checkout login-feature

最近は次のコマンドも使われます。

git switch login-feature

ブランチ作成 + 切り替え

次のコマンドを使うと

作成
切り替え

を同時にできます。

git checkout -b login-feature

または

git switch -c login-feature

ブランチのイメージ

main
 ├ commit1
 ├ commit2
 └ commit3

新しいブランチ

main
 ├ commit1
 ├ commit2
 └ commit3
       \
        login-feature

つまり

履歴を分岐

しています。

ブランチでの開発

一般的な流れ

main
↓
featureブランチ作成
↓
機能開発
↓
mainに統合

例

main
 └ login-feature

実務でのブランチ名

実務では次のような名前を使います。

例

feature-login
feature-payment
fix-header

ルール例

feature-
fix-
hotfix-

ブランチのメリット

ブランチを使うメリット

安全な開発

mainを壊さない

並行開発

複数人で同時に開発できる

実験

新しいコードを試せる

GitHubでのブランチ

GitHubではブランチは次のように使います。

main
↓
feature branch
↓
Pull Request
↓
merge

この流れが

GitHub Flow

です。

ブランチ削除

不要になったブランチは削除できます。

git branch -d login-feature

よくあるミス

初心者がよくやるミス

mainで作業

直接

main

を編集してしまう。

ブランチ名が分かりにくい

例

test
update
fix2

まとめ

この記事では Gitのブランチ を解説しました。

重要なポイント

ブランチ = 開発の分岐
mainは本番コード
featureブランチで開発

ブランチを使うことで

安全な開発

ができます。

次回は

git checkout / git switch

を解説します。

ここでは

ブランチ切り替え

を詳しく説明します。

Gitのブランチとは？安全に開発するための基本機能 – 5/12