現場で実際に使うGitコマンド

はじめに

Gitコマンド使っているでしょうか。 現在だとSourceTreeやGitHubDesktopなど数々のGUIがありますが、現場ではコマンドを使うことが多いかといるかと思います。 でも、便利なGUIがあるのに使わない理由とは何なのでしょうか。 おそらくですが...

  • コマンドのほうが早い
  • IDEからのGUIへの切り替えがめんどくさい
  • そもそもGUIだと処理が重いときがある
  • ポチポチがエンジニアとしてかっこ悪い

とかでしょうか。けっこう最後のかっこ悪いを意識している人もいますね。

コマンドで何ができるの?

では、Gitコマンドで何ができるのって話ですが、GUIでできていることほとんどできます。 GUIのほうが便利なシーンもありますが、それは稀なので、稀なときにGUIを使って、普段はコマンドで十分用をなします。 では、コマンド見ていきましょう。

ほとんどこれだけ

git init

GUIだと連携しているGitHubプロジェクトから簡単に持ってこれるので何も意識しないでしょうが、 コマンドだと、まずgit initしないとその場所にgitプロジェクトを展開できません。 まずこれをおまじないとして実行します。

git clone git@github.com:userName/repositoryName.git

こちらもGUIだとただポチっとするだけですが、コマンドでは、cloneというものを実行します。 これでそのリポジトリを持ってこれます。

ここまでは、確かにGUIでやってもいいですが、慣れるとコマンドほうがスムーズにいくことも多くなると思います。

git checkout -b feature/hogehoge

ブランチの作成&チェックアウト同時にします。

  • ブランチ ... その親ブランチ(masterやdevelopといったもの)から枝をはやします
  • チェックアウト ... 現在あなたがいる居場所を移動します。

git branch feature/hogehoge でもブランチを作れますが、そのあとそのブランチに自分の居場所を移動する必要があります。 それを同時にしてくれるのがこれです。

git status

現在の状態を見ます。 変更点の確認で多投すると思います。

git pull

リモートの状態と差異があるとき、ローカルを最新にしたいです。そのときはこれ。 pullはfetchとmergeというものを一気にしてくれるコマンドで、ほとんどこれだけで用をなせます。 ここの中身の仕組みは知っておくと理解が深まるかと思います。

git add .

変更したファイルをインデックス(コミットされる情報)に追加します。

git reset HEAD
git reset HEAD core/src/main/resources/application.properties
git reset --soft HEAD~
git reset --hard #コミットid

resetは色々取り消すときに使います。

  • 1番目は、インデックスを取り消します。addをミスしたので全て取り消したいときなどに使うことが多いです。
  • 2番目は、特定のファイルのみaddを取り消します。これも変更不要なファイルをaddしちゃったときによく使います。
  • 3番目は、コミットの取り消し時に使います。変更している内容は残るので安心コマンドです。
  • 4番目は、コミット、インデックス、変更内容もすべて取り消します。コミットidはログから追えます。git revertという便利コマンドでもできますがログが残らないので注意です。

HEADとかHEAD~の仕組みは知っておくと理解が深まるかと思います。 HEADは現在地、HEAD~は現在地から1つ前、HEAD~2なら現在地から2つ前、といった意味です。

git commit -m "fix: refactoring shopping cart controller"

そしてコミットはこれ。 これでようやく、ローカルリポジトリに反映されます。 まだリモートリポジトリには反映されていません。

git commit --amend

コミットがいくつもできるとログが見にくくなります。 同じ領域の修正なら1つのコミットで集約するべきです。 そんなときにはこれ。これで、1つにコミットに集約できます。

git push

これでGitHubならGitHub反映です。

番外編

git stash

あまりstashは好まれない傾向のようですが、急ぎのときは私も使います。 ちょっとした調査が入り、修正前の状態にすぐにブランチ切り替えたいときに、stashです。 一時的に保存しておき、調査が終わったら戻すかんじです。 本来はcommitですべて補えますので、stashは本当にそんときの気分次第かもしれません。

git branch -d feature/hogehoge

ローカルブランチの削除です。 よく使うわけではないですが、ブランチが増えてきての削除のときに使います。 または、どうしてもブランチが元に戻せないなど、困ったときはこれでチャラにしたりも数年に数回あるかもしれません。 あるなら、hotfix的な対応が入ったときや、複数開発が動いているとどうしてもブランチ管理が複雑になるときがあり、そういうときはあるかもしれません。

git log --graph

コミットのログを見たいときはこれ。 このあたりはいろいろプロパティあるので、もっと見やすくできたりします。 ログに関してはGUIが勝っているので、そちらを見るのがいいと思います。 ちょっと見たいぐらいならコマンドでいいのではないでしょうか。

まとめ

他にもrebaseやconflictマージなど難しいものもありますが、それは多投するわけでもないので今回は省略します。 あと、gitコマンドをaliasに登録することで、毎回長ったらしいコマンドを打たなくてよくなります。 git log --graphglg など。

でも、現場開発での8,9割はここにあるコマンドで開発できちゃうのが現実です。 Gitの1,2割しか使っていないのではないでしょうか。やはり、プログラミングでも実際によく使われるのは2割です。 現実はそんなものなんだ、となってもらえればと思います。