【初心者向け】GitHubの使い方 Gitとの違いも解説

プログラミングやWeb開発、Difyのようなサーバー構築を学ぶ上で、必ず耳にする「GitHub（ギットハブ）」という言葉。これは、現代のIT開発において「常識」とも言える必須のツール（Webサービス）です。

この記事では、「GitHubとは何か？」という基礎から、よく混同される「Git」との違い、そして基本的な使い方までを初心者向けに分かりやすく解説します。

1. GitHubとは？
2. 最大の関門：「Git」と「GitHub」の違い
1. Git（ギット）
2. GitHub（ギットハブ）
3. なぜGit/GitHubが必要なのか？
4. GitHub初心者がまず覚えるべき基礎用語
5. GitHubの始め方 5ステップ
6. GitHubの基本的な使い方（流れ）
1. 【操作例１】ファイルをローカルリポジトリに登録
2. 【操作例２】リモートリポジトリにpush
7. 学習者がGitHubを使うメリット
８．情報の取り扱いには注意が必要
９. まとめ
【付録】Gitに対する用語やコマンドの詳細まとめ

1. GitHubとは？

GitHubは、ソフトウェア開発プロジェクトのソースコードや、デザインデータ、ドキュメントなどを保存・管理・共有するためのオンライン（クラウド）プラットフォームです。

世界中の開発者がGitHub上で自分のプログラムを公開したり、チームメンバーと共同でプロジェクトを進めたりしています。

もともとはエンジニア向けのサービスでしたが、現在ではデザイナー、ライター、そしてプログラミング学習者まで、ITに関わる多くの人々が「ITの常識・ド定番」ツールとして活用しています。

2. 最大の関門：「Git」と「GitHub」の違い

初心者が最初につまずくのが、「Git（ギット）」と「GitHub（ギットハブ）」の違いです。名前が似ていますが、役割は明確に異なります。

Git（ギット）

- 役割: バージョン管理システム（道具・ツール）
- 場所: 自分のPC（ローカル環境）にインストールして使う。
- 目的: ファイルの「変更履歴」を記録・管理するための「道具」です。誰が、いつ、どの部分を変更したかを記録できます。Linuxの開発者であるリーナス・トーバルズ氏が開発しました。
- GitのWEBサイト：https://git-scm.com/

GitHub（ギットハブ）

- 役割: Gitの仕組みを使った（サービス・作業場）
- 場所: クラウド（Web上）で提供されるサービス。
- 目的: Git（道具）を使って記録した変更履歴やファイルを、インターネット上で保存・共有し、複数人での共同作業（開発）を簡単にするための「作業場」です。
- GitHubのWEBサイト：https://github.co.jp/

「Git」という道具を使ってPC上で作業し、その結果を「GitHub」という作業場（クラウド）にアップロードして、他の人にも見せたり、一緒に作業したりする、とイメージすると分かりやすいでしょう。

3. なぜGit/GitHubが必要なのか？

チーム開発でも個人学習でも、Git/GitHubは以下のような強力なメリットを提供します。

変更履歴がすべて残る
「誰が・いつ・どの部分を・どう変更したのか」がすべて記録されます。これにより、「いつの間にかファイルが書き換わっていた」「エラーが出たけど、いつからおかしくなったか分からない」といった事態を防げます。
いつでも過去の状態に戻せる
「新しい機能を追加したら、全部動かなくなった…！」という時でも、Gitを使えばエラーが起こる直前の正常な状態（コミット）に簡単に戻すことができます。
共同作業（チーム開発）が劇的に楽になる
Aさんは機能追加、Bさんはバグ修正、といった並行作業（ブランチ）が簡単に行え、後でそれらの変更を安全に合流（マージ）させることができます。

4. GitHub初心者がまず覚えるべき基礎用語

GitHubを使いこなすには、いくつかの専門用語を覚える必要があります。まずはこれだけ覚えましょう。

リポジトリ (Repository)　⇒　「保管庫」

- プロジェクトのファイルや変更履歴をまとめて保存しておく「保管庫」です。
- ローカルリポジトリ: 自分のPC内にある保管庫。
- リモートリポジトリ: GitHub上にある保管庫（チームで共有する場所）。

