0

I am working on a topic branch which I will call 'topic'. A colleague pushed some changes to a shared branch called develop which I wanted to pull into the topic branch. I figured I'd want to rebase as pushing a merge commit seemed messy. So I performed the following commands:

git checkout develop
git pull
git rebase topic develop
git checkout topic
git merge develop

The git pull I performed pulled down several changes including the one I wanted. I have my git configured to always rebase when pulling down in case that is relevant.

It was only after I performed all the commands I realised I've changed the shared history and messed up. I haven't pushed anything yet. What is the best way to undo/fix the above? Will this fix things in a safe way in my situation, despite the fact that my situation involves changing shared history?

Community
  • 1
  • 1
CalumMcCall
  • 1,665
  • 4
  • 24
  • 46
  • 1
    Yes, `git reflog` is your friend. Actually, it allows to "recall" any previously abandoned commits (to some extent, of course), so you may put your branches into states there were before your recent changes. – user3159253 Sep 11 '14 at 10:09
  • And yes, you may revert your branches independently of each other. Certainly, the result should be carefully verified, but technically git branches are simply labels pointing to tips of some commit chains, so you're free to point a particular branch to some other place discovered via `git reflog`. – user3159253 Sep 11 '14 at 10:12
  • I reset --hard to the commit before the rebase, but the commits that I tried to merge into the topic branch from develop still have their dates changed. They were originally made 2 days ago, but their date still says today. Will this not mess things up? It doesn't seem safe to push that. – CalumMcCall Sep 11 '14 at 10:22
  • 1
    You have to revert each of your branches involved if you want them to be reset to previous states. – user3159253 Sep 11 '14 at 10:40
  • Ah ok, got it. Thanks very much! If you write an answer I'll mark it as accepted. – CalumMcCall Sep 11 '14 at 10:52

1 Answers1

1

This is what I whould do

git stash # clean index and working copy
git reflog topic # see history of topic ref
git checkout topic # switch to topic branch
git reset --hard topic@{N} # restore topic branch to state previous to merge and rebase (use the number from git reflog instead of N)

git stash # clean index and working copy
git reflog develop
git checkout develop # switch to develop branch
git reset --hard develop@{N} # since index and WC was clean, there is no changes to lost due to --hard

Note: You should have extremly caution when combining rebase and merge to avoid this, and if possible you should choose one of both (or rebase, or merge, not both)

Once you restored the previous clean state, to acchieve what you did want to do from the beginning, you can rebase topic on develop, this way:

git checkout topic # switch to topic branch
git fetch # get last changes from remote repository on "origin/" branches
git stash # clean WC and index
git rebase origin/develop

Remember, you only can do this rebase if the pushes on topic branch are not shared for different clients (i.e. would be no merges on topic branch with other repositories than yours)

dseminara
  • 11,665
  • 2
  • 20
  • 22