git 工作流程，并将更改从 master merge 到分支

Question

在与 SVN 斗争之后，有人告诉我应该检查 GIT，因为分支对于我试图实现的工作流来说是理想的。我一直得过且过，认为我现在已经掌握了 GIT 的基础知识。

我们基本上有一个我们的一些客户使用的中央框架，我想有一个主干/主控并像往常一样使用分支，用于开发/尝试，但我也想为每个客户创建分支，这样我就可以对代码进行客户特定的更改。这些分支将永远是一个分支，永远不会最终 merge 回主干/主干。

我想要实现的主要目的是让我可以轻松地将所有更改从 trunk/master merge 到各个客户端分支，我对是否需要 merge 或 rebase 感到困惑。

那么我的问题... 我是否应该始终为此使用 rebase，如果是，为什么？ (因为我想保留每个分支中的个人提交？)

编辑 所以我创建了一个 repo，在那个 repo 中我说 file.php with $x = 1

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

• 在 master 中，我对 file.php 进行了更改，但它是一个新行，$x 仍然是 $x = 1
• 在 client1 中，我 merge master 并在 $x
上发生冲突

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

Answer 1

你应该 merge 。自从分支从 master fork 以来，Rebase 将采用 master 上的所有更改，并在分支之上重新创建它们。这意味着对于您正在跟踪的每个客户端分支，master 上的每个提交都将被复制。

从语义上讲， merge 就是您正在做的事情。生成的提交图看起来会更好，Git 执行 merge 也更容易，因为每次 merge 后，master 的历史将成为分支自身历史的一部分——Git 只需要考虑 master 上的提交，因为最后 merge ，而不是重新考虑 master 上的每个提交。