コミット (Commit)　⇒　「セーブ（記録）」

- ファイルの追加や変更を、ローカルリポジトリに「セーブ（記録）」する操作です。変更内容のまとまりごとにコミットを作成します。

プッシュ (Push)　⇒　「アップロード」

- ローカルリポジトリにコミット（セーブ）した変更内容を、リモートリポジトリ（GitHub）に「アップロード」する操作です。これを実行して初めて、変更がチームメンバーに共有されます。

プル (Pull)　⇒　「ダウンロード」

- リモートリポジトリ（GitHub）にある最新の変更内容を、自分のローカルリポジトリに「ダウンロード」する操作です。共同作業では、作業開始前に必ずプルを行い、最新の状態にします。

ブランチ (Branch)　⇒　「分岐」

- 作業履歴の流れを「分岐」させる機能です。
- 例えば、リリース済みの「main（メインブランチ）」から、新機能開発用の「featureブランチ」を分岐させれば、メインのコードに影響を与えずに安全に作業ができます。

ブランチ (Branch)とフォーク（fork）の違い

「フォーク」とは、他人のリモートリポジトリをコピーし、自分のリモートリポジトリを作成する機能です。他人のリモートリポジトリをベースにすることで、自分の開発を手軽に始められます。

ブランチはリポジトリ内のファイル・フォルダ一式を枝分かれさせますが、フォークはリモートリポジトリを枝分かれさせます。

フォークで作成したリモートリポジトリに入れた変更は、元のリモートリポジトリにマージすることも可能です。ただし、前述のプルリクエストを作成し、レビューしてもらう必要があります。

GitHubのリモートリポジトリには公開・非公開の設定があります。非公開のリモートリポジトリはフォークできないため注意が必要です。

ブランチを作成する

ブランチを作成するには、まずファイルを作成してローカルリポジトリにコミットしましょう。

次に「git branch」コマンドを実行してください。

$ git branch [ブランチ名]

ここでは、ブランチ名を「branch_test」にしています。

$ git branch branch_test

引数なしの「git branch」コマンドで、作成されたブランチの一覧を確認できます。

$ git branch<br>* branch_test<br>master

マージ (Merge)　⇒　「統合」

- 分岐させたブランチでの作業が完了した際、その変更内容を別のブランチ（例: main）に「合流（統合）」させる操作です。

プルリクエスト (Pull Request)　⇒　「依頼」

- 「featureブランチでの作業が終わったので、mainブランチにマージしてください」と、変更内容のレビュー（確認）をチームメンバーに依頼する機能です。チーム開発の品質を保つための中核機能です。

GitHubは、プログラムの管理以外にも以下の用途でも使用されます。

Issues（課題管理）
バグや改善案を「課題」として記録・共有し、担当者や進捗を管理できる。
GitHub Actions（自動化機能）
コードをプッシュすると、自動的にテストやデプロイを行うなどのワークフローを設定できる。
Wiki・ドキュメント管理
開発ガイドラインや仕様書をリポジトリ内に整理できる。

その他に覚えておくと便利な操作

ファイルを比較する

「git diff」コマンドを使用すると、2つのファイルを比較して差分を確認できます。

例えば、リモートリポジトリに変更したソースファイルをマージする際、「変更内容が反映されているか」「他の担当者が編集した内容を消してしまってないか」などを確認するために、「git diff」コマンドを使用します。

「git diff」コマンドの基本的な書き方は次のとおりです。

$ git diff

引数なしの「git diff」コマンドで、リポジトリの中にあるファイルすべてを比較することができます。

リポジトリにtagをつける

「git tag」コマンドを使用すると、ファイルにタグをつけてわかりやすくできます。

例えばリリースの際、コミットごとにバージョンをつけて管理したい場合（ver1.0 → ver1.1など）にタグをつけておけば、効率よく履歴管理や検索作業が可能です。「git tag」コマンドを使用することでタグを簡単に作成できます。

「git tag」コマンドの書き方は次のとおりです。

