【月間10万PV達成】ブログの作り方を無料公開中!

【初心者】Gitコマンドの使い方を体系的に覚える【一覧あり】

Gitコマンドの使い方

プログラミング初心者の頃から、Gitの使い方を覚えておいたほうがいい理由は2つ。

  • Gitに触れる時間が長くなり習慣化する
  • 自分のソースコードを管理できる

僕の研修でも、入社3日目の未経験者にGitでソースコードを管理してもらっています。

これは、Gitに触れる時間をできるだけ長くし、体で覚えてもらうためです。

Gitを使っていると、突然エラーでハマり、自分で調べ対応するなんてのは日常茶飯事。

これが習慣化されると問題に対する解決能力が上がり、エンジニアとしても大きく成長できます。

また、Git本来の目的である「ソースコードの管理」もできるので、一石二鳥ですね。

そんなわけで、この記事はプログラミング初心者が、実際にGitコマンドを使いながら体系的に学んでいく「勉強型のコンテンツ」となっています。

もちろん、読むだけでも知識は深まると思うので、気になる方は最後まで読んでみてください。

「Gitの仕組みがよくわかってない!」という方は、さきに以下の記事を読んでくださいね。

Gitとは?仕組みを解説【読むだけ】Gitとは?仕組みを初心者にもわかりやすく解説【図解】

上から順番に読むだけで、Gitコマンドの全体像をつかめるよ!

Gitを使うための準備

この記事では、実際に手を動かしながら、体系的にGitコマンドを学習できるようになっています。

そのため、事前に以下の2つを終わらせておく必要があります。

  1. Gitのインストール、GitHubの設定
  2. 作業ディレクトリの作成

もちろん、読むだけでも勉強になると思いますので、その場合はスキップして大丈夫です。

では、それぞれ見ていきましょう。

1. GitのインストールとGitHubの設定

Gitを使う前に、GitやGitHubの準備ができているかを確認しましょう。

Gitは「ローカルリポジトリ」、GitHubは「リモートリポジトリ」として使いながら進めていきます。

もし、GitのインストールやGitHubの設定が終わっていない方は、以下の記事を参考にやってみてください。

Gitのインストールと設定【導入】Gitのインストール方法と初期設定(Windows、Linux) GitHubの使い方と用語【入門】GitHubとは?初心者向けに登録や使い方、リポジトリ作成を紹介!

2. 作業ディレクトリの作成

この記事では、Gitコマンドを体系的に学ぶため、2つのディレクトリを使って作業を進めていきます。

  • キツネ側…「~/work/kitsune」
  • タヌキ側…「~/work/tanuki」

そのため、以下のコマンドを実行してディレクトリを準備しておいてください。

ディレクトリを作成
# 「work」ディレクトリを作成
$ mkdir ~/work

# 「work/aaa」ディレクトリを作成
$ mkdir ~/work/kitsune

# 「work/bbb」ディレクトリを作成
$ mkdir ~/work/tanuki
Linuxのディレクトリ構成Linuxのディレクトリ構成(構造)とは?Windowsフォルダとの違いを覚える! Linuxコマンドとオプションこれで完璧!Linux基本コマンドとオプションの使い方【一覧あり】

Gitコマンド一覧と使い方(初心者向け)

ここからは、Gitの基本的なコマンドの使い方を体系的に解説していきます。

上から順番に実行していくことで、何をしているのかイメージしやすくなっています。

実際に手を動かしながら理解していくほうが身につきやすいので、ぜひやってみてください!

もちろん、コマンド一覧として使ってもらってもいいですよ。

init(イニット)とは

「git init」とは、リポジトリを作成するためのコマンドです。

ローカルリポジトリ、リモートリポジトリをそれぞれ作ることができますが、リモートはGitHubなどのサービスを利用することがほとんどなので、ここではローカルリポジトリを作成することにします。

以下に「引数なし」、「引数あり」のコマンドパターンを紹介していますが、どちらでも好きなほうを実行してください。

もし、すでにコミットされた状態のリモートリポジトリがある場合は、「init」ではなく「clone」を使いましょう。「clone」を参照

リポジトリを作成
# バージョン管理するプロジェクトを作成
$ mkdir ~/work/kitsune/training
$ cd ~/work/kitsune/training

# カレントディレクトリにローカルリポジトリを作成(引数なし)
$ git init
Initialized empty Git repository in /home/vagrant/work/kitsune/training/.git/

