Rewriting history on solo projects is fine but as soon as you work with another person you should consider it extremely harmful to do so on non-local branches.
Don’t push your work until you’re happy with it
One of the cardinal rules of Git is that, since so much work is local within your clone, you have a great deal of freedom to rewrite your history locally. However, once you push your work, it is a different story entirely, and you should consider pushed work as final unless you have good reason to change it. In short, you should avoid pushing your work until you’re happy with it and ready to share it with the rest of the world.
Correct me if I'm wrong, but I didn't get the impression from reading this article that the author suggests we should be editing the history of the master branch or any other shared branch. I'm more under the impression that it's about tidying up your own fix or feature branch shortly before it goes into master, and I do not see any harm or problem with that, even in a team.
To the contrary, the benefit of a cleaner, more readable history that removes all clutter such as quick and dirty in-between commits and iterations that didn't end up in the final result, should bring all contributions into a sensible timeline that is easier to follow.
Talking about big teams, here's the stance from Phabricator's development team, a development and collaboration tool that originated from Facebook and turned into an Open Source project:
A strategy where one idea is one commit has no real advantage over any other strategy until your repository hits a velocity where it becomes critical. In particular:
Essentially all operations against the master/remote repository are about ideas, not commits. When one idea is many commits, everything you do is more complicated because you need to figure out which commits represent an idea ("the foo widget is broken, what do I need to revert?") or what idea is ultimately represented by a commit ("commit af3291029 makes no sense, what goal is this change trying to accomplish?").
"One idea = one commit" means that the entirety of the fix or feature branch should be squashed into a single commit in the mainline branch. A single commit that easy to apply and revert if necessary. All in-between steps should be removed. The proposed solution to this issue is:
...squashing checkpoint commits as you go (with git commit --amend) or before pushing (with git rebase -i or git merge --squash), or having a strict policy where your master/trunk contains only merge commits and each is a merge between the old master and a branch which represents a single idea
Editing the history is only problematic when the editor doesn't 100% know what they are doing, and even then, destructive changes can be prevented by simply setting up the git repository server to reject destructive changes to the shared mainline / development branches.
On GitHub you can set up branch protection rules to prevent any push --force to any branch of your choice from being accepted. Phabricator doesn't allow "destructive changes" to any branch by default. Bitbucket offers the same protection under "branch permissions".
Practically speaking there is nothing to worry about with proper repository configuration and with the right education. And articles like this one are helpful
Hi yes I agree there's nothing in the article that says rewriting master is a good idea, however I felt it was important to state that there are problems. Rewriting history and rebasing are not silver bullets and can cause issues without proper procedure.
Admittedly reading my comment back it sounds like I've dismissed the whole article on that basis but that was absolutely not my intention!
I didn't get the impression from reading this article that the author suggests we should be editing the history of the master branch or any other shared branch
Absolutely, that was not my intention, if it wasn't clear then that's my bad.
On GitHub you can set up branch protection rules to prevent any push --force to any branch of your choice from being accepted.
Yeah, I don't see an instance where force pushing to master would be recommended, glad you mentioned these protections for others to know about.
And thanks for sharing some resources, I'm glad you commented 😄
Rewriting history on solo projects is fine but as soon as you work with another person you should consider it extremely harmful to do so on non-local branches.
From git-scm.com/book/en/v2/Git-Tools-R...
Correct me if I'm wrong, but I didn't get the impression from reading this article that the author suggests we should be editing the history of the
masterbranch or any other shared branch. I'm more under the impression that it's about tidying up your own fix or feature branch shortly before it goes into master, and I do not see any harm or problem with that, even in a team.To the contrary, the benefit of a cleaner, more readable history that removes all clutter such as quick and dirty in-between commits and iterations that didn't end up in the final result, should bring all contributions into a sensible timeline that is easier to follow.
Talking about big teams, here's the stance from Phabricator's development team, a development and collaboration tool that originated from Facebook and turned into an Open Source project:
"One idea = one commit" means that the entirety of the fix or feature branch should be squashed into a single commit in the mainline branch. A single commit that easy to apply and revert if necessary. All in-between steps should be removed. The proposed solution to this issue is:
Source
Several other articles online give the same idea that squashing and rebasing is the way to go, especially when you work in teams:
Editing the history is only problematic when the editor doesn't 100% know what they are doing, and even then, destructive changes can be prevented by simply setting up the git repository server to reject destructive changes to the shared mainline / development branches.
On GitHub you can set up branch protection rules to prevent any
push --forceto any branch of your choice from being accepted. Phabricator doesn't allow "destructive changes" to any branch by default. Bitbucket offers the same protection under "branch permissions".Practically speaking there is nothing to worry about with proper repository configuration and with the right education. And articles like this one are helpful
Hi yes I agree there's nothing in the article that says rewriting master is a good idea, however I felt it was important to state that there are problems. Rewriting history and rebasing are not silver bullets and can cause issues without proper procedure.
Admittedly reading my comment back it sounds like I've dismissed the whole article on that basis but that was absolutely not my intention!
Absolutely, that was not my intention, if it wasn't clear then that's my bad.
Yeah, I don't see an instance where force pushing to
masterwould be recommended, glad you mentioned these protections for others to know about.And thanks for sharing some resources, I'm glad you commented 😄
I totally agree with your statement, all these manipulations should be done locally before pushing your work. 😀