# 注釈なしタグ<br>git tag [タグ名]<br><br># 注釈付きタグ<br>git tag -a [タグ名] -m [“コメント“]

「git tag」コマンドには、「注釈なし」コマンドと、簡単なコメントがつけられる「注釈あり」コマンドがあります。

サブモジュールを作成する

サブモジュールを作成すれば、現在の自分のリモートリポジトリに外部のリモートリポジトリをサブモジュールとして追加できます。

例えば、別のチームが作業中のプロジェクトを自分が担当しているプロジェクトでも利用・参照できるようにしたい場合、サブモジュールを使うのがおすすめです。

サブモジュールを作成するには、「git submodule」コマンドを使います。

まず、ファイルを作成してリモートリポジトリにプッシュします。その後、外部のリモートリポジトリである「Sample」を「git submodule」コマンドで追加しましょう。

$ git submodule add https://github.com/takataka58/Sample.git<br>Cloning into ‘/Users/taka/sample/Sample’…<br>remote: Counting objects: 7, done.<br>remote: Compressing objects: 100% (4/4), done.<br>remote: Total 7 (delta 0), reused 7 (delta 0), pack-reused 0<br>Unpackin: 100% (7/7), done.

現在のディレクトリに、リモートリポジトリの「Sample」が追加されています。

$ ls -l Sample/<br>total 16<br>-rw-r—r—  1 taka  staff  23  9 20 08:23 sample1.txt<br>-rw-r—r—  1 taka  staff  23  9 20 08:23 sample2.txt

このときに「git status」コマンドを使って現在の状態を確認してください。

$ git status<br>On branch master<br>Changes to be committed:<br>  (use “git reset HEAD <file>…” to unstage)<br> <br> <br> new file:   .gitmodules<br> new file:   Sample

「.gitmodules」とリポジトリの「Sample」が追加されていることがわかります。

「.gitmodules」ファイルを確認してみると、サブモジュール名とURLの情報が記載されています。

$ cat .gitmodules<br>[submodule “Sample”]<br> path = Sample<br> url =<a href="https://github.com/takataka58/Sample.git"><br>https://github.com/takataka58/Sample.git</a>

サブモジュールを追加したら「git commit」でプロジェクトをコミットするのを忘れないでください。

$ git commit -m "git add Sample"

5. GitHubの始め方 5ステップ

GitHubを使い始めるための手順は以下の通りです。

ステップ1： Gitをインストールする

まずは「道具」であるGitを自分のPCにインストールします。Git公式サイト（https://git-scm.com/）からダウンロードしてください。

なお、次の記事ではOS別にGitのインストール方法を詳しく解説しているので、あわせて参考にしてください。
→ Gitをインストールしてみよう！Windows/Macどちらも丁寧に解説

Git Bash

Git for Windowsをインストールすると、Git Bashというツールもインストールされます。

Git Bashは、Windowsのコマンドプロンプトと同じようなツールで、Linuxでよく使用されているlsコマンドなどを利用できます。

ステップ2： GitHubのアカウントを作成する

次に「作業場」であるGitHub公式サイト（https://github.co.jp/）で、ユーザー登録（無料）を行います。

ステップ3： Gitの初期設定を行う

PCにインストールしたGitに、あなたが誰なのかを教えます。ターミナル（コマンドプロンプトやGit Bash）で以下のコマンドを実行し、GitHubに登録したユーザー名とメールアドレスを設定します。

ユーザー名やメールアドレスの設定は、git configコマンドで行えます。WindowsのコマンドプロンプトやmacOSのターミナルなどを開き、次のようにGitコマンドを実行すればOKです。

git config --global user.name "Your GitHub Username"
git config --global user.email "your-email@example.com"

ステップ4： GitHubの2要素認証を設定する

セキュリティのため、GitHubは2要素認証（パスワード＋認証アプリなど）が必須となっています。アカウント設定から必ず有効化してください。

ステップ5：ログインしてリポジトリを作成する

GitHubにログインし、新しいリモートリポジトリを作成すれば準備完了です。

6. GitHubの基本的な使い方（流れ）

