1

I have a develop branch and a main branch. Of course, I was supposed to be developing on the develop branch (but I was on main). I work alone in this project, so the only changes were made by me.

This is what I did:

Both main and the develop were on the same commit. Because I had merged develop to main at some point.

Then I started coding and committed twice on main, thinking I was in the develop branch.

So now my main branch is 2 commits ahead of the develop branch. This is the opposite of where I should be right now.

Anyway, I'm fine with the commits I made, but now I need my to branches to meet again at the same point (i.e: I need my develop branch to also incorporate those two commits that I made on main by mistake).

What should I do? Rebase or merge main to develop?

NOTE: It was only local. No pushes were made.

cbdeveloper
  • 27,898
  • 37
  • 155
  • 336
  • 2
    Does this answer your question? [Git - correct commits made to wrong branch](https://stackoverflow.com/questions/49579636/git-correct-commits-made-to-wrong-branch) – tripleee May 07 '21 at 10:34
  • 1
    @tripleee Other than the title, I don't think that question is the same. This seems to be a more specific question than most questions of its type. Undoubtedly the answers to the other generalized questions would also work for this question. However, with this question, we can have answers that would not work in the other generalized questions. – TTT May 07 '21 at 17:41
  • 1
    @TTT Thanks for your feedback. I'll retract my close vote. If this is closed nevertheless, feel free to ping me here. – tripleee May 08 '21 at 11:18

2 Answers2

3

You just have to swap your local branches :

# from 'master', write down the current commit sha :
git log -1 master
# or store it in a shell variable :
commitsha=$(git rev-parse HEAD)

# reset your master branch to where 'develop' is :
git reset develop

# switch to develop :
git switch develop

# reset your develop branch to the sha at step 1 :
git reset $commitsha

note : using git reset (which defaults to git reset --mixed) as I suggested above will leave the content of your files on disk untouched.

If you have staged changes at the beginning of your sequence, which you want to keep, you may use git reset --soft (for the two calls), which will additionally preserve the content of your index.

I explicitly didn't use the --hard flag : git reset --hard will silently discard the modifications of your files without saving them (it's one of those few destructive git commands).
This may be fine if you have a clean worktree, or if you know for a fact that you don't care about the uncommitted changes, just be aware of what you do if you use it.

LeGEC
  • 46,477
  • 5
  • 57
  • 104
  • Using `reset --mixed` for this is pretty slick. I think it's important to note that this only works because `master` and `develop` were on the same commit before the new commits were added. – TTT May 07 '21 at 14:18
  • @TTT : actually, I thought the shortest indication was to give one which would at least leave the files on disk (the worktree) as it is. You are right, I'll say this more explicitly. – LeGEC May 07 '21 at 16:12
  • That makes sense. I really enjoy thinking about different ways to do the same thing in Git. I added another answer with my initial thought too. – TTT May 07 '21 at 17:35
3

I do like the approach in LeGEC's answer of "swapping the branches". As usual in Git, there are many ways to achieve the same thing. Here's another way of thinking about this which is just slightly more versatile. This method will work if the two branches were on the same commit, but also works if the "other" branch doesn't even exist yet (perhaps because you intended to make a new branch but didn't).

Given you're on master and have 2 extra commits that you wish were on another branch instead:

git branch -f develop   # create branch develop, or reset develop it if already exists
git reset --hard @~2    # reset master back 2 commits (note @~2 is like HEAD~2)
TTT
  • 22,611
  • 8
  • 63
  • 69