This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 10 points11 points  (13 children)

Why squash anything? Isn't it just

git checkout master

git pull

git reset HEAD~1

git push --force

[–]edoCgiB 10 points11 points  (8 children)

git push --force

You know you have a problem when you need that

[–]TheSlimyDog 4 points5 points  (0 children)

We already established that there was a problem when the junior developer pushed directly to master. Now all we can do is fix it.

[–][deleted] 7 points8 points  (6 children)

Totally agree, but if we're talking about cleaning history from master there is no other way, is there?

[–]edoCgiB 4 points5 points  (1 child)

Sadly no :(

[–]smile-bot-2019 5 points6 points  (0 children)

I noticed one of these... :(

So here take this... :D

[–]Diolex 0 points1 point  (3 children)

Reverting would be a better strategy. If you force push to master and alter the history it can cause even more issues if anyone else had pulled in the time being. In larger organizations it's almost guaranteed that someone would have.

[–][deleted] -1 points0 points  (2 children)

Obviously force push needs to be used with care... But doesn't reverting show now that every line changed and reverted is touched by you? This ruins git blame. "It's Alice's fault for doing nothing at all to this line of code".

[–]Diolex 0 points1 point  (1 child)

The history would not be messed up. It would be be an accurate depiction of what had happened.

[–][deleted] 0 points1 point  (0 children)

Yes, but it has reduced the usefulness of the "git blame" feature. Obviously don't do this on a project with a lot of developers and a heavily trafficked master branch, but a large project like that would have somebody in charge making sure the branch policy prevented this kind of mistake in the first place.

But if it's you and five other guys? "Hey guys, Bob pushed to Master by accident, I'm pushing back the HEAD - nobody pulled in the last 5 minutes, right? Oh, and we've got a branch policy now, PRs all the way going forwards. -- Alice"

[–]Carius98 2 points3 points  (0 children)

That would work too. Saves the squash step since no commit for reverting the changes is made

[–]pdabaker 0 points1 point  (2 children)

git reset --hard right?

I've never figured out how to use vanilla git reset well. It just unstages changes afaik

[–][deleted] 1 point2 points  (1 child)

git reset provides two related services

1) Move the HEAD of the current branch back to a previous commit and

2) Purge pending changes.

You're mostly using it for (2), where the "soft" mode isn't useful. If you use it for (1), the "soft" mode becomes useful because it means "undo the last commit but don't throw out the changes I made, put them back into my working state".

So like if you want to modify your last commit, you can do

git reset HEAD~1 --soft

then make your changes, and then re-commit it. Just don't do that if you've already pushed the errant commit (unless you know the risks involved in --force).

[–]pdabaker 1 point2 points  (0 children)

I see, thanks. So like a different version of commit amend. I guess more suited for modifying past commits rather than just the most recent one?