3

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?

4

2 回答 2

1

您可以重命名它们，或者您可以更新每个分支以包含另一个分支的内容。这两个操作之间的唯一区别是reflog会发生什么。假设您不在乎，那么是的，您可以将一个重命名为另一个。或者您可以使用git reset更改签出分支，或者git update-ref，这基本上是下面的机器git branch -m。

最简单的方法可能是使用git branch -m.

于 2012-12-16T09:24:40.210 回答
1

git reset是的，从技术上讲，您可以使用or将您的分支设置为任何提交git branch -m，但我认为您应该首先考虑分支的含义。

根据您的描述，您有不同版本的软件。一个旧的，当前由您的主分支跟踪，一个新的当前由您的开发分支跟踪。

如果有人知道您的旧版本并想要对其进行处理，那么他将检查您的master分支并期望它包含旧版本。如果您现在只是将您的master设置为开发分支（无论是合并还是重置），那将会激怒任何希望获得旧版本的人。

如果你曾经想过将分支指针移动到完全不同的提交上，这通常意味着你没有好的分支概念。- 也许您应该将您的主分支称为current-stable。然后，一旦有新的稳定版本可用，就将其重置为新的提交是有意义的。

但这一切都取决于你的发展方式。也许最好有一个开发分支，每个稳定版本一个分支，一个当前稳定分支，只要新版本准备好，它就会跳转。

于 2012-12-16T21:27:39.480 回答