個人で利用する際の最も基本的な流れは「コミット (Commit) → プッシュ (Push)」です。

リポジトリの準備
- （A）新規の場合: PC上に作業フォルダを作り、git init コマンドでローカルリポジトリ化。その後、GitHubで作成したリモートリポジトリと接続（git remote add）します。
- （B）既存の場合: GitHubにあるリモートリポジトリを git clone [URL] コマンドでPCに丸ごとコピーしてきます。（こちらの方が一般的です）
ファイルの編集
- PC上でコードを書いたり、ファイルを編集したりします。
変更をインデックスに追加 (add)
- コミットしたい変更を「インデックス」という待合室に登録します。
- git add . （カレントディレクトリ以下の全ての変更を登録）
ローカルリポジトリにコミット (commit)
- インデックスに登録した変更内容を、ひとかたまりの履歴としてローカルリポジトリにセーブします。-m で変更内容のメッセージを付けます。
- git commit -m "〇〇機能のバグを修正"
リモートリポジトリにプッシュ (push)
- ローカルリポジトリにセーブした履歴を、GitHub（リモートリポジトリ）にアップロードして反映させます。
- git push origin main （mainブランチの変更をプッシュする場合）

【操作例１】ファイルをローカルリポジトリに登録

ファイルを新規に作成してローカルリポジトリに作成してみます。任意のテキストファイルをディレクトリ「pushtest」に作成します。ここでは「pushtest.txt」にしています。

$ vi pushtest.txt

pushtest.txtの内容

push test!

ファイルを作成したら、「git add」コマンドでファイルをインデックスに追加します。インデックスに追加することでGitで管理する対象のファイルになります。

$ git add pushtest.txt

インデックスの追加を実施したら、リポジトリに登録します。登録には「git commit」コマンドを実行します。

$ git commit -m “pushコマンドの確認”

指定した引数はこのリポジトリの内容を表します。成功すると以下のように表示されます。

Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:

これでリポジトリの登録が完了しました。

【操作例２】リモートリポジトリにpush

リモートリポジトリに作成したファイルをpushコマンドで送信してみましょう。gitのpushコマンドは、ローカル環境であるローカルリポジトリで編集したファイルをリモートリポジトリにアップロードするためのものです。

送信する前に「git remote」コマンドを使用してリモートリポジトリに追加を行います。リポジトリのURLは先程GitHubで作成したリポジトリのURLを指定します。

$ git remote add origin https://github.com/ユーザーID/push_test.git

続いて「git push」コマンドでリモートリポジトリに送信を行います。以下のコマンドを実行します。

$ git push origin master

ユーザーネームとパスワードを聞かれますので、それぞれGitHubのユーザーとパスワードを入力しましょう。成功したら以下のように表示されます。

Counting objects: 3, done.
Writing objects: 100% (3/3), 245 bytes | 245.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/takataka58/push_test.git
 * [new branch]      master -> master

GitHub上で登録されていることを確認します。

これでローカルリポジトリからのアップロードが完了しました。

7. 学習者がGitHubを使うメリット

学習の履歴（ポートフォリオ）になる: あなたが日々学習し、コミットした履歴（通称「草」）がGitHub上に可視化されます。これは、就職・転職活動において、あなたの継続的な努力と技術力を証明する最強のポートフォリオになります。
実務（チーム開発）の流れを体験できる: ブランチを切り、プルリクエストを送ってレビューをもらう、という流れは、実際の開発現場で毎日行われていることです。これを学生のうちから体験できるのは大きな強みです。
世界中のコードを参考にできる: 世界中の優れたエンジニアが公開しているコード（オープンソース）を自由に読み、学ぶことができます。

８．情報の取り扱いには注意が必要

GitHubではさまざまな成果物を公開できますが、情報の取り扱いには注意が必要です。

たとえば、重要な認証情報（パスワードなど）が含まれるプログラムを公開すると、第三者に見られてしまうリスクがあります。安易に認証情報をアップロードすべきではありません。

また、チームでGitHubを使う場合、GitHubアカウントの共用は避けるべきです。パスワードなどの重要な情報が外部に漏えいしやすくなり、乗っ取りのリスクが高まります。

