基礎から学ぶPython入門 90日コース | 実践開発 － Day 78：ブランチ

Python 90日で身につけるPython
スポンサーリンク
スポンサーリンク
  1. Day 78：ブランチ ― 「並行して開発しても、ちゃんと元に戻れる」
  2. ブランチとは ― 「時間軸を分岐させる、もうひとつの道」
    1. ブランチのざっくりイメージ
    2. なぜブランチが必要なのか
  3. branch の基本操作 ― 「横道を作って、そこに移動する」
    1. 例：Day 77のGitHub練習リポジトリを使う
    2. 現在のブランチを確認する ― git branch
    3. 新しいブランチを作る ― git branch feature-message
    4. ブランチを切り替える ― git checkout feature-message
  4. ブランチ上で変更してみる ― 「横道で自由に遊ぶ」
    1. feature-message ブランチで main.py を編集する
    2. ブランチ上でコミットする
    3. master ブランチに戻ってみる
  5. merge ― 「横道で育てた変更を、メインの道に合流させる」
    1. merge のイメージ
    2. master に feature-message を取り込む ― git merge feature-message
  6. 開発フロー ― 「ブランチをどう使うか」の基本パターン
    1. シンプルなブランチ開発フロー
    2. チーム開発でのブランチ運用（ざっくり）
  7. Day 78ミニテンプレート ― ブランチ＆マージ練習セット
    1. 1. プロジェクトを作って、最初のコミット
    2. 2. 機能ブランチを作って移動する
    3. 3. 機能ブランチで変更してコミット
    4. 4. master に戻って、違いを確認する
    5. 5. merge で master に変更を取り込む
  8. Day 78のまとめ ― 「ブランチは、“壊してもいい場所”をくれる」

Day 78：ブランチ ― 「並行して開発しても、ちゃんと元に戻れる」

Day 78では、Git・GitHubの世界でとても重要な概念、

  • branch（ブランチ）
  • merge（マージ）
  • 開発フロー

を扱っていきます。

ここまでで、Gitの基本（init / status / add / commit）と、 GitHubへの push / pull を体験してきました。

今日はそこに 「ブランチ」というもう一本の軸 が加わります。 これを理解すると、

「新しい機能を試しながら、今動いているコードを壊さない」

という、プロっぽい開発の感覚がぐっと近づいてきます。

ブランチとは ― 「時間軸を分岐させる、もうひとつの道」

ブランチのざっくりイメージ

Gitのブランチ（branch）は、一言で言うと、

「履歴の流れを分岐させるための“別ルート”」

です。

もう少しイメージを膨らませると、

  • メインのコード（main や master）は「安定した道」
  • 新機能を試すときに「横道」を作る
  • 横道でいろいろ試して、うまくいったらメインの道に合流させる

という感じです。

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

ブランチがない世界を想像してみると、こんなことが起きます。

  • メインのコードに直接新機能を書き始める
  • 途中でバグが出て、メインが壊れる
  • 「前の状態に戻したいけど、どこまで戻せばいいか分からない」

これでは、安心して実験ができません。

ブランチを使うと、

  • メインは「常に動く状態」を保つ
  • 新機能は別ブランチで自由に試す
  • うまくいったらメインに取り込む（merge）

という、安全な遊び場 を手に入れられます。

branch の基本操作 ― 「横道を作って、そこに移動する」

例：Day 77のGitHub練習リポジトリを使う

前の日に作った day77_github_basic を、 ブランチ練習の舞台にしてみましょう。

フォルダ構成はこんな感じだとします。

bash

day78_branch_flow/
└── main.py

main.py はシンプルにこんな内容。

# main.py
def main():
    print("Hello Branch!")
    print("Day 78: ブランチの練習中")


if __name__ == "__main__":
    main()
Python

このフォルダでGitを初期化し、コミットしておきます。

bash

cd day78_branch_flow
git init
git add main.py
git commit -m "Add main.py for branch practice"

現在のブランチを確認する ― git branch

まずは、今どのブランチにいるかを確認します。

bash

git branch

出力はこんな感じになるはずです。

* master

* が付いている行が「今いるブランチ」です。 ここでは master が現在地ですね（環境によっては main の場合もあります）。

新しいブランチを作る ― git branch feature-message

新機能用のブランチを作ってみましょう。 例えば、「メッセージを増やす機能」を試すブランチを作るとして、

bash

git branch feature-message

これで、新しいブランチ feature-message が作られます。

もう一度 git branch を見てみます。

bash

git branch

* master
  feature-message
  • master：今いるブランチ
  • feature-message：新しく作ったブランチ

という状態です。

ブランチを切り替える ― git checkout feature-message

新しいブランチに「移動」してみましょう。

bash

git checkout feature-message

出力はこんな感じ。

Switched to branch 'feature-message'

そして、再び git branch。

bash

git branch

  master
* feature-message

今度は feature-message に * が付いています。 つまり、

「今は feature-message ブランチの世界で作業している」

という状態です。

ブランチ上で変更してみる ― 「横道で自由に遊ぶ」

feature-message ブランチで main.py を編集する

feature-message ブランチにいる状態で、main.py を編集してみます。

# main.py
def main():
    print("Hello Branch!")
    print("Day 78: ブランチの練習中")
    print("このメッセージは feature-message ブランチで追加されました")


if __name__ == "__main__":
    main()
Python

編集したら、いつものように git status を見てみましょう。

bash

git status

On branch feature-message
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
        modified:   main.py

ここでのポイントは、

  • ブランチ名が feature-message になっている
  • main.py が編集されたことが分かる

というところです。

ブランチ上でコミットする

編集した内容をコミットします。

bash

git add main.py
git commit -m "Add extra message in feature-message branch"

