23
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめての Git 実務ガイド:ブランチ運用からトラブル対処まで

23
Posted at

Git を使い始めると、ブランチの使い分けや pull / rebase の違いなど、最初に戸惑うポイントがいくつかあります。
特に実務では、操作の意図や使いどころが分からず手が止まってしまうことも少なくありません。

この記事では、現場でよく使われるブランチ運用と基本的な作業フローを整理し、
最後に 初心者がつまずきやすいトラブルとその対処法 をまとめています。
日々の開発で迷わないための “最初のガイド” として活用してください。


1. Git のブランチ運用を理解する(main / develop / feature)

まずは、実務でよく使われるブランチ構成を押さえておきましょう。

  • main:リリースされる安定版コード
  • develop:開発中のコードを集約するブランチ
  • feature/:機能追加や修正ごとの作業用ブランチ
main ────────────────●───────────────●─────────── →
                       ↑ リリース

develop ────────●─────┴──────●─────────────── →
                  ↑ feature ブランチから merge

feature/xxx ────●───────●──────── →

基本の流れは次の 3 ステップです。

  1. feature ブランチで作業
  2. develop に取り込む
  3. まとまったら develop → main へ反映

実務ではこの流れが “型” として定着しているため、まずはこの形を覚えておくと迷いにくくなります。


2. 実務で使う Git 操作の基本フロー

実務では、新しい作業は develop ブランチを起点に進めるのが一般的です。
まずは develop を最新の状態にしてから作業を始めます。

0. develop ブランチに切り替えて最新化する
1. 作業用ブランチ(feature/xxx)を作る
2. コードを編集する
3. コミットする
4. 最新の develop を取り込む(rebase)
5. push する
6. 必要に応じて PR を作成しレビューを依頼する

🔍 ちょっと補足:なぜ develop → feature/xxx なの?

開発中のコードは基本的に develop に集まっていきます。
そのため、新しい作業は develop をベースに切り出すのが自然です。

develop → feature/awesome-feature

「まず develop を最新にしてから作業を始める」という流れだけ覚えておけば大丈夫です。


2.1 作業用ブランチを作成する

まずは develop を最新化してから、feature ブランチを作ります。

git switch develop
git pull
git switch -c feature/awesome-feature
  • switch develop:develop に移動
  • pull:最新の状態を取得
  • switch -c:新しいブランチを作成して切り替え

🔍 補足:checkout なら develop に切り替えずに作成もできる

git checkout -b feature/awesome-feature origin/develop
  • origin/develop を指定すると、develop に切り替えなくても作成できる
  • ただし checkout は用途が広く初心者には分かりにくいため、
    switch を使う方が安全で理解しやすい

2.2 編集 → コミット

コードを編集したら、変更をステージングしてコミットします。

git add .
  • add . はカレントディレクトリ以下の変更をすべて追加
  • 個別に追加したい場合は git add <ファイル名>
git commit -m "Add awesome feature"
  • -m はコミットメッセージをその場で指定
  • 「何をしたか」が分かるメッセージにすると後で楽

2.3 最新の develop を取り込む(rebase)

作業中に develop が進んでいることはよくあります。
作業をまとめる前に、最新の状態を取り込みましょう。

方法①:fetch → rebase(最も安全)

git fetch origin
git rebase origin/develop

origin/develop は “最後に fetch/pull した時点のリモートの状態をローカルに保存した参照” です。
fetch を挟まないと古い状態に rebase してしまう可能性があります。

方法②:pull --rebase(fetch + rebase を一括で実行)

git pull --rebase origin develop

内部的には次の 2 ステップを行っています。

1. git fetch origin develop
2. git rebase origin/develop

fetch が自動で走るため、別途 fetch を実行する必要はありません。
実務でもよく使われる安全な方法です。


2.4 push

作業内容をリモートに送ります。

git push -u origin feature/awesome-feature
  • -u は「次回以降の push/pull のデフォルト先として覚える」
  • 初回 push のときだけ付ければ OK

