Git初学者のための、よく噛み砕いた、でもちょこっと詳しい「Git」&「GitHub」 ローカル操作編

目次 閉じる

はじめに

ソフトウェア開発のために誕生したGitは、その利便性の高さから瞬く間に全世界に普及し、今やエンジニアにとっては習得が欠かせないスキルとなっています。

ただ、画面への英字入力を主とする「コマンドライン」をベースにした、初心者にとっては少々難易度の高い操作性や、そもそも実際の活用場面が共同開発の現場であるということもあり、プログラミング初学者にとってはやや馴染みが薄く、またとっつきにくさを感じる存在であるというのが、Gitに抱く初めの印象ではないでしょうか。

ですが、多くのプログラミング言語やプログラミングにまつわる知識がそうであるように、その最初の難関を突破すれば、あとは実際に触り利便性を実感しながら知識や技術を習得していくことができます。

今回はそんな「Gitってなに?」段階のGit初学者の方が、初手でつまずくことなくスムーズに学習に入っていくことができるよう、Gitの入門の入門という位置づけでこの記事を作成しました。

特に、今回本記事で扱う「ローカル上(お手元のPC)でのGitの操作」は基本にしてGit操作の礎(いしずえ)でもあるため、ここの理解をおろそかにしてしまうと今後の学習に大きく支障を来してしまう部分でもある重要な部分です。そのためなるべく平坦な言葉で、なるべく分かりやすく説明することを心がけました。

今回の記事を読みながら実際に手を動かし学習を進めていくことで、Gitという便利なシステムのローカル上での操作について、ざっと全体像は掴むことができると思います。

ぜひ、最後までお付き合いいただけましたら幸いです。

Gitについて

さて、みなさんはそもそも、Git(ギット)という名前を耳にしたことがあるでしょうか?

GitHub(ギットハブ)があまりに有名なため、そちらの名前は聞いたことがあるいらっしゃるかもしれませんね。

けれどもGitGitHubはそもそも同一のものを指しているわけではありません。GitHubの略語がGitであるわけではないのです

ではそのGitとはそもそも何なのか、まずはそこから説明をしていきましょう。

Gitとは?

Git(ギット)は、ファイルなどの変更履歴を記録したり、ある時点まで遡ったり、また遡るだけでなく過去の状態に戻したりができる「バージョン管理」を行うためのシステム(仕組み)ですGitのようなバージョンを管理を行うシステムのことを「バージョン管理システム(Version Control System)」と総称したりもします。

バージョン管理システムはGitのほかにもいくつも種類がありますが、現在もっとも利用されているのが今回学んでいくGitです。

ではまずこの「バージョン管理」および「バージョン管理システム」について、まずは詳しく確認していくことにしましょう。

「バージョン管理システム」とは?

たとえば社会人の方なら、参加した会議の議事録や記録を取ったことが一度はあるかと思います。

また会議の記録のみならず、会議で使用するパワーポイント資料や進めているプロジェクトの計画書など、多くの記録や資料は一度で完成することは稀で、大体のものは推敲やチェックなどを重ね、たくさんの変更を経て完成に至りますよね。

同様のことがソフトウェア開発の現場でも行われています。

ソフトウェアを開発するためのソースコードなどのドキュメントや、たとえば編集した画像、また音楽なども含むの多くの電子ファイルは何度も手を加えられ、加筆や修正などの編集を経てようやく完成をします。

その編集の過程である「履歴」をファイルへの変更を行うたびに記録し保存しておくことで、何度変更を加えたファイルであっても過去の状態や変更内容を確認したり、以前の状態を復元したりすることが可能となります。

また変更の履歴があると「誰がいつ加えた変更なのか」を記録から辿ることもでき、振り返りもとても容易になります。

このファイルなどが最初に作成されてから何回変更や更新などがされたかを識別するための表記を、バージョンと呼びます。バージョンを更新することは「バージョンアップ」などとも呼ばれており、馴染み深い言葉のひとつでもありますね。

そうした「(変更の履歴などを識別する)バージョンを管理をするシステム」がGitなどの「バージョン管理システム」なのです。

なおバージョン管理システムにおける履歴の保管はあくまでも履歴のデータ保管であるため、ファイル本体をコピーし、そのコピーを削除しないように気をつけていくつも保管して、もし誤って削除してしまったファイルがあればゴミ箱から探して……という煩雑な作業も必要ありません。

バージョン管理システムの基本的かつ重要な機能のひとつが、システム名の由来ともいえるこの「ファイルの変更内容や履歴の保管」であるわけです。

ほかにも「バージョン管理システム」を利用することで大きな恩恵を受ける場面があります。それが複数人でのソフトウェアなどの開発現場です。

開発の現場においては、ファイルなどの編集作業を複数人で同時並行におこなう場合も多々発生します。そうした際に問題となってくるのが作業の重複や衝突です。

何人もの人がいくつものファイルを各々編集すると、それぞれのファイルの最新の状態がどれであるか分からなくなってしまったり、また同じファイルに対する変更が噛み合わない状況が発生するなどの問題が生じやすくなってしまいます。

バージョン管理システムはこのような開発上の問題を解決する仕組みも提供しているため、いまや開発の現場では欠かせないシステムとなっているのです。

バージョン管理システムの種類

バージョン管理システムはGitの他にもいくつもの種類があります。下記には代表的なものをピックアップしていくつかご紹介しています。

