Git ブランチ

GitHub Desktop で Main ブランチから V1（開発用ブランチ）を作り、開発が終わったら Main に取り込む（マージ）するという標準的なワークフローは問題なくできます。以下に、実際の手順（画面操作）と注意点を分かりやすくまとめます。私は手を動かして実行する代わりに、やり方を段階的に案内します。

やることの概略（ストーリー）

  • Main から新しいブランチ V1 を作る
  • V1 上で変更をコミットしてリモートに公開（Publish）
  • 必要に応じてリモートの Main の最新を取り込む（同期）
  • 開発完了後、V1 を Main に取り込む（マージ） — GitHub Desktop でローカルマージするか、GitHub.com で Pull Request を作る
  • マージ後、Main をリモートに push してブランチを整理

具体的な手順（GitHub Desktop）

  1. Main から V1 ブランチを作る
  • GitHub Desktop を開く。画面左上の Current branch（現在のブランチ）ドロップダウンを開く。
  • 「New branch」または「Create new branch」を選び、Name に V1（例: v1）を入力して作成。
  • これでローカルに v1 ブランチが作成され、そのブランチに切り替わります。
  1. 開発（変更を行いコミット）
  • コードを編集 → GitHub Desktop に戻り変更内容を確認。
  • 変更に説明的なコミットメッセージを書いて Commit to v1 を実行。
  • 作業を続ける場合は必要に応じてコミットを重ねます。
  1. ブランチをリモートに公開（push）
  • 画面上に「Publish branch」ボタンが出ているのでクリックしてリモート（origin）にブランチを作成・push。
  1. （任意だが推奨）Main の最新を取り込む（ブランチを最新化）
  • 他の人が Main を更新している可能性があるので、定期的に v1 に Main の変更を取り込むのが安全です。
    • GitHub Desktop で v1 にいる状態で、Repository メニュー → Fetch origin（または Pull origin）を行い、次に Branch → Merge into current branch… を選び、マージ元として main を選択して v1 に取り込みます。
    • コンフリクトが出たら GitHub Desktop が知らせてくれるので、指示に従って手動で解決してコミットします。
  1. 開発完了 → Main に取り込む（2つの方法） A. GitHub.com で Pull Request を作る（推奨、レビューが必要な場合）
  • GitHub Desktop の上部に「Create Pull Request」ボタンが表示されるので押すとブラウザで PR 作成ページが開きます。
  • PR 上でレビュー・CI 実行・マージを経て、マージボタン（Merge）で main に統合します。
  • マージ後、ローカルの main を GitHub Desktop で Fetch/Pull して最新にします。

B. ローカルでマージしてから push する（小規模・単独作業向け）

  • GitHub Desktop で main に切り替える（Current branch → main）。
  • Branch メニュー → Merge into current branch… を選択し、マージ元として v1 を選ぶ。
  • コンフリクトがなければマージコミットが作成されるので、Push origin でリモート main に反映します。
  • コンフリクトがあれば指示に従って解決してコミット → push。
  1. マージ後の後片付け
  • リモートにマージ済みなら、使い終わったブランチ v1 は削除しても良いです（GitHub Desktop の Branch メニュー → Delete を選択、あるいは GitHub.com の PR 画面で Delete branch）。
  • main を pull（Fetch/Pull origin）してローカルを最新に保ちます。

よくある注意点・ベストプラクティス

  • 「pull」という言葉は文脈で意味が変わります。一般に「pull」はリモートから自分のローカルブランチへ最新を取り込む操作（fetch + merge）を指します。あなたが言っている「V1 → Main に pull する」は通常「V1 を Main にマージする（merge）」または「Pull Request で Main に統合する」という意味です。
  • 共同開発では Pull Request を使ってレビュー・CI を回し、問題なければ GitHub のマージ機能で統合するのが安全です。
  • マージ前に main を最新にしておく（v1 に main を取り込む）ことでコンフリクトの解決を早めに行えます。
  • 取り返しのつかない操作を避けたい場合は、merge（または squash とか rebase）戦略をチームで決めておいてください。

