git - How do I switch the content of two branches?

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.

Answer 2

Yes, you technically could set your branches to any commit with git reset or git branch -m, but I think you should first think of the meaning of your branches.

From what you describe you have different versions of your software. An old one, currently tracked by you master branch and a new one currently tracked by your develop branch.

If someone knows your old version and wants to work on it, he will therefore checkout your master branch and expect it to contain the old version. If you now just set your master to the develop branch (no matter if merge or reset) that will pretty much irritate anyone expecting to get the old version.

If you ever think of moving branch pointers to completely different commits it usually means you have no good branching concept. - Maybe you should call your master branch something like current-stable. Then it would make sense to just reset it to a new commit once a new stable version is available.

But that all depends on the way you develop. Maybe it would be good to have one development branch one branch for each stable release and one current-stable branch which is expected to jump, whenever a new release is ready.