GitHubは便利なWebサービスですが、情報の扱い方によってはセキュリティ上のリスクが生じます。情報の取り扱いに注意してGitHubを利用しましょう。

９. まとめ

Gitは、ファイルの変更履歴を管理する「道具」です。
GitHubは、Gitの仕組みを使い、クラウド上でコードを共有・管理する「作業場（サービス）」です。
Difyサーバーの設定ファイルなども、Git/GitHubで管理することで「いつ、どの設定を変更したか」が全て記録され、安全に運用できます。
まずはアカウントを作成し、「add → commit → push」という基本的な流れをマスターすることから始めましょう。

【付録】Gitに対する用語やコマンドの詳細まとめ

Gitの基本用語

Gitで良く使われる基本用語について、一覧表でご紹介します。なお復習もかねて、前章までに登場した用語も入れておきます。

用語	意味
リポジトリ	ソースファイルなどを管理するための格納場所
リモートリポジトリ	チームメンバーとサーバー上で共有するリポジトリ
ローカルリポジトリ	マスターリポジトリをコピーして各担当者が管理するリポジトリ
クローン	リポジトリをコピー（複製）する
フォーク	他の開発者のリポジトリをGitHub上でクローンする
イニット	リポジトリを新規作成する
プル	マスターリポジトリのデータをローカルリポジトリに取り込む
プッシュ	ローカルリポジトリの変更内容をマスターリポジトリに加える
コミット	ファイルやディレクトリの作業をローカルリポジトリに記録
ワークツリー	ユーザーが作業中のディレクトリ
マージ	異なるリポジトリの変更内容を統合
コンフリクト	同じファイルの同一箇所で同時に変更が起こってしまうエラー

よく使うGitコマンド一覧

Git使用経験の豊富なエンジニア目線で、よく使うGitコマンドを19個ピックアップしました。まずはコマンド名と用途を一覧表にしましたので、参考にしてください。

コマンド名	用途
git init	リポジトリを新規作成 `$ cd [リポジトリを作成するディレクトリ] $ git init`
git clone	リポジトリをコピー `$ git clone [コピーするリポジトリ] [コピー先ディレクトリ(省略可)]`
git gc	リポジトリを最適化 `$ git gc`
git pull	リモートリポジトリの変更点をローカルリポジトリにマージ `$ git pull [マージ元のリモートリポジトリ名] [マージ先のローカルリポジトリ名]`
git push	ローカルリポジトリの変更点をリモートリポジトリにマージ `$ git push [マージ先のリモートリポジトリ名] [マージ元のローカルリポジトリ名]`
git add	コミット対象のファイルを登録 `$ git add [追加/変更/削除したファイルパス1] [追加/変更/削除したファイルパス2] ・・・` 【一括追加】 `$ git add .`
git commit	変更されたファイルをコミット（ローカルリポジトリに変更内容を入れ込む） $ git commit $ git commit -m “[コミットメッセージ]”
git reset	直前のコミットを取消 $ git reset
git revert	特定のコミットを取消 $ git revert [取り消すコミットID]
git tag	コミットにタグを付ける $ git tag [タグ名] $ git push origin [タグ名]
git log	コミット履歴を表示 $ git log
git status	作業ツリー内の差分ファイルを表示 $ git status [表示するディレクトリ(省略可)]
git diff	ファイル内の差分箇所を表示 $ git diff [変更を確認するファイル名またはディレクトリ(省略可)]
git mv	ファイルを移動／ファイル名を変更（コミットが必要） $ git mv [移動するファイル名] [移動先のディレクトリ] $ git mv [変更前のファイル名] [変更後のファイル名]
git stash	作業ツリーの状態を一時的に保存 $ git stash [実行コマンド] 【実行コマンド】 save：作業ツリーの状態を保存 list：保存されたバックアップデータを一覧表示 apply：保存されたバックアップデータを使用する環境に戻す drop：保存されたバックアップデータを削除
git branch	ブランチの作成／一覧表示【ブランチの作成】 $ git branch [作成するブランチ名] 【ローカルブランチの一覧表示】 $ git branch 【リモートブランチの一覧表示】 $ git branch -r
git checkout	処理対象ブランチの切り替え $ git checkout [切り替えるブランチ名]
git merge	別のブランチから変更点をマージ $ git merge [変更点の取り込み元ブランチ名]
git rebase	派生元ブランチに変更点をマージ $ git rebase [派生元ブランチ名]

