Git初心者必見:clone・ブランチ運用・マージコンフリクトの基本と対処法

Git初心者必見:clone・ブランチ運用・マージコンフリクトの基本と対処法

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 がスムーズになります。

改行コードポリシーをチームで統一

環境一般的な推奨備考
Windowsfalse + .gitattributes で LF 固定true は便利ですが、混乱リスクがあるため方針を確認
macOS / Linuxinputコミット時に 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 FlowGitHub FlowTrunk‑Based
主ブランチmain / developmainmain
リリース管理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..HEADPR 前のセルフチェック
設定確認git config --list --show-originどのファイルで設定されたか判別できる

マージコンフリクトの原因と安全な解消手順

コンフリクトが起こる典型例

同じファイル・同じ行を複数ブランチで変更すると Git は自動的に解決できません。以下のコンフリクトマーカーが挿入されます。

<<<<<<< HEAD
// 現在ブランチの内容
=======
// 競合ブランチの内容
>>>>>>> feature/xyz

VS Code と CLI 併用の解決フロー

  1. 競合箇所を確認git status で対象ファイルを把握します。
  2. 内容を統合:VS Code の Accept Current / Accept Incoming で片方を採用するか、手動編集します。
  3. 動作確認:ビルドとテストを実行し、統合後の挙動をチェックします。
  4. ステージgit add 解決済みファイル
  5. コミットgit commit -m "Resolve merge conflict"
  6. リモートへ pushgit 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 でレビューを受けるサイクルを習慣化すれば、開発は格段に滑らかになります。

初心者向けLinuxサーバー構築ガイド|UbuntuでLAMP・LEMP環境を簡単に設定する方法

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
目次