4 ms·
In cases where forced pushes are disabled, deleting whole branches are typically disabled too, and generally for good reason (if someone else already pulled the
by jgraham 13y ago
In cases where forced pushes are disabled, deleting whole branches are typically disabled too, and generally for good reason (if someone else already pulled the branch with the removed commit they can end up in a mess and/or just repushing the unwanted thing by accident.
So actually reverting a merge in git isn't that painful. It's typically just
git revert -m 1 sha_1_of_merge_commit
The problem is that if you then do more work on the branch and fix the problems that caused the merge to be reverted, redoing the merge doesn't work the way you expect; the commits that were previously merged don't get re-merged. So re-merging the branch consists of reverting the revert and then merging to get the new commits. Which is painful in-as-much as it requires you to know about the previous revert.
My favoured solution to this is to never merge, always rebase, which also has the property of giving a nice linear history that can actually be understood. However some people prefer a merge-based workflow (and if you happen to use github it is very difficult to enforce anything else, due to the Big Green Button), so it is a real problem.
- MatthewPhillips 13y agoInteresting. Can you explain your rebase workflow a bit? I never thought of merge and rebase as overlapping that much, although I only use rebase to combine commits together.
- weaksauce 13y agoI'd imagine that the gp is working in a collaborative environment and before pushing to the origin for a merge commit if the ancestors are different, that gp will instead rebate on whatever changes have been made in the origin repo first so that the repo maintainer can just do a fast forward merge.
- neckro23 13y agoIt's pretty straightforward -- always rebase your feature branch on top of your upstream before you merge, ensuring that the merge is a fast-forward and your feature branch's history is at the end. This also gives you a chance to fix up any conflicts before merging, instead of possibly having to merge twice.
- Crito 13y agoWhere I work we have forced pushes disabled, but allow "delete the branch/recreate the branch" as an inconvenient workaround for people who really need it. Of course the remote is set up to never prune the seemingly now unreachable commits, and it keeps a record of what branches exist/have existed and what they have been pointed at. I think if you push sensitive information you can get it actually removed if you contact the VC team, but everything is set up to be auditable and safe by default. I agree with your "always rebase" method, the readable history is well worth it alone.