Don’t you love when you name your commit and push something like “Fixed x, y, and z” but the actual changes are in the unsaved files you forgot to save, so you have to do, “Actually fixed x, y, and z.”

Use the same commit message like a boss.

@Root commit so good, I had to make it twice

git add whatever-you forget && git commit --amend --no-edit

Changes history, so you have to `git push --force-with-lease` if incomplete commit has already been pushed to the remote.

@k0pernikus I wasn’t aware amend could be used that way, nice. I’ve only used it to change a commit message, not files

@Plasticnova
If not pushed already, you can also squash both with rebase.

git rebase -i

Your new best friend

Sorry guys, rebasing or amending to an already pushed branch that is not your absolute private one, is a no-go. If you do that, you should get fired immediately.

I always do a diff before committing and if necessary do a git show to check the changes again, before they are pushed, to minimize the risk of missing something or leaving temporary development/debugging/testing stuff in.

If I still miss something, it is the way it is and has to be fixed by another commit or a revert, but NEVER change history on pushed stuff

@ddephor Should've been more clear: git rebase -i is a saint (on your unpushed commits)

name the new commit "Remembered to save the changes that actually contain fixes mentioned in previous commit"

Amend commit.

That happens when a colleague does not review your changes.

@aviophile Jesus. You dont use pull request against the master branch at your place?

We do, the OP did not.

@aviophile OP didn't state which branch they pushed to

git commit -am "fixed 4REAL"

@ddephor I disagree. Rebase allows to have a meaningful history in the first place. The "fix it" and "work in progress" commits are what truly makes a git history worthless.

I don't need a history of commits but a history of features. Rebase is fine, if it's your owned feature branch, even it is a remote.

Amend is also rather safe as it is semi-automated. Github and bitbucket allow squash strategry on merge. That all boils down to a rebase in the end just hidden from the user.

I am the last one to teach the manual workflow of `git rebase -i` to newbies, but this dogma of never changing the history has no merits.

You certainly have to now what you are doing and you certainly can mess things up. Yet you can also safeguard. (E.g. protecting the remote's main branch(es) from history changes and deletion.)

In the end it's like gun safety: You can shoot yourself in the foot if you mishandle the weapon, yet this is not the fault of the weapon.

@ddephor This whole fud against rebase becomes really annoying when people even start to freak out on a `git pull --rebase` even though that works completely on the *local* repository avoiding the unnecessary merge commits (merge master into master).

The tango history becomes even more convoluted if people keep their feature branch up to date through constantly merging in the remote's master into their feature branch instead of simply rebasing their feature branch against the remote's master.

I grant that in certain team structures it makes sense to forbid changing the history, but the only one that comes to mind right now is when developers are working on the same branch at the same time, which most often is a root of all kind of different management problems. Too many people still confuse git and its workflow with subversion and try to impose subversion's restriction on git.

@k0pernikus I don't say that rebase is evil. I say don't change history on anything anyone else is working on.

If it's your private branch or changes not yet pushed, you can do whatever you want with it. I also like to commit early and often and then cleanup afterwards, before I push.

But if you change history on already pushed stuff, you let others walk straight into the trap. They cannot see the issue until it's too late and then have to cope on their side with the mess they aren't accountable for. And most of the time for convenience of the lazy dev or to cover your ass. That's just back-stabbing your own colleagues.