0
1

More than 3 years have passed since last update.

【git初心者】gitでやらかした時の対応まとめ

Last updated at Posted at 2021-01-22

初心者なのでgitでやらかすことが多いです。
やらかした時の対応をよくやるレベル・ケース別にまとめました。

よくやるレベル1:けっこう頻繁にやるやつ

頻繁にやらかすので割と慣れてきた感のある対応です。

ケース1:間違えてgit addしてしまった

% git reset HEAD .
Unstaged changes after reset:
M   app/path/file.php

複数ファイルあるうち特定ファイルのステージング(add)のみ取り消したい場合は、カレントのところをパスにする
ちなみにHEADは最新のコミットハッシュのエイリアス
git push origin HEAD とかするけど最新のHEADをプッシュすることだったんですね

ちなみにgit add済みと取り消し後のステータスの違いは下記。
<add済みの状態>

% git status
On branch feature/update_bootstrap
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   app/config/bootstrap.php

<add取り消し後>

% git status
On branch feature/update_bootstrap
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   app/config/bootstrap.php

ケース2:間違えてgit commitしてしまった

大体addと共に歴史から抹消したいので下記を使う

git reset --soft HEAD^

git add(ステージングした状態)は残る。
コミットしたもののうち特定のファイルのaddだけ取り消す、等の場合はオプション指定で場合分けをするみたいです

ケース3:git commitする内容を間違えた

git commit --amend

現在のワーキングツリーの内容を上書きする
コミットメッセージまで変更したい場合は下記

git commit --amend -m "<コミットメッセージ>"

ケース4:間違えてgit pushしてしまった

まずはローカルのインデックスの状態をHEADに戻し、その状態をプッシュする
プッシュする際はエラー回避のためオプションをつける

git reset --hard HEAD
git push -f origin HEAD

ケース5:ブランチの名前を間違えた

ローカルブランチの名前変更

git branch -m <ブランチ名(変更前)> <ブランチ名(変更後)>

もし間違ったブランチ名のままプッシュしてしまっていたら、間違った名前のリモートブランチを削除し、正しい名前のブランチに再度プッシュする

git push origin :<ブランチ名>

間違った名前のリモートブランチに色々変更を加えてしまっていたらどうするんだろう。
ローカルにプルしてローカルでブランチ名変更して改めてプッシュ?
きっと上記より便利な方法がありそう(そんな事態に陥ったら調べる)

よくやるレベル2:たまにやらかして少しひるむやつ

これを乗り越えて少しずつgitに慣れてきました。
(乗り越えられなくて数時間分の作業が消えたこともあった)

ケース1:ブランチを間違えてプッシュしてしまった

正しいブランチに作業した内容を反映したい、ローカルブランチでのコミットまでは正しいブランチで作業している想定
間違えてプッシュした先の修正は不要なパターン

//push先を指定
git branch --set-upstream-to=origin/<ブランチ名>
git push

ケース2:プッシュしたらファイルのサイズが大きくエラーになってしまった、さらにそれに気付かないままローカルで作業を行っていた

もう一度コミットからやり直す必要があるけど、ローカルで行っていた作業が含まれない状態でのコミットが必要、プッシュまで終わったらローカルで行っていた作業を元に戻してそれもプッシュしたい、と言う状況です

作業の流れとしては下記で最初考えていたけど

1.今のワーキングツリーを退避:git stash
2.リポジトリの巻き戻し:git reset --soft HEAD^
3.git reset HEAD サイズが大きいファイルのパス
4.該当ファイルを.gitignoreに記載 <-記載するとファイルがコミット対象ではなくなるが実は不要な手順
5.再びコミット
6.再びプッシュ
7.退避したスタッシュを適用:git stash apply
8.再びコミット
9.再びプッシュ

4.は不要、理由は3.でそもそもステージングから外しているから
もし4.を実施した場合、6.までは上手くいくけど、7.でスタッシュを元に戻すときに.gitignoreの状態が違うことで競合してしまいエラーになります。
また、8.を行う前にaddが必要か悩んだけど、git stash applyを行うとadd済みの状態になるため不要なのがポイント

よくやるレベル3:滅多に起こらない災害レベル(人災)

ケース1:gitの挙動が何もかもおかしい

何しても、何もしなくても、git関連の挙動が全て通常では考えられない状態になったことがありました
謂わゆる「リポジトリが壊れた」状態だと思うのですが、壊れるのには理由がある、、
ということで起こった事象の整理から原因の調査、その結果行った対応までまとめたのが下記になります

https://qiita.com/mby/items/80a79b3a65e28d1c782c
本当にこの時はgit扱うの無理だと思った(原因gitじゃなかった)

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1