こんにちは！
この記事ではgitの操作についてまとめます。エンジニアとして働き始めた方のほとんどがgitで壁にぶつかります。
今現在、困ってる方も多いのではないでしょうか。
僕も壁にぶち当たりました。。
そんな経験をもとにこの記事を執筆しました。
gitの操作についてこの記事を読めば大丈夫！というものを目指すので記事が長くなります。
困ったら該当箇所を見る辞書のように使っていただければと思います！
では早速本題に入りましょう！
前提知識
gitでのソースコードの管理
gitを扱う上で知っておくべき前提知識をここで説明します。
前提知識とは言いましたが、そんなに難しい話ではないのであまり怖がらず読んでみてください。
(gitには詳しいから大丈夫という方は飛ばしていただいて構いません。)
まずは下の図をみてください！
gitでのソースコードの管理を簡単に説明すると以下の通りです。
- ワークツリー(作業環境)でコードを修正 or 新規作成する。
- 変更内容をステージに上げる(add)
- ステージの内容をリポジトリ(ローカル)に上げる(commit)
- ローカルリポジトリの内容をリモートリポジトリに反映する(push)
詳しい内容は後で説明しますが、概要は上記の通りです。
少し内容を説明します。
リモートリポジトリって？
リモートリポジトリはみんなで共有しているリポジトリです。
ここでいうみんなとは開発チームのメンバーなどです。
そしてこのリモートリポジトリを個人の環境(ローカル)に持ってきます。
そしてそれぞれが自分の環境でソースコードを修正し、ステージにあげ、そしてリポジトリにあげます。
このリポジトリをリモートリポジトリに反映させると、各々が書いたコードを一つにまとめられます。
無知猫じゃあ最初からみんなでリモートリポジトリをいじればいいじゃん！
しかしこれをしてしまうと不都合があるのです。
例えば、AさんとBさんが同時にリモートリポジトリ内のコードを編集したとします。
Aさんは早めにコードの編集を終えて実際に動くかテストしようとしました。
しかしBさんはコードの編集が終わっていないためプログラム全体としては不完全となり、Aさんはテストを行うことができません。結果として効率が落ちて不便になってしまいます。
こう言ったことを防ぐために、一旦リモートリポジトリを個人の環境にクローンして編集をします。
そうすることで自分がいじった部分以外に変更がなく、自分の作業が終わった段階で実際に動くか試せます。
少し長くなりましたが、前提知識については以上です。なんとなくイメージできたでしょうか。
ここから先は実際にgitのコマンドについて解説していきます。最初にも言いましたが、数が多いので長くなります。
なので自分が知りたいところを見る辞書のように使っていただいて構いません！
時間があるときにすべてに目を通していただけると嬉しいです
頻出のgitのコマンド一覧
git add
ここからはgitのコマンドを一つずつ見ていきます。まず一つ目はgit addコマンドです。
git addの役割はワークツリーでの変更点をステージに記録することです。
このステージに記録するためのコマンドがaddです。
なのでソースコードを編集したらまずはaddすることになります。
見ているのは最初の状態との差分なので、何回かに分けてaddしても問題ありません。
ただ基本的には一通りの作業(機能を一つ開発する、不具合を一つ修正する)が終わったらaddすることが多いです。
git addの使い方を見てみましょう。
git add ファイル名
git add ディレクトリ名
git add .git add は変更を記録したいファイル名やディレクトリ名を指定して使います。
一番最後の例のピリオドは、現在のディレクトリの中身を全て対象として、変更を記録できます。
結構使うので覚えておくと便利かもしれません！
git addはワークツリーでの変更点をステージに記録するコマンド
git commit
git commitはステージに記録された変更をリポジトリに記録するためのコマンドです。
リポジトリではcommitされた時の状態をスナップショットとして保存しています。
無知猫スナップショットとして保存すると何がいいんだろう
ここでは詳細に理解する必要はありませんが、「あの時の状態に戻したい」と言った場合に、スナップショットを利用して戻すことができます。これに関しては後でまた紹介します。
git commitの使い方を見てみましょう。
git commit
git commit -m "メッセージ"単にgit commitと実行するだけでもステージ上の変更をリポジトリに記録することはできます。
しかしよく使うのは -m オプションをつけてメッセージを添付する方法です。
理由はこの後紹介する、push (ローカルリポジトリの内容をリモートリポジトリに反映)に関わってきます。
pushするとcommitの履歴も反映されます。
リモートリポジトリは開発チームのメンバー全員で共有しているため、commitの履歴にメッセージが書かれていないと、この変更はどういう意図でどんな修正をしたのかが分かりません。
そのためcommitするときは-mオプションをつけてメッセージを添付しましょう。
メッセージに書く内容は人により(または開発チームにより)異なりますが、基本的に
- コードを修正した人の氏名
- 変更(新規作成したファイル名)
- 変更理由(新規関数の追加、不具合の修正)
などを書くことが多いです。
git commitはステージに記録された変更をリポジトリに記録するためのコマンド
git status
git statusは現在の変更状況を確認するコマンドです。
具体的にはワークツリーとステージ間の差分、ステージとリポジトリの差分を確認することができます。
少しイメージがしにくいと思うので具体例を見てみましょう。
青い長方形はそれぞれソースコードが書かれたファイルだと思ってください。
以前aaaaaと記述してステージにaddした状態からコードを修正して、今回bbbbbと新たに追記した状態です。
ここでgit statusを実行すると
「ステージにaddしてない変更があります」
と教えてくれます。
そしてステージ上に変更が記録されているということは、commitもされていない状態なので
「commitされてない変更がステージ上にあります」
とも教えてくれます。
git statusコマンドは具体的な差分(今回だとbbbbbの部分)は教えてくれません。
わかるのはステージにaddされてない変更があるのか、リポジトリにcommitされてない変更があるのかです。
git statusコマンドの使い方は
git statusと実行するだけです！
git statusは現在の変更状況を確認するコマンド
(ワークツリーとステージ間の差分、ステージとリポジトリの差分の有無を確認できる)
git diff
git diffコマンドは実際の変更内容を確認するコマンドです。
先ほどのgit statusは差分があるかどうかの確認でしたが、git diffは具体的な変更内容を見ることができます。
git diff単体で実行するとワークツリーとステージ間の変更差分を確認することができますが、
git diff –stagedとするとステージとリポジトリ間の変更差分を確認することができます。
図で見てみましょう。
先ほどと同じく、青い長方形がテキストファイルだと思ってください。
この状況でgit diffを実行すると、ワークツリー上のオレンジ色の部分が変更差分として確認できます。
(実際に実行してみてください)
ではこれをgit addによりステージに追加するとどうなるでしょうか。
git addでステージに追加するとファイルの状況は↑のようになりますね。もうわかるかと思いますが、
この状況でgit diffコマンドを実行すると、「差分は何もないよ」と教えてくれます。
git diff –stagedの詳細な解説は省略しますが、ワークツリーとステージ間で比べてたものが、ステージとリポジトリ間で比べることになっただけなので問題ないと思います！
git diff // ワークツリーとステージ間の変更差分を確認
git diff --staged // ステージとリポジトリ間の変更差分を確認git diffコマンドは実際の変更内容を確認するコマンド
- git status→差分の有無を確認
- git diff→具体的な変更内容を確認
git log
git logは今までのcommitの履歴を確認するコマンドです。
ここでは特に解説することはありませんが、よく使うオプションがいくつかあるのでそれらをまとめておきます。
git log // commit履歴を確認
git log --oneline // 結果を1行で表示する
git log -p ファイル名 // ファイルのcommitを確認する
git log -n コミット数 // 表示するcommitの数を制限するgit logはcommitの履歴を確認するコマンド
git push
git pushはローカルのリポジトリの内容をローカルのリポジトリ(githubなど)に反映させるコマンドです。
まずは実行のコマンドを確認してみましょう。
git push origin master
(git push リモート名 ブランチ名)これだけみてもよくわからないですよね。一つずつ解説します。まずはoriginについてです。
いきなり出てきたoriginってなんだよと思いますが、これはリモート名です。
git pushは先ほど解説したように、ローカルリポジトリの内容をリモートリポジトリに反映させるものです。
なのでどのリモートリポジトリかを指定しなければなりません。
そこで初回のpushの時に以下のコマンドを実行します。
git remote add origin リモートリポジトリのURLこれはリモとリポジトリをoriginという名前で登録しています。リモートリポジトリのURLはgithubなどのページに行くと確認することができます。
指定する名前はoriginである必要はないのですが、慣習的にoriginが使われます。(origin以外は見たことない)
なので特別な理由がなければoriginにしておきましょう。
コマンドにエイリアスをつける
ここではよく使うコマンドにエイリアス(別名)をつける方法を紹介します。
なぜ別名をつけるのかは、多分想像できるかと思いますが作業を楽にするためです。
例えばgit commitコマンドひとつとっても、”commit”と何回も入力するのは少し手間ですよね。
なのでここで紹介するコマンドでエイリアスをつけてみましょう。
git config --global alias.ci commitここではcommitに”ci”というエイリアスをつけています。
git configコマンドは、設定を変更するコマンドです。–globalを指定することでPC全体の設定を変更することができます。
(複数のプロジェクトに参加している場合、PC全体の設定を変更しておけば全てのプロジェクトでこのエイリアスを使用することができます)
このようによく使うコマンドにはエイリアスをつけておくことをおすすめします。
commit以外にもstatusコマンドなどにもエイリアスをつけておくと良いかもです！
.gitignoreについて
.gitignoreファイルはバージョン管理したくないファイルを指定するためのテキストファイルです。
バージョン管理したくないファイルは、パスワードなどの知られたくない情報が含まれるファイルです。
このようなファイルがgitでバージョン管理されてしまうと、パスワードの流失などに繋がってしまいます。
また、このようなファイル以外にも自動生成されるファイルなど、チームでの開発には不要なものも.gitignoreに指定してバージョン管理から外しましょう。
.gitignoreの書き方は、バージョン管理から外したいファイル名を指定するだけです。
他にもワイルドカードを使用する方法などたくさんありますが、ここでは省略させていただくので、ぜひ一度調べてみてください。
git checkout — (ワークツリーで加えた変更の取り消し)
これはワークツリーで加えた変更を取り消すためのコマンドです。
なぜ–オプションが付いているかは、また後で出てきますがgit checkoutはブランチ変更にも使うコマンドです。
git checkout –とすることで、後ろに来るのはブランチ名ではなく、ファイル名やディレクトリ名だよと教えてあげているのです。
ここではgit checkout –について解説します。
git checkout -- ファイル名 // 指定したファイルの変更を取り消す
git checkout -- ディレクトリ名 // 指定したディレクトリの変更を取り消す
git checkout -- . // 全ての変更を取り消す使い方は↑の通りです。
参考までにですが、このコマンドはワークツリーの状況をステージと一緒にしているだけです。
git checkout — ファイル名 このコマンドを実行すると指定したファイルについて、ワークツリーとステージで比較して、差があればステージ上のものに合わせています。
ディレクトリを指定した場合も同じです。
git reset HEAD (ステージに追加した変更の取り消し)
git reset HEADコマンドを使用することで、ステージに追加した変更を取り消すことができます。
使い方は以下の通りです。
git reset HEAD ファイル名
git reset HEAD ディレクトリ名
git reset HEAD .このコマンドを実行することで、ステージに追加された変更を取り消すことができます。
このコマンドでは最新のコミットを参照してステージとリポジトリの内容を同じにすることでステージに追加された変更を取り消しています。
このコマンドで出てきているHEADは今いるブランチの最新のcommitを表しています。
先ほども伝えたようにgit reset HEADではステージに追加された変更を取り消すことはできますが、ワークツリーでの作業はそのままになります。
なのでワークツリーでの変更も取り消したい場合は、先ほど紹介したgit checkout –コマンドをgit reset HEADの後に実行する必要があります。
git commit –amend (直前のコミットを取り消す)
git commit –amendを使用することで、直前のコミットを取り消すことができます。
少し図を使って説明します。
これが今の状態だと思ってください。テキストファイルにaaaaaとbbbbbと書いてリポジトリにコミットした状態です。
コミットした後に、cccccも書くべきだったことに気づいたためこのコミットを取り消したいです。
次の図をみてください。
直前のコミットを取り消すために、まず正しい変更(この例だとcccccを書き込む)を加えて正しい状態にしてステージにaddします。
その状態で
git commit --amendを実行します。
このコマンドは現在のステージの状態でのコミットで、直前のコミットを上書きしています。
こうすることで直前のコミットを取り消して正しいコミットに変えることができます。
ここでとても大事な注意点があります！
それはpushしてしまったコミットには、このコマンドを実行しないでください！！絶対に！！
理由がわかるでしょうか。
まずpushとはリモートリポジトリにローカルリポジトリの内容を反映させることでしたね。
そしてリモートリポジトリはチームメンバーなど自分以外の人も使うことのできるリポジトリです。
つまりpushしたコミットの内容は自分以外の他の人がるようすることができるのです。
自分がpushして他の人が利用しているコミットを勝手に取り消してしまうと、それを使っている人がとても困ります。
そもそもプログラムが動かなくなってしまうことすらあります。
なので絶対にpushしたコミットにはgit commit –amendを実行しないでください！！
git pull, git fetch (リモートリポジトリから情報を取得)
ここではリモートリポジトリから情報を取得するコマンドについて紹介します。
リモートから取得するコマンドはpullとfetchの二つがあります。
この二つの挙動の違いはわかっていない人も結構いるので、しっかり理解しておきましょう。
git fetch
まずはfetchです。git fetchを実行するとリモートリポジトリの内容をローカルリポジトリに反映します。
ここで注意しなければいけないのは、ワークツリーにはリモートリポジトリの内容は反映されないということです。
ワークツリーにもリモートリポジトリの内容を反映させたい場合は、fetchした後にmerge(マージ)をする必要があります。
マージについては後ほど紹介します。
git fetchの使い方は以下の通りです。
git fetch リモート名git pull
続いてgit pullです。
pullを実行すると、リモートリポジトリの内容をローカルリポジトリとワークツリーどちらにも反映させることができます。
なのでpullはfetch + mergeと覚えておきましょう。
pullとfetchは似ていますが、実行結果が全く異なるのでしっかりと理解しておいてくださいね。
pullの使い方を下に示します。
git pull リモート名 ブランチ名git branch (ブランチの作成、一覧表示)
ここではブランチの新規作成と一覧表示のコマンドを紹介します。
まずは新規作成です。使い方を最初に紹介します。
git branch ブランチ名例えば、
git branch homeと実行すると、hogeという名前のブランチが作成されます。
作成されるだけで、hogeブランチに移動はしません。
(ブランチの移動方法は後ほど紹介します)
次に一覧表示です。使い方は以下の通りです。
git branch // ブランチの一覧と自分が今いるブランチを教えてくれる
git branch -a // リモートのブランチも含めて教えてくれる開発を進めていく中で、ブランチは一個や二個では収まらないことがほとんどです。
そうなってくると今自分はどのブランチで開発しているのかがわからなくなることがあります。
そんな時に上記のコマンドを実行することで、どのブランチにいるのかがわかります。
また、ブランチの移動の際に、移動先のブランチの名前を調べる時にもよく使うので覚えておくと便利です！
git checkout (ブランチの切り替え)
ここではブランチの切り替えのコマンドについて解説します。まずは使い方です。
git checkout ブランチ名 // 既存ブランチに移動
git checkout -b ブランチ名 // 新規ブランチを作成して移動git checkoutコマンドを使用することでブランチの切り替えができます。git checkoutでは作成済みのブランチしか指定することができません。
なので先ほど紹介したgit branchコマンドで現在あるブランチを一覧で表示して、そこに書いてあるブランチ名を指定してブランチの切り替えを行います。
また、-bオプションをつけることもできます。このオプションをつけることで、ブランチの新規作成と切り替えを同時に行うことができます。
新機能開発を行うとき、最初にこのコマンドを実行することが多いです。
git merge (マージ)
ここではマージのコマンドを紹介します。
まずマージとは何かを簡単に説明します。マージとは、他のブランチの作業内容を自分のブランチに取り込むことです。
例えば、アプリを作成しているとき、今完成している機能はmasterブランチで管理します。
(基本的にmasterブランチを完成品です。実際に世に出すのはこのmasterブランチの内容であることが多いです。mainブランチという名前のこともあります。)
そこにブランチAで新機能を開発しました。このブランチAの内容をmasterブランチに取り込むことをマージと言います。
では使い方を見てみましょう。
git merge ブランチ名
git merge リモート名 ブランチ名mergeはローカルブランチからだけでなく、リモートブランチから取り込むこともできます。
しかし実際はリモートブランチに他のブランチからマージすることが多いです。
ブランチの変更、削除
ブランチの名前を変えたり、ブランチ自体を削除する方法を紹介します。
まずは変更についてです。
git branch -m 新しいブランチ名このコマンドを実行することで、今作業中のブランチ名を変更することができます。
git checkout -bコマンドでブランチを新規作成した際に、スペルが間違ってしまうことなどはあり得ます。
そんな時にこのコマンドで名前を修正しましょう。
次に、ブランチの削除についてです。
git branch -d ブランチ名 // masterブランチにマージしていないブランチは削除しない
git branch -D ブランチ名 // 強制削除-dコマンドではマスターにマージされてないブランチは削除しません。つまり先ほどの例で言うと、ブランチAで新機能を開発したのに本番環境(masterブランチ)にマージしていない場合、-dオプションではブランチAを削除することはできません。
一方、-Dオプションを利用するとどんなブランチでも削除できます。
基本的に-d オプションを利用することが安全で良いと思います。
git branch コマンドはオプションで色々な挙動をするので一つずつ覚えていきましょう！
git stash (変更の一時避難)
ここでは変更を一時退避させるgit stashコマンドについて紹介します。
まずなぜ変更を一時退避させる必要があるかを説明します。退避なんてしなくてもcommitすればいいと思うかもしれませんが、コミットは保存のように何回もしすぎると分かりにくくなってしまいます。
stashを使う場面として一つ例を挙げます。
ブランチAで機能Aの開発をしている時、緊急で機能Bのバグの修正を行う必要が出てきました。
機能Aの開発は途中なのでcommitするわけにはいきません。さらに機能Bの修正をするためにはブランチBに移動する必要があります。
コミットしていない変更があるとブランチの切り替えは行うことができません。
このような場合にstashを使って変更を一時避難させます。
使い方を見てみましょう。
git stashとてもシンプルですね。
先ほどの例だとブランチAでgit stashを実行することで、今加えた変更分を一時避難させます。
そうすることでブランチBに切り替えることができます。
git stashはいくつも同時に実行することができます。
どういうことかと言うと、ブランチAでstashした後にブランチBで作業をしていました。
そこでも同様にstashする必要が出てくると、ブランチBでもstashを実行することができます。
こうなってくると、自分がしたstashがわからなくなってしまいそうですよね。実際わからなくなります。
その時のために自分がstashした内容を確認するコマンドを紹介します。
git stash listこのコマンドを実行することで、どのブランチでstashしているかを見ることができます。
またもちろん、stashした内容は元に戻すことができます。それが次のコマンドです。
git stash apply // 最新のstashを復元
git stash apply スタッシュ名 // 特定のstashを復元上記コマンドによりstashした内容を元に戻すことができます。
最新のstashとは一番最後にstashした内容のことです。また特定のstashを復元する時に必要なstash名は、先ほど紹介したgit stash listコマンドで確認することができます。
おすすめの参考書
gitについてのおすすめの参考書を一応紹介します。私は何冊か持っていますが正直この一冊で十分！！というものがあります。それがこちらです。
何がいいのか。それは図(イメージ)の豊富さと分かりやすさです。
この記事でも大事な部分ではイラストを入れていますが、このテキストではほとんどの部分をイラストで説明してくれています。
正直gitはコマンドを覚えれば誰でも操作することは可能です。しかし、そのコマンドは実際何をしているのかを理解していないまま操作をすると、取り返しのつかないことになります。大袈裟じゃないです！
gitは自分だけが使うものではありません。自分がした操作により他のチームメンバーにとんでもない迷惑がかかることもあります。
しかし、ちゃんとした操作の意味を知っているだけでそのリスクはほとんどなくなります。
(復旧方法も理解できるから)
このテキストはまず一通り目を通すだけで多分ほとんどの人がgitって面白い！と思えるはずです。
そして今後開発を進める中で、この本を辞書代わりに手元に置いておくことでgitに対する不安はなくなるはずです。
amazonのリンクからサンプルを読むことができるので一度目を通してみて、自分にも合うかどうかを試してみてください！！
まとめ
この記事では基本的なgitのコマンドをまとめました。
わからなくなった時に見返してくれるとまとめた甲斐があります！！
本サイトではプログラミングの勉強に役立つ知識をまとめています。
また随時更新していくので確認してみてください。
コメント