これで、

  • feature-message ブランチには「メッセージが増えた状態」がコミットされている
  • master ブランチには「まだメッセージが増えていない状態」が残っている

という、履歴の分岐 が生まれました。

master ブランチに戻ってみる

ブランチの違いを体感するために、 master に戻ってみましょう。

bash

git checkout master

そして、main.py を開いてみます。

# main.py
def main():
    print("Hello Branch!")
    print("Day 78: ブランチの練習中")


if __name__ == "__main__":
    main()
Python

feature-message で追加した行が、ここにはありません。

つまり、

「ブランチごとに、ファイルの中身が違う」

ということが、目で見て分かります。

merge ― 「横道で育てた変更を、メインの道に合流させる」

merge のイメージ

merge は、一言で言うと、

「あるブランチの変更を、別のブランチに取り込む」

操作です。

今回の例で言えば、

  • feature-message ブランチでメッセージを増やした
  • それを master ブランチにも反映させたい

というときに、merge を使います。

master に feature-message を取り込む ― git merge feature-message

今、master ブランチにいる状態で、 次のコマンドを実行します。

bash

git merge feature-message

うまくいけば、こんな出力になります。

Updating 1234567..89abcde
Fast-forward
 main.py | 1 +
 1 file changed, 1 insertion(+)

ここで起きたことは、

  • feature-message ブランチの変更が、master に取り込まれた
  • main.py に追加された行が、master 側にも反映された

ということです。

main.py を開いてみると、こうなっているはずです。

# main.py
def main():
    print("Hello Branch!")
    print("Day 78: ブランチの練習中")
    print("このメッセージは feature-message ブランチで追加されました")


if __name__ == "__main__":
    main()
Python

重要ポイント：

  • merge は「ブランチ間の変更を合流させる」操作
  • 今回は「masterに、feature-messageの変更を取り込む」方向で行った

開発フロー ― 「ブランチをどう使うか」の基本パターン

シンプルなブランチ開発フロー

ブランチを使った開発フローの、 いちばんシンプルな形はこんな感じです。

  1. メインブランチ（main/master）
    • 常に「動く状態」を保つ
    • リリースやデプロイの元になる
  2. 機能ブランチ（feature branch）
    • 新機能や修正ごとに作る
    • 例：feature-login、feature-todo-api など
  3. 開発の流れ
    • メインから機能ブランチを切る
    • 機能ブランチで開発・コミットを重ねる
    • 完成したらメインにmergeする

図にすると、こんなイメージです。

main:    o----o----o-----------------o------o
               \                     /
feature:        o----o----o----o----o
  • 上の線：メインブランチ
  • 下の線：機能ブランチ
  • 分岐して、合流する

という流れですね。

チーム開発でのブランチ運用（ざっくり）

チーム開発では、もう少しルールが増えます。

  • main：本番用
  • develop：開発用
  • feature/*：機能ごとのブランチ
  • hotfix/*：緊急修正用ブランチ

など、いろいろなパターンがありますが、 Day 78では、

「メイン＋機能ブランチ＋merge」

という 最小セット をしっかり理解しておくことが大事です。

Day 78ミニテンプレート ― ブランチ＆マージ練習セット

最後に、今日の内容をひとまとめにした 「ブランチ＆マージ練習テンプレート」 を載せておきます。

1. プロジェクトを作って、最初のコミット

bash

mkdir day78_branch_flow
cd day78_branch_flow

bash

cat << 'EOF' > main.py
def main():
    print("Hello Branch!")
    print("Day 78: ブランチの練習中")


if __name__ == "__main__":
    main()
EOF

bash

git init
git add main.py
git commit -m "Add main.py for branch practice"
git branch   # master（または main）が表示される

2. 機能ブランチを作って移動する

bash

git branch feature-message
git branch   # master と feature-message が表示される
git checkout feature-message
git branch   # * feature-message が現在地

3. 機能ブランチで変更してコミット

bash

cat << 'EOF' > main.py
def main():
    print("Hello Branch!")
    print("Day 78: ブランチの練習中")
    print("このメッセージは feature-message ブランチで追加されました")


if __name__ == "__main__":
    main()
EOF

bash

git status          # On branch feature-message / modified: main.py
git add main.py
git commit -m "Add extra message in feature-message branch"

4. master に戻って、違いを確認する

bash

git checkout master
cat main.py         # まだ追加メッセージはない

5. merge で master に変更を取り込む

bash

git merge feature-message
cat main.py         # 追加メッセージが反映されている
git branch          # master にいる状態

この一連の流れを体験すると、

「ブランチは、安心して試せる“横道”なんだ」

という感覚が、じわっと染み込んできます。

Day 78のまとめ ― 「ブランチは、“壊してもいい場所”をくれる」

今日の主役は、

  • branch：履歴の流れを分岐させる「別ルート」
  • merge：別ルートで育てた変更を、メインに合流させる操作
  • 開発フロー：メイン＋機能ブランチ＋merge という基本パターン

でした。

ブランチを使い始めると、

  • 「メインを壊さずに、新しいことを試せる」
  • 「機能ごとに履歴を分けて考えられる」
  • 「チームでの変更が整理されて見える」

という、開発の安心感がぐっと増していきます。

そして何より、ブランチは、

「壊してもいい場所」をくれる仕組み

でもあります。

  • 失敗しても、メインは無傷
  • うまくいったら、堂々とメインに取り込める
  • 「試してみようかな」が、少し軽くなる

Day 78でその感覚をつかんだことで、 これからの実践開発は、 もっと自由に、もっと安全に、 コードの世界を探検できるようになっていきます。

スポンサーリンク
タイトルとURLをコピーしました