システム名モデル特徴
RCS(Revision Control System)ローカル初期のバージョン管理システムの1つ。プログラムや文書などの頻繁に改版されるテキストの管理に使用される。能率や機能は限定的だが、2進数データであるバイナリファイルのバージョンも管理が可能。
CVS(Concurrent Version System)集中1990年代に開発された、バージョン管理システムの元祖。その後に登場するSVNやGitに大きな影響を与えたが、いくつかの欠陥があり、最終的にはCSVの欠陥を補完しているSVNやGitに取って代われることとなった。現在は開発も終了している。
SVN(Apache Subversion集中現在も利用されているバージョン管理システム。CVSの問題点を解決すべく開発された。クライアントサーバ型(中央集中型)のため、専用のサーバが必要になり導入に手間やお金がかかる。
Azure DevOps Server集中かつてマイクロソフトが開発し販売していた小規模なソフトウェア開発プロジェクト向けのバージョン管理システムであるMicrosoft Visual SourceSafe (VSS) の後継。
Mercurial(マーキュリアル)分散Gitとほぼ同時期にLinuxを開発するために開発がされた、ソフトウェア開発者向けの分散型バージョン管理システム(Linuxの開発には最終的にはGitが採用された)。Microsoft Windows、FreeBSD、MacOS、Linux等の Unix 系システムでサポートされている。Gitよりも小さいサイズで管理ができるなどの利点はあるものの、利用者も少なく現状は汎用性がさほど高くない。
主なバージョン管理システムの種類

上の表で「モデル」と記載してある部分は、バージョン管理システムの管理手法を指しています。バージョン管理システムの管理手法には大きく分けて次の3つの種類があります。

  1. ローカルバージョン管理システム(Local Version Control System)
  2. 集中バージョン管理システム(Centralized Version Control System)
  3. 分散バージョン管理システム(Distributed Version Control System)

それぞれの特徴も併せてざっとご紹介していきますね。

ローカルバージョン管理システム(Local Version Control System)

ファイルやプロジェクトのバージョン管理を、個々の開発者のローカル環境(コンピュータ)で行うシステムです。
ファイルの変更履歴を記録し、過去のバージョンとの比較・復元が可能です。
個別の作業環境に対応しており、各開発者が自分のローカルなリポジトリで変更を管理します。
複数人での協力作業やリモートでの共有が容易ではないため、小規模なプロジェクトや個人のプロジェクト向けです。

集中バージョン管理システム(Centralized Version Control System)

ファイルやプロジェクトのバージョン管理を中央のバージョン管理システムサーバー(Central VCS Server)で行うシステムです。
開発者は中央にて保管している「バージョンデータベース(Version DataBase)」という保管場所(リポジトリ)から編集するファイルを取得(チェックアウト)して作業をし、変更を終えたら再度「バージョンデータベース(Version DataBase)」に保存(コミット)します。
中央にあるバージョンデータベースを介して全ての開発者が協力作業を行い、最新のファイルを共有する仕組みです。
ファイルの変更履歴や過去のバージョンは、すべて中央の「バージョンデータベース」と保管場所に集中して保存されます。

分散バージョン管理システム(Distributed Version Control System)

ファイルやプロジェクトのバージョン管理を個々の開発者のローカル環境(コンピュータ)で行い、各開発者が完全な「バージョンデータベース」という保管場所(リポジトリ)を持ちます。
開発者は自身のローカル環境にある保管場所(リポジトリ)にアクセスして作業をし、変更もローカル環境に保存(コミット)します。その後、必要な時点でスーパーコンピューター(Super Computer)などにあるリモートのバージョンデータベースと同期(プッシュやプル)して共有します。
リモートリポジトリは通常複数存在し、それらを同期させることで、分散したチームでも柔軟に協力作業が行えます
オフライン作業や柔軟なブランチ戦略が可能で、大規模なプロジェクトや分散した開発チーム向けに適しています

ローカルのバージョン管理システムはシンプルな構造のためさほど理解に苦しむことはないと思いますが、「集中バージョン管理システム」と「分散バージョン管理システム」の違いについては、下記画像でも改めて確認いただけると、より理解が深まるかと思います。

なお、これまでにバージョン管理システムの説明の際に、「リポジトリ」「チェックアウト」「コミット」など耳慣れない用語がいくつも出てきたかと思います。こうしたGitに関する用語は、後ほどまとめて詳しく説明します。

Gitの特徴

Git(ギット)とは、先ほどご紹介した「CVS」や「SVN」の欠点を補いより使いやすく開発された、分散バージョン管理システムの代表格ともいえるものです。

GitはもともとはLinuxというOS(Operating System)のソースコードの管理に用いる目的で、Linuxの開発者であるリーナス・トーバルズ(Linus Torvalds)氏によって2005年に開発されたのがはじまりでした。

Linuxの開発には多くの人が関わっていたため、その多くの人々が同時に作業を行っても不具合なく、そして高速にバージョンができるという目的を持ってGitは開発されたのでした。

またGitが広がった1つのきっかけとして、GitHub(ギットハブ)の存在も欠かすことはできません。

GitHubはGitの仕組みを利用しインターネット上でのスムーズな共同作業を可能にした、ソフトウェア開発のWebプラットフォームです。

GitHub日本語サイト

GitHubでは、ソースコードをインターネット上に公開することで複数人のソフトウェア開発者と協働してコードをレビューしたり、プロジェクトを管理しつつ開発を行うことができます

また他ユーザと簡単にコミュニケーションが取れる仕組みやプロジェクト管理に便利な機能などもあり、誰でもどこからでも効率的に開発が行えるという利点から、現在では広く普及したサービスです。また2023年にはユーザ数1億人も突破したことから、今ではもっともポピュラーなGitホスティングサービスとなりました。

Gitの用語とその概念を学ぶ

Gitの基本操作に移っていく前に、Gitの用語について学んでおきましょう。

バージョン管理システムおよびGitでは、一般的に浸透している名称とは異なる用語が使用されていたり、聞き慣れない言葉が聞き慣れない概念とともに使用されていたりします。

そうした、いわゆる専門用語を先に理解しておくかどうかでGitの理解の難易度も変わってきますので、ぜひ下記一覧をご覧になり、それぞれの用語の意味を軽くでもいいので把握しておいてください。

一度にすべてを覚える必要はありませんので、不安になったり「あれ?」と思ったタイミングでまたここに立ち戻るようにすると、学習も進めやすくなるかと思います。

なお、バージョン管理システムでは同じ言葉で少し違う意味を指すものもありますが、以下でご説明しているのはあくまでも「Git」における用語の意味であることに留意してください。

用語説明
コミット(Commit)ファイルやコードの変更履歴をリポジトリに記録する操作のことを指します
コミットはファイルの変更をスナップショットとして記録し、それにメッセージ(コミットメッセージ)を付けた形でリポジトリに保存されます。
コミットによりファイルの変更履歴が永続的に保存され、過去のバージョンに戻ったり、ある時点の変更内容を確認できるなどの特定の時点でのプロジェクトの状態を完全に再現することが可能になるのです。
リポジトリ(Repository)「保管庫」「貯蔵庫」「倉庫」などといった意味のある言葉です。
Gitではファイルやプロジェクトの変更履歴を管理するデータベースのことを指しています。リポジトリにはファイルの変更履歴やブランチ情報など過去の状態を記録することができます。
手元のパソコン内のリポジトリを「ローカルリポジトリ」、中央のサーバーや外部のホスティングサービス上にあるリポジトリのことを「リモートリポジトリ」といいます。
このリモートリポジトリでの代表格が先ほどご紹介したGiHubです。
(なお余談ですが、「ホスティングサービス」とはウェブサイトやアプリケーションなどのデータやファイルをインターネット上に公開・保存するためのサービスを提供プロバイダーのことです)
ワーキングツリー(Working tree)ワーキングツリー」は別名「ワークスペース」「ワーキングディレクトリ」「作業ディレクトリ」などと呼ばれることもありますが、すべて同一の概念を指しています。
全体的に「稼働中の場所」や「作業中の場所」「作業しているディレクトリ(フォルダ)」などといった意味を持つ言葉たちですが、実際には一般的なディレクトリ(フォルダ)・使用中のディレクトリ(フォルダ)のことをGitではワーキングツリーと呼んでいます。
スナップショット(Snapshot)スナップショットは、特定の時点でのファイルやプロジェクトの全体像のことを指しています
Gitではファイルの変更履歴をスナップショットとして記録します。
ブランチ(Branch)英語では「」という意味の言葉です。「」という言葉のとおり、プロジェクトの変更履歴を分岐させるための機能です。メインのコードラインから派生した、独立したラインでの開発を可能にします。
特にソフトウェアやWebの開発などは、このブランチ機能を効果的に多用して開発を進めます。リリース(公開)しているバージョンから派生させたブランチで新機能などを追加し、問題がなければリリースしている旧版に新版を統合し、最新版という形で再リリースをしたりします。
新しいブランチを作成することで、元のコードから変更を行っても元のブランチに影響を与えることなく別の作業を進めることができます。
マージ(Merge)マージは、異なるブランチで行われた変更を1つのブランチに統合する操作のことです。マージは日本語では「統合」「合併」「併合」などの意味を持ちます。
異なるブランチで並行して開発を進める際に、それぞれのブランチで行われた変更を最終的にはマージして、1つの統合されたコードにまとめることが目的です。
プッシュ(Push)プッシュは、ローカルリポジトリ(開発者のコンピュータ上のリポジトリ)で行った変更をリモートリポジトリ(中央のサーバーやホスティングサービス上のリポジトリ)に反映させる操作を指します。ローカルで行ったコミット(変更の記録)をリモートリポジトリに送信することで、他の開発者と変更を共有することができます。
プル(Pull)プルは、リモートリポジトリの変更をローカルリポジトリに取り込む操作を指します。プルを行うことで、ローカルリポジトリが最新の変更内容を反映し、最新の状態で作業を続きから継続することができます。
チーム全体が同じリモートリポジトリを共有している場合、プルを定期的に行うことで他の開発者が行った変更を取り込むことができ、コードの一貫性を保つことが可能になります。プルとプッシュを組み合わせることで、バージョン管理や共同作業をスムーズに行うことができるのです。
コンフリクト(Conflict)コンフリクトは、複数のブランチで同じファイルの同じ箇所に変更が行われた場合に発生する矛盾状態のことを指しています。「競合」「衝突」などの意味があります。
同一ファイル内で別の変更を加えてしまった場合などにGitが自動的に変更を統合できず、手動で解決する必要がある状態のことをコンフリクトと呼んでいます。
ステージング(Staging)ステージングは、変更したファイルをコミットする前に、コミット対象となる変更内容を一時的に準備・選択する作業のことを指します。
コミットする部分をステージ上に押し上げるイメージです。
ステージングをすることで、ステージ上に上がった変更内容のみをコミットしていくことができ、記録する範囲をユーザが細かく指定することが可能になります。
プルリクエスト(Pull Request)プルリクエストは、コードの変更を他の開発者にレビューしてもらうためのメカニズムです。主にオープンソースプロジェクトやチームでの共同作業に利用されます。
リモートリポジトリで行われた変更を他の開発者に通知し、内容をチェックした上で統合を依頼する機能です。
Gitにおける用語群

他にもいくつも専門用語はあるうえに本記事内では取り扱わない用語もありますが、まずは上記内容をざっと把握しておくとよいでしょう。

ではここからは上記専門用語の内容や仕組み、使い方などをより詳しく見ていくことにしましょう。

「コミット」の概要

Gitでは変更の履歴を、管理の対象となっているすべてのファイルのその時点での「状態」として保存し記録していきます。

この「状態」として記録していくことを「スナップショット」といいますが、この点がGitの最大の強みでもあります。

変更を加えたファイルのみならず、管理の対象となっているファイルすべての「状態」をまるごと記録することができるため、過去の状態を完全に復元することが可能なうえ、コミット単位で「状態」へ自由に行き来することができます。

この保存する操作のことを「コミットする」といい、その記録自体も「コミット」と呼びます。

そしてこのコミットを連続して保存していくことでファイルの変更履歴を管理していく、というのが、Gitの基本的な仕組みです。

また「コミット」の際には、ファイルのそのときの状態だけでなく、変更を加えたユーザ情報や変更日時・時刻も併せて記録されます。よって、いつ」「誰が」「何の」変更を加えたかを誰もが振り返ることができ、透明性の高い履歴管理が可能となっています

コミットの「粒度」

これまでご説明してきたコミットの頻度に関しては、変更を加えた場合に常に行わなければいけないというわけではなく、通常「キリの良いところ」で行っていくのが一般的なやり方です。たとえば「ボタンのデザインを変更した」「ヘルプのページを作成した」などといった具合に、ユーザの実行によって行われます。決して自動的に行われるものではありません。

こうした「どの程度のどの頻度でコミットをするか」というコミットの単位(区切り)のことを「コミットの粒度などとも呼びますが、「いつ」「どのようなタイミングで」コミットをするかは、取り扱っているプロジェクトの内容や扱うファイルの種類、変更履歴を振り返る頻度などを目安に適宜判断していくものです。時と場合などによって理想とするコミットのタイミングは異なってくるため、明確な基準というものは特にありません。

たとえばひとりで開発を進めている方は自分が振り返りたいと考えるタイミングでコミットを行っていくでしょうし、他のメンバーと共同で開発に取り組んでいる方にとっては、そのメンバーが履歴を追いやすい単位でコミットを行っていくことが重要になってきます。

複数のファイルを一気にコミットする場合は手間を省くなどの利便性の観点からではなく、どのコミットの粒度でバージョンを更新していくと後々(戻したい時や振り返りたい時に)楽になるか」を第一に考え、作業を行っていくのが良いでしょう

最初の頃はこの「コミットの粒度」をどうするか悩ましく感じられることもあるかもしれませんが、Gitを使い慣れてくる頃には、意味を持ったまとまりや便利に扱いやすい粒度でのコミットが自然とできるようになってくるはずです。

リポジトリの概要

先ほどご説明したコミット」を記録・保管していく場所が「リポジトリです。

リポジトリ(Repository)」という英単語自体が「貯蔵庫」「保管庫」などの意味を持っています。この「貯蔵庫」には過去の”状態”を記録することができます。

過去の状態を記録しておくことで、たとえば「今はCの状態だけど、やっぱり1つ前のBの状態まで戻したいな」というときにすぐにその”状態”を貯蔵庫であるリポジトリから引き出すことができるのです。

「リポジトリ」を用意する手段は2つ。「新規で新しいものを作成」をするか、「すでにあるリポジトリをコピー(コピーをGitの用語では「クローン」と呼びます)」するかのいずれかです。

「ローカルリポジトリ」と「リモートリポジトリ」

ローカル(お手元のPC)上での「リポジトリ」は、いわゆるフォルダのことを指しています

たとえばあるフォルダをGitで管理すると決めた場合は、基本的にそのフォルダのなかにあるすべてのファイルやフォルダがGitでの管理の対象と認識されます(フォルダのなかにまたフォルダが存在する場合は、そのフォルダの中身もすべてです)。

Gitで管理すると宣言するコマンドは「git init」というコマンドなのですが、この一文をGitの管理対象としたいフォルダ上で打ち込むことで、フォルダの中身に「.git」という名前の隠しフォルダが作成されます。これが「ローカルリポジトリ」の実体です(コマンドについての詳しい説明は後ほど)。

たとえば上の画像では、「practice1」というフォルダの中に「.git」という隠しフォルダが存在することが見て取れます。うっすらと半透明になっているフォルダは、通常は可視できない隠しフォルダであるという証です。

(隠しフォルダや隠しファイルはcommand+shift+.を同時に押すことで表示モードに切り替えることができます。非表示モードへの切り替えも、同様です)

ただし、Gitの管理下にあるファイルをすべて一度にコミットしなければいけないというわけではありません。コミットをして記録するファイルは、ユーザ側がどれにするか自分で選ぶことができます。選択していないファイルまで記録されてしまっては、不便なうえに不都合や不具合が生じる場合もありますからね。

対して「リモートリポジトリ」とは、インターネット上など外部に存在するリポジトリのことを指しています。作業する人々がソースコードなどを共有する場所として、サーバー上に配備されるのが一般的です。

前述のGitHubも、この「リモートリポジトリ」を提供しているサービスのひとつです。

そしてこの手元の「ローカルリポジトリ」と、外部の「リモートリポジトリ」を行き来しながら開発をすることが、一般的な共同開発の流れとなります。

手元の「ローカルリポジトリ」で開発をしたソースコードなどを、GitHub上にある「リモートリポジトリ」に反映させ、また別のメンバーがそのソースコードなどを自分の「ローカルリポジトリ」に取得するなどして作業を行っていくスタイルが、GitとGitHubを使用した共同開発のスタンダードです。

「3つ」+「1つ」のエリア概念

こうした基本的な開発の流れを、Gitの用語を確認しながら整理してみていきましょう。

まず「ローカルリポジトリ」にコミットを行いファイルの状態を保存するには「ワーキングツリー(またはワーキングディレクトリ or ワークスペース)」「ステージングエリア(またはステージ or インデックス)」「ローカルリポジトリ(またはGitディレクトリ)」と呼ばれる3つのスペースを使用します。

表記に「または」などの記載がありはっきりしないのは、説明によって場所の呼称に少々ゆらぎがあるためですが、たとえば「ステージングエリア」と「ステージ」と「インデックス」は同じ場所を指しているため、こうした言葉が出てきても「あぁ、あのスペースのことだな」と分かることが重要です。

ワーキングツリー」で編集を加えたファイルは、「コミット」をするためにまずは「ステージングエリア」にステージし準備をします。その後、「ローカルリポジトリ」へ「コミット」をすることで、変更が記録されます。

ただし変更が記録されたのはあくまで「ローカルリポジトリ」のため、この状態では自分以外のメンバーが変更の内容を知ることはできません。

そのため「リモートリポジトリ」に変更を反映することで、共同で開発をしている他メンバーもファイルに加えた変更を確認することができ、その情報をもとにまた新たな開発などに着手することができるのです。

なおこの「ローカルリポジトリ」は前述の通り、インターネット上など外部にあるリポジトリです。本記事では主に「GitHub」のことを指して説明を進めていきます。

ローカルリポジトリでの操作

では1つ前の章でご説明した「ワーキングツリー」「ステージングエリア」「ローカルリポジトリ」の具体的な役割や、そこで起きていることなどをより詳しく確認していくことにしましょう。

まず、編集を開始した時点で作業の基点となるのが「ワーキングツリー」です。以前にもご紹介しましたが、この「ワーキングツリー」の呼び方は複数あり、媒体や教材によっては「ワークツリー」「ワーキングディレクトリ」「作業ディレクトリ」「ワークスペース」などと呼んでいるものもありますが、いずれも呼び方が異なるだけで、実際は本記事での「ワーキングツリー」部分を指しています。

新規ファイルを作成した場合、この「ワーキングツリー」内に新規ファイルは生まれますが、はじめはGitに追跡はされていない「untracked」の状態です。まだ一度もコミットをされたことがないためにGitの管理下にはなく、Gitが管理対象としていないという状態を示しています。

上の画像内には、すでにGitの管理下に置かれているファイルも2つ存在していますね。

このファイルのなかの1つ、「unmodified(変更されていない)」ファイルは前回のコミット以降なんの変更も加えられていないもので、「modified(変更済み)」ファイルは前回のコミット以降に何らかの変更が加えられたファイルである、ということを示しています。

つまり、新規作成したファイルは作成直後は「untracked(追跡されていない)」状態、そして以前にコミットしたファイルにコミット以降なんの変更も加えていないものは「modified(変更済み)」状態、コミット以降に変更を加えたものは「modified(変更済み)」となります。

一見すると判別のつかないファイルの「状態」にも種類があり、ワーキングツリー内には多くて三種類の状態のファイルが混在することがある、ということをここではご説明しました。

続いて、「ワーキングツリー」内の「untracked(追跡されていない)」状態のファイルと「modified(変更済み)」状態のファイルが「ステージングエリア」とどのように関わるかを説明していきます。

ワーキングツリー」で編集したファイルをコミットする前に、まずは「ステージングエリア」にステージングする作業が必要であることは『「3つ」+「1つ」のエリア概念』でもご説明しましたね。

編集変更済み」のファイルをadd gitというコマンドで「ワーキングツリー」から「ステージングエリア」にステージングすることでコミットの準備が整い、そこではじめて「コミット」ができるというのがGitのコミットまでの流れでした。

また、新規作成したあとに一度もコミットしていないファイルはまだ「untracked(追跡されていない)」状態ですが、このファイルをGitの管理下に置きたい場合も、「ステージングエリア」への追加を行うことでGitの管理下に置くことが可能になります。

ステージングエリア」に追加したファイルは「staged(ステージングエリアに追加済み)」状態と変化し、あとはコミットされるのを待つのみとなります。

ステージングエリア」に追加され「staged(ステージングエリアに追加済み)」状態になったファイルは、その後「コミット」を待っていると説明しました。「コミット」は、「staged」されるまでの変更を記録する行為ですが、実際に「コミット」後は、「リモートリポジトリ」に「コミット」されたデータがスナップショット形式で格納されていきます。

そして「コミット」された「staged」ファイルは、コミット後に「unmodified(変更されていない)」状態に変わります。

そうしてまた変更が加えられるまで、ワーキングツリー内でつまりGitの管理下で追跡もされているけれど「unmodified(変更されていない)」状態、となるわけです。

こうしてコミットを繰り返すことで、ファイルの状態も「unmodified(変更されていない)」→「modified(変更済み)」→「staged(ステージングエリアに追加済み)」→コミット後にはまた「unmodified(変更されていない)」とサイクルを繰り返していくことになるのです。

リモートリポジトリの操作

ローカルリポジトリ」に格納した内容は、ユーザの任意のタイミングで「リモートリポジトリ」へ反映をさせることができます。また「リモートリポジトリ」に格納されているデータも、いつでも自分の「ローカルリポジトリ」に取り込むことが可能です。

こうして「ローカルリポジトリ」から「リモートリポジトリ」に変更したデータを反映したり、「リモートリポジトリ」から変更したデータを取り込んだりしながら開発を進めていくことが、チームでの共同開発の一般的な流れとなります。

開発の環境を整える

【macOS】Gitをインストールする

ではここからは、実際にmacOSでGitを使用するための環境構築方法を説明していきます。なお本記事では以降もmacOSでの作業や解説を前提として進めていきます。

事前準備

Gitの環境構築をする前に、必要なツールの確認をしましょう。

Gitをローカル環境で開発するために、macOSでは「ターミナル」を使用していきます。

ターミナル」は標準でインストールされているソフトですので、実際に「ターミナル」を起動してみましょう。

1.

まずcommand(⌘)キーとスペースバーを同時に押すと、左画像のようなSpotlightウィンドウが開きます。

2.

このウィンドウに「たーみなる」と入力すると、目的の「ターミナル」アプリケーションが表示されますので、クリックして開きましょう。

3.

すると左のような画面が表示されるかと思います。このウィンドウが「ターミナル」です。

なお環境によっては表示されている文字や背景色などは変わりますので、ご注意ください。

今後「ターミナル」と言った場合は、この黒い画面に「コマンド」と呼ばれる文字列等を入力していくものと考えてください。

ターミナルについて

ターミナル」の起動後、まずはお手持ちのパソコンにGitがインストールされているかどうかを確認してみましょう。

…と、その前に、まずは「ターミナル」そのものについて軽くご説明をしておきます。

ターミナル」はコマンドラインと呼ばれるインターフェースです。

インターフェースとは、異なるソフトウェアやシステムが情報や機能を共有するための方法や仕組みのことを指しています

これだけではまだ分かりにくいと思いますが、たとえば人がコンピュータを操作するには、使う側であるユーザの意思を何らかの手段でコンピュータに伝えなければなりません。

例に挙げるとすれば、スマホやタブレットPCは画面を指でなぞって操作を行いますし、パソコンではマウスやトラックパッドを使用しウィンドウやアイコンをクリックしたり、ドラッグしたりします。

これらは視覚的かつ直感的で、多くの人にとっては敷居が低く簡単な操作方法です。こうした、使い手の視覚に訴えるやり方を、グラフィカルユーザーインターフェース(Graphical User Interface)、略してGUIと呼んだりします。

そうしたGUIと対照に位置するのが「ターミナル」に代表されるコマンドラインインターフェース(Command Line Interface)、略してCLIと呼ばれるものです。

CLIは主にキーボードから打ち込んだ文字列をコンピュータへの指示や命令として入力し操作する方法です。この命令の文字列のことを「コマンドライン」、コンピュータへ出す指示や命令のことを「コマンド」と呼びます。またCLIではコマンドを入力したあとの結果も、文字列として表示されます。

この動きそのものが「ターミナル」の操作時の動きとなります。

また下画像もターミナルの操作画面をイメージしやすくしたものです。

上画像の[zomy@localhost~]$の部分はコマンドプロンプトといいます。コマンド受付の準備が整い、「ターミナル」がユーザからのコマンドの入力を待ち受けていることを示す文字列です。

この「コマンドプロンプト」が表示されていない場合は、入力したコマンド(PCなどへの実行命令)が実行中であるため、実行が終わるまではもう少し待ってね、というサインでもあります

また実際にユーザである皆さんが打ち込む部分は「コマンド」と書かれている短い文字列部分です。

ただ、「コマンド」という短い文字列は画面に入力しただけでは「実行」処理は行われません。そのためコマンドを実行するために続けてエンターキーを押すと、画像のように「出力結果」が出力された、という図になっているわけです。

では「ターミナル」の挙動についても軽く理解ができたところで、ここからは実際に、お手持ちのパソコンにGitがインストールされているかどうかを確認していくことにしましょう。

Gitのバージョン確認

まず「ターミナル」画面に以下のコマンドを打ち、Enterキーで実行していきましょう。

なお$はコマンドプロンプトの最後尾部分ですので、実際に入力する必要はありません。ターミナル」画面には$以降の文字列のみを入力していくようにしてください。これは今後も同様です。

$ git␣--version

または半角のスペースキーを空ける、という印です。部分には何も打ち込まず、半角スペースで文字と文字の間を空けるようにしてください

Enterキーで実行したあと以下のようにGitのバージョン番号が表示されるようであれば、すでにGitはインストール済みであるため、Gitを使用することが可能ということになります。

もしGitのバージョン情報が表示されなかった場合、もしくは「インストールが必要」などのメッセージとともにポップアップウィンドウが表示された場合は、お手元のパソコンにGitのインストールがまだされていないということですので、これから一緒にインストールを行っていきましょう!

Gitのインストール

1.

まずGitの公式ホームページを開き、青枠で囲まれた「Downloads」をクリックしましょう。

2.

続いて使用しているOSを選びます。今回はmacOSにおけるダウンロード手順を説明していますので、「macOS」をクリックしてください。

3.

次に「Binary installer」の「installer」部分をクリック。

4.

するとインストーラーのダウンロードページに移動しますので、「Download」ボタンをクリックし、インストーラーをダウンロードしていきましょう。

5.

ダウンロードしたdmgファイルをダブルクリックで開きます。

6.

続いてpkgファイルをダブルクリックすると、ダウンロードが開始します。

zomy
zomy

もしここで「セキュリティに関する警告」として、pkgファイルが「開発元が未確認のため開けません。」というメッセージが表示されてしまった場合は、controlキーを押しながらpkgファイルを再度クリックし、表示されたメニューの「開く」をクリックすると、開封できるようになるはずです。

7.

するとインストール開始のウィンドウが表示されますので、「続ける」をクリック。

8.

続けて、画面に沿って「インストール」もクリックしましょう。

9.

しばらく待っているとインストールが完了しますので、あとは「閉じる」ボタンをクリックすればOKです。

これで無事にGitのインストールを行うことができました。

Gitの初期設定

Gitの設定をする場合はgit configというコマンドを使用します。

git configコマンドでは、3つのレベルの設定を管理することができます。

  1. システムレベル:システム全体の設定を管理します。システムの全ユーザーに適用されます。--systemオプションを使用して設定できます。
  2. ユーザレベル:個々のユーザに関連付けられた設定を管理します。ユーザごとに異なる設定ができます。--globalオプションを使用して設定できます。
  3. リポジトリレベル:特定のリポジトリに関連付けられた設定を管理します。そのリポジトリ内でのみ適用されます。何もオプションを指定せずに設定できます。

今回はユーザレベルである--globalオプションを一緒に使い、設定をしていきます。

ユーザ名とメールアドレスの登録

まずはユーザ名とメールアドレスの登録です。この2つの情報を登録しておくことで、コミット時に情報として一緒に記録され、だれがコミットをしたのか振り返ることができるようになります。

共同開発を行う計画が今現在はなくても、将来的に可能性がある場合は必ず登録をしておくことにしましょう。

また、ここで登録したユーザ名とメールアドレスはリモートリポジトリのアカウントとも紐づけられることが多いため、公開しても問題のないメールアドレスを登録するように気をつけましょう。

1.

まずは「ホームディレクトリ」へ移動します。

画面のように、赤枠で囲んだコマンドプロンプト部分に~(チルダ)が表示されていれば、現在地が「ホームディレクトリ」であるということを示しています。

ですが、もし現在地が「ホームディレクトリ」になっていない方は、以下のようにコマンドを入力し実行してください。

$ cd␣~

cd部分は「change directory」を意味するcdコマンドです。~(チルダ)は先ほどご説明した通り、「ホームディレクトリ」を示しています。

つまり、現在地を「ホームディレクトリに移動する」、という指示をターミナルに出したということです。

2.

では最初にユーザ名を登録していきましょう。

ユーザ名を登録する際には以下のようにコマンドを入力します。

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

ユーザ名の部分には左画像のようにご自身のユーザ名を置き換えて入力してください。

コマンドを入力したあとにEnterキーを実行することで設定完了です。

3.

続いてメールアドレスを設定します。

メールアドレスを登録する際には以下のようにコマンドを入力します。

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

メールアドレスの部分にはご自身のアドレスを置き換えてご入力ください。

4.

これまでの設定を確認するには、git configコマンドに--listオプションをつけて、設定項目を一覧表示します。

先ほど登録したユーザ名とアドレスはuser.nameuser.emailの値を確認することでチェックできます。

左の画像ではユーザ名とアドレスが確かに設定されていることが確認できますね。

テキストエディタの準備

他の事前準備としましては、ファイルの編集などに使用するテキストエディタの用意があります。

このテキストエディタについては多様な種類のものが出回っておりますし、それぞれ使いやすいものをお使いいただければと思いますが、もしテキストエディタを使用したことがないという方がいらっしゃれば、ここでインストールをしておいてください。

本記事では「Visual Studio Code|ヴィジュアル スタジオ コード」というテキストエディタ(以降VScodeと表記します)を使用していきますので、同じものをご使用になられたい方は以下の記事をご参考にするなどして、ご自身のパソコンへインストールしていただくようにお願いします。

基本的コマンドの確認

Gitを操作する前にまず、基本的なコマンドをいくつかご紹介しておきます。

Git専用のコマンドではありませんが、「ターミナル」を代表するようなコマンドラインインターフェースを通じてコンピュータに指示を出す際に使用される、Unix系オペレーティングシステムの代表的なコマンドです。

Unix系オペレーティングシステムとは、Linuxをはじめとした「Unixオペレーティングシステム(OS)」の基本的な特性や概念を受け継いでいるオペレーティングシステムの一群を指す用語ですが、ここでは詳しくは述べません。

とにかくここでは「ターミナルを操作する際には覚えておいたほうがいいんだな〜」との理解で十分です。

Unix系OSの基本コマンド

コマンド働き
pwd現在自分が位置している「カレントディレクトリ」の絶対パスを表示します。
lsカレントディレクトリ内のファイルやディレクトリの一覧を表示します。
cd現在地である「カレントディレクトリ」を移動します。
mkdirディレクトリ(ファイル)を新規で作成します。
touch新しいファイルを作成するか、既存のファイルの更新日時を変更するために使用されるコマンドです。
cat一般的にはファイルの中身を表示するために使用されます。
rmファイルやディレクトリを削除するために使用されます。
基本的なコマンド

なお、上記以外のコマンドの働きに関してや他の便利なコマンド、そしてディレクトリに関する詳細については、下記記事でもご説明をしています。

特に「ディレクトリ構造」や「パス」についての詳しい説明は本記事では省きますので、その辺りの知識にご不安がある方は一度上記記事を事前にお目通しいただくと、Gitの操作もよりスムーズに行うことができるためオススメです。

Gitの基本コマンドを学ぶ

実際に「ターミナル」を使用してGitの基本操作を学んでいく前に、基本的なGitコマンドを事前にざっと確認しておきましょう。

Gitの基本コマンド

コマンド主な働き詳細
git initリポジトリの作成ローカルリポジトリを作成する
git addコミットの作成ステージングエリアに変更をステージングする
git commitコミットの作成コミットを作成する
git rmコミットの作成Gitの管理下にあるファイルやディレクトリを削除する
git tagタグの作成特定のコミットなどにタグを付加する
git checkout状態の復元ワーキングツリーの変更を取り消す
git restore状態の復元ワーキングツリーもしくはステージングエリアの変更を取り消す
git reset状態の復元ステージングエリアに追加した変更をワーキングツリーに戻す
git status状態の確認ローカルリポジトリの状態を確認する
git diff状態の確認各エリアの差分を確認する
git log状態の確認コミットの履歴を確認する
git show状態の確認特定のコミットや特定のタグのの内容を確認する
基本的なGitコマンドの一覧

結構な数があるように思えるかもしれませんが、ひとつひとつの役割や働き・動きなどを確認しながら操作していくことで、理解しながらGitコマンドを使用できるようになると思いますので、ぜひ手を動かしながら覚えていきましょう。

ファイルをバージョン管理する

ターミナルを使用する前に

ターミナル」には、一度使用したコマンドを再度使用したい場合に履歴を呼び出すことで入力の手間を省くことができます。この機能を利用することで打ち間違いなども防ぐことができる、シンプルながら使い勝手のいい機能ですので、事前にご紹介しておきます。

プロンプトが表示されコマンド入力の受付待ちの状態で、キーボードの上矢印キーを押しましょう。そうすると、直前に入力したコマンドを呼び出すことができます。

呼び出したコマンドを実行したい場合は、通常時同様Enterキーを押して実行ができますし、もし呼び出したコマンドの内容を修正したい場合は、キーやキーなどで修正したい箇所へ移動し、Deleteキーで削除ののち入力、などを行って編集しながら使用していきましょう。

また画面に何度もコマンドを入力するため、途中で画面上が散らかり見にくくなることもあるかもしれません。

その場合はclearと入力することで、表示範囲の画面を一掃できますので、こちらも適宜使用してみてください。

ディレクトリを新規に作成する|mkdir

まず、練習用に使用するディレクトリ(フォルダ)を新規に作成するところから始めていきましょう。

1.

まずご自身の好きなディレクトリへ移動をします。

今回私の場合はデスクトップに新規ディレクトリを作成したいため、下記のようにコマンドを入力し、元々いた「ホームディレクトリ」から「デスクトップディレクトリ」へ移動をしました。

$ cd␣~/Desktop

コマンドを入力し実行するためにEnterキーを押すと、赤線を引いたとおり、「デスクトップディレクトリ」へ移動をしたことが、コマンドプロンプトの表示で分かりますね。

2.

続いて、練習用の新しいディレクトリ(フォルダ)「git-practice」を新規に作成します。

ディレクトリを新規に作成する場合は、「make directory」を意味するmkdirコマンドを使用します。

$ mkdir␣git-practice

Enterキーを押し実行すると、特になにも表示はされていませんがエラーはでていないため、新規ディレクトリの作成に成功したはずです。

3.

では実際に「git-practice」ディレクトリが作成されたかどうかlsコマンドで確認をしてみましょう。

lsコマンドは「list」の略で、現在地である「カレントディレクトリ」内のファイルやディレクトリの一覧を表示することができます。

実行してみると、たしかに「git-practice」ディレクトリが新規に作成されていることが確認できました。

これまで行った内容を図解すると、以下の図のようになることがわかりますね。

作業ディレクトリを移動する|cd

1-1.

では作成した「git-practice」内で作業をしていきたいので、「change directory」を意味するcdコマンドで「git-practice」ディレクトリへ移動をしていきましょう。

$ cd␣git-practice
1-2.

なおターミナルには補完機能が備わっており、ディレクトリ名である「git-practice」を打つ際、「git-」くらいまで打ったあとにTabキーを押すことで補完候補が表示され、残りのディレクトリ名である「practice」部分を自動で補完してくれます。

こうした便利機能を効果的に利用して、入力ミスをなるべく防いでいくといいでしょう。

2-1.

さて、作業用ディレクトリである「git-practice」に移動することはできましたが、この段階ではまだ「ディレクトリ(フォルダ)」は、データの貯蔵庫である「リポジトリ」にはなっていません。

試しにgit statusコマンドで現状を確認してみましょう。

git statusコマンドは、Gitバージョン管理システムで使用されるコマンドの一つで、リポジトリ内の変更状態を確認するために使います。

実行してみると、やはり正しく動作しないことがわかります。これはディレクトリ(フォルダ)がまだリポジトリになっていないことが原因です。

なお表示されているメッセージの内容は以下のとおりです。

  • On branch master:現在のブランチが「master」ブランチであることを示しています。
  • No commits yet:まだコミットが行われていないことを示しています。リポジトリにはまだコミットが存在せず、新しい変更もコミットされていない状態です。
  • Untracked files:ワーキングツリーには存在するものの、Gitがまだ追跡していないファイル(Untracked files)が表示されています。これらのファイルは、まだコミットされていない変更です。
  • use "git add <file>..." to include in what will be committed:コミット対象としてファイルを追加するには、git addというコマンドを使用するよう促すメッセージが表示されています。

ローカルリポジトリの作成|git init

ではいよいよリローカルポジトリの作成に入っていきましょう。

Gitでファイルを管理する際には、最初に「リポジトリ(保管庫)」を作成する必要があります。通常フォルダのままではGitでファイル管理することはできません。

そして通常フォルダを「リポジトリ」と変化させる際に使用するコマンドがgit initコマンドです。

上の図のように、git initコマンドを実行する前と後では、同一のフォルダであるものの、フォルダの中に「ローカルリポジトリ」が自動的に追加される仕組みになっています。

では早速、git initコマンドを実行し、ローカルリポジトリを作成していきましょう。

1.

現在作業中のワーキングディレクトリをリポジトリに指定するには、下記のコマンドを入力・実行します。

$ git␣init

git initコマンドの「init」は英語の「initialize(初期化)」の略で、言葉のとおりディレクトリの初期化と、これからこのディレクトリをGitで管理をするという宣言を行うことができます。

2.

すると、左の画像のようなメッセージが表示されました。

詳しく説明すると、「Initialized empty Git repository」は「初期化が成功し、Gitリポジトリが作成された」ことを示している一文です。

これでgit initコマンドの実行が成功し、「git-practice」ディレクトリがGitの管理下に置かれたことがわかりました。

3.

また念のためlsコマンドに-aオプションをつけてコマンドを実行してみましょう。

lsコマンドを実行すると、ディレクトリ内のファイルやディレクトリの一覧を表示することができるのでしたね。

くわえて、-aオプションをつけることで、通常時は不可視となっている隠しファイルもすべて表示することができます。

実行すると「.git」ディレクトリの存在を確認することができました。

Gitではこの「.git」ディレクトリの中にファイルの履歴やバックアップなどを保管していくことで、バージョン管理を行っています。

つまり、この「.git」ディレクトリが存在することは、「git-practice」ディレクトリがGitで管理できるようになったという証でもあるのです。

zomy
zomy

git initコマンドを実行すると自動的に作成される「.git」ディレクトリの中には、Gitのバージョン管理に関わる重要な設定ファイルやリポジトリなどが含まれてているため、削除しないように気をつけましょう。

新規ファイルの作成|touch

せっかくリポジトリの作成が完了しましたので、「git-practice」ディレクトリのなかに新しいファイルを作ってみましょう。

1.

新しいファイルを作成するにはtouchというコマンドを使用します。

$ touch␣index.html

上記コマンドを実行すると「index.html」というファイルが作成されることになります。

2.

では実際に「git-practice」ディレクトリのなかに「index.html」というファイルが作られたかどうか確認してみることにしましょう。

$ ls

下記のように実行したところ、「git-practice」ディレクトリのなかに無事に「index.html」ファイルが作成されていることが確認できました。

3.

ファイルの中身にも内容を記載しておきましょう。

VSCodeを起動し、「git-practice」ディレクトリから「index.html」を開いたら、以下のように内容を記入します。

<h1>indexファイルを作成しました</h1>

入力が完了したらCtrl+sキーを押して保存をしてください。

ファイルをステージングする|git add

ではいよいよ、編集したファイルをステージングエリアにステージングしていきましょう。

ファイルをステージングエリアにステージングする場合に使用するコマンドはgit addコマンドです。

このステージングエリアに追加されたファイルがコミットされていくということはすでにご説明したかと思います。

では実践していきましょう。

1-1.

まずはgit statusコマンドで現在の状況を確認してみましょう。

$ git␣status

実行後に表示されたメッセージは以下のとおりです。

1-2.
  • On branch main:現在のブランチがmainブランチであることを示しています。
  • No commits yet:まだコミットが行われていないことを意味します。リポジトリにはコミットが存在せず、新しい変更がコミットされていない状態です。
  • Untracked files:ステージングエリアに含まれていないファイル(index.html)が存在しています。つまり、このファイルの変更はコミットされておらず、Gitの追跡対象になっていません。
  • nothing added to commit but untracked files present (use "git add" to track): コミット対象の変更がなく、かつ追跡対象でないファイルが存在するため、新しいコミットが行われていないというメッセージです。

index.html」は先ほど作成したばかりのため、まだステージングもコミットもされていないことが確認できました。

2.

では「index.html」をステージングしていきましょう。

ステージングにはgit addコマンドを使用します。

$ git␣add␣index.html

上記コマンドを実行することによって、「index.html」をステージングすることができます。

3-1.

では再度git statusコマンドを実行し、現状を再確認してみましょう。

$ git␣status

すると左の画像のとおりメッセージが表示されました。

メッセージは「index.html」ファイルが無事ステージングされたことを示しています。

一部は省略しますが、大まかな内容は以下のとおりです。

3-2.
  • On branch main: 現在のブランチがmainブランチであることを示しています。
  • No commits yet: まだコミットが行われていないことを意味します。リポジトリにはコミットが存在せず、新しい変更がコミットされていない状態です。
  • Changes to be committed 〜: ステージングエリアにindex.htmlという新しいファイルが新規に追加されていることを示しています。

以上のとおり、「index.html」ファイルのステージングまで行うことができました。

ファイルの差分確認|git diff

Gitのリポジトリ内で行われた変更の差分を表示するために使用されるコマンドがgit diffコマンドです。このコマンドでは特定のコミット間や、「ステージングエリア」と「ワーキングディレクトリ」との間の変更を比較することができます。

git diffコマンドでは一緒に使用するオプションによってさまざまな差分を確認することができますが、今回は代表的な2つの使用方法について学んでいきましょう。

ファイルの差分確認方法の1つ目は「ステージングエリア」と「ワーキングツリー」の内の変更を比較しその差分を確認する方法です。

1.

では変更の差分を確認する事前準備として、「index.html」ファイルの中身に以下の文章を追記していきましょう。

<p>git␣diffで差分を確認</p>

この追記を行うことで、ステージングエリアにステージングしてある状態と現在のワーキングツリーの状態に変更した分の差分が生まれます。

2.

ではgit diffコマンドを実行し差分を表示させてみましょう。

なお、git diffdiffは「difference」の省略形です。

左画像①の先頭に「-」がついた赤字で、②の先頭に「+」ついた緑文字で内容が表示されています。

zomy
zomy

なお、実行結果を見てみると、今回変更していない「<h1>indexファイルを作成しました</h1>」の部分が赤字と緑文字で表示されていることが見て取れます。

これは「<h1>indexファイルを作成しました</h1>(改行なし)」だったものが削除され「<h1>indexファイルを作成しました</h1>(改行あり)」という変更を実行したと見なされたためです。

ファイルの差分確認|git diff –cached

ファイル差分確認方法2つ目は、「ステージングエリア」と「ローカルリポジトリ」の差分を確認する方法です。「ローカルリポジトリ」には直前に行われたコミットが登録されているため、厳密には「ステージングエリア」と「直前に行われたコミット」との間の変更の差分を確認する方法といえます。

3.

では前回の続きから進めていきましょう。

git diffコマンドに--cachedオプションをつけると、「ステージングエリア」と「ローカルリポジトリ」の内容(直前のコミット)との差分を確認できるのでしたね。

入力したコマンドは以下のとおりです。

$ git␣diff␣--cached

内容を確認してみると、前回「ステージングエリア」にステージングした内容だけが表示されていますね。

現在の「ワーキングツリー」での変更はまだステージングしていないため、今回の結果には表示されていないことが分かります。

このようにしてこまめに差分を確認しながらステージングやコミットを行っていくことで、意図しない変更を登録するミスを防ぐことができます。

コミットメッセージについて

コミット」を実践する前に、「コミットメッセージ」についても軽く触れておきます。

リポジトリにファイルの変更履歴を記録する行為を「コミット」というのでしたね。この「コミット(commit)」という言葉には、委託や委任、預けるといった意味があります。

コミット」を行う際には、一緒に「コミットメッセージ」も付けます。

コミットメッセージ」とは、コミット(変更の記録)に関する説明やコメントのことです。「コミットメッセージ」は、なぜ変更を行ったのか、どのような変更を行ったのか、変更の目的や背景などを記述することで、将来の自分や他の開発者がコードの変更履歴を理解しやすくするための重要な要素のひとつです。

コミットメッセージ」に関してはチームや開発現場によって運用のルールが設定されている場合もあります。たとえば「英語で簡潔に記述する」「タイトルと本文の間に行間を設け、計3行で記述する」などです。

この「コミットメッセージ」を入力する際、オプションを使用しないとVim(ヴィム)という少々特殊なエディタが立ち上がり、そのエディタを使用してメッセージを入力→保存する必要が生じます。

扱いに慣れている方にとっては支障になることはないと思いますが、Vimに触れたことがない方にとってはVimの操作が少しのハードルになったりもします。

そのため、本記事ではVimを立ち上げずに「コミットメッセージ」を入力することができる-mオプションを使用し、コマンドとともに「コミットメッセージ」を入力する手法をご紹介していきます。

なお、Vimについて詳しく知りたい方は、以下の記事で操作方法などをご紹介しておりますので、よろしければそちらもご活用ください。

ファイルをコミットする|git commit

次はいよいよステージングしたファイルをコミットしていきましょう。

コミットする際に使われるコマンドはgit commitです。

では早速実践していきましょう。

1.

ではまず、現在の状態をgit statusコマンドで確認してみましょう。

$ git␣status

すると、左の画像のように①と②が表示されました。

①は先ほどステージングをしたため、ステージングエリアに「index.html」ファイルが登録されていることを示しています。

②はワーキングツリーにある「index.html」ファイルに変更があることを示しています。先ほどgit diffコマンドを使用する際に「index.html」ファイルに追記をしたので、その変更のことを指していますね。

では①からまずはコミットをしていきましょう。

2.

まずはgit commitコマンドを入力します。

$ git␣commit

この際、ファイル名などを入力する必要はありません。

ではEnterを押してコマンドを実行していきましょう。

3-1.

すると自動的に「Vim」というエディタが起動します。

Vim」は起動してからすぐの状態では、文字の入力はできない「ノーマルモード」になっています。

そのため「挿入モード」にモードの切り替えをしてから文字入力を行う必要があります。

挿入モード」へは英字の「i」を押すことでモードが切り替わり、切り替わった証として画面下部に①のように「INSERT」の文字が表示されるようになります。これが「挿入モード」の状態です。

そこからは画面上部から文章が入力できるようになっているはずです。

今回は公式サイトでも推奨されている方式で、コミットメッセージの入力を行っていきます。

3-2.

公式サイトで推奨されている入力方法は、1行目に要約(コミットタイトル)、2行目は空欄、3行目以降にコミット内容の詳細を記述する方法です。

そのため、今回もその方式に倣って、画像内の②〜④の赤枠のようにメッセージを記述しました。

indexページを新規作成
Gitのコマンドをターミナルに入力しながら学習するためのindexページを新規作成した。

メッセージの入力を終えたら保存をして「Vim」を終了させるのですが、この際もいくつか「Vim」特有の手順があります。

3-3.

まず「INSERT(挿入)」モードから「ノーマルモード」へ切り替えるためにESCキーを押します。

するとカーソルがコミットメッセージの末尾から画面下部へ移りますので、変更内容を保存し終了したい場合は「: w q」の3文字を入力後、Enterキーで実行をしましょう。

すると「Vim」エディタは終了し、再度元の画面に切り替わるはずです。

では切り替わった画面の表示内容を確認していきましょう。

4-1.

するとコミットが無事に完了し、結果がコマンドラインに表示されています。

内容の詳細は以下のとおりです。

4-2.
  • [main (root-commit) 54cdf2a] indexページを新規作成:これは、新しいコミットがmainブランチに追加されたことを示しています。54cdf2aはコミットの識別子(ハッシュ値)であり、indexページを新規作成は先ほど入力したコミットメッセージのタイトルです。
  • 1 file changed, 1 insertion(+):この行は、今回のコミットが行われたファイルが1つで、そのファイルの変更の内訳は1行の追加(1 insertion)であることを示しています。
  • create mode 100644 index.html:これは、新しいファイル index.htmlがローカルリポジトリ内に追加されたことを示しています。create mode 100644はファイルのモードを示していて、ここでは通常のファイルとして作成されたことを意味しています。

要するに、git commitコマンドを使用して新しいコミットを作成したことと、そのコミットにはindex.htmlというファイルの変更(1行の追加)が含まれていることが画面上に示されているということです。

コマンドの最後の行がコマンドプロンプトに戻るため、新しいコミットが正常に作成されていることが読み取れます。

5.

では再度git statusコマンドで現状を再確認してみましょう。

すると、先ほどまで緑の文字で表示されていた「index.html」の表示はなくなっています。これは今回コミットを行ったためですね。

ほかにもう1つ、ステージングもしていないファイルがあると赤文字で表示されていた「index.html」はそのまま変わらずに表示されています。

では次回はこのファイルをステージングからコミットまで一気に行っていきましょう。

ファイルをコミットする|git commit -m

1.

まずは「index.html」ファイルのステージングからです。

$ git␣add␣index.html

コマンドを入力しEnterキーを押して実行していきましょう。

2.

ステージング後に再度git statusコマンドで状況を確認してみます。

すると、「index.html」ファイルが無事にステージングされたと表示されました。

3.

続いてコミットに移ります。

今回は「Vim」を立ち上げず、コマンドラインで完結するコミット方法について学んでいきます。

コミットを行う際はgit commitコマンドを使用するとすでにご説明しましたが、併せて-mオプションを使用することで、コマンドライン上に直接コミットメッセージを1行だけですが入力することができるようになります。

$ git␣commit␣-m␣'任意のコミットメッセージ'

そのため、今回は次のように入力します。

$ git␣commit␣-m␣'git diffについて追記'

上記コマンドの「git diffについて追記」の部分が、コミットメッセージに該当する部分です。

なお、今回はコミットメッセージをシングルクォーテーションで囲んでいますが、コミットメッセージをダブルクォーテーションで囲んでもかまいません。

ではコマンドを実行し「index.html」ファイルをコミットしていきましょう。

4-1.

すると左の画像のとおりコミットが無事に完了し、結果がコマンドラインに表示されています。

内容の詳細は以下のとおりです。

2-2.
  • [main 143d6dc] git diffについて追記:これは、新しいコミットがmainブランチに追加されたことを示しています。143d6dcはコミットの識別子(ハッシュ値)であり、git diffについて追記は先ほど入力したコミットメッセージのタイトルです。
  • 1 file changed, 2 insertions(+), 1 deletion(-): この行は、今回のコミットが行われたファイルが1つで、そのファイルの変更内容は2行の追加( 2 insertions)と1行の削除(1 deletion)であることを示しています。

要するに、git commitコマンドを使用して新しいコミットを作成したことと、そのコミットにはindex.htmlというファイルの変更(2行の追加と1行の削除)が含まれていることが画面上に示されているということです。

コマンドの最後の行がコマンドプロンプトに戻るため、新しいコミットが正常に作成されていることが読み取れます。

3-1.

ではコミットが成功した状態で、またgit statusコマンドを実行し、現状を確認してみましょう。

$ git␣status

すると、左画像のような結果がコマンドラインに表示されました。内容を簡単に説明しますと…

3-2.
  • On branch main: 現在のブランチがmainブランチであること。
  • nothing to commit: コミットする変更がないこと。
  • working tree clean: ワーキングツリー(作業ディレクトリ)はクリーンで変更がなく、ローカルリポジトリとワーキングツリーの状態が一致していること。

上記3点の内容を読み取ることができました。

編集が加えられていたすべてのファイルがコミットされたことにより、現在はワーキングツリーがクリーンな状態に保つことができています。

これでコミットは完了です。

zomy
zomy

今回は日本語でコミットのメッセージを入力しましたが、開発チームによっては英語で記載するルールであったり、コミットメッセージのタイトル(概要)を命令形で記述するよう取り決めているところもあるようです。

さて、ここまでを振り返ってみると、次のような手順でした。

  1. ファイルをステージングエリアにステージングする
  2. コミットメッセージの入力
  3. コミットの実行

Gitでのコミットの際には、必ずこの「ステージング」作業と「コミットメッセージの入力」作業という2つの作業が必要になります

このことをぜひ忘れずに、作業を進めていくようにしてください。

ファイルの削除|rm

さて、たとえばGitの管理下にあるファイルが不要となった場合はどのようにしたら良いでしょうか?

ここからはファイルの削除時に使用されるコマンドをご紹介していきます。

まずはrmコマンドです。

rmコマンドは先頭にgitとついていないことからもお分かりの通り、実はGitのコマンドではありません。

ですが、ファイルやディレクトリの削除をする際にコマンドラインで使用されるコマンドですので、ぜひここで使い方を覚えていきましょう。

rmコマンドは画像のとおり、ワーキングツリー内にあるファイルを削除することができます。

では早速使い方を見ていきましょう。

1.

まずは「index.html」ファイルの削除です。

rmコマンドを使用して削除する場合、コマンドの記述方法は以下のようになります。

$ rm␣index.html

ではEnterキーを押してコマンドを実行していきましょう。

なおrmは「削除」を意味する「remove」の略です。

2.

では削除ができているかlsコマンドで確認をしてみましょう。

$ ls

すると、コマンドを実行した後も何も表示されることなく、またコマンドプロンプトが表示されてしまいました。

これはディレクトリの中に表示できるものがないということを表しています。

つまり、「index.html」ファイルが削除できたというわけです。

変更の取り消し|git checkout

では例えば、たとえば今回の削除行為が勘違いによるミスだった場合はどうしたらいいでしょうか?

その場合はgit checkoutコマンドを使用することで解決できます。

git checkoutコマンドを使用することで、「ステージングエリア」から「ワーキングツリー」へファイルの情報を取り出すことができます。そして取り出した情報で情報を上書きする形となるため、結果として前回の「index.html」ファイルの削除行為を取り消したような形になるというわけです。

1.

まずgit statusコマンドで現状を確認してみましょう。

左の画像の内容を確認すると、「index.html」ファイルは削除されているものの、ステージングもコミットもされていない状態であることが読み取れます。

2.

ではここでgit checkoutコマンドを実行してみましょう。

git checkoutコマンドの使い方は以下のとおりです。

$ git␣checkout␣ファイル名orディレクトリ名

もしくは

$ git␣checkout␣--␣ファイル名orディレクトリ名

と指定します。

ファイル名」の部分に取り出したいファイルの名前を指定するか、もしくはすべてのファイルを変更前の状態に戻したい場合は「.」を使いすべてを指定していくこともできます。

今回は「index.html」ファイルを削除実行前の状態に戻したいため、以下のようにコマンドを入力し実行していきます。

$ git␣checkout␣index.html
3.

すると左画像のような結果がコマンドラインに表示されました。

出力された内容としては、git checkoutコマンドを使用したことによって「ワーキングディレクトリ」の状態が「ステージングエリア(インデックス)」の情報へと上書き更新され、削除した「index.html 」ファイルを復元したことを示しています。

4.

ではgit statusコマンドで現状を再度確認してみましょう。

先ほどgit statusコマンドを実行した際は「index.html 」ファイルが「ワーキングツリー」から削除されたことが赤文字で表示されていましたが、現在はコミットするべきファイルも見当たらず、「ワーキングツリー」もクリーンな状態であると表示されています。

これで「index.html 」ファイルの削除を実質的に取り消すことができました。

補足

ここでご紹介したgit checkoutコマンドは、変更の取り消しのためだけのコマンドというわけではありません

git checkoutコマンドは①「ブランチの切り替え」や②「タグの状態に切り替え」などの結果ももたらすコマンドですが、今回は③「特定のコミットの状態、もしくはステージングの状態に戻す」という働きを利用して、『ステージングエリアから「index.html」ファイルを呼び戻す』という作業を行いました。

そして$ git␣checkout␣--␣ファイル名orディレクトリ名とコマンドを記述する場合に、なぜファイル名などの前に--を記入しているのかという理由も、実はこのgit checkoutコマンドの用法にあります。

たとえばファイル名(もしくはディレクトリ名)と同一のブランチ名が存在した場合、ファイルとブランチのどちらを指しているのか分からなくなってしまう可能性があり、それを避けるためです。

つまり『これは「ファイルorディレクトリの状態」を呼び戻すための指示ですよ』とGitに知らせるために--を併用しているというわけです。

(ブランチについてはまたの機会にご説明予定です)

zomy
zomy

なお今回のような形でgit checkoutコマンドを使用する際、ステージングエリアにファイル状態が登録されたままになっていると、今回ご説明したような動作にならない場合があります。

そのため、ステージングエリアの状態に気にかけながらgit checkoutコマンドを使用していくとよいでしょう。

ファイルの削除とステージング|git rm

では続いて、Gitの削除コマンドを学んでいくことにしましょう。

先ほどご紹介したrmコマンドはGit専用のコマンドではなかったのですが、Gitにも専用の削除コマンドがあります。それがgit rmコマンドです。

git rmコマンドは「ワーキングツリー」に存在するファイルの削除をし、その上でファイルを削除したという状態を「ステージングエリア」にステージングする作業までを一挙に行ってくれる便利なコマンドです。

ですが、自動的に行ってくれるのはあくまでも「ステージングエリア」のステージングまでですので、ファイルを削除した状態はユーザ自身がコミットする必要があることは忘れないでください。

1-1.

ではまずgit statusコマンドで現在の状態を、lsコマンドで「git-practice」の中身をそれぞれ確認してみましょう。

$ git␣status
$ ls

すると、コミットすべきものは何もなく、またワーキングツリーもクリーンな状態であること、そして「index.html」ファイルが「git-practice」ディレクトリのなかにあることが確認できました。

2.

では「index.html」ファイルの削除に移っていきます。

今回使用する削除コマンドはgit rmです。

$ git␣rm␣index.html

上記のようにコマンドを入力・実行することで、「index.html」ファイルを「ワーキングディレクトリ」から削除し、そのうえで「ステージングエリア」へステージングまで行うことができます。

3.

コマンドラインの表示を確認してみると、「index.html」ファイルが「ワーキングツリー」から削除されたと表示されています。

ファイルの削除はこれで完了です。

4.

念のためlsコマンドでも、「index.html」ファイル削除がされているかどうか確認してみましょう。

$ ls

すると、コマンドを実行してもなにも表示がされませんでした。つまりここでも「index.html」ファイルが削除されたことが確認できました。

git rmコマンドを使用して目的のファイルを「ワーキングツリー」から削除することができましたね。

zomy
zomy

ただし、Finderやデスクトップ上などで手動でファイルを削除した場合は、git addコマンドを使用して「ステージングエリア」に削除したという状態を登録しなければ、「ステージングエリア」に削除状態を登録することはできません。

補足

今回は削除したい対象の種別が「ファイル」であったためgit rmで削除をすることができていますが、もし削除をしたい対象が「ディレクトリ」であった場合は、コマンドは以下のように入力する必要があります。

$ git␣rm␣-r␣ディレクトリ名

たとえば、「practice」という名前のディレクトリを削除したい場合は、以下のようにコマンドを入力する必要があるというわけです。

$ git␣rm␣-r␣practice

さて、たとえば今回の削除行為がまたうっかりによるミスだった場合を想定してみましょう。

その場合の対処方法を次から学んでいきます。

ステージングエリアの変更の取り消し|git restore –staged

先ほど「ワーキングツリー」で編集をしていた「index.html」ファイルをgit rmコマンドで削除するところまでを実行しましたね。

そしてgit rmは「ワーキングツリー」でのファイルを削除を行うのと同時に、その削除した状態を自動的に「ステージングエリア」へステージングまで行ってくれるコマンドでした。

今回はその「ワーキングツリー」から削除したうえにその削除状態を「ステージングエリア」にステージングしてしまった一連の行為自体がミスによるものだった場合の、一連の行為の取り消し方法について学習していきます。

このような場面想定時に使用できるコマンドはいくつかありますが、その中でも今回使用していくコマンドというのがgit restoreコマンドです。

git restoreコマンドは、Gitバージョン2.23以降で導入されたコマンドで、ワーキングツリー(作業ディレクトリ)やステージングエリア(インデックス)内の変更を取り消すために使うことができます。

そのgit restoreコマンドですが、今回は2つの使い方をご紹介します。

まず1つ目はgit restoreコマンドに--stagedオプションを併用したgit restore --stagedです。

git restore --staged コマンドは、指定したファイルの変更をステージングエリア(インデックス)内で取り消すことができます。ステージングエリアの内容は最新のコミットの状態に戻りますが、ワーキングツリーの内容には影響を与えません。すなわち、ワーキングツリー内の変更は取り消されないコマンドです。

2つ目の使い方は、オプションを併用しないgit restoreコマンドです。

git restoreコマンドは、指定したファイルの変更をワーキングツリー内で取り消します。ファイルの内容は最新のコミットの状態に戻りますが、ステージングエリアの内容には影響を与えることはありません。つまり、ステージングエリア(インデックス)にステージされていた変更までは取り消されないということです。

では今回はそのgit restoreコマンドの2つの働きを利用して、ステージングまでしてしまった「ファイルの削除」という変更の取り消しを行っていきます。

1.

ではまず、現在の状態と「git-practice」ディレクトリの中身を確認していきましょう。

$ git␣status

git statusコマンドを実行してみると、左画像のように緑文字で「deleted:index.html」の表示があり、「index.html」ファイルの削除状態がステージングエリアに登録されていること、そしてその削除状態はまだコミットされていないことが分かります。

$ git␣ls

またlsコマンドを実行しても何も表示されないことから、「git-practice」ディレクトリの中から「index.html」ファイルが削除されていることが併せて確認できましたね。

2-1.

ではここから、まずはステージングエリアにステージングした変更を取り消していきましょう。

今回はステージングエリアの変更取り消しのため、git restoreコマンドに--staged オプションを併用していきます。

使い方は以下のとおりです。

$ git␣restore␣--staged␣ファイル名

ただし、このコマンドでステージングエリアから取り消された変更は、ワーキングツリーツリーのファイル状態には影響を与えません。

あくまでも「ステージングエリアの変更を取り消す」点に注意してください。

ではコマンドを入力・実行していきましょう。

$ git␣restore␣--staged␣index.html
2-2.

実行してみたところ、コマンドラインには何の変化も起こらずにまたコマンドプロンプトが表示されてしまいました。

ですがエラーは起きていないため、どうやら正しく実行されたようです。

3.

ではgit statusコマンドで現状を確認してみましょう。

実行すると、左画像のように表示がされました。

ワーキングツリー内の変更がステージングエリアに登録されていないとの表示で、その変更というのが「index.html」の削除であると赤文字で表示されていますね。

つまり、先ほど実行したgit restore --staged によって「ステージングエリアの変更を取り消す」ことができたというわけです。

またGitは次の作業を画面上で教えてくれてもいます。

変更をコミットするためには、git addまたはgit rmコマンドを使用して変更をステージングする必要があること。

変更を取り消すには、git restoreコマンドを使用して変更をワーキングツリー(作業ディレクトリ)内で破棄することができることを示してくれています。

4.

試しにlsコマンドを実行してみても何も表示がされないことからも、「index.html」ファイルがまだ削除されたままであることが確認できます。

今回の目標はこの「index.html」ファイルの削除変更取り消しですので、ここからは再度git restoreコマンド使用し、ワーキングツリー内の変更の取り消しを行っていくことにしましょう。

ワーキングツリーの変更の取り消し|git restore

1.

ワーキングツリーから変更を取り消す際は、以下のようにgit restoreコマンドを使用します。

$ git␣restore␣ファイル名

これによってワーキングツリー内のファイルの変更ももとに戻すことができるのです。

ではコマンドを実行していきましょう。

$ git␣restore␣index.html
1-2.

すると、コマンドを実行してもなにも表示されない代わりに、エラーも表示されず、上手く実行ができたようです。

では再度内容などを確認していきましょう。

2-1.

git statusコマンドとlsコマンドをそれぞれ実行してみたところ、「ワーキングツリー内は、ステージングすべき状態のファイルも、コミットすべき状態のファイルもないクリーンな状態である」ということ、そして「git-practice」ディレクトリ内部には「index.html」ファイルが復元できていることが確認できました。

2-2.

念のため「index.html」ファイルの中身もcatコマンドで確認してみましょう。

catコマンドはファイルの内容を表示することができます。

なお「cat」は「concatenate(連結)」の略で、これは元々catコマンドが複数のファイルの内容を結合して表示するためのコマンドであったことから由来しています。

$ cat␣index.html

実行すると、「index.html」ファイルを削除する前の内容のままであることも確認ができました。

これで「index.html」ファイルの削除を取り消すことができました。

zomy
zomy

git restoreコマンドは今回ご紹介した使い方以外にも、「指定したコミットの内容を復元」したり「全ての変更を取り消す」ことができたりします。

  • 指定したコミットの内容を復元」する場合:git␣restore␣--source=コミットハッシュ値␣ファイル名
    • このコマンドは、--sourceオプションを使用して、復元したいコミットをハッシュ値で直接指定する方法です。
  • 全ての変更を取り消す」場合:git␣restore␣.
    • このコマンドでは.を使用することによって、作業ディレクトリ内のすべての変更を取り消すことができます。同時にステージングエリアの変更も取り消され、以前のコミット状態に戻ります。

そのため状況に応じて適切なコマンドを使い分けるようになるといいでしょう。

再度削除して、今度はコミットまで実行する

では、今度は「index.html」ファイルの削除からコミットまでの一連の作業を実際に行ってみましょう。

行う内容を図にすると以下のとおりです。

ファイルを削除した」という状態をコミットして記録する、ということ自体が少し不思議な感じがするかもしれませんが、Gitでバージョン管理を行っている以上、この「変更の登録」は必要不可欠なものです。

今回はコミットまで実行するため、「リモートリポジトリ」にもファイルを削除したという状態を登録することになります。

1.

まずはgit rmコマンドで「index.html」ファイルを削除します。

$ git␣rm␣index.html

git rmコマンドはステージングまで一気に完了させてくれるのでしたね。

2.

コマンドを実行すると左画像のように画面が表示され、「index.html」ファイルが削除されたことがわかります。

3-1.

その後git commit-mオプションをつけてコミットしていきます。

今回は下記のように実行しました。

$ git␣commit␣-m␣'indexページを削除'

なお「''(シングルクォーテーション)」で囲んだ「indexページを削除」の部分がコミットメッセージにあたります。

コマンドを実行した結果に表示されたメッセージについては、以下でご説明します。

3-2.
  • [main 07349c5] indexページを削除:コミットが正常に行われたことを示すメッセージです。mainはコミットが行われたブランチ名を示し、07349c5は本コミットを識別するハッシュ値(一意の識別子)です。
  • 1 file changed, 2 deletions(-):コミットによって変更されたファイルの情報です。本コミットでは1つのファイルが変更され、2行が削除(deletions)されました。
  • delete mode 100644 index.html:「index.html」というファイルが削除されたことを示しています。delete modeはファイルの削除のことで、100644はファイルのモードを表し、ここでは通常のファイルであるということを示しています。。

以上のことから、「index.html」ファイルのコミットが正常に行われたことが確認できます。

4.

念のためlsコマンドでも確認してみますが、なにも表示されないため、「index.html」ファイルが削除されていることが改めて確認できました。

変更をリセットする|git reset

では今度は、ファイルの削除をコミットまで実行したあとで、実はそのファイルは削除してはいけないファイルであったと気づいた場合を想定してみることにしましょう。つまり、コミット後に間違いを取り消す方法です。

その場合はgit resetコマンドをモードを指定しながら使用します。今回は下の図のとおり--hardモードを指定していますね。

ただし、このgit reset --hardは、コミット自体をなかったことにしてしまう大変強力なコマンドです。そしてコミット自体に修正を加えると、予期していなかったさまざまな問題を引き起こす原因にもなりかねませんので、使用する場合はあくまで「どうしてもやむを得ない」場合のみ使用するように心がけましょう。

1-1.

変更をリセットする場合はgit resetコマンドを使用します。今回は下記のようにオプションを指定して入力をしましょう。

$ git␣reset␣HEAD^␣--hard

HEAD^の部分は「どこまでリセットするか」の範囲を表しています。HEADというのは先頭のコミットのことで、HEADの後ろに^を1つ付けるすると「1つ前のコミットまで」、^^と2つ付けると「2つ前のコミットまで」リセットすることを示しています。

^の個数で何個前のコミットまで戻るかを指定できます。

--hardはリセットモードの指定です。リセットモードについては下記にて詳しく説明します。

1-2.

リセットモードには3つのモードがあります。

  • Mixed モード: デフォルトのモードです。「変更」→「ステージング」→「コミット」作業のうち、「変更」→「ステージング」までをリセットする方法です。
  • Soft モード: 「変更」→「ステージング」→「コミット」作業のうち、最後の「コミット」だけをリセットする方法です。
  • Hard モード: 「変更」→「ステージング」→「コミット」作業のうち、「変更」からリセットする方法です。この場合はファイルの変更などを含めてリセットしてしまうため、注意が必要です。今回のように「間違えて削除してしまった」ときや「正常に動いていたプログラムファイルを壊してしまった」場合などに利用しましょう。

今回は3-1Hard モードを指定したため、「変更」つまり「index.html」ファイルの削除からリセットするよう指定したことになります。

2.

すると左画像のような結果が表示されました。

HEAD is now at 143d6dc git diffについて追記」の部分により、git resetコマンドが成功し、現在のHEAD(最新のコミット)が「git diffについて追記」のコミットに戻されたと表示されています。

これで「index.html」ファイルの削除からコミットまでの「変更」が取り消され、ファイルも元に戻すことができたはずです。

3.

lsコマンドを実行してみたところ、やはり「index.html」ファイルが元に戻っていることが確認できました。

これで、ファイルを削除してからステージング、そしてコミットまでの一連の「変更」行為をリセットすることができました。

コミットIDでのリセット|git reset

また先ほどまでは、「どこまでリセットをするか」の範囲はHEAD^の個数の組み合わせで指定をしていましたが、「コミットID」を使用してしていすることもできます。

コミットID」とは、各コミットごとを識別するため割り当てられる一意の長い文字列のことです。別名「SHA-1ハッシュ値」と呼ばれたりもします。データを一意に識別するための「指紋」のようなものだと考えてください。

1.

「コミットID」を調べる場合はgit logコマンドを使用します。

$ git␣log

では早速実行し確認してみましょう。

2.

すると左図のような結果が表示されました。赤枠の部分がコミットIDに値する部分です。

この今回は最新コミットのコミットID(英数字)をコピーして使用していきます。

3.

どこまで」の範囲にコミットIDを使用する場合は、git resetの指定は以下のようになります。

$ git␣reset␣143d6dcebac329c0add4f13a883d2d1f1118e015␣--hard

なおこの「コミットID」は40桁と長いため、一部のIDを指定することで一意に特定できる場合は後ろの部分が省略されることも多々あります。

例えば以下のように、先頭の7〜10桁程度の短縮形のコミットIDを使うことも一般的です。

$ git␣reset␣143d6dc␣--hard

最新のコミットにタグを指定する|git tag

前回使用したGitのコミットログは便利な一方、作業をどんどん進めていくとコミットログが長くなり、どこでどんな作業をしたのか分かりにくくなってしまうことがあります。

そこで、Gitには「タグ」という便利な機能が用意されています。その際に使用されるのがgit tagコマンドです。

git tagコマンドは、リモートリポジトリ内の特定のコミットに対してラベル(タグ)を付けるために使用されるコマンドです。タグは通常、リリースやマイルストーンなどの重要なポイントを示すために使用されます。

これによってコミットのハッシュ値でコミットを特定する必要性がなくなり、より利便性があがります。

1.

タグを指定するにはgit tagコマンドを使用します。

今回は「tag-practice」というタグを作りたいため、下記のように入力します。

$ git␣tag␣tag-practice

するとタグが作成されるのですが、作成されたタグは最新のコミットに付加されます。

今回の場合、直近に作成したコミットは「index.html」のため、「index.html」ファイルに付加されたはずです。

2.

タグが作成されても特になんのメッセージも表示されないため、タグ作成の結果を確認したい場合は追加でコマンドを打つ必要があります。

git tagコマンドを単体で使用するとタグの一覧を表示することができます。

$ git␣tag

実際にコマンドを入力してみると、左画像のような結果が表示され、無事に「tag-practice」タグが作成されたことが確認できます。

3-1.

ただ、git tagでは具体的に何のコミットにタグを付加したのかどうかは表示されません。

そのため、タグの詳細情報を確認したい場合はgit show タグ名で細かい内容を確認することができます。

今回は「tag-practice」の詳細情報を確認したいため、以下のように入力・実行します。

$ git␣show␣tag-practice

すると左画像のような結果が表示されました。

3-2.
  • ①の部分は「tag-practice」が付加されたコミットの「コミットID(SHA-1ハッシュ値)」です。
  • ②のメッセージは今回のタグが付加されたコミットの「コミットメッセージ」です。

以上のことから、今回作成したタグ「tag-practice」は、やはり最新のコミットである「index.html」に付加されたことが確認できました。

コミットを指定してタグを付加する|git tag(コミットID)

ただ、最新のコミットにだけしかタグが付加できないのは少々不便です。

そのため、特定のコミットを指定してタグを付加することもできるようになっています。続いてはそのやり方を見ていきましょう。

1.

まずはgit logでコミットを一覧表示します。

左画像で囲った赤枠の部分が「コミットID(SHA-1ハッシュ値)」ですので、このコミットIDをコピーします。

今回は「indexページを新規作成」というコミットメッセージを持つコミットにタグをつけてみましょう。

コミットID」は40桁と長いため、一意に特定できる場合は先頭の7〜10桁部分のみのコピーでも構いません。

2.

続いて下記のようにコマンドを入力します。

$ git␣tag␣tag-practice2␣54cdf2a...

tag-practice2」は今回作成するタグ名、その後半角スペースを空けて続いている英数字が「コミットID」です

こうすることによって指定したコミットIDのコミットに、任意をタグを付加することができるようになります。

3.

では実際に「indexページを新規作成」というコミットメッセージを持つコミットに「tag-practice2」タグを付加することができたか確認してみることにしましょう。

今回もgit logで詳細情報を確認したいため、以下のようにコマンドを入力します。

$ git␣log

すると左画像のように詳細情報を表示することができました。

indexページを新規作成」というコミットメッセージを持つコミットには、今回コマンドを実行したとおり「tag-practice2」タグが付加されていることが確認できました。

これで最新のコミット以外にもタグをつけることができるようになりましたね。

タグを削除する|git tag -d

では今度は不要になったタグを削除する方法を学んでいきましょう。

1.

今回は、先ほど作成した「tag-practice2」を削除していくことにしましょう。

タグを削除する場合はgit tag-dオプションをつけて使用します。-dは「delete(削除)」の頭文字です。

$ git␣tag␣-d␣tag-practice2
2.

コマンドを実行すると左画像のように結果が表示されました。

Deleted tag 'tag-practice2' (was 54cdf2a)では、削除されたのが「tag-practice2」であること、そしてそのタグは「54cdf2a」というコミットID(ハッシュ値)を持つコミットについていたものだと表示されています。

54cdf2a」は「indexページを新規作成」というコミットメッセージを持つコミットでもあるので、無事にコミットからタグを削除できたことがわかります。

3.

念のためgit logコマンドでも確認してみましょう。

すると先ほどまで「tag-practice2」タグを持っていた「54cdf2a」コミットからは「tag-practice2」タグが消えなにも表示されなくなりました。

これでタグの削除に成功したことを改めて確認することができました。

ファイルをGitで管理しない指定をする|git ignore

Gitでのバージョン管理は大変便利なものですが、一度バージョン管理に指定してしまった場合、そのディレクトリ下のすべてのディレクトリとファイルがバージョン管理されてしまうことはすでにご説明しました。

ですが、もしそのなかにバージョン管理をしたくないファイルがあった場合はどうしたらいいのでしょうか?

たとえばパスワードなどが記載されているセキュリティに関連するファイルや、自動生成されるログファイルなどです。

このような場合にはそのファイルを「無視」するように指定をすることで、Gitの管理下から外すことができます。

指定の仕方は簡単、「.gitignore」ファイルの中に、無視したいファイルの名前を記述するだけです。

なおこの働きのとおり、「ignore」という英単語はまさに「無視」という意味です。機能そのままの名前であるので、わかりやすいですね。

1.

では早速、.gitignoreの効果を実感するために、Gitの管理から外したいファイルを作成していきましょう。

VS Codeを立ち上げ、「ignore.txt」という名前でファイルを新規作成しています。

ファイルを保存する場所はこれまで同様、「git-practice」ディレクトリ内です。

2.

ではこれから「.gitignore」ファイルを作成していくのですが、その前に現在のGitの状態をgit statusコマンドで確認してみましょう。

$ git␣status

すると、左画像のように表示がされました。

Gitが追跡していない「Untracked」なファイルが検出され、それが「ignore.txt」であると知らせています。

3.

続いてVS Codeに再度戻り、今度は「.gitignore」ファイルを新規に作成していきましょう(①)。

そしてそのファイルの中にGitで無視したいファイルの名前を記述します。

今回の場合は「ignore.txt」ですので、②のように記載しましょう。

またこのファイルも、先ほど作成したばかりの「ignore.txt」と同じディレクトリの中に保存をしていきましょう。

4.

.gitignore」ファイルの中に無視したいファイルである「ignore.txt」の名前を記述したあとに、再度ターミナルでGitの状態確認のためにgit statusコマンドを入力してみると…

$ git␣status

左の画像のとおり、先ほどまで「Untracked files」として表示されていた「ignore.txt」ファイルの表示が消えており、新たに作成した「.gitignore」ファイルに関してのみ表示がされています。

.gitignore」ファイルに関しては新規作成したあとに何の登録もしていないため、「Untracked」のファイルであるとの表示がされていますね。

これで「ignore.txt」ファイルがGitから無視され、管理から外せたと確認できました。

5.

では作成した「.gitignore」ファイルは通常どおりコミットしていきましょう。

まずはステージングからですね。

$ git␣add␣.gitignore
6.

続いてコミットです。

$ git␣commit␣-m␣'.gitignoreファイルを追加'

コマンドを実行すると、無事に「.gitignore」ファイルをコミットすることができました。

zomy
zomy

.gitignore」ファイルは、どの場所に置いても問題ありませんが、その影響はファイルが配置されたディレクトリおよびそのサブディレクトリ内のファイルやディレクトリに対してのみ適用されます

今回のようにローカルリポジトリ内のすべてのディレクトリに「.gitignore」ファイルの設定を適用したい場合、リポジトリのルートディレクトリ(今回の場合は「git-practice」ディレクトリの直下)に「.gitignore」ファイルを配置します。つまり「.git」ディレクトリがある場所と同じディレクトリ内ということですね。

これにより、リポジトリ内のすべてのディレクトリとサブディレクトリに「.gitignore」ファイルの設定が反映されるということを覚えておきましょう。

これでローカル上でのGitの基本的な使い方を一通り学習することができました!

ここまで本当にお疲れ様でした!

おわりに

ここまで、Gitのローカル上での基本操作をざっと解説してきましたが、いかがでしたでしょうか?

本記事1本を読んだだけではソフトウェアの共同開発などを行うほど使いこなすことができるようになるわけではありませんが、「Gitの概要」「Gitの利便性」「各コマンドそれぞれの挙動」などはざっくり掴むことができたのではないでしょうか?

ここまで読み進めていただいた方であれば、Gitを扱う上での前提知識として「ターミナルの基本操作や基本コマンド」や「VS Codeの使い方」「Vimの使い方」に関する知識が必要であることもご理解いただけたかと思います。

またこの先Gitの有用性を更に高めていくためには、そしてGitの利便性を最大限に向上させるためには、まだご説明しきれていない「GitHubについて」「ブランチについて」「チームでの共同開発の手法」などなどの知識を手に入れる必要があります。

ですが、そうした知識を獲得していくために必要となる基礎の部分が本記事で取り扱った内容でもあります。そのためこの部分の理解をあやふやにしてしまうと、その土台に知識を積み上げることが難しくなってしまう非常に重要な部分でもあるのです。

こうしてGitを操作するためには多くの知識を要するわけですが、それらの学習コストを割いても余りあるほどの利便性をGitが秘めていること、そしてその魅力の一端を少しでもご説明できていたら嬉しく思います。

参考書籍・動画

最後に、本記事を書くために勉強・参考にさせていただいた書籍と動画を下記にてご紹介いたします。

では以上、長くなりましたがここまでお付き合いいただきまして、誠にありがとうございました。

本記事がどなたかの学習の一助となりましたら、幸いです。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です