プログラムのコードを修正した後に、
あ、しまった。考慮漏れのパターンがある。この修正ダメじゃん。
ということは、多々あること。
だから、git addやgit commitの取消等はしっかり覚えておかないといけないですね。
git addする前のファイルの変更の取消、ファイルの削除
エディター(VSCode等)のソース管理からも対処できるし、エディターから間違いを修正しちゃえばいいじゃんとも思うけど、とりあえずgitコマンドからの対処を記載します。
git addする前のファイルを削除する
cancel/before-add1.html、before-add2.htmlというファイルを作成。
そこに、作成したファイルを削除するための
git clean -f 「ファイル名」
を投入。
ファイル名が削除されました。
しかし、git add前の削除ならエディターからファイルを削除してもできますからね。
わざわざコマンド使う人も少ないでしょう。
git add する前の変更を取り消す
ファイルの変更を取り消すときには
git restore 「ファイル名」
を投入します。
変更が取り消されています。
この変更作業の取消は、エディターを使うよりもgitの機能を使った方がいいかなと思うところはあります。
git addしたものをすべて取り消すなら、
git restore .
で、全取消です。
git addした後のファイルの変更の取消
git addは比較的軽い気持ちで実行してしまうコマンドじゃないかと思います。
だから、git addからの取消というのが、一番使うんじゃないでしょうか。
git addで、stagingしたコードを、
「ちょっと待てよ。」
と思って、working Treeに戻すというのが一番多いんじゃないでしょう。
その時使うのが、
git restore --staged 「ファイル名」(すべてファイルの時は”.”)
ファイルをgit addでstagingした状態。
git restoreを投入すると、ファイルがworking Treeに戻っています。
get reset
コマンドを使っても同様のことができます。
git commit後のファイルの変更の取消
git commit後の取消は３種類あります。
では、ファイルをcommitした状態でスタート
stagingに戻す:git reset –soft HEAD^
git commitしたファイルをstagingまで戻すコマンドは、
git reset --soft HEAD^
コマンドを入力すると、ファイルはcommit状態からstaging状態に移行します。
working Treeに戻す:git reset –mixed HEAD^
git commitしたファイルをworking Treeまで戻すコマンドは、
git reset --mixed HEAD^
コマンドを入力すると、ファイルはcommit状態から、working Treeでの変更状態に移行しています。
無かったことにする:git reset –hard HEAD^
その変更自体いらない。ファイルも削除していい。
というときは、
git reset -- hard HEAD^
コマンドを投入すると、新規で追加したファイルも無くなる状態に。
ファイルの追加・変更自体がリセットされます。
commitのコメントを修正したい。
取消ではないですが、commitのコメントを修正したいということは多々あるでしょう。
それには、
commit --amend -m "修正後のコメント"
です。
commitのコメントって後々まで残りますから、間違ったらしっかり修正したいですね。
ただ、pushしたものを変更するとコンフリクトが発生するので、pushした後のコメントを修正するときは、根性入れて対処しましょう。
git pushを取り消す
githubへのpushを取り消したい…当然ありますね。
その取り消しには
の２種類があります。
commitの履歴を残す方法:git revert
準備
まずは、push-cancel.htmlというファイルを作ります。
作成したファイルをcommit & push。
git revert
git revert 「commit ID」
を投入すると、revertに関するコメント入力を求められる。
VSCodeターミナルで実行すれば、VSCodeのエディターが使えるので便利。
get revertを投入して、コメントを入力すると、working Treeから新規追加したファイルが削除され、その削除のcommitが作成される(「revertした」というcommit)。
revertしたcommitをpushすることによって、githubにアップロードしたpushがキャンセルされる。
キャンセルされたcommitもrevertしたcommitも残るので、「commitの履歴を残す」ということになる。
commitの履歴を残さない方法:git reset –soft 「commit ID」
準備
最初にファイルとgithubに「push.html」をpush。
git reset
push済みのcommitを
git reset --soft 「commit ID」
で、取消。
githubからpushしたcommitが消えました。
git mergeを取り消す。
mergeの取消も、pushの取消のように
があります。
mergeを取り消す前のmergeの状態
以下のコマンドでもチェックできます。
git show
でチェックしておくと便利。
merge先とmerge元のcommit IDなんかもチェックできます。
履歴を残す:git revert -m 「残す方の番号」 「commit ID」
revertを使うとちょっと複雑になりますね。
git revert -m 「残す方の番号」 「commit ID」
git revertをする前に、git showでmergeの情報をチェック。
今回は、ｍainの方に倒すということで「残す番号」は1としてget revert投入。
そうすると、practice branchのmergeがrevertされました。
mainとpracticeで差分があるから、またmergeどうなるんだろう。
と思うところですが、
すでに、mergeはされています！
そうか、履歴を残す取消だから、mainのコード上に存在しなくても、それはすでにmergeしたものとして扱うんだな。
では、もう一回practiceでadd commit してmergeすればいいじゃん。
そうすると、なんとコンフリクトが発生します。
え～、main branchのソースとpractice branchのソースではファイルも修正もかぶっていないのに。
なんで～！
ここでよく考えてみると、すでにmergeを実行しているので、practice branchのコードはmainに反映されています。
それを履歴つきのrevertで取り消したのですから、取り消したmergeの時のcommitとはコンフリクトを起こすのですね。
ちょっと、違和感はありますが、よく考えてみれば「履歴を残してある」ので、納得です。
こんな時は、冷静にコンフリクトを解消しましょう。
履歴を残さない:git reset –hard ORIG_HEAD
git reset --hard ORIG_HEAD
コマンドを投入すると、main branchにはpractice branchで追加したファイルが無くなっています。
さらに、Git Graphでみると、mainとpracticeは分かれて、maerge前の状態に戻りました。
※この記事は「git/github」に関する備忘録です。
