3 ms·
My policy is this: You may rewrite commits you've made to your local repo since your last push, but you may never rewrite a commit that has been pushed. Your t
by jarrett 13y ago
My policy is this: You may rewrite commits you've made to your local repo since your last push, but you may never rewrite a commit that has been pushed.
Your teammates don't care much if you do the former. From their perspective, it's the same as if you'd committed at different points in your development process. So long as your final, rewritten history doesn't violate your team's preferences as to the granularity of commits, you're fine.
So go ahead and rewrite your local, un-pushed changes if you feel it makes the history more organized.
But if you do the latter--rewriting history that has been pushed--you're in trouble. All developers should be able to assume that the history in the central repo is immutable. Most likely, they will rely on that assumption.
- icambron 13y agoI'd like to separate private from local. I allow for private branches on the central repo to be mutable. (By "private", I just mean marked in such a way that its clear it's owned by a particular user.) Otherwise, people end up keeping their changes local until they're ready to merge and you lose the backup aspect of git. But no one should be merging private branches (regardless of location) without their author giving an explicit OK anyway, so this doesn't seem dangerous.
- jarrett 13y agoThat's a good point. How do you synchronize history rewriting across the local and remote copies of the private branches? Do you have a formalized way to ensure it doesn't get messed up?
- acchow 13y agoWhere I work, you prefix the name of your branch with your username, like "acchow/new-feature". This tells other people "do not touch this branch because its history will be changed by acchow". Alternatively, if you use github, you can set access controls on forks to read-only and send pull requests from your fork to the main repo.
- benesch 13y agoIf you enforce a convention that private branches start with the developers initials (nb-restructre-everything), and that developers can force-push only their own branches, you can rely on each developer to keep their remote up-to-date. You can even rewrite a branch shared between developers that hasn't been merged mainline: once it's done, have one of the developers create a duplicate branch in their own private namespace, and rebase and merge that. Accidents happen, though. If you want to be guaranteed safety, enforce that every developer have their own remote fork. They can rebase at-will on their own fork, and submit pull requests to the mainline repository. (If you're using GitHub, this is dead simple, since you can open pull requests across forks.) This method introduces a fair bit of hassle and overhead for a smallish team, though.
- icambron 13y agoWhat benesch said, basically: just force push your own branches. Have to be careful if you work from multiple computers, though.
- ngoldbaum 13y agoIncidentally this is the enforced-by-design behavior of mercurial with respect to history modifying actions.
- jheriko 13y ago> All developers should be able to assume that the history in the central repo is immutable. Most likely, they will rely on that assumption. Amen.