Question

I have a repository with an open source iOS framework. There’s two branches at the moment: master and develop.

master contains the current version of my framework, which is now obsolete. develop contains the new version, which is ready for “release”.

Now, I want to make the new version on develop the official version so I want to move it to master. Normally, I’d use a simple merge from develop to master. However, there are quite a bit API changes between develop and master so I get quite a bit of merge conflicts.

Before I dive into these conflicts, I’d like to know if there’s a better way to just switch master and develop. The 2 versions are quite different, so I don’t care about properly moving the changes. Backwards compatibility is not really a problem, just being able to switch would be just fine.

I know of git branch -m <old> <new>: I could rename master to v1.4 and develop to master (and create a new develop from the new master), but I’m not sure if this is the way to go. It works fine locally, but I have no clue how this will affect downstream users once I push to Github.

So, is git branch -m okay, or should I bite the merge bullet? Or is there some other way?

Answer 1

You could rename them, or you could update each branch to contain the contents of the other. The only difference between the two actions is what happens to the reflog. Assuming you don’t care, then yes, you can rename one to the other. Or you can use git reset to change the checked-out branch, or git update-ref, which is basically the machinery underneath git branch -m.

The easiest approach is probably to use git branch -m.