我喜欢在我的开发分支上进行开发，然后在我准备推向生产时合并到master。只要我不向主分支提交任何内容，一切顺利。
但是，我遇到过一些情况，我已经向主分支提交了与开发分支上已更改的内容冲突的内容。当我将开发分支合并到主服务器中时，我必须解决冲突。没什么大不了的，但是为了确保开发分支在主分支中具有所有内容（确保开发是最新的）我合并主分支并最终必须再次解决冲突。
我听说变革通常很糟糕，特别是对于你公开推出的事情。
有没有更好的方法来管理这种类型的设置？
答案 0 :(得分：5)
定期从主服务器合并到您的开发分支，然后解决所有冲突。 （如果你经常这样做，冲突通常很小。）
当合并回主人的时候，发展不应该发生冲突。
答案 1 :(得分：5)
我认为你可能会在这里遇到一些误解，而不是任何技术错误。
首先，您通常不应直接提交到主分支。从你描述你的情况的方式来看，我不确定这是否正在发生，但如果是，请尽量不这样做。
如果您发现某些内容无法完全合并到master中，则不应尝试在master上解决问题。相反，您应该在功能分支上修复问题。一旦你解决了那里的问题，你就可以干净地合并到主人。
就rebase而言，在推送到远程存储库之前使用rebase是完全没问题的。一旦你把东西推到了远程仓库，你就不想变硬了，因为那时你正在为别人弄乱历史，而git无法真正解决这个问题。因此，不要害怕变形，只知道何时使用它以及何时不使用它。
您可以在这里使用变基的一种方法（再次，假设您没有远程推送有问题的分支）来帮助您解决问题，那就是将无法干净地合并为master的功能分支转换为master 。这将强制您解决该分支上的问题。一旦解决了，合并到master中应该是微不足道的（除非master在此期间再次被更改）并且你可以干净地合并到master中。
有很多可用于git的教程，他们也会提供一些很好的代码示例。这是更经典的一个，我相信这里描述的工作流程运作良好。 http://nvie.com/posts/a-successful-git-branching-model/
请注意我不支持名为'git flow'的bash脚本集，它试图在那里半自动化工作流程（当我们尝试这些脚本时，这些脚本对我们来说效果不好）但工作流本身就在那里描述效果很好。
答案 2 :(得分：2)
我这样做的方式是相反的：
在合并时解决所有冲突。
虽然git在合并和处理分支方面非常出色，但我认为除了使用3向差异/合并工具进行手动，繁琐的工作之外，我认为没有快速解决冲突的方法。
另外，@ cHao在下面的回答中说的很有帮助 - 经常合并，合并小，你几乎不会有大的冲突合并情况。
答案 3 :(得分：0)
okay, we're releasing那样，所以在这一点上你将把master合并到develop中（只是因为某人做了一个流氓提交master）然后checkout master和merge开发成它。
希望没有人直接承诺发展或掌握。这两个应该只合并到。此外，我希望您在开发功能时和合并后进行测试。
就rebase而言，是的，他们说在你分享你的分支后不要这样做。所以在这种情况下你不会在开发分支上这样做，因为它是共享的。
答案 4 :(得分：0)
我做
git checkout master
git reset --hard dev
因此，主人变得完全开发。如果你想在master上提交修补程序，请不要忘记重新设置dev。