Rebase isn't working as expected maybe I should try a different approach

Question

All I want to do is make my master branch exactly like my develop branch.

I tried to merge and rebase my master from my develop branch. Neither solution worked.

My develop branch has a different directory structure and it is proving to be more difficult than I anticipated.

Previous Rebase

The rebase I tried in the link above worked for the test branch, but not the master. The master was the initial commit and hadn't been updated since, so it was far behind.

Although both the test branch and the master branch had the same directory structure. I am not sure why master isn't working.

During rebase, I got an error that stated to look in the patch file, but I have no idea what to look for.

I was researching this issue and came across a few threads in which the question was how to change what branch the HEAD is on.

So, can I change the HEAD to develop, then delete the master branch and just create a new one from the develop branch?

That seems a lot more clean than trying to rebase/merge in my situation.

Answer 1

I put a bunch of stuff in comments, but to answer the question posed:

So, can I change the HEAD to develop, then delete the master branch and just create a new one from the develop branch?

Yes, you can do just that. In fact, you don't even have to do that, you can forcibly move the label master (i.e., no separate "delete" step is required—see the second section below).

The commits within the repository will be quite unchanged by this process. For instance, before you do this, you might start out with ths:

                         HEAD
                          |
                          v
o--o--...--o--o     <-- master
    \
     o--o--...--o   <-- develop

In the middle, when HEAD points to develop instead of master, you get this:

o--o--...--o--o     <-- master
    \
     o--o--...--o   <-- develop
                          ^
                          |
                         HEAD

If you then delete the name master you have this:

o--o--...--o--o     [abandoned]
    \
     o--o--...--o   <-- develop
                          ^
                          |
                         HEAD

and if you then add master as another name pointing to the same commit as develop, you get:

o--o--...--o--o     [abandoned]
    \
     o--o--...--o   <-- develop, master

(at this point you can make HEAD point back to master, if you like).

---

Without actually deleting master, you can simply make master point to the same commit as develop. There are two commands that can do this; which one to use, depends on what's in HEAD.

The more obvious command is:

git branch -f master develop

This tells Git to change master so that it now points to wherever develop points. That is, this tells Git to overwrite the hash ID stored under the name master with the hash ID stored under the name develop.

If HEAD currently points to master, the command is:

git reset --hard develop

The reason to use git reset is that if HEAD currently points to master, that indicates that the work-tree (and its corresponding index) are set up to match the commit to which master points. If you change the commit to which master points, without changing the index and work-tree, Git's internals will be out of sync (not a total disaster, but potentially very confusing). The drawback to git reset --hard is that it wipes out any uncommitted work you have in the work-tree. This is also the advantage to git reset --hard. (It's an advantage if that's what you want; it's a drawback if not.)

(Note that if you're not on master and you git reset --hard develop, you've just forcibly re-pointed whatever other branch you are on. That is, git reset always affects the current branch.)