Git コマンド（CLI）での手順

以下は「Main（main）ブランチから開発用ブランチ V1（v1）を作り、開発後に main に取り込む（マージ）する」一般的な CLI（git）手順です。状況に応じて「PRでマージする方法」と「ローカルでマージする方法（単独開発向け）」の両方を載せます。各ステップの説明とよく使うコマンドも併記します。

前提：リモート名は origin、メインブランチ名は main とします。リポジトリはすでにクローン済みとします。

  1. main を最新にする（出発点）
git checkout main
git fetch origin
git pull origin main
  • git fetch でリモート情報を取得してから pull（fetch + merge）する習慣が安全です。
  1. main から v1 ブランチを作成して切り替える
git checkout -b v1
  • これでローカルに v1 が作成されます。
  1. 作業 → ステージ → コミット
# ファイル編集したら
git add <ファイル>   # または git add .
git commit -m "実装: 機能X を追加"
  1. リモートに公開（初回 push）
git push -u origin v1
  • -u は upstream を設定するので次回は git push だけで良くなります。
  1. 開発途中で main の最新を取り込む（競合回避のため推奨） 方法A）マージして取り込む（より安全、履歴がそのまま）
git checkout v1
git fetch origin
git merge origin/main
# コンフリクトが出たら解消 -> git add <解決したファイル> -> git commit
git push

方法B）リベースして取り込む（履歴を直線化したい場合）

git checkout v1
git fetch origin
git rebase origin/main
# コンフリクトが出たら解消 -> git add <解決したファイル> -> git rebase --continue
# リベース後は強制プッシュ（他人が同じブランチを使っていないことを確認）
git push --force-with-lease
  • チームでの明確な方針がない場合、rebase の強制プッシュは注意が必要です。
  1. 開発完了 → main に取り込む（方法は2つ）

A. GitHub 上で Pull Request を作ってマージする（推奨）

  • 手順（CLI側）：
    1. v1 を push（済みであれば不要） 
      git push origin v1
    2. ブラウザで GitHub のリポジトリを開き、v1 → main の Pull Request を作成してレビュー/CI/マージを行う。
    3. GitHub でマージしたらローカル main を更新： 
      git checkout main
git fetch origin
git pull origin main
    4. 使い終わったブランチを削除（ローカル・リモート）： 
      git branch -d v1                 # マージ済みなら削除
git push origin --delete v1      # リモート削除

B. ローカルで main に切り替えてマージする（単独作業向け）

git checkout main
git fetch origin
git pull origin main

# main に v1 をマージ
git merge --no-ff v1
# コンフリクトが出たら編集 -> git add <解決ファイル> -> git commit

# リモート main に反映
git push origin main

# ブランチの後片付け
git branch -d v1
git push origin --delete v1
  • –no-ff を付けるとマージコミットが必ず残るので履歴が分かりやすくなります。好みに応じて省略可。
  1. コンフリクト発生時の基本操作
  • マージまたはリベースでコンフリクトが出たら、該当ファイルを編集しマーカー（««< 等）を消して修正後：
git add <解決したファイル>
# マージの場合
git commit   # 自動でマージコミットメッセージが入る
# リベースの場合
git rebase --continue
  1. よく使う確認コマンド
git status                 # 現在の状態
git branch -a              # ローカル・リモートのブランチ一覧
git log --oneline --graph  # 履歴の概要
git remote -v              # リモート確認

付録：用語の整理（短く）

  • pull: リモートから取得してローカルブランチに反映（fetch + merge）。fetch と merge を分けて使うと安全。
  • merge: 2つのブランチの変更を統合。マージコミットができる。
  • rebase: ベースを付け替えて履歴を直線化。共有ブランチでの強制プッシュは注意。

おすすめワークフロー

  • チーム開発なら PR を作ってレビュー→マージする流れを推奨。
  • 定期的に main の最新を v1 に取り込んで早めにコンフリクトを潰す。
  • 履歴ポリシー（merge commit を残すか squash するか、rebase を使うか）はチームで決めておく。

