プログラマーデビューして約1年弱、その期間でよく使ったGitコマンドまとめです。
基本的なコマンド紹介ではなく
「◯◯の状態を◯◯したい」
というような例を上げて紹介していこうと思います。
コミットログを書き換える手法も紹介していくので、会社のプロジェクトチームの規約によっては好まれない場合もあるかもしれません。
conflictが出ている時にスマートに解消する
git pull –rebase origin
「作業ブランチ」と「開発ブランチ」でconflictが出ている場合に解消させます。
例：開発ブランチはdevelop。現在は作業ブランチで作業している。
$ git pull --rebase origin develop 〜conflictをエディタで修正後〜 $ git add . $ git rebase --continue $ git push --force-with-lease
conflict自体は発生するのでgit pull --rebaseは高頻度で使います。
基本的に開発ブランチから切った作業ブランチの状態は「最新の開発ブランチの状態」と同じにしておきたい。
「PRを見てもらう前」「マージする前」など使う機会は多かったです。
git pull --rebaseを使っている理由は以下の説明とかが分かりやすいです。
git pull と git pull –rebase の違いって？図を交えて説明します！/ KRAY
マージコミットは基本的に不要だったのでgit pull --rebaseを使っていました。
ローカルをリモートと強制的に一致させる
git fetch & git reset –hard
細かいことはどうでもいいので、「ローカル」と「リモート」を一致させたい時に使う。
例：「なんかローカルで色々修正加えたけど、リモートの最新の状態にとりあえず戻そう！」
$ git fetch origin branchA $ git reset --hard origin/branchA
ここではbranchAで作業していた想定。
「指定したブランチの（リモートの）現在の状態」に強制的に一致になることに注意する。
ブランチのコミットを1から積み直す
git reset –soft & git reset . & git push –force-with-lease
「レビュー → 修正」の繰り返しで
「◯◯の修正」
「◯◯の修正」
「◯◯の修正」
みたいなコミットがたくさん積み上がる時ってあると思います。
その場合、紆余曲折を経てレビュー終了後
「即マージ」
とするのはマズイ時があります。
理由は簡単でこのままマージするとコミットログが汚くなるからです。
（「◯◯の修正」だらけのコミットログになる）
そこでコミットログをキレイにするために、コミットを再度積み直す時に使います。
$ git reset --soft develop $ git reset .
作業ブランチは「develop」から切ったブランチを想定。
やっていることは、
「コミットの取り消し（ブランチを切った直後まで）」
「ステージングからの取り消し」
なお、git reset --mixed developだと一行で済む。
ちなみに origin develop指定するとdevelopが進んでいた場合に厄介になる。
コミットを積み直した後は
$ git push --force-with-lease
で強制的にpushする。
基本的に一つのブランチで共同開発することはなかったので git revertはあまり使わなかった。
（revertのコミットは好まれなかった。）
リモートにpushしたコミットを元に戻す
git reset –hard & git push –force-with-lease
「やっぱpushしなければよかった！」という時に元に戻す方法。
「リモートにpushしたコミット」というものを跡形もなく消す方法。
「コミットID」は戻したいコミットの一つ前を指定して git resetする。
HEAD指定の方は例として一つ前を指定している。
$ git reset --hard コミットID or $ git reset --hard HEAD^
これで「ローカル」は戻したい状態まで戻る。
次のコマンドで「リモート」を戻す（ローカルと一緒の状態にする）
$ git push --force-with-lease
これで戻った「ローカル」の状態を「リモート」に強制的にpush。
これで結果的にpushしたコミットが取り消された事になる。
別のブランチから特定のファイルだけ持ってくる
git checkout
「他の人が別ブランチで開発しているファイルを試しにこっちのブランチでも使いたい」
「でもまだ開発ブランチにはマージされていない・・・」
git checkout で特定のファイルだけを持ってくる事も出来る。
$ git checkout ブランチ名 -- ファイル名 $ git checkout origin/sample -- app/assets/stylesheets/sample/sample.css.scss
例としてsampleブランチを指定している。
指定したファイルがgitでいつ変更されたかを確認する
git log -p
「このファイル、自分の知らぬ間に変な修正が入っている・・・」
「誰がいつ修正を加えたかチェックしたい」
そんな時もコマンドでサクッと確認出来る。
$ git log -p ファイル名
gitの操作を間違えた！
git reflog
gitで操作していると結構ミスをすることがある。
例えば、git reset --hardで戻りすぎたり、rebase間違えたり、ブランチ消したり。
そんな一見「致命的に見えるミス」でも、「履歴」から戻ることが出来るのがgitの凄い所
$ git reflog
$ git reset --hard HEAD@{1}
git reflogではHEADの移動履歴というものが見れる。
その移動履歴をHEAD@{n}という形で指定してあげてgit reset --hardすると元に戻れます。
ここでは@{1}を指定しているので、HEADの履歴を1つ前に戻していることになります。
上記のようなミスはこのreflogで大抵カバー出来ます。
しかしHEADの移動を伴わないgitの操作は戻せないので注意。
まとめ
もっとGitコマンドを使いこなそう
おわり
コメント