6 ms·

What do you mean by undoing a merge? I assume you're talking about something more complicated than what I usually do git reset --hard HEAD~ That just kic

• jheriko 13y ago
  nope. if i merge two branches, push that to the remote and i wan't to undo it.
  • Crito 13y ago
    So push your fix? Push hard if necessary, and if your remote forbids non-fastforward pushes even with force, then delete the remote branch and recreate it under the same name with the commit that you want.
    • 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 ago
        Interesting. 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 ago
          I'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 ago
          It'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 ago
        Where 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.
  • Osiris 13y ago
    If no one has pulled your branch, just do a force push (use --dry-run to double-check your push).
• justinhj 13y ago
  The scenario is something I try very hard to avoid via workflow, but sometimes it still happens. Somebody merges something and pushes it to the master branch of the repo before it's ready. Now you want to pretend that never happened. You can't just revert it. If anyone can post instructions for easily getting the master branch back to how it was before the merge let me know.
  • Osiris 13y ago
    Your problem is not undoing merges, but allowing people to merge that shouldn't. A good solution like GitHub Enterprise or Stash will allow you to use pull requests, so you can require that code gets reviewed by a third-party before merging. In the case of Atlassian Stash, you can set branch permissions, which allow only certain users to commit/merge to that branch, and you can also require that a merge request be reviewed by specific individuals before the system allows it to be merged. Preventing the merge problem in the first place is a much better approach than trying to fix it afterwards.
    • thinkpad20 13y ago
      > Preventing the merge problem in the first place is a much better approach than trying to fix it afterwards. In a perfect world, all problems would be prevented. Unfortunately, we live in the real world, where being able to fix it afterwards is very important.
    • justinhj 13y ago
      Exactly. We use github enterprise. Our normal workflow prevents this problem, but shit happens.
  • justinmk 13y ago
    > Somebody merges something and pushes it to the master branch of the repo before it's ready. Now you want to pretend that never happened. Say 'abc123' is the commit immediately before the merge commit. Run this: git rebase -i abc123 In the editor window that appears, delete the commit(s) that you want to "pretend never happened". Exit the editor. Git then replays the commits from abc123 up to HEAD, except without the commits you deleted. Now your local branch is in a state that omits the premature merge commit.