見出し画像

アプリを作ろう──妙高市雪情報グラフ第3回：動作確認準備

堀川圭一

アプリを作ろう──妙高市雪情報グラフ

第3回：動作確認準備


:::message
この連載は、Webアプリ開発初心者が、同じく初心者の方に向けて書いている記事です。
私自身も学びながら進めているので、一緒に「できた！」を積み重ねていけたら嬉しいです。
:::

動作確認の準備として、gitで動作確認用のブランチを作ってから仮想環境の構築までのコマンドを、確認のためにAIに聞いて整理してみました。
いつも使うこのようなコマンドは、スクリプトにしておくと良いですね。
次からそうします。

（※ 実際の動作確認は次回の記事で行います。今回は見慣れないコマンドに出会ったので、準備段階のコマンド解説です。）

cd /Users/apple/GitProjects/PROJECT_DIR
git pull --rebase
git switch -c bugfix/<short-description>
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -U pip setuptools wheel
pip install -r requirements.txt

この中で、今まで使ったことがないものが2つありました。

git pull --rebase
git switch -c bugfix/<short-description>

どちらも「意味は分かりそうで、実はちゃんと説明できない」コマンドでした。
そこで ChatGPT に聞いて整理し、自分用の備忘録としてまとめておきます。

① `git pull --rebase` は何をしているのか？

まず `git pull` の正体

実は `git pull` は、次の2つをまとめて実行しています。

git fetch   （リモートの変更を取得）
git merge   （ローカルブランチに統合）

つまり普通の `git pull` は、

リモートの変更を取ってきて、merge する

という動きになります。

図で見る：`git pull`（merge になる）

ローカルに自分のコミットがあり、リモートにも新しいコミットがあるとき：

(remote)  A---B---C
               \
(local)         D---E

ここで `git pull` をすると、merge commit（M）が作られて履歴が合流します。

       A---B---C
                \
                 M (merge commit)
                /
           D---E

※ 実際の見え方はツールや状況で違いますが、「合流点（merge commit）ができる」のがポイントです。
※ Mは履歴上、CとEの両方を親に持つコミットになります。

`git pull --rebase` の意味

`--rebase` を付けると、merge の代わりに rebase が使われます。

やっていることは、ざっくり言うと

1. リモートの変更を取得（fetch）
2. 自分のコミットを、最新のリモートの上に載せ直す（rebase）

図で見る：`git pull --rebase`（一直線になる）

同じ状態から `git pull --rebase` をすると、

(remote)  A---B---C
               \
(local)         D---E

自分のコミットが「Cの上に載せ直される」形になります。

A---B---C---D'---E'

  • `D'` と `E'` は「載せ直した後のコミット」（見た目上、別コミットになる）

  • ただし結果として 履歴が一直線で読みやすい

どちらを使えばいい？（個人開発の目安）

  • 自分しか触らないブランチ

  • 個人開発・学習用途

なら、`git pull --rebase` はとても相性が良いです。

※ すでに push 済みの共有ブランチを rebase するのは注意が必要（履歴が書き換わるため）。

② `git switch -c bugfix/xxx` は何をしているのか？

git switch -c bugfix/<short-description>

これは一言で言うと、

新しいブランチを作って、そのブランチに切り替える

です。

  • `switch`：ブランチ切り替え専用コマンド

  • `-c`：create（作成して移動）

図で見る：`git switch -c` は「作って移動」

たとえば今 `main` にいる状態で、

* main
  |
  A---B---C   (HEAD)

ここで

git switch -c bugfix/fix-typo

を実行すると、`bugfix/fix-typo` ブランチが作られ、そこへ移動します。

  main
   |
　　A---B---C
   　　　    \
        　　　bugfix/fix-typo  (HEAD)

`git checkout -b` との違い（いつも使っているコマンド）

git checkout -b bugfix/fix-typo

も、やっていることは 同じ です。

git switch -c xxx   （新：ブランチ専用で分かりやすい）
git checkout -b xxx （旧：何でも屋。歴史的に使われてきた）

最近の Git では、役割が分離されました。

  • ブランチ操作 → `git switch`

  • ファイルを元に戻す → `git restore`

③ ブランチ名に `/` が入っているのはなぜ？

bugfix/fix-login-error

一見、ディレクトリのように見えますが、

Git 的には、これは「1つのブランチ名」

です。実際に作業フォルダにディレクトリができるわけではありません。

なぜスラッシュを使うのか？

人間が読みやすくするためです。

  • 一目で「作業の種類」が分かる

  • ブランチ一覧が自然に整理される

  • 自分の中でもルール化しやすい

よくある例：

feature/xxx   新機能
bugfix/xxx    バグ修正
hotfix/xxx    緊急修正
release/xxx   リリース準備

`/` は ディレクトリではなく、名前の区切り として使われています。

まとめ

生成AIに git コマンドを聞くと、
自分がこれまで使ってこなかった「新しい書き方」が出てくることがあります。

今回整理して分かったことは、

  • `git pull --rebase`
    → 履歴をきれいに保ちながら最新を取り込む方法（一直線になりやすい）

  • `git switch -c xxx`
    → ブランチ作成と切り替えを分かりやすく書いた新しい形（`checkout -b` と同じ意味）

  • `bugfix/xxx` の `/`
    → ディレクトリではなく、整理のための区切り

という点でした。

「知らないコマンド＝危ない」ではなく、
意味を整理して納得して使う ことが大事だと感じています。



続く

書いている人について

投稿者の紹介です。
noteでは、次の3つを軸に、日々の学びや記録を残しています。

  • Python・AI
    趣味の開発で試したこと、つまずいた点、学びの記録

  • 健康・からだ
    自分自身の不調や気づきをもとにした、学びと養生の記録

  • 生まれ故郷への想い
    新潟・妙高（小局）にまつわる歴史や記憶を残すための記録

👉 マイペースで続けている記録はこちら

👉アプリ開発に関するマガジン



いいなと思ったら応援しよう！