Git初心者必見:clone・ブランチ運用・マージコンフリクトの基本と対処法
Git はプログラミング初心者の最初の壁になりがちですが、ポイントを押さえれば怖くありません。ここではclone・ブランチ戦略・マージコンフリクト解消を中心に、つまずきやすいポイントをやさしく解説します。
Gitとは?バージョン管理の基本を押さえよう
Git はソースコードの変更履歴を時系列で保存できる分散型バージョン管理システムです。ローカルにフル履歴を保持できるため、ネットワークが途切れても作業を継続できます。また、ブランチとマージの仕組みにより衝突が起きても履歴を失わず安全に統合できる設計が特徴です。
ローカル環境と git clone のコツ
git clone の基本手順
リモートリポジトリを手元にコピーするには次を実行します。
$ git clone https://github.com/owner/project.git
完了するとディレクトリ project
が作成され、リモート origin
が登録されます。
clone 後に確認したい設定一覧
ユーザー名とメールアドレス
グローバル設定:
$ git config --global user.name "Your Name"
$ git config --global user.email "you@example.com"
SSH キーでパスワードレス操作
HTTPS では毎回パスワード入力が必要です。SSH 鍵を登録すると push がスムーズになります。
改行コードポリシーをチームで統一
環境 | 一般的な推奨 | 備考 |
---|---|---|
Windows | false + .gitattributes で LF 固定 | true は便利ですが、混乱リスクがあるため方針を確認 |
macOS / Linux | input | コミット時に LF へ変換し、チェックアウト時は変更しません |
.gitattributes
で改行コードを明示しておくと OS 混在チームでも安心です。
おすすめブランチ戦略とワークフロー
GitHub Flow:シンプルで高速
main
にデプロイ可能なコードを常に保ち、機能開発は feature/◯◯
ブランチで行います。PR でレビュー後すぐマージするので、リリースサイクルが短いサービスに合います。
Git Flow:大規模プロジェクト向け
主ブランチを main / develop
(旧 master / develop
)に分け、release/*
や hotfix/*
ブランチでリリース管理を行います。履歴が整理される一方、ブランチ数が増える点に注意してください。
Trunk‑Based Development:最新トレンド
1 本の main
に短命ブランチをこまめにマージし、機能の切り替えは Feature Flag で行います。CI/CD が整った環境で威力を発揮します。
項目 | Git Flow | GitHub Flow | Trunk‑Based |
---|---|---|---|
主ブランチ | main / develop | main | main |
リリース管理 | release/* ブランチ | タグ | タグ |
用途 | 大規模・長期運用 | 短サイクル開発 | 高速デリバリー |
複雑さ | 高め | 低め | 中 |
基本コマンド早見表
目的 | 代表コマンド | ポイント |
---|---|---|
リポジトリ取得 | git clone URL | 遠隔リポジトリを丸ごとコピー |
変更の取得 | git pull | 既定は fetch+merge。 公開ブランチでは --rebase 利用時に履歴書き換えを避ける運用が安全 |
ブランチ作成 | git switch -c 新ブランチ (git checkout -b も可) | Git 2.23 以降は switch が快適 |
履歴確認 | git log --oneline --graph | –graph でツリー表示 |
差分確認 | git diff main..HEAD | PR 前のセルフチェック |
設定確認 | git config --list --show-origin | どのファイルで設定されたか判別できる |
マージコンフリクトの原因と安全な解消手順
コンフリクトが起こる典型例
同じファイル・同じ行を複数ブランチで変更すると Git は自動的に解決できません。以下のコンフリクトマーカーが挿入されます。
<<<<<<< HEAD
// 現在ブランチの内容
=======
// 競合ブランチの内容
>>>>>>> feature/xyz
VS Code と CLI 併用の解決フロー
- 競合箇所を確認:
git status
で対象ファイルを把握します。 - 内容を統合:VS Code の Accept Current / Accept Incoming で片方を採用するか、手動編集します。
- 動作確認:ビルドとテストを実行し、統合後の挙動をチェックします。
- ステージ:
git add 解決済みファイル
- コミット:
git commit -m "Resolve merge conflict"
- リモートへ push:
git push
。PR は自動更新されます。
よくあるつまずきポイント Q&A
pull で “fatal: refusing to merge unrelated histories” が出た
履歴がまったく別のリポジトリを統合しようとしています。新規 clone が安全ですが、履歴を上書き移行したい特殊ケースでは git merge --allow-unrelated-histories
が使われることもあります。
リモートブランチが一覧に表示されない
git fetch --prune
で不要な追跡ブランチを整理し、最新状態を取得しましょう。
次のステップ:コミットメッセージ規約と設定確認
チーム開発では履歴を読みやすく保つため、Conventional Commits などのメッセージ規約を採用するケースが増えています。また、CI でメッセージフォーマットを自動チェックすると品質が安定します。
まとめ:小さく試して継続的に改善しよう
Git は機能が多彩ですが、clone
・ブランチ運用・マージコンフリクト解消の三つを押さえれば実務で困りません。小さな変更をこまめにコミットし、PR でレビューを受けるサイクルを習慣化すれば、開発は格段に滑らかになります。