# 指定したディレクトリにローカルリポジトリを作成(引数あり)
$ git init ~/work/kitsune/training
Initialized empty Git repository in /home/vagrant/work/kitsune/training/.git/

status(ステータス)とは

「git status」とは、ワーキングディレクトリやインデックスの状態を確認するためのコマンドです。

ほかのGitコマンドとあわせて、「git status」を実行する癖をつけることで、ほかのコマンドの動きを理解しやすくなるので頻繁に使っていきましょう。

以下は、ローカルリポジトリにまだ何もコミットをしていない状態です。

現在の状態を確認
# 現在の状態を確認
$ git status
# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)

「git status」で状態を確認する癖をつけよう!

add(アド)とは

「git add」とは、コミット対象ファイルをインデックスに登録するためのコマンドです。

「profile.md」ファイルを作成し、インデックスに登録してみましょう。

インデックスに登録
# 「# I am kitsune」という文字列を「profile.md」に記述
$ echo "# I am kitsune" >> profile.md

# 現在の状態を確認
$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#       profile.md
nothing added to commit but untracked files present (use "git add" to track)

# 「profile.md」をインデックスに登録
$ git add profile.md

# 「profile.md」がインデックスに登録されたことを確認
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached ..." to unstage)
#
#       new file:   profile.md
#

「new file」としてインデックスに登録されたのがわかるね!

commit(コミット)とは

「git commit」とは、インデックスにあるファイルの変更内容を「コミット」するためのコマンドです。

コミットとは、ファイルの変更内容を「リビジョン」としてローカルリポジトリに残すこと

コミットする際には、必ず変更内容などを記述した「コミットメッセージ」を添えて実行する必要があります。

「-m」オプションは、「message」の略です。

コミット
# コミットメッセージ「Add キツネのプロフィール」をつけてコミット
$ git commit -m "Add キツネのプロフィール"
[master (root-commit) d66e548] Add キツネのプロフィール
 1 file changed, 1 insertion(+)
 create mode 100644 profile.md

# リポジトリとワーキングディレクトリの差分がないことを確認
$ git status
# On branch master
nothing to commit, working directory clean

log(ログ)とは

「git log」とは、リポジトリにあるリビジョンを確認するためのコマンドです。

以下の内容がリビジョンとして表示されます。

  • リビジョン番号(英数字のハッシュ値)
  • コミットしたユーザー名<メールアドレス>
  • コミットした日時
  • コミットメッセージ

さきほどコミットした内容が、正しく反映されているか確認してみましょう。

リビジョンを確認
# リビジョンを確認
$ git log
commit d66e548a69956f9c5a06d5e2ea16bbd4592ae6f5
Author: kitsune <example@example.com>
Date:   Fri May 3 05:07:55 2019 +0000

    Add キツネのプロフィール

最新リビジョンが1番上にくるよ!

remote(リモート)とは

「git remote」とは、ローカルリポジトリで指定するリモートリポジトリの追加や削除をおこなうためのコマンドです。

ここでは、事前に準備したGitHubのリモートリポジトリを「origin(オリジン)」という名前で紐づけます。

このコマンドは、リモートリポジトリを追加したいときだけ実行するコマンドなので、頻繁には使いません。

リモートリポジトリを設定
# GitHubのリポジトリをリモートリポジトリに設定
$ git remote add origin https://github.com/(ここに自分のアカウント名)/(ここにリポジトリ名).git

「origin」がGitHubのリモートリポジトリをあらわすように設定したんだね!

push(プッシュ)とは

「git push」とは、ローカルリポジトリの内容をリモートリポジトリに反映させるためのコマンドです。

もう少し具体的に説明すると、「ローカルの現在のブランチ」を「リモートの指定したブランチ」に反映させるためにプッシュします。

ブランチはデフォルトで「master」ブランチになっているはずなので、そのままリモートの「master」ブランチにプッシュしてみましょう。

「-u」をつけることで、ローカルのブランチとリモートのブランチを紐づけ、次回から「git push」だけで実行可能になります。

コマンド実行時にGitHubのアカウント名とパスワードを求められるので、間違えないように気をつけて入力しましょう。

プッシュが終わったら、GitHubの自分のリポジトリを確認してみてください。リビジョンが追加されているはずです。

リモートリポジトリにプッシュ
# リモートリポジトリ(origin)に「master」ブランチの情報をプッシュ(今回はスキップ)
$ git push origin master