2.5 必要に応じて PR 作成

push 後は、チーム開発では PR(Pull Request)を作成してレビューを依頼します。

※PR は Git の機能ではありませんが、
「push → レビュー → develop に取り込む」 という実務フローの一部として一般的です。


3. pull(merge)と rebase の違いを理解する

3.1 前提:リモートとローカルが分岐している状態

Git を使っていると、作業している間にリモート側に新しいコミットが追加されることがあります。

リモート:  A ── B ── C   ← 他の人の作業
ローカル:  A ── B ── X   ← 自分の作業

この「分岐」をどう解消するかが、pull(merge)と rebase の違いです。


3.2 pull(merge)の動き

pull を実行すると、Git は両方の履歴をそのまま残したまま合流させます。
その結果、merge commit(M) が 1 つ作られます。

A ── B ── C
       \      \
        X ---- M

複数人が同時に作業する develop ブランチでは自然な形ですが、
feature ブランチではノイズに感じることもあります。


3.3 rebase の動き

rebase は、あなたの作業(X)を リモートの最新コミット(C)の上に付け替える 操作です。

A ── B ── C ── X'

履歴がまっすぐに整うため、feature ブランチでよく使われます。


3.4 pull(merge)と rebase の違いをまとめてイメージする

【pull(merge)】
A ── B ── C
       \      \
        X ---- M

【rebase】
A ── B ── C ── X'
  • pull(merge):枝分かれしたまま合流
  • rebase:枝分かれを解消してまっすぐに並べ直す

3.5 どちらを使うべきか

ブランチの役割によって使い分けるのが一般的です。

  • feature ブランチ(自分の作業用)
    → 履歴をきれいに保つため rebase がよく使われる

  • develop ブランチ(複数人の作業を集約する場所)
    → 履歴を書き換えないように pull(merge)が一般的


4. よくあるトラブルと対処法

初心者がつまずきやすいポイントを中心に

Git は便利ですが、慣れるまでは「どう直せばいいの?」と迷う場面が必ずあります。
ここでは、実務で特に遭遇しやすいトラブルと、その対処方法をまとめました。


4.1 コミットを間違えた(push 前)

git commit --amend
git rebase -i HEAD~3

push 前であれば、履歴を書き換えても問題ありません。

  • --amend:直前のコミットを上書き
  • rebase -i:複数コミットをまとめたり整理できる

「まだ誰にも共有していない履歴は自由に整えて OK」という考え方を覚えておくと安心です。


4.2 コミットを間違えた(push 後)

git revert <commit>

push 後は履歴を書き換えると他の人に影響が出るため、revert が基本 です。

  • 指定したコミットを「打ち消す」新しいコミットを作る
  • 履歴を壊さず安全に取り消せる

4.3 rebase でコンフリクトしたとき

git add <修正したファイル>
git rebase --continue

やり直したい場合:

git rebase --abort
  • 修正 → add--continue で続行
  • どうにもならない場合は --abort で元に戻れる

「rebase は途中で止まっても戻せる」と知っておくと、怖さがぐっと減ります。


4.4 コミット履歴をまとめて整理したいとき(push 前)

作業途中のコミット(WIP)や細かい修正が増えて履歴が見づらい場合、
PR 前に squash(複数コミットを 1 つにまとめる) で整理できます。

git rebase -i HEAD~5

rebase -i で、まとめたいコミットを squash に変更すると、
WIP や細かい修正を 1 つのコミットにまとめられます。

※push 前のブランチでのみ安全に使える操作です。


5. まとめ

この記事では、Git 初心者がつまずきやすいポイントを中心に、

  • ブランチ運用の基本
  • 実務で使う Git 操作の流れ
  • pull(merge)と rebase の違い
  • よくあるトラブルと対処法

を紹介しました。

Git は慣れるまで少し時間がかかりますが、
流れを理解してしまえばとても強力なツールになります。

日々の開発で少しずつ使いながら、ぜひ慣れていってください。


23
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
23
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?