0

I've managed to get two unrelated branches somehow synchronized, such that git logs for both branches are now pretty much identical. Here's how I manged this feat:

  1. I was working in a branch dev.
  2. Fetched and checkout out releaseBranch, but forgot to commit changes made to dev.
  3. Realized my mistake and checkout dev and committed my changes.
  4. Deleted releaseBranch and re-fetched and checkout another branch.
  5. As shown below, git log now shows identical commits for not branches, and two HEADs

git log on dev

commit f6824f8f7e85d27087d91f7b2ed18d6ac0bb3b2c (HEAD -> releaseBranch, dev)
Author: Me <me@example.com>
Date:   Mon Jan 23 12:13:17 2023 +0000

    Last commit to dev

git log on release Branch

commit f6824f8f7e85d27087d91f7b2ed18d6ac0bb3b2c (HEAD -> dev, releaseBranch)
Author: Me <me@example.com>
Date:   Mon Jan 23 12:13:17 2023 +0000

    Last commit to dev

What's the best way to untangle myself from this mess?

git version 2.25.1

Olumide
  • 5,397
  • 10
  • 55
  • 104
  • Does this answer your question? [Reverting to a specific commit based on commit id with Git?](https://stackoverflow.com/questions/3639115/reverting-to-a-specific-commit-based-on-commit-id-with-git) – mkrieger1 Jan 23 '23 at 13:10
  • `git checkout branch-at-wrong-commit`, then `git reset --hard correct-commit`, possibly also `git push -f` to update the remote repository to this state. – mkrieger1 Jan 23 '23 at 13:10
  • @mkrieger1 I cannot push non code changes to the remote repo. This would be frowned on as the problem is not with the remote repo. Also logs seem to show commits from both branches., so its difficult to determine which Id to reset to. – Olumide Jan 23 '23 at 13:17
  • If the remote branch is still ok, you won't need a force push. – jessehouwing Jan 23 '23 at 13:23
  • `git reflog` can help you find out the correct commit id. Alternatively just check the remote host via a web UI (most git hosts have one) and find the correct commit id for the releaseBranch this way. – Joachim Sauer Jan 23 '23 at 13:26

1 Answers1

1

This happens to all of us once in a while. The best approach now is to create 2 new local branches, one for your development and one for your release branch. If you haven't pushed yet, you can base these on origin/releaseBranch and origin/dev.

Now you'll need to figure out which commits belong to which branch we can't really help you there. But you could look at the git reflog to get a feel to which commits used to be checked out locally.

Your safest route would then be to git cherrypick the-commit-sha-s65sd7s57s each commit you hadn't pushed yet into the right branch. Do this from oldest to newest. Once satisfied, delete your messed up branches and optionally rename the local branches you're on. Then push the correct commits to your remote.

You can probably also fix this by resetting each branch to the correct latest commit that should be on that branch by checking out the branch and then git reset --hard the-commit-sha-of-the-latest-correct-commit and you may again find that sha in the git log or git reflog. If you reset to a commit that would change the history on the remote, then you'd need to force push.

You can probably also fix this by rebasing interactively.

jessehouwing
  • 106,458
  • 22
  • 256
  • 341