未来エンジニア養成所Blog

月単価180万以上のプログラミング講師がプログラミングを皆に楽しんでもらうための情報をお届けします。

【Git&GitHub】リベースでの注意

title


リベースでしてはいけないこと

今回はリベースでしてはいけないこと、リベースの運用上の注意点について見ていきます。


リベースでしてはいけないことは、GitHubにプッシュしたコミットをリベースするのだけはしないようにしてください。

逆に言うと、これさえ気をつけて頂ければ大丈夫です。


では、GitHubにプッシュしたコミットをリベースすると何が起きるのか確認しましょう。

いまローカルで「コミット1」があって、それをmainブランチが指しているとします。

リベースでの注意1


その状態からfeatureブランチを作成してコミットして「コミット2」ができました。

リベースでの注意2


それを「git push」コマンドでGitHubにアップします。

リベースでの注意3


この状態から、再度ローカルに戻って作業します。

別のブランチで作業して、「コミット3」を作りました。

リベースでの注意4


ここで、「コミット2」に「コミット3」の変更内容を取り込みたい、しかも履歴を綺麗にした形で取り込みたいとなりました。

ですので、featureブランチにいる状態で「git rebase」をしました。

リベースでの注意5


すると、「コミット2」の親コミットが「コミット1」から「コミット3」に変更されます。


「コミット2」というのはGitHubにもうプッシュしたコミットです。

GitHubにプッシュしたコミットを今回リベースしました。

その状態で「git push」コマンドをすると何が起きるのか。

このリベースしたコミットというのをGitHubに「git push」しようとした場合、なんと「git push」できなくなります。

リベースでの注意6


これは何が起きているのかというと、「コミット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」は絶対に使わないようにしましょう。


参考図書



独学で挫折しそうになったら、オンラインプログラミングスクール
未来エンジニア養成所Logo



あわせて学習したい

phoeducation.work



【まついのLINE公式アカウントはこちらから!】
Line公式アカウント