Introduction
One major benefit of version control is that you can roll back your code to any time in history without significantly disru...
For further actions, you may consider blocking this person and/or reporting abuse
I generally do this
You shoud never force
Why not? The option is there.
Here’s an article on why it’s sometimes dangerous : blog.developer.atlassian.com/force...
Thanks, I'll have a look. But I reacted more to the "never".
Gotcha..I agree..never is a little strong lol. There's exceptions.
Although git is a distributed VCS and the client repositories are more or less independent, it is most common that the one remote repository is treated as the single source of truth.
Force pushing to that remote repo is essentially like saying 'screw what others might have pushed before, my local copy is the new single source of truth now'
The king is dead, long live the king!
You explained that pretty well! Going to refer to your response every time someone questions why I’m not using git push force
Me too. However this article is a new learning..
Nice! Sometimes, I find myself taking that approach as well. I used the one in my article because it's safe and hopefully easy for folks to understand.
If you're working with others, I'd recommend
git push --force-with-leaseto avoid accidentally deleting someones changes.It is considered good practice to disable force pushing. Often it's just banned.
It's considered good practice to have readable commit logs, and force pushing is essential for that task.
Thanks for the
revertapproach instead of the hazardous force push 🙏🏻 some people might use to "cover" their mistakes. It often creates more problem than it solves, whilerevertis perfectly readable and safe.yeah thank you and I agree. Sometimes there's situations where a force push or "cover up" is needed..maybe for something like environment variables, but I agree that this method is easy to follow.
@blackgirlbytes the problem is who's using it. Every time someone tries to manipulate the history and overwrite stuff, it's a bit risky, by nature. Even if git experts might have appropriate usages of the command, I prefer disabling it as a general rule (e.g., in GitHub, you can protect branches against force push).
If you work alone, you do what you want, including rewriting history, but at your own risks if you damage your repository. If you work in a team, that's not acceptable because you might mess with other's work.
You’re absolutely right
Hey @nenadj ! Happy to have your thoughts here, but I prefer a more positive, kind conversation. I’m not a fan of being dismissive.
Comments like, “Learn everything about git and you won’t have a problem” isn’t helpful to anyone lol. I work at GitHub, and I don’t know everything about Git.
Here are some thoughts on why rewriting history may be dangerous: stackoverflow.com/questions/149100...
:D
Thank you so much :)
hey, this is what i do.
Undo Pushed Commits in Git With Reset and Revert
Undo Pushed Commits With the git reset Command.
Undo Pushed Commits With the git revert Command.
Undo Pushed Commits With the git checkout Command.
Git revert is definitely a nice option. I would love a more in-depth article and look at git rebase and all it's options
More content on git rebase is on the way!
Good stuff!
Congratulations 🎉! That's a helpful article👏
Normally my approach is to a git rebase, but there are some cases where the revert is much more simple 🤩
Thank you! Yeah, that's a common approach..not a wrong approach at all. I found this method is easy for me to explain and for others to understand.
You are welcome! I do agree 💯👏
So to have multiple commits reverted, we have to do git revert multiple times ? If so I assume from the top commit. Any insights on that?
As the article mentioned, you can revert multiple commits by reverting an entire branch or a tag. And no, you don’t need to start from the top. You can pick any commit or group of commits in the repo’s history to revert.
Thanks @eberjoe ! That's correct. @vineetgnair I don't go too deep into it, but you can use any git revision with git revert.
You don’t have to use the commit hash to identify the commit you want to revert. You can use any value that is considered a gitrevision, including the:
Tag
Branch
Hash
Reference
And yes, you don't need to start from the top. I just start from the top in my example.
Love the article! It's very informative
Thank you!!!
Very informative and easy to digest!
Thank you!!!
Completely agree. Force push can get a little tricky for folk, but I can see situations where it's needed.
Excellent article. Recently, during an interview I was asked the difference between
git revert&git resetand I did previously soft reset to revert the commit before even pushing the changes to remote repo. This would even work after we had pushed the changes. 🎉🎊🥳Awesome! Glad that it's helpful to you!
Usually I use git reset rather than git revert and then git push.I don't like git revert because it will break my commit log because the " revert"🙃
Thank you
Good article, thank you.