Git を初めて触る人にとって「この辺で困る」と思うポイントが多いものです。
この記事では、基本操作から実際の開発フロー、よくあるトラブルへの対処法までを、わかりやすく段階的にまとめました。
「Git って何？」「どうやってコミットしたらいい？」といった疑問に答えると同時に、実際に手を動かしやすいサンプル例も紹介しますので、読後は「今すぐ実践したい！」と思えるはずです。
Gitとは何か？
Git は分散型バージョン管理システム（DVCS）であり、ソフトウェア開発（ひとえにコード変更）の履歴を管理し、複数人が同時に作業できるように設計されています。
以下が Git の特徴です。
-
ローカルに完全な履歴が存在
すべてのコミット、ブランチ、タグがローカルに保存されるため、ネットワークに接続していない状態でも全ての操作が可能です。 -
変更点の差分で追跡
ファイル全体ではなく差分が管理されるため、効率的にデータを扱えます。 -
高いデータ整合性
SHA‑1 ハッシュでファイルとコミットを管理し、不正な変更検知が簡単です。 -
ブランチが軽量
ブランチ（名前付きポインタ）は数バイトのハッシュ参照にすぎず、切り替えも高速です。
1. Gitを始める前に
1.1 インストール
-
Windows
・Scoop でscoop install git
・Chocolatey でchoco install git
・公式インストーラ（Git for Windows） -
macOS
・Homebrew でbrew install git
・Xcode コマンドラインツールをxcode-select --install -
Linux
sudo apt-get update && sudo apt-get install git # Debian/Ubuntu sudo dnf install git # Fedora sudo pacman -S git # Arch
1.2 初期設定
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global core.editor "code --wait" # VS Code をエディタに設定
git config --global alias.co checkout # コマンド短縮
git config --global alias.ci commit
git config --global alias.br branch
※--global は全てのリポジトリで共通設定。個別リポジトリでは git config --local ... で書き換えられます。
2. ローカルリポジトリの作り方
mkdir myproject && cd myproject
git init # リポジトリ作成
2.1 .gitignore の作成
ビルド成果物や IDE が生成するファイルを追跡対象外にしましょう。
例：
node_modules/
dist/
.DS_Store
2.2 初めてのコミット
echo "# My Project" > README.md
git add README.md
git commit -m "Initial commit"
git status で現在の状態を確認できます。
3. ステージングとコミット
ステージングエリア
git add fileで変更をインデックスに追加git reset fileでインデックスから除外
コミット
git commit -m "メッセージ"
変更を履歴に残す。
コミットメッセージの書き方（ココナラ式）
- 簡潔に要約（50文字以内）
Add feature X - 詳しい説明（必要に応じて複数行）
Refactor authentication module. This addresses the login bug reported in issue #123. - 変更箇所（バグID、チケット番号）は必ず入れると追跡に便利。
4. ブランチ操作の基礎
4.1 ブランチ作成と切り替え
git branch dev # ブランチ作成
git checkout dev # ブランチ切替
# あるいは
git checkout -b dev # 一度に作成・切替
4.2 ブランチの一覧
git branch # ローカル
git branch -a # ローカル＋リモート
4.3 ブランチのマージ
git checkout main
git merge dev --no-ff # マージコミットを残す
--no-ff はブランチが fast-forward で結合されてもマージコミットを生成します。
履歴が分岐・統合したことが明確に残るため、後から追跡しやすいです。
4.4 マージではなくリベース
git checkout dev
git rebase main
git checkout main
git merge dev
リベースはコミットを直線化します。
メリット：履歴がシンプル
デメリット：共有リポジトリで既に公開されたコミットをリベースすると、他人に衝突を起こす可能性があります。
4.5 ブランチの削除
git branch -d feature/old-feature # マージ済みなら安全に削除
git branch -D feature/old-feature # 強制削除（未マージでも可）
# リモートブランチの削除
git push origin --delete feature/old-feature
4.6 ブランチの命名規則
チームで統一したプレフィクスを付けると管理しやすくなります。
| プレフィクス | 用途 |
|---|---|
feature/* |
新機能の追加 |
bugfix/* |
バグ修正 |
hotfix/* |
本番環境の緊急対応 |
release/* |
リリース準備作業 |
5. コンフリクト（衝突）への対処
5.1 コンフリクト発生のサイン
Auto-merging file.txt
CONFLICT (content): Merge conflict in file.txt
Automatic merge failed; fix conflicts and then commit the result.
5.2 解析方法
git status→ 何個のファイルがboth modifiedか- 直感的にファイルを開くと、
<<<<<<< HEAD,=======,>>>>>>> branch-nameのマーカーが表示<<<<<<< HEAD // 現分岐 ======= // マージ対象分岐 >>>>>>> dev
5.3 解消手順
- マーカーを消して自分の望むコードに整える。
git add <ファイル>でステージ。git commitでマージコミット（またはgit commit -m "Resolve conflicts"）。
5.4 コンフリクトを防ぐヒント
- 頻繁に pull / fetch：他人の変更を自分の作業と合わせる。
- 小さなコミット：変更を細かく保つ。
- ブランチ分解：大きな機能は小さなタスクに分割し、コンフリクトのリスクを減らす。
6. リモートリポジトリとプッシュ / プル
6.1 リモートを追加
git remote add origin https://github.com/owner/repo.git
git remote -v
6.2 プッシュ
git push -u origin main # 初回に upstream を設定
git push # upstream 設定後は省略可
git push origin feature/my-work # ブランチ名を明示
強制プッシュ（リベース後など）
リベースでコミットを書き換えた後にリモートへ反映する場合、通常の push は拒否されます。--force-with-lease を使うと、自分が知らない間に他人がプッシュしていた場合に失敗してくれる安全な強制プッシュができます。
git push --force-with-lease # 安全な強制プッシュ
認証
- HTTPS：GitHub では PAT（Personal Access Token）が必要。
- SSH：
~/.ssh/id_rsaの公開鍵を GitHub に登録して使う。
6.3 プル
git pull は fetch → merge（または rebase）の 2 ステップをまとめたコマンドです。
git pull # fetch + merge（デフォルト）
git pull --rebase # fetch + rebase（履歴を直線化）
git pull origin feature/main # ブランチを明示して取得
| 設定 | 詳細 |
|---|---|
| デフォルト（merge） | マージコミットができるので履歴が分岐する。頻繁に行うと履歴が複雑になることがある。 |
| rebase 推奨 | git config pull.rebase true でデフォルトを rebase に変更すると、直線的な履歴を保てる。 |
| ブランチ指定 | git pull origin feature1 のようにブランチを明示すると意図しない統合を防げる。 |
6.4 Fetch のみ
git fetch
最新情報を取得しただけで自動でマージはしません。
git fetch origin でリモートブランチをローカルに取り込むが、作業ブランチには影響しない。
6.5 push と pull の使い分け
| シナリオ | 推奨コマンド |
|---|---|
| 最新状態をローカルに取り込みたい | git pull（または git pull --rebase） |
| 自分の変更をリモートに共有したい | git push |
| リベース後にリモートを上書きしたい | git push --force-with-lease |
| マージせずにリモートの状態だけ確認したい | git fetch |
| 新しいマシンにリポジトリを複製したい | git clone <url> の後 git pull で最新化 |
7. ブランチ戦略とワークフローのパターン
チームの規模やリリースサイクルに合わせてブランチ戦略を選びます。
7.1 Git Flow
master（リリース済み）と develop（開発中）の 2 本柱で管理するモデル。長期プロジェクトや大規模チームに有効です。
| ブランチ | 用途 |
|---|---|
master |
本番環境（常にリリース可能） |
develop |
開発ベース |
feature/* |
新機能の追加 |
release/* |
リリース準備 |
hotfix/* |
本番の緊急修正 |
git checkout develop
git checkout -b feature/login
# 開発...
git checkout develop
git merge --no-ff feature/login
git checkout master
git merge --no-ff develop
7.2 GitHub Flow
main を常にデプロイ可能な状態に保ち、feature ブランチから PR でマージするシンプルなモデル。小規模チームやスピード重視の開発に向いています。
git checkout -b feature/chatbot
# 開発・コミット...
git push -u origin feature/chatbot
# GitHub で PR を作成 → レビュー・CI → main にマージ
7.3 Trunk-Based Development
main ブランチ 1 本を中心に、短命なブランチを頻繁にマージするモデル。コンフリクトが少なく、CI/CD との相性が抜群です。機能の切り替えに Feature Toggle（機能フラグ）を活用します。
git checkout -b feature/notification # 短命なブランチ
# 少量のコミット
git push -u origin feature/notification
git checkout main
git merge feature/notification # すぐにマージ
7.4 Fork & Pull Request
オープンソース開発でコントリビューターが自分の fork で作業し、PR で統合するモデル。
8. よく使う Git コマンドの小技
| コマンド | 詳細 |
|---|---|
git log --graph --oneline --decorate |
履歴を図解で表示。 |
git reflog |
HEAD の変更履歴を表示。失われたコミットが復元できる。 |
git stash |
作業中の変更を退避。git stash pop で復帰。 |
git reset --hard HEAD~1 |
最後のコミットを消す（破壊的）。慎重に。 |
git cherry-pick <コミットハッシュ> |
別ブランチの特定コミットを自分のブランチへコピー。 |
git bisect start <良いコミット> <悪いコミット> |
バグの原因コミットを探索。 |
git tag -a v1.0 -m "Release 1.0" |
バージョン管理用タグ。 |
9. 実際にやる：小さな CRUD アプリ開発例
9.1 環境構築
mkdir todo-app && cd todo-app
git init
code . # VS Code でオープン
9.2 初期 commit
echo "# Todo App" > README.md
git add README.md
git commit -m "Add README"
9.3 Feature ブランチ作成
git checkout -b feature/add-todo-list
echo "import sys;" > main.py
git add main.py
git commit -m "Create main.py skeleton"
9.4 変更をステージして commit
# 例：タスクを追加するコードを編集
git add main.py
git commit -m "Implement basic Todo functionality"
9.5 リモートを追加し Push
git remote add origin https://github.com/yourname/todo-app.git
git push -u origin feature/add-todo-list
9.6 PR 作成
GitHub にアクセスし、feature/add-todo-list の PR を main に向ける。
9.7 競合があったとき
git pull origin main # main をローカルに取得
# コンフリクトがあれば手動解消
git add main.py
git commit -m "Merge main into feature with conflict resolution"
9.8 マージ
git checkout main
git merge feature/add-todo-list --no-ff
git push origin main
9.9 タグ付け
git tag -a v0.1 -m "First release"
git push origin v0.1
10. よくある質問（FAQ）
| 質問 | 答え |
|---|---|
| Git の初期化に失敗した | git init を実行するディレクトリが書き込み権限を持っているか確認。 |
Pull で non fast-forward エラー |
git pull --rebase でリベースするか、git fetch && git merge origin/main で統合。 |
| コンフリクトが多すぎる | 小さなコミットを頻繁に push し、リポジトリの同期頻度を上げる。 |
| コミットメッセージが長すぎる | -m での一行メッセージと -m での詳細を分ける、あるいはエディタでコミットメッセージを書き込む。 |
| 別ブランチに切り替えると追跡してないファイルが消える | git stash で退避、あるいは全ての変更をコミットしておく。 |
11. さらに深くなるためのリソース
| タイトル | 内容 |
|---|---|
| Pro Git (オンライン版) | 標準リファレンス。分岐から Git Flow まで網羅。 |
| 「Git Pocket Guide」 | 簡潔で実務重視。 |
| GitFlow Cheat Sheet | ブランチ運用を視覚化。 |
| GitHub Learning Lab | インタラクティブに学べる。 |
12. まとめ
- Git はローカルに完全な履歴を保持し、ネットワークに依存せず作業できる強力なツールです。
- 最初は小さなコミットと頻繁な同期を心掛けると、後々の混乱を減らせます。
- ブランチの活用は「機能ごとに作業を分離し、最終的に main へ安全に反映」する最良の手段です。
- コンフリクトは避けられないものですが、素早く対処し、履歴をきれいに保つことが重要です。
- 実際のプロジェクトで取り組むことで、理論では得られない実践力が養われます。
Git の世界は一度マスターすれば、スケールアップも簡単。今この瞬間から、今回の「簡単な CRUD アプリ」をベースに、さらに奥深いプロジェクトへ挑戦してみてください。 Happy coding!
コメント