我喜欢在我的开发分支上进行开发，然后在我准备好投入生产时合并到 master 中。只要我不向主分支提交任何内容，一切都会顺利进行。
但是，我遇到过一些情况，我向主分支提交了一些与开发分支上更改的内容相冲突的内容。当我将开发分支合并到主分支时，我必须解决冲突。没什么大不了的，但是为了确保开发分支拥有主分支中的所有内容（确保开发是最新的），我将主分支合并并最终不得不再次解决冲突。
我听说变基通常很糟糕，尤其是对于你公开推出的东西。
有没有更好的方法来管理这种类型的设置？
问问题
7616 次
5 回答
5
定期从主分支合并到您的开发分支，然后解决任何冲突。（如果你经常这样做，冲突通常会很小。）
当合并回到主服务器时，开发根本不应该发生冲突。
于 2013-02-28T20:22:57.317 回答
5
我认为您可能只是在这里有一些误解，这些误解对您的影响比任何技术上的错误都要大。
首先，您通常不应该直接提交到 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 脚本集，它试图半自动化那里的工作流程（当我们尝试这些脚本时，这些脚本对我们来说效果不佳），但那里描述的工作流程本身运行良好。
于 2013-02-28T20:24:42.120 回答
3
我会这样做的方式是相反的：
- 合并master到dev
- 之后将 dev 合并到 master
在合并时解决所有冲突。
尽管 git 在合并和处理分支方面非常出色，但我认为除了使用 3-way diff/merge 工具进行手动繁琐的工作之外，没有其他快速解决冲突的方法。
此外，执行@cHao 在下面的回答中所说的也很有帮助 - 经常合并，合并小，并且您几乎不会遇到大的冲突合并情况。
于 2013-02-28T20:22:51.170 回答
0
据我所知，发展是所有新事物发生的地方。所以，如果是这样的话，分支开发（功能分支）。在那个分支上工作。完成后，只需将开发合并到您的功能分支中以确保它是最新的。然后，签出开发分支并将您的功能分支合并到其中。随着您团队中的人们继续向开发分支添加功能，在某些时候经理会像okay, we're releasing，所以那时您会将 master 合并到开发中（以防有人在 master 上进行了恶意提交）然后结帐掌握并合并发展到它。
希望没有人直接致力于开发或掌握。这两个应该只合并到。另外，我希望您在开发功能时和合并后进行测试。
就目前rebase而言，是的，他们说在您共享分支后不要这样做。所以在这种情况下，你不会在开发分支上这样做，因为它是共享的。
于 2013-02-28T20:21:58.843 回答
0
我愿意
git checkout master
git reset --hard dev
所以master变成了dev。如果您想在 master 上提交修补程序，请不要忘记 rebase dev。
于 2014-02-07T21:03:10.500 回答