必要なら、あなたの現在のブランチ状態（git status や git branch -a の出力）を貼ってください。具体的にコマンドを教えながら一緒に操作を進めます。どちらのマージ方法（PRベース／ローカルマージ）を使いたいですか？

PRベース（GitHubでレビューしてマージ）とローカルマージ（手元で main に直接マージ）の両方について、実際に使うコマンドと注意点を分かりやすく示します。まずやることをざっと示してから、手順とよく使うオプションを示します。

PRベース（推奨：レビュー／CI を通すワークフロー）

  1. v1 ブランチをリモートに push
git checkout v1
git push -u origin v1
  1. Pull Request を作る
  • ブラウザでリポジトリを開き、Compare & pull request（v1 → main）を作成して説明・レビュワーを設定、CI を待つ。
  • または GitHub CLI を使う場合:
gh pr create --base main --head v1 --title "タイトル" --body "説明"
  1. レビュー・CI を行い、問題なければマージ
  • GitHub の UI で選べるマージ方法：
    • Create a merge commit（通常のマージコミット） ← 履歴をそのまま保持
    • Squash and merge（コミットを1つにまとめる） ← 履歴を綺麗にしたいとき
    • Rebase and merge（リベースしてコミットを主ブランチに適用） ← 直線的な履歴
  • gh CLI でマージ（通常のマージの例）:
gh pr merge <PR番号またはブランチ名> --merge
# squash:
gh pr merge <pr> --squash
# rebase:
gh pr merge <pr> --rebase
  1. ローカル main を更新
git checkout main
git fetch origin
git pull origin main

（または git pull だけでも可。fetch+pull を分けると安全）

  1. ブランチの後片付け
  • ローカル削除（マージ済みなら安全）
git branch -d v1
  • リモート削除
git push origin --delete v1

ローカルマージ（単独開発や簡単なケース向け）

  1. main を最新にしてチェックアウト
git fetch origin
git checkout main
git pull origin main
  1. main に v1 をマージ
  • 通常（自動で fast-forward する場合もある）:
git merge v1
  • マージコミットを必ず残したい（履歴を明確にする）:
git merge --no-ff v1
  1. コンフリクトが出たら
  • コンフリクト発生時の基本:
    • 影響ファイルを編集してコンフリクトマーカー（«««<）を消す
    • 解決したファイルをステージしてコミット
git status            # コンフリクトファイル確認
# ファイルを編集して解消したら
git add <file>
git commit            # マージコミットを作成
  • マージを中止したい場合:
git merge --abort
  1. リモート main に push
git push origin main
  1. ブランチの後片付け（同様）
git branch -d v1
git push origin --delete v1

よく使うオプションと注意点

  • fast-forward とマージコミット
    • fast-forward されるとマージコミットが作られない。履歴を残したければ –no-ff を使う。
  • squash マージ
    • コミット履歴を 1 件にまとめたいときに有効（PR でよく使う）。
  • rebase
    • v1 を main の最新に合わせたいときは v1 側で git rebase origin/main。ただし共有ブランチで rebase -> 強制 push は注意（他人が同ブランチを使っていると混乱する）。
  • リベース中の操作
    • コンフリクト解消 -> git add -> git rebase --continue
    • 中止: git rebase --abort
  • 安全な強制プッシュ
git push --force-with-lease
  • 他人の更新を上書きしないようにするために –force-with-lease を使う。

チェックと確認コマンド

git status
git branch -vv        # upstream と最後のコミットを確認
git log --oneline --graph --all
git remote -v

使い分けの目安

  • チーム／レビューが必要：PR ベース（GitHub 上でレビュー・CI を回す）
  • 単独で短い修正：ローカルマージでもよい（ただし main を破壊しないよう注意）
  • マージ前にコンフリクトを早めに解消したい：開発中に main の変更を v1 にマージ（またはリベース）しておく