# 次回から「git push」でリモートリポジトリにプッシュ(おすすめ)
$ git push -u origin master
Username for 'https://github.com': kitaaaa-kitsune
Password for 'https://kitaaaa-kitsune@github.com':
Counting objects: 3, done.
Writing objects: 100% (3/3), 260 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/kitaaaa-kitsune/training.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

入力したパスワードは画面に表示されないから注意してね!

branch(ブランチ)とは

「git branch」とは、ブランチの確認や作成、削除などをおこなうためのコマンドです。

ブランチの操作
# ブランチを確認
$ git branch
* master

# 現在のブランチをコピーして新しいブランチを作成
$ git branch develop
$ git branch test

# ブランチを確認(「*」は現在のブランチ)
$ git branch
  develop
* master
  test

# ブランチの削除
$ git branch -D develop
Deleted branch develop (was d66e548).

# ブランチを確認
$ git branch
* master
  test

# 「-a」オプションでリモートブランチも含めて確認
$ git branch -a
* master
  test
  remotes/origin/master

diff(ディフ)とは

「git diff」とは、「ワーキングディレクトリ」と「インデックス」の差分を表示するためのコマンドです。

差分があった場合は、対象行の先頭に「+」「-」などの記号が表示されます。

指定するオプションや引数によって動きが変わりますが、ここではシンプルなパターンを紹介します。

ファイルの差分を確認
# インデックスとワーキングディレクトリの差分を表示(差分なし)
$ git diff

# ファイルを書き換える
$ echo "僕はキツネだよ!" >> profile.md

# ファイルが編集されていることを確認
$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#       modified:   profile.md
#
no changes added to commit (use "git add" and/or "git commit -a")

# 指定したファイルの差分を表示(差分あり)
$ git diff profile.md
diff --git a/profile.md b/profile.md
index 06b3a76..90abc22 100644
--- a/profile.md
+++ b/profile.md
@@ -1 +1,2 @@
 # I am kitsune
+僕はキツネだよ!

追加された行の頭に「+」がついてるね!

reset(リセット)とは

「git reset」とは、コミットやインデックス登録をリセットするためのコマンドです。

ここでは、インデックスに登録したファイルをリセット(登録前に戻す)しています。

インデックス登録をリセット
# 「profile.md」をインデックスに登録
$ git add profile.md

# インデックスに登録されていることを確認
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#       modified:   profile.md
#

# 「profile.md」をリセット
$ git reset profile.md
Unstaged changes after reset:
M       profile.md

# 元に戻ったことを確認
$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#       modified:   profile.md
#
no changes added to commit (use "git add" and/or "git commit -a")

checkout(チェックアウト)とは

「git checkout」とは、ワーキングディレクトリを特定の状態に変更するためのコマンドです。

チェックアウトできる対象はこれらです。

  • ファイル
  • コミット
  • ブランチ

非常によく使うコマンドなので、それぞれ紹介します。

ファイルのチェックアウト

「git checkout file」で、ファイルを最新リビジョンと同じ状態に戻します。

「ファイル編集しちゃったけど、前の状態に戻したいな」ってときですね。

ファイルを管理状態に戻す
# ファイルに変更が加えられていることを確認
$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#       modified:   profile.md
#
no changes added to commit (use "git add" and/or "git commit -a")

# ファイルを最新リビジョンと同じ状態にする(編集をなかったことにする)
$ git checkout profile.md

# ファイルに変更が加えられていないことを確認
$ git status
# On branch master
nothing to commit, working directory clean

コミットのチェックアウト

「git checkout revision_number」で、指定したリビジョンのブランチを作成します。

このブランチには名前がなく、ほかのブランチに切り替えると自動的に消滅します。

指定したリビジョンのブランチを作成
# リビジョンを確認
$ git log
commit d66e548a69956f9c5a06d5e2ea16bbd4592ae6f5
Author: kitsune <example@example.com>
Date:   Fri May 3 05:07:55 2019 +0000

    Add キツネのプロフィール

# 指定したリビジョンの無名ブランチに切り替える
$ git checkout d66e548a69956f9c5a06d5e2ea16bbd4592ae6f5
Note: checking out 'd66e548a69956f9c5a06d5e2ea16bbd4592ae6f5'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at d66e548... Add キツネのプロフィール

# 無名ブランチができたことを確認(一時的に生成されたブランチ)
$ git branch
* (detached from d66e548)
  master
  test