git configについて

git configとは一言で言うとGitの設定内容を変更するためのコマンドです。Gitにはさまざまな設定項目がありますが、git configコマンドを実行することでGitの設定項目を指定して内容を変更することができます。

git configの書き方

$ git config [種別] [設定項目] [変更内容(値)] <value>

Gitの設定はオプションでそれぞれの種別「system」「global」「local」に分けて設定することができます。

–system：システム全体の設定
–global：該当ユーザーの全リポジトリの設定
–local：該当のリポジトリのみ設定

Gitの設定はlocalでは該当のリポジトリのみ設定が有効となるので、通常はglobalで設定を行うことが多いと言えるでしょう。

git configで設定内容を確認する

現在の設定内容を一覧で表示するには「git config」コマンドでオプション「–list」を設定します。例えばlocalの設定内容を確認したい場合は以下のように実行します。

$ git config --local --list

出力例：

core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
core.precomposeunicode=true
remote.origin.url=https://github.com/takataka58/sample.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*

設定内容は「KEY=値」のように出力されます。値がtrueになっているKEYは設定が有効になっています。全ての設定内容を表示したい場合は以下のように実行します。

$ git config --list

git configで設定内容を変更する

git configで設定できる項目はたくさんありますが、ここではよく行う設定方法を紹介します。

ユーザー名の設定

ユーザー名を設定する場合は引数に「user.name」を指定して以下のように実行します。

$ git config --global user.name [ユーザー名]

ここでは以下のように変更してみます。

$ git config --global user.name samurai

設定内容を確認すると、以下のようにユーザー名が変更されています。

user.name=samurai

メールアドレスの設定

メールアドレスを設定する場合は引数に「user.email」を指定して以下のように実行します。

$ git config --global user.email [メールアドレス]

出力内容の色分け

ターミナルで出力する文字に色付けしたい場合は「color.ui」を指定します。

$ git config --global color.ui true

色を指定したい場合は以下のように指定します。

$ git config --global color.指定色

公式によると、指定できる色は以下の通りです。

色として指定できる値は normal、black、red、green、yellow、blue、magenta、cyan あるいは white のいずれかです。先ほどの例の bold のように属性を指定することもできます。bold、dim、ul、blink および reverse のいずれかを指定できます。引用：Git

mergeの詳細

まず早速ですが、マージを一言で説明すると…

「現在のブランチ(HEADの指している場所)へ、他のブランチの更新を取り込む処理」と言えるでしょう。言葉だけではわからないと思うので図にして見てみましょうか。現在の開発状況が、以下の図のようだったとしましょう。

開始地点や丸はコミットです。Aさんの使っているブランチがブランチA。Bさんの使っているブランチがブランチBだったとしましょう。この状況で、AさんがBさんの更新を取り込みたくなったとしましょう。そこで登場するのがマージです。

マージを使用すると…

Bさんの更新を取り込み、取り込んだ後のマージコミットが一つ作成されました。マージコミットには、ちゃんとBさんの更新が含まれています。つまり自分のブランチへ他のブランチの更新を取り込んだということですね!

mergeの使い方

ここまででマージの概念は理解できたかと思います。

では次にコマンドを使用して、実際にマージを行ってみましょう。コマンドは非常に簡単です。取り込みを行いたい場所に居た上で、以下のコマンドを投げましょう。

git merge 取り込みたいブランチ

これだけです。

少し実例を見てみましょう。例えば先ほどの、AさんがBさんのブランチを取り込む例を見てみましょう。

この画像の状況で、Aさんは最新の「ブランチA」に居たとします。その状況で以下のコマンドを実行しましょう。

git merge ブランチB

すると…

