Git amend pitfalls

[chuckadams]

@willybeans

• When you forget to delete that one console log in your PR but you dont want anyone to see you write a second commit just for that: git reset HEAD~1 → git add → git commit -m → git push origin + (that plus is what forces the push) WARNING: only do this before it is reviewed because it does break stuff for other people

No need for all that. Just use git commit --amend. Like the above, don’t do this if you’ve already pushed the previous commit.

[willybeans]

Ah, thank you! What are the instances where this isnt safe? I noticed in ohshitgit that it said this will break things if being pushed to a shared branch, but im not clear on what constitutes a ‘shared’ or ‘unshared’ branch if im always working on on local branches that go into dev branches. If im pushing to a dev branch, that is technically shared, right? Or am i missing something?

[chuckadams]

“shared” just means someone else might use the branch, it doesn’t have any technical meaning. In this case, it doesn’t matter if it’s shared or not. git commit --amend rewrites the last history entry to include your current changes, but if you’ve already pushed to a remote, the remote won’t rewrite its history to match yours (you can force it, but never ever do that). So you end up with divergent history, which is never fun.

In specific terms, this is what isn’t safe:

git commit
git push
... make changes ...
git commit --amend   # diverges due to having already pushed

(moved this part of the thread to the DevOps sub-forum, the name of which I am never going to like)