Gitで操作ミスしたときに読む記事

Git loverの皆さん、今日もgitコマンド使い倒していますよね。

みんな大好きなgitを操作しているとヒヤリハットするときありますよね。

筆者も過去に

上司のコミットを吹き飛ばす
頑張って自分で書いたソースコードの変更を無に帰す
コミットしたいブランチを間違えてデフォルトブランチをレビューなしでPUSHした

など数多くの取り返しのつかないことを経験しています。

そんなしくじりを学びに変えるべくこの記事を書きます。

具体的なケースとどう対応すると良いのかを連ねていきます。

プロジェクト独自のリポジトリ運用ルールに従わないで作業した

コードの変更を行ってコミット完了！

そしてVSCodeの左下を見て、git branchコマンドを打ってブランチを確認すると develop, main だった。

まだ慌てるような時間じゃない

心を落ち着けて下の格言を読んでほしい

pushするべからず

あなたがローカルリポジトリに対してコミットをしただけならpushさえしなければリモートリポジトリを汚してしまうこともない。

ひとまず落ち着こう。落ち着いて対応すれば大丈夫。

reset/rebaseもするべからず

ここで「よし、すぐにコミットを消そう」とも思ってはいけない。

頭では対応がわかっていても気持ちはまだ焦ったままだ。

安易に git reset --hard HEAD^ なんてコマンドで先頭のコミットを消したらあなたの作業は無に帰してしまう。

そんな悲しい事にならないために、まずはブランチを切ろう。

git switch -c temp

これで一時的にブランチを作ってあなたの作業を守るんだ。それからコミットを消す対応をしても遅くはない。

ちなみにコミットの削除についてはこちらで解説しているからぜひ見てほしい。

もう一度言う。すぐにコミットを消そうとしてはいけない。

git push -fでリモートブランチの過去を改変した

さて、よいこのみんなは git push -f なんてコマンドはほぼ使わないはずだが、これを一人でやってしまう可能性もある。

ちなみにこのコマンドはリモートのUpstream Branchに対して強制的にコミット履歴を書き換えてしまう操作をする。

コマンドなんて上キーを何度か打てばだいたいやりたいことを遡れるからこんな危険コマンドもすぐに打ててしまう。

そして気づいた頃にはforce pushが完了して頭が真っ白になる。

ひとまず落ち着こう。そして下を読もう

他のチームメンバーに復元可能かすぐに連絡だ

デフォルトブランチはチームのみんなは事あるごとにpullしているはず。

今あるべきの姿を持っている人を探して再度force pushしてもらえればあら元通り。

その時にはチームメンバーに目一杯感謝しよう。

ちなみにforce pushはGitHubなどのBranch rulesで禁止することができます。仕組み的に防ぐならむしろこっちが推奨。

git add * で入ってほしくないファイルがcommit/pushされてしまった

特にAPIキーなどシークレットキーなどのファイルがpushされたら世の中の悪人たちが一斉にその情報を使って良からぬことをするだろう。

これも落ち着いて対応しよう。

まずは早めにキーの再発行だ。

公開されてしまったキーを使えなくすれば良からぬことにも使えまい。

ただ気をつけるべきはサービスで使っているキーを使えなくしてしまったらサービスが動かなくなること。

自分たちのサービスが不用意に止まってしまったらせっかく獲得したユーザーたちが離れてしまう。そんな悲しい未来を誰も望んでいない。

必ずわかる人と一緒に作業をしよう。ここでのお約束だ。

そして大事なのはとにかく仕組み化だ。人である以上誰もが間違う可能性がある。

おすすめするものは２つだ。

.gitignoreでシークレットがリポジトリに上がらないようにする

シークレット情報が1ファイルである場合はgitにコミット自体されないようにignoreに追加しよう。

これだけでも十分に効果はある。

Secretlintを導入する

ソースのファイル内にシークレットを書いてしまう場合もあるだろう。それを防ぐにはSecretlintでgit-hooksを入れると良い。

そうすることでコミット前に検知が可能になりSecret情報をコミットしたら失敗させる事ができる。

むしろグローバルに設定して上げるとどんなプロジェクトにも効いてより良いだろう。

最後に

楽しく開発を続けるためにも常に落ち着いていこう。