More than 3 years have passed since last update.

push後にコードの変更を前のコミットに追加する方法

Last updated at 2020-12-20Posted at 2020-12-17

プログラミングを勉強していると、GitやGitHubを使う機会は非常に多いと思います。
GitやGitHubを使う上でコミットの粒度を綺麗に保つことが大切。

しかし、それが結構難しく、pushした後に「この変更、さっきのコミットに追加したいな」なんて思うことが私は多々ありました。
今回はその時に私が使っている方法を記事にしました。

間違っている部分があれば申し訳ないです。m(_ _)m

コマンド

今回使うコマンドは以下の通りです。

git diff
git commit  --amend
git push origin ブランチ名 --force
git diff HEAD^

一つひとつのコマンドについて詳しく説明します。

git diff

最新のコミット(HEAD)からの差分を見ることができます。

git commit  --amend

git commit --amendを行うと、直前の修正したいコミットと新しいコミットをひとつにまとめてリポジトリにコミットします。直前のコミットはなかったことになります。
ちなみに、amend は「改正する」「修正する」という意味です。

// git push を強制するオプション (２つは同義)
git push origin ブランチ名　--force
git push origin ブランチ名　-f

無理やりリモートリポジトリの履歴を上書きします。
このコマンドを使う場合は注意が必要です。（以下「git push --force を使う場合の注意点」参照）

git diff HEAD^

コミットの変更が追加できているか確認します。

本来、明示的に git diff HEAD^..HEAD と書くことで、「最新のコミット」と「最新のコミットのひとつ前」の差分を表示します。ただし..HEADを省略しても、暗示的に現在のブランチの最新のコミット(HEAD)を示すことになるので、この書き方でも大丈夫です。

強制 push は、自分ひとりで作業しているブランチではそれほど問題にはなりません。
一方、チームで開発を行っており、共有されたブランチを強制的に更新するときは注意が必要です。

もし、強制 pushで削除されたコミットを起点にして、チームメンバーがローカル環境で開発を進めていた場合、チームメンバーの次の push でコンフリクトが発生してしまいます。
また、すでに存在しない状態をベースに開発を進めてしまうため、全ての前提が崩れてしまう可能性さえあります。

チームメンバーが多いほどこの問題は発生しやすいため、共有されたブランチでの強制 push は避けるべきです。

今回久しぶりに記事を書きました。記事を書いていると、普段何気なく使っていたコマンドの意味や新しい知識を得ることができ、アウトプットの重要性を改めて感じることができました。
これからはアウトプットの量も増やしていきたい。

参考記事