# 無名ブランチのリビジョンを確認
$ git log
commit d66e548a69956f9c5a06d5e2ea16bbd4592ae6f5
Author: kitsune <example@example.com>
Date:   Fri May 3 05:07:55 2019 +0000

    Add キツネのプロフィール

ブランチのチェックアウト

「git checkout branch」で、指定したブランチに切り替えます。

「-b」オプションをつけることで、現在のブランチをコピーした「新しいブランチの作成」と「切り替え」を同時におこないます。

ブランチの切り替え
# 「develop」ブランチを作成すると同時に切り替える
$ git checkout -b develop
Switched to a new branch 'develop'

# 無名ブランチが消え、「develop」ブランチに切り替わっていることを確認
$ git branch
* develop
  master
  test

# 「test」ブランチに切り替える
$ git checkout test
Switched to branch 'test'

# ブランチを確認
$ git branch
  develop
  master
* test

clone(クローン)とは

「git clone」とは、リモートリポジトリをローカルリポジトリに複製(コピー)するためのコマンドです。

  • 「git init」…新しくリポジトリを作りたい場合
  • 「git clone」…すでにあるリポジトリを複製して使いたい場合

実際の業務では、「git init」よりも「git clone」コマンドの使用頻度が高いです。

「git init」を一度も実行しないことだって普通にあるよ!

ここでは、「tanuki」ディレクトリに移動してクローンしています。

リモートリポジトリを複製
# 「tanuki」ディレクトリに移動
$ cd ~/work/tanuki

# クローンする
$ git clone https://github.com/kitaaaa-kitsune/training
Cloning into 'training'...
Username for 'https://github.com': kitaaaa-kitsune
Password for 'https://kitaaaa-kitsune@github.com':
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.

# 「training」ディレクトリに移動
$ cd training

# ブランチは「master」のみ
$ git branch
* master

# ログも同じ
$ git log
commit d66e548a69956f9c5a06d5e2ea16bbd4592ae6f5
Author: kitsune <example@example.com>
Date:   Fri May 3 05:07:55 2019 +0000

    Add キツネのプロフィール

fetch(フェッチ)とは

「git fetch」とは、リモートリポジトリの情報をローカルリポジトリに反映するためのコマンドです。

あくまで、更新情報を持ってくるだけなので、ワーキングディレクトリのファイルは何も変わりません。

そのため、パッと見て何が変わったのかわからない方も多いと思ので、確認方法とあわせて紹介します。

  1. タヌキ側でファイルを編集しプッシュ(準備)
  2. キツネ側でフェッチ(実行)

フェッチの準備

フェッチするための準備をします。

ファイルを更新してプッシュしておきましょう。

フェッチするための準備
# 現在のディレクトリを確認
$ pwd
/home/vagrant/work/tanuki/training

# 「profile.md」を編集
$ echo "僕はタヌキだよ!" >> profile.md

# インデックスに追加
$ git add profile.md

# コミット
$ git commit -m "Add タヌキのプロフィール"
[master e117b19] Add タヌキのプロフィール
 1 file changed, 1 insertion(+)

# リビジョンを確認
$ git log
commit e117b19b72fe587cc5025e7e8b91ee35a277b70a
Author: kitsune <example@example.com>
Date:   Fri May 3 20:12:52 2019 +0000

    Add タヌキのプロフィール

commit d66e548a69956f9c5a06d5e2ea16bbd4592ae6f5
Author: kitsune <example@example.com>
Date:   Fri May 3 05:07:55 2019 +0000

    Add キツネのプロフィール

# リモートにプッシュ
$ git push -u origin master
Username for 'https://github.com': kitaaaa-kitsune
Password for 'https://kitaaaa-kitsune@github.com':
Counting objects: 5, done.
Writing objects: 100% (3/3), 322 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: This repository moved. Please use the new location:
remote:   https://github.com/kitaaaa-kitsune/training.git
To https://github.com/kitaaaa-kitsune/training
   d66e548..e117b19  master -> master
Branch master set up to track remote branch master from origin.

フェッチの実行

フェッチすることで、リモートブランチの情報が最新の状態になります。

フェッチされたことを確認するため、リモートブランチと現在のワーキングディレクトリとの差分をチェックしています。

フェッチを実行
# フェッチするディレクトリに移動
$ cd ~/work/kitsune/training