このように、Bさんの更新を取り込めるわけですね!

コンフリクトとは

マージの基本的な使い方を理解できましたでしょうか?

しかし、理解が進んでくると、一つ疑問が湧いてくるとおもます。

同じ場所を同時に更新してしまったらどうなるんだろう？

実はこれがあるからマージは難しいのです。例えば「test.txt」というファイルをgitで管理していたとしましょう。これを同時に同じ箇所を修正してしまったとします。

この状況でマージを行うと、コンフリクト(衝突)が発生します。

どちらの処理を優先すればいいのか、gitが判別できないからです。これに関してはユーザーが手動で対処する必要があります。

ではコンフリクトが起きた時にはどう対処すれば良いかの？　それを次に見ていきましょう。

コンフリクトの解消の仕方(手動)

ここでは実例をベースに解消方法を見ていきましょう。

例えばtest.txtの中身が以下のように変更されている状況でマージを行い、コンフリクトが起きた場合を見ていきましょう。

元々:

AAA

ブランチAでの変更:

BBB

ブランチBでの変更:

CCC

コンフリクトの場所を確認

コンフリクトが発生した際、以下のようなエラー文章が流れます。

Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Automatic merge failed; fix conflicts and then commit the result.

これは読めば分かると思いますが「test.txtで衝突が発生しています」というエラー文です。衝突が起きた場合は、まずエラーをみて場所を判断しましょう!

コンフリクトを解消

そしてそれを解消するためにtext.txtの中身を覗きます。すると以下のようになっているはずです。

<<<<<<< HEAD
BBB
=======
CCC
>>>>>>> branchB

これは、現在いるブランチ(ブランチA)は「BBB」に変更しているけど、ブランチBは「CCC」に変更しているよ!という意味です。優先したい方だけ残すように修正しましょう。

BBB

今回はブランチAのみを残すことにします。

解消し終わったらコミット!

修正が終わったら、必ず変更箇所に対してaddとコミットを行いましょう。そうすることで、マージコミットが生成されます。

コンフリクトの解消の仕方(片方を破棄する方法)

片方の更新のみ優先したい場合ならば、もっと簡単な方法があります。checkoutコマンドを利用して、指定したブランチ側のファイルを落とし直す方法です。

ブランチA側(現在いるブランチ)を優先したい:

git checkout --ours text.txt

ブランチB側(取り込むブランチ)を優先したい:

git checkout --theirs text.txt

これを使用すると、任意のブランチの内容のみを残すことができます。またこちらの手段を用いた場合も、addとcommitを最後に行い、マージコミットを作りましょう。

mergeには二種類ある!

ここまでで、マージについて一通り学ぶことができたと思います。しかしもう一点、重要な要素があるので勉強しておきましょう。実はマージには2種類のマージがあるんです。

その2種類とは?

fast-forward(早送りマージとも呼ばれる)
no-fast-forward

この二つです。

どう違うのかというと、マージコミットが作られないのがfast-forwardのマージ。マージコミットが作られるのが、no-fast-forwardのマージです。

fast-forward

fasta-forwardはマージコミットが作られません。

例えばこのような状況の時は、単純にブランチAに、ブランチBの更新が反映されていないだけです。そのためマージしても、マージコミットが作られません。

このように、ブランチの位置が最新の位置に移動されるだけです。

no-fast-forward

逆に最初見たように、ブランチAとブランチBで、それぞれ別々の開発が進んでしまっている場合、マージコミットが作られます。このようにマージコミットが作られるコミットが、no-fast-forwardと呼ばれるコミットです。

–no-ffオプションで必ずマージコミットを作る!

ここまで読んで…

だからなんなんだ?

と初心者の方は思うかもしれませんが、これが結構重要な話なのです。それは運用ルールによりはしますが、マージコミットが必要ない場合でも、あえてマージコミットを残しておいた方が良いケースも多いからです。

それを実現するために、mergeには–no-ffオプションが存在します。

git merge --no-ff 取り込みたいブランチ名

このオプションをつけると、強制的にマージコミットが作られますので、ぜひ覚えておきましょう!