• WEB

基本+αでおぼえたいGitコマンド・オプション

  • ともぞう
    ともぞう システムちーむ
  • このエントリーをはてなブックマークに追加
基本+αでおぼえたいGitコマンド・オプション

みなさんGit使ってますか?私は毎日使っています。
今回は、add/commit/push/pullなどの基本的なGit操作ができるようになったあとで、+αで知っておくと便利そうなGitコマンド・オプションを淡々と紹介していきます。

紹介Gitコマンド

checkout

checkoutはブランチの切り替えだけでなく、ローカルブランチの作成にも使えます。-tオプションは省略可能ですが、追跡ブランチを指定するとpushpullするときにリモートブランチの指定を省略することが出来ます。

$ git checkout -b <new_branch_name> -t <tracking_branch_name>

また、workingの変更取消もcheckoutで可能です。以下のように変更済みファイル名を指定すると、そのファイルの変更が取り消されます。ファイル名でなく、「.」を指定するとworkingの変更が全て取り消されます。

$ git checkout -- <fixed_file_name>

commit

コミットする際、commit -m 'message'のように使っていると思いますが、--amendオプションをつけることで直前のコミットを上書きすることが出来ます。
直前のコミットの変更内容に修正漏れがあったときや、コミットメッセージを修正したい場合に活用できます。
コミットメッセージを変えずに変更内容のみ修正したい場合は更に--no-editオプションを加えることで、コミットメッセージの入力を省略することができます。

$ git commit -m 'typo'
$ git commit --amend -m 'type'

branch

branchは、現在のローカル/追跡ブランチの状況を確認するのに便利なコマンドです。
オプションを付けずに使用するとローカルブランチの状況のみ確認できますが、-aオプションと-vvオプションをセットで使うと、追跡ブランチと直近のコミットメッセージも一緒に確認することが出来ます。

$ git branch -avv

git branch -avv

remote

remoteは、リモートリポジトリの設定や確認ができるコマンドです。
remote -vで現在の設定を確認できたり、remote set-url <name> <newurl>でリポジトリの変更ができたりしますが、ここで紹介しておきたいのがremote pruneです。
github-flowで開発を進めていると、既に削除したリモートブランチの追跡ブランチがローカルに溜まっていくため、気になって集中できないという綺麗好きな方もいるかもしれません。
remote pruneを使うと、リモートブランチが既に削除されている追跡ブランチを削除することが出来ます。これにより、branch -avvでもクリーンな表示を保つことが出来ますし、git-completionによる補完の際、既に亡きブランチ名に惑わされることもなくなるでしょう。

$ git remote prune <name> [-n | --dry-run]

stash

stashは、workingとindexの状態を一時退避してworkingをHEADの状態まで戻すことが出来るコマンドです。
例えば、Aブランチで作業中にBブランチの確認や修正作業が必要になったときの活用法を考えると、

  1. Aブランチで途中まで行っていた変更をstashして一時的に退避する
  2. Bブランチにcheckoutして確認や修正(fix->add->commit->push)を行う
  3. Aブランチにcheckoutして一時退避した変更を戻す

というような使い方ができます。
保存する場合はstash save、保存した変更を現在のブランチに戻す場合はstash pop、stashで保存した変更一覧を見る場合はstash listを使います。
stash saveに関しては以下の例にもありますが、コメントを省略する場合はgit stashのみでもOKです。また、-uオプションを付けることで、未追跡のファイル(新規ファイル)も含めて退避させることが出来ます。

$ git stash [save [-u] [<comment>]]
$ git stash list
$ git stash pop <stash>

rebase

もしかすると、Gitがなんとなく使えるようなってきたタイミングで、mergerebaseの違いについて悩む人が少なくないかもしれません。
mergerebaseも、異なるブランチの変更を統合するために使いますが、履歴の残し方が異なります。

$ git checkout topic
$ git merge master

mergeする場合、masterの変更とtopicの変更をマージしたマージコミットをtopicで作成します。

$ git checkout topic
$ git rebase master

rebaseする場合、topicのベースをmasterに置き換えたあと、topicに対して行った変更を新しいコミットとしてtopicに追加し直します。
topicの変更は新しいコミットとして追加し直されるため、コミットIDは新しいものとなります。また、マージコミットが作成されないため、履歴がすっきりとします。

変更内容を統合するという点においてこの2つのコマンドの結果に違いはないため、どちらか一方のみ使って開発するということもできます。しかし、変更を統合した履歴を残すか残さないかという違いを考慮して、場合に応じて使い分けると良いでしょう。
あとでログを見たときにどのタイミングでマージしたかが分かりやすいため、基本的にはマージコミットを残しておき、pullするときのマージコミットが不要であればpull --rebaseのようにオプションを指定してrebaseさせるなどいろいろ考えられます。
rebaseを使うか使わないか、使うとしたらどのタイミングで使うかは、プロジェクトごとにチーム内で決めておくと良いかもしれません。

log

コミットログを表示させるコマンドです。
何かと使う場面が多いとは思いますが、このコマンドにはオプションも多く、自分の好きなようにログ表示をカスタマイズすることができます。
私は普段git log --decorate --oneline --graphのように3つのオプションを使っていますので、今回はこの3つのオプションで表示がどのように変わるのか紹介します。

まずはオプションを何も指定しないデフォルト表示です。

$ git log

git log default

1つ目のオプション--decorateを指定すると、各コミットのブランチ情報が表示されます。

$ git log --decorate

git log decorate

2つ目のオプション--onelineを指定すると、1コミットが1行で表示されます。

$ git log --oneline

git log oneline

3つ目のオプション--graphを指定すると、コミット履歴の樹形図が表示されます。

$ git log --graph

git log graph

これら3つをセットで使うと、以下のような表示になります。

$ git log --decorate --oneline --graph

git log set

締め

Gitは非常に柔軟で、あらゆる操作が可能な優れたバージョン管理システムです。上記で紹介したGitコマンド・オプションはGitのほんの一部に過ぎません。
更にGitの深淵を覗いてみたいという人は、ProGitman git[-<command>]を読んでみることをお勧め致します。

現場からは以上です。

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

ともぞうが最近書いた記事

WRITERS POSTS もっと見る

他にもこんな記事が読まれています!

  • WEB
  • マーケティング
  • サーバー・ネットワーク
  • ライフスタイル
  • お知らせ