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