SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

すぐ使いこなせるようになりたい人のためのGit入門

【Git入門解説】Gitの基本的な使い方をマスターしよう

すぐ使いこなせるようになりたい人のためのGit入門 第1回

  • X ポスト
  • このエントリーをはてなブックマークに追加

 Gitはバージョン管理システムの一つです。本連載では、株式会社MIXIで行っているGit研修の内容をもとに、3回にわたりGitについて解説します。第1回となる本記事では、Gitの基礎や使い方を解説します。

  • X ポスト
  • このエントリーをはてなブックマークに追加

はじめに

 こんにちは。株式会社MIXIでGit研修の講師を務めている登内です。本連載では、株式会社MIXIで行っているGit研修の内容をもとに、3回にわたってGitについて解説します。第2回ではGitをチーム開発で使う方法を紹介し、第3回では発展的な内容になりますが、Gitの内部構造について解説していきます。

対象読者

  • これからGitを使い始めようと思っている方

バージョン管理とは?

 あるファイルに変更を加えた時、念のため元の状態も残しておきたいということは良くあると思います。例えば、こういったファイル名による管理をしていた方もいるのではないでしょうか?

レポート.pdf / レポート(1).pdf / レポート_最新.pdf / レポート_修正版.pdf / レポート_最終稿.pdf

 しかし、これだとどれが最新版なのか、1つ前の版はどれか分からなくなってしまうこともあるかと思います。 以下のようにファイル名のサフィックスに日付を付けておく工夫もできますが、新しいバージョンを保存するたびにファイル数が増えて管理の手間がかかるうえ、バージョンごとにどのような更新を行ったかが分からなくなるなどのデメリットがあります。

レポート_20220814.pdf => レポート_20220816.pdf => レポート_20220901.pdf

 1人で編集する資料であれば、これだとしてもそこまで問題にはなりません。ただし、100人で数年かけて開発するソフトウェア開発の場面ではどうでしょうか? 編集が複数人により同時並行で行われると、それぞれのファイルの最新状態がどれであるか分からなくなったり、同一ファイルに対する変更が競合したりするなどの問題が生じやすくなります。

 Gitを始めとするバージョン管理システム(VCS)を使うと、こういった問題を解決できます。VCSを使うことの主なメリットは以下です。

  • 多数のファイルのバージョンをかしこくバックアップできる
  • ファイルを任意の時点の状態まで簡単に戻せる
  • 変更履歴を簡単に辿ったり、比較したりできる
  • 問題が生じた際、誰がいつバグを混入させたかを確認できる

Gitの初期設定

 Gitのインストールがまだの方は、こちらのサイトを参考に、ご自身の環境にインストールしてください。インストール後は以下のコマンドを実行し、Gitの初期設定を行ってください。

$ git config --global user.name XXXXXX
$ git config --global user.email XXXXX@XXXXXX

 また、必要に応じて、ご自身のGitの使用環境に合わせて使いやすいように追加設定してください。例としてBashでGitを使用する方は、こちらのサイトを参考に設定するとGitをより便利に使うことができます。

Gitの使い方

 ここからはGitの基本的な使い方を解説していきます。第一回となる本記事ではあくまで基礎的なコマンドの使い方の解説にとどめます。ここで紹介する各コマンドや操作について、より詳しい仕組みの解説は第3回のGit内部構造についての記事で解説予定なので、興味を持たれた方はそちらの記事をお待ちください。

Gitリポジトリの初期化

 プロジェクトをGitで管理したい場合は、そのプロジェクトのディレクトリに移動して、git initコマンドを打ちます。

$ mkdir git-tutorial && cd git-tutorial
$ git init

 これにより、Gitリポジトリが初期化され、つまりGitによるバージョン管理ができるようになります。

 具体的に何が起きているかというと、そのプロジェクトのディレクトリに.gitというサブディレクトリが作られ、その中にGitリポジトリに必要なすべてのファイルが格納されます。.gitディレクトリの中身の詳細については、第3回の記事で紹介します。

ファイルを管理対象に追加

 初期化しただけの状態では、まだどのファイルもGit管理下にありません。ファイルのバージョン管理を始めるには、そのファイルを管理対象に追加する必要があります。

 以下のように、ファイルを作成したあと、そのファイルについてgit addコマンドを実行した後にgit commitコマンドを実行してください。

$ echo Hello > README.md
$ git add README.md
$ git commit -m "first commit"

 これで作成したREADME.mdというファイルをGitの管理対象に加えたことになります。

編集履歴の記録

 これでバージョン管理の準備が整いました。それでは、管理対象ファイルであるREADME.mdに変更を加えていきます。変更を加えた際も、先ほどと同じ手順でgit addコマンドの後にgit commitを実行します。git commitを実行するごとに新しくバージョンが記録されていきます。

