git工作流，并将更改从主服务器合并到分支机构

Question

在与SVN斗争之后，我被告知我应该查看GIT，因为分支机构非常适合我想要实现的工作流程。我一直在混淆，认为我现在已经对GIT的基础知识进行了分类。

我们基本上有一个中央框架，我们的一些客户使用，我希望有一个trunk / master和正常使用分支，dev /尝试东西，但我也想为每个客户端创建分支，所以我可以处理客户端特定的代码更改。这些分支永远是一个分支，永远不会最终合并回主干/主服务器。

我想要实现的主要功能是，我可以轻松地将所有更改从主干/主服务器合并到各个客户端分支，如果我需要合并或重新定义，我会感到困惑。

所以我的问题...... 我是否应该一直使用rebase，如果是这样，为什么？ （因为我想在每个分支中保留各个提交？）

编辑所以我创建了一个仓库，在那个仓库中我说了{。1}}

的file.php

• 我将其提交给 master
• 我创建了一个名为 client1
的分支
• 在 client1 中，我添加了一个新文件并提交
• 在 client1 中，我更改了file.php $x = 1

• 在 master 中，我对file.php进行了更改，但是换了一行，$ x仍为$x = 2
• 在 client1 中合并 master 并在$x = 1
上发生冲突

是不是因为我在$x附近的file.php中添加了一条新行，导致冲突？

Answer 1

你应该合并。重新绑定将在master上进行所有更改，因为分支从master分离并且在分支顶部重新创建它们。这意味着对于您正在跟踪的每个客户端分支，将对主服务器上的每个提交进行复制。

合并在语义上是你正在做的。生成的提交图看起来会更好，Git将更容易执行合并，因为在每次合并之后，master的历史将成为分支自己的历史记录的一部分--Git将只需要考虑master上的提交上次合并，而不是重新考虑每次提交主。