# 「master」ブランチに切り替える
$ git checkout master

# フェッチしたリモートブランチとの差分を確認(差分なし)
$ git diff origin/master

# フェッチ
$ git fetch

# フェッチしたリモートブランチとの差分を確認
$ git diff origin/master
diff --git a/profile.md b/profile.md
index 72ab616..06b3a76 100644
--- a/profile.md
+++ b/profile.md
@@ -1,2 +1 @@
 # I am kitsune
-僕はタヌキだよ!

フェッチでリモートブランチが更新されたことで、ローカルブランチとの差分が出たね!

merge(マージ)とは

「git merge」とは、特定のブランチやリビジョンを、現在のブランチに取り込むためのコマンドです。

今回はフェッチしてきたリモートブランチ「origin/master」をローカルブランチ「master」に取り込んでみましょう。

ちなみに、マージするとコンフリクト(衝突)が発生するケースもありますが、ここではコンフリクトせずにマージできるはずです。

リモートブランチをローカルブランチに取り込む
# 現在のディレクトリを確認
$ pwd
/home/vagrant/work/kitsune/training

# 現在のリビジョンを確認
$ git log
commit d66e548a69956f9c5a06d5e2ea16bbd4592ae6f5
Author: kitsune <example@example.com>
Date:   Fri May 3 05:07:55 2019 +0000

    Add キツネのプロフィール

# 現在のブランチにリモートブランチ「origin/master」を取り込む
$ git merge origin/master
Updating d66e548..e117b19
Fast-forward
 profile.md | 1 +
 1 file changed, 1 insertion(+)

# リビジョンが追加されていることを確認
$ git log
commit e117b19b72fe587cc5025e7e8b91ee35a277b70a
Author: kitsune <example@example.com>
Date:   Fri May 3 20:12:52 2019 +0000

    Add タヌキのプロフィール

commit d66e548a69956f9c5a06d5e2ea16bbd4592ae6f5
Author: kitsune <example@example.com>
Date:   Fri May 3 05:07:55 2019 +0000

    Add キツネのプロフィール

rebase(リベース)とは

「git rebase」とは、マージと同じように、ほかのブランチのリビジョンを取り込むコマンドです。

マージと違うところは、取り込んだブランチがベースとなり、自ブランチの差分リビジョンをうしろに付け替えるところです。

この付け替え(リベース)によって、対象となったリビジョンの番号も新しくなります。

また、マージ同様に2つのブランチで同じファイルを変更していた場合、コンフリクトが発生する可能性があります。

ただ、ここで紹介するのはコンフリクトが発生しないパターンでのリベースになります。

リベースの準備

ここでは、「master」ブランチと「develop」ブランチのリビジョンを、あえて異なる状態にさせます。

リビジョンの異なるブランチを取り込んだとき、リベースがどのような動きをするのか確認するためです。

リベースの準備
# 現在のディレクトリを確認
$ pwd
/home/vagrant/work/kitsune/training

# 現在のブランチを確認
$ git branch
  develop
* master
  test

# 「master」ブランチのリビジョンを確認
$ git log
commit e117b19b72fe587cc5025e7e8b91ee35a277b70a
Author: kitsune <example@example.com>
Date:   Fri May 3 20:12:52 2019 +0000

    Add タヌキのプロフィール

commit d66e548a69956f9c5a06d5e2ea16bbd4592ae6f5
Author: kitsune <example@example.com>
Date:   Fri May 3 05:07:55 2019 +0000

    Add キツネのプロフィール

# 「develop」ブランチに切り替え
$ git checkout develop
Switched to branch 'develop'

# 「develop」ブランチのリビジョンを確認
$ git log
commit d66e548a69956f9c5a06d5e2ea16bbd4592ae6f5
Author: kitsune <example@example.com>
Date:   Fri May 3 05:07:55 2019 +0000

    Add キツネのプロフィール

# 「develop」ブランチに新規ファイルをコミットし、リビジョンを確認
$ echo "リベースさせたいファイルだよ!" >> target.md
$ git add target.md
$ git commit -m "Add リベース用ファイル"
[develop bbce334] Add リベース用ファイル
 1 file changed, 1 insertion(+)
 create mode 100644 target.md
$ git log
commit bbce334dc749be2d99c6480bfef07b21e1106895
Author: kitsune <example@example.com>
Date:   Sat May 4 06:32:45 2019 +0000

    Add リベース用ファイル

