.png)
リベースでしてはいけないこと
今回はリベースでしてはいけないこと、リベースの運用上の注意点について見ていきます。
リベースでしてはいけないことは、GitHubにプッシュしたコミットをリベースするのだけはしないようにしてください。
逆に言うと、これさえ気をつけて頂ければ大丈夫です。
では、GitHubにプッシュしたコミットをリベースすると何が起きるのか確認しましょう。
いまローカルで「コミット1」があって、それをmainブランチが指しているとします。
その状態からfeatureブランチを作成してコミットして「コミット2」ができました。
それを「git push」コマンドでGitHubにアップします。
この状態から、再度ローカルに戻って作業します。
別のブランチで作業して、「コミット3」を作りました。
ここで、「コミット2」に「コミット3」の変更内容を取り込みたい、しかも履歴を綺麗にした形で取り込みたいとなりました。
ですので、featureブランチにいる状態で「git rebase」をしました。
すると、「コミット2」の親コミットが「コミット1」から「コミット3」に変更されます。
「コミット2」というのはGitHubにもうプッシュしたコミットです。
GitHubにプッシュしたコミットを今回リベースしました。
その状態で「git push」コマンドをすると何が起きるのか。
このリベースしたコミットというのをGitHubに「git push」しようとした場合、なんと「git push」できなくなります。
これは何が起きているのかというと、「コミット1」の次のコミットがGitHubでは「コミット2」、ローカルでは「コミット3」とそれぞれ別になっていて違うよと怒られて「git push」できません。
GitHubの方を見てみると「コミット1」の次のコミットは「コミット2」になっています。
それに対して、ローカルの方のコミットの履歴、つまり今「git push」したGitの履歴は「コミット1」の次のコミットは「コミット3」になっています。
同じfeatureブランチの情報にもかかわらず、GitHubにあるものとローカルにあるもので、情報が矛盾しているのです。
そのため、GitHubの方で、どちらを優先して良いかわからなくなってしまうのです。
このようになった場合、GitHubは今自分の情報（GitHubにアップされている情報）を優先してローカルから新しく「git push」された情報を受け取らないという行動にでます。
そのため、GitHubにプッシュしたコミットをリベースして、それを「git push」すると、「git push」ができなくなってしまいます。
GitHubにプッシュしたコミットをリベースするのだけは絶対NGです。これだけはやめにしましょう。
もしGitHubにプッシュしたコミットの内容を修正したい場合は、コミットの履歴を修正するのでは無く、もう一度作業して、新しいコミットをしてその内容を修正するようにしてください。
それともう1点、追加で押さえておいて欲しいことが、「git push -f」は絶対に使わないようにしましょう。
これは何かというと、GitHubにプッシュしたコミットをリベースすると「git push」できなくなるのですが、この「git push -f」（fはforce「強制」するの略）コマンドを使うと、今あるGitHubの内容を上書きして、強制的にGitHubにプッシュすることができます。
プッシュできなくなったので、「git push -f 」で強制的にプッシュすることができてしまうのです。
このようなやり方をすることもできるのですが、これをするとGitの履歴が完全に壊れてしまいます。
そのため、「git push -f」は絶対に使わないようにしましょう。
参考図書
独学で挫折しそうになったら、オンラインプログラミングスクール
