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