commit d66e548a69956f9c5a06d5e2ea16bbd4592ae6f5
Author: kitsune <example@example.com>
Date:   Fri May 3 05:07:55 2019 +0000

    Add キツネのプロフィール

リベースの実行

「master」ブランチと「develop」ブランチの準備ができたので、リベースしてみましょう。

リベースを実行
# 「develop」ブランチにいることを確認
$ git branch
* develop
  master
  test

# リベース前のリビジョンを確認
$ git log
commit bbce334dc749be2d99c6480bfef07b21e1106895
Author: kitsune <example@example.com>
Date:   Sat May 4 06:32:45 2019 +0000

    Add リベース用ファイル

commit d66e548a69956f9c5a06d5e2ea16bbd4592ae6f5
Author: kitsune <example@example.com>
Date:   Fri May 3 05:07:55 2019 +0000

    Add キツネのプロフィール

# リベースで「master」ブランチを取り込む
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: Add リベース用ファイル

# リベース後のリビジョンを確認
$ git log
commit 0ba40c30a60de846d50e57a6dd9f08129a53f20b
Author: kitsune <example@example.com>
Date:   Sat May 4 06:32:45 2019 +0000

    Add リベース用ファイル

commit e117b19b72fe587cc5025e7e8b91ee35a277b70a
Author: kitsune <example@example.com>
Date:   Fri May 3 20:12:52 2019 +0000

    Add タヌキのプロフィール

commit d66e548a69956f9c5a06d5e2ea16bbd4592ae6f5
Author: kitsune <example@example.com>
Date:   Fri May 3 05:07:55 2019 +0000

    Add キツネのプロフィール

ここでは、「develop」ブランチに「master」ブランチを取り込んでいます。

取り込んだ「master」ブランチのリビジョンをベースとして、「develop」ブランチとの差分である「リベース用ファイル」のリビジョンをうしろに付け替えています。

リビジョン番号も

「bbce334dc749be2d99c6480bfef07b21e1106895」から

「0ba40c30a60de846d50e57a6dd9f08129a53f20b」に書き変わっているのがわかりますね。

リベースとマージの違い

「マージとリベースのどちらを使うべきか?」ですが、基本は「リベース」を使いましょう。

もし、ここでリベースではなくマージをしていた場合、「マージした」という情報を残すための「マージリビジョン」が余計に生成されてしまいます。

このマージリビジョンはGit管理を複雑にさせるため、あまり好まれていません。

そのため、いまはマージよりもリベースを使うほうが一般的です。

マージリビジョンが気になる方は、さきほどの手順を「git merge」に置き換えて試してみてください。

ここまで読んだあなたなら、自分の力だけで再現できるはずです!頑張りましょう!

pull(プル)とは

「git pull」とは、「git fetch」と「git merge」の2つをまとめて実行するコマンドです。

わざわざコマンドを分ける必要がないときは、「git pull」コマンドを利用しちゃいましょう。

また、「--rebase」オプションを使うことで、「merge」の代わりに「rebase」を実行することができます。

ここではコマンドのパターンだけ紹介します。

プルのパターン
# 「git fetch」と「git merge」を実行(リモートを省略)
$ git pull

# 「git fetch」と「git merge」を実行(リモートを指定)
$ git pull origin master

# 「git fetch」と「git rebase」を実行(リモートを省略)
$ git pull --rebase

# 「git fetch」と「git rebase」を実行(リモートを指定)
$ git pull --rebase origin master

まとめ:Gitがわからないなら勉強法を変えてみよう!

とっても長い解説になりましたが、Gitの知識は深まりましたか?

Gitは奥が深く、ここで紹介したコマンドも一部に過ぎません。

実際に使ってみない限り、Gitはなかなか覚えられないので、まずは自分で動かしてみることが大切です。

「書いてあることが難し過ぎてわからない!」という方は、前提知識が足りていない可能性があります。

独学にこだわって投げ出すくらいなら、プログラミングスクールに通って講師に質問するなど、勉強法を変えてみることも大切です。

またね、キツネ(@kitaaaa_kitsune)でした!

【エンジニア講師が比較】プログラミングスクールのおすすめと選び方【エンジニア講師が比較】プログラミングスクールのおすすめと選び方 【Git入門】基本操作からコマンドの使い方までの学習ステップ【Git入門】基本操作やコマンドの使い方を勉強しよう【学習】
テキストのコピーはできません。