VP of DevRel RapidAPI ❯ Award-winning Web Developer NodeCLI.com ❯ Google Dev Expert Web tech ❯ 2x GitHub Stars Award ❯ WordPress Core Dev ❯ TEDx Speaker ❯ "awesome example for devs" — Satya Nadella
Location
San Francisco Bay Area
Education
EE-CS Engineer turned Software Developer
Work
VP of DevRel (DX Eng., Content & Community) RapidAPI ❯ Google Dev Expert ❯ GitHub Star ❯ NodeCLI.com
Can you explain if there is a better way to do this once you have committed and pushed to remote the wrong commit message? You cannot do it without --force. I'm all ears for a better solution. :)
You live with the wrong commit message for that commit. Unless you are the only one on that branch, NEVER(*) use force. History rewriting is bad, and you can make others lose their work.
(*) For almost never values of never. The use cases are rare enough that it should never be scripted.
VP of DevRel RapidAPI ❯ Award-winning Web Developer NodeCLI.com ❯ Google Dev Expert Web tech ❯ 2x GitHub Stars Award ❯ WordPress Core Dev ❯ TEDx Speaker ❯ "awesome example for devs" — Satya Nadella
Location
San Francisco Bay Area
Education
EE-CS Engineer turned Software Developer
Work
VP of DevRel (DX Eng., Content & Community) RapidAPI ❯ Google Dev Expert ❯ GitHub Star ❯ NodeCLI.com
I think this function is too dangerous... You should not use
--force
paramCan you explain if there is a better way to do this once you have committed and pushed to remote the wrong commit message? You cannot do it without
--force
. I'm all ears for a better solution. :)You live with the wrong commit message for that commit. Unless you are the only one on that branch, NEVER(*) use force. History rewriting is bad, and you can make others lose their work.
(*) For almost never values of never. The use cases are rare enough that it should never be scripted.
You folks are right!
You're right. After sharing this, what was meant to be a personal workflow, I ended up in long debates on Fb/Twitter about how this can be improved.
Here's what we end with
git push --force-with-lease
as shared here above (updated the post) dev.to/mrahmadawais/one-command-to...But I am still not satisfied, so I am building a git hooks based workflow to make sure no bad git commit message gets committed in the first place.
Thanks for mentioning that though. Peace! ✌️
If you are using a development environment that is integrated with git,
--force-with-lease
can have the exact same problems as--force
I think you can revert your commit with the wrong message.
Now, cherry-pick your commit with the wrong message, amend it, replace with the right message and push without --force.
Ok, there are a little bit more manipulation but you avoid the wrath of your team. :)