$ echo "Hello World" > README.md
$ git add README.md
$ git commit -m "second commit"

 ちなみに-mオプションの後に文字列が続いていると思いますが、これはそのコミットについてのメモ・コメントを記録するもので、そのバージョンや差分の意味がわかるようなメモを残しておくと、後で履歴を確認する際に分かりやすくなります。

$ touch report_1.txt
$ git add report_1.txt
$ git commit -m "Add report_1.txt"

$ echo "Git is one of the version control systems." >> report_1.txt
$ echo "writing report_1..." > README.md
$ git add README.md
$ touch report_2.txt

 ここで、git statusコマンドを打つと、一つ前のコミットで記録されたバージョンから差分のあるファイルを確認できます。

 階層ごとに分けてファイルが表示されていると思いますが、それぞれ以下の意味があります。

  • Changes to be committed
    • 次回コミットの対象に含まれているファイル
    • 変更後にgit addしたファイル
  • Changes not staged for commit
    • Gitの管理下にあるファイルのうち、差分はあるが次回コミット対象に含まれていないファイル
    • 変更後にgit addしていないファイル
  • Untracked files
    • Gitの管理下にないファイル

 ここから分かる通り、git addは次回コミットの対象(Gitではステージングと呼びます)に含めるコマンドになります。まとめて編集したからといって、一度にすべての変更を次のバージョンに記録してしまうと、問題が生じたときに切り分けが難しくなります。新しくバージョンを記録するときは、できるだけ意味のある最小単位で記録するのがおすすめです。

 なお、git diffコマンドで変更の内容を見ることもできます。git add済みのREADME.md--cachedオプションが必要です。

 report_1.txtgit addしてコミット対象に含め、変更をコミットしておきます。

$ git add report_1.txt
$ git commit -m "Update README.md and report_1.txt"

編集履歴の確認

 これまで記録したコミットログ(バージョン履歴)は、git logを実行することで確認できます。

 黄字で表示されているのがコミットハッシュで、コミットを一意に識別するためのものです。

履歴を遡って任意の時点にチェックアウト

 履歴を遡って、特定のバージョン時点の状態にするにはチェックアウト機能を使います。

 git logをしたときに最初に表示されたコミットのハッシュ値の横に(HEAD -> main)とあることがわかると思います。このHEADというのが現在参照しているコミット(バージョン)です。mainとあるのはブランチ名ですが、これは後ほど説明します。

 この状態で、二つ前のコミット(second commit)の時点に移ることにします。

 該当のコミットハッシュを使い、checkoutというサブコマンドを使うことでそのコミットに移ることができます。

$ git checkout e01472f75fb2daa7bebe35c2d874ded1772643e2

$ git log
commit e01472f75fb2daa7bebe35c2d874ded1772643e2 (HEAD)
Author: tonouchi510 <xxxxxx@gmail.com>
Date:   Thu Aug 25 11:50:56 2022 +0900

    second commit

commit d808fdd96f2fb2861e49929d1e7b85331de84e91
Author: tonouchi510 <xxxxxx@gmail.com>
Date:   Thu Aug 25 11:48:14 2022 +0900

    first commit

$ cat README.md
Hello World

 git logの結果からも、HEADが該当コミットのところに動いていることが分かります。cat README.mdの結果から、ファイルの中身もそのバージョン時点の内容になっていることが確認できると思います。

 最後に、元々の状態に戻すために以下のコマンドを実行します。

$ git checkout main

作業のやり直し

 Gitのコマンドを間違えて実行してしまったという場合には、その作業をやり直すためのコマンドも存在します。

  • 間違えてgit addしまったファイルを取り消す
    • 例:git reset HEAD ファイル名
    • git resetで一括で取り消すこともできます
  • 間違えて行ったコミットを取り消す
    • 例:git reset HEAD

 ここでは基礎的なコマンド実行例にとどめますが、git resetは実は奥が深いコマンドです。また、git checkoutとも微妙に重なる部分もあります。この辺りを正確に理解するには第3回の記事で解説するGitの内部構造に関する理解が必要なので、興味がある方はそちらも見ていただけたらと思います。

 ※ちなみに最近ではcheckoutresetの代替として、switchrestoreというサブコマンドが使われることが多くなっているので、興味のある方はそちらも調べてみてください。

次のページ
ブランチとマージ

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
すぐ使いこなせるようになりたい人のためのGit入門連載記事一覧

もっと読む

この記事の著者

登内 雅人(株式会社MIXI)(トノウチ マサト)

 Vantageスタジオ みてね事業部 Data Engineering グループ所属。 2020年に株式会社ミクシィ(現MIXI)へ新卒として入社。現在は「家族アルバム みてね」の開発チームにて、AIを活用した自動顔認識系の研究開発やMLOpsの整備などを主に担当している。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/16559 2022/10/14 11:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング