我们将把TFS/TVC存储库迁移到Git。在TFVC中，我们曾经有一个基于主干的开发，具有长期发布维护分支。发布分支上的错误修复必须合并回主干。有时，较小的功能必须从主干转移到发布分支。在TFVC中，我们通过"；合并"；从一个分支到另一个分支的单个(或小组(变更集。所得到的变更集被标记为"；合并"；，尽管我不知道这对TFVC意味着什么，尤其是考虑到未来的合并操作。
所以我把分支图想象成这样：(尽管注意TFVC从不显示任何图形(
-A--B--C---D--E--F--- trunk
/
G--H--I--J---K--L- release-x
(这里的发布分支是从A创建的，I->D是一个错误修复合并，E->K是一个功能转发(但也许我错了。在这种情况下，有人能解释一下TFVC合并变更集的真正作用吗？
有人告诉我，在Git中，一种等效的方法是挑选单个提交。然而，在生成的分支图中，我看不到樱桃选择提交后的分支之间有任何联系。我知道从技术上讲，樱桃采摘并不是一种合并操作，因此分支之间的历史关系不会被继承。我有什么东西不见了吗？有没有更好的方法可以将这样小的提交从一个分支转移到另一个分支，同时仍然保留一些合并信息？我不想合并整个分支。例如，变更集B、C或H必须保持彼此独立。
Cherry picking时，您可以添加-x选项，让git向每个Cherry pick提交的提交消息中添加一条消息：
-x当记录提交时，附加一行，上面写着"；(从承诺中摘下的樱桃…)"到原始提交消息，以指示此更改是从哪个提交中精心挑选的。这样做只是为了在没有冲突的情况下进行挑选。如果你从私人分支机构挑选信息，请不要使用此选项，因为这些信息对收件人毫无用处。另一方面，如果您在两个公开可见的分支之间挑三拣四(例如，从开发分支将旧版本的修复程序向后移植到维护分支(，那么添加这些信息可能会很有用。
这是最接近的。一个精心挑选的提交记录为目标分支上的新提交，而不是反向或正向集成。
Git不做"；部分合并"；由于git将工作树的状态存储为"0"；版本"；。TFVC存储各个文件的工作区版本。
你看到的是两件截然不同的事情。
在TFVC中，您可以看到一个分支图，它是通过具有已定义父分支的分支对象明确定义的。这些分支之间的每次集成都是可视化的，因为合并存储了哪些文件被合并，哪些变更集是合并的一部分，以及这些文件是通过哪个分支关系合并的。TFVC中的变更集(最接近git中的提交(也是一个非常不同的东西。例如，变更集可以跨越多个分支，甚至是存储库，并且一个变更集包含一个或多个文件更改。
在Git中，分支只是一个特殊的指针，指向提交图中某个地方的提交。Parentage是计算出来的(基于提交图(，分支可以自由合并，而不必考虑预先配置的层次结构。可视化显示了提交之间的关系，而不是分支之间的关系。一种特殊类型的提交，即合并，在基于两个或多个其他提交创建新提交时存储。存储与这些提交的关系，而不是恰好指向这些提交的分支的名称。提交将更改存储到工作树中。一个或多个分支可能指向该提交。
由于cherry-pick将提交树中一个分支上的更改重放到另一个分支，因此它不会被记录为多组提交链接在一起的合并。相反，它被记录为一个新的提交，碰巧有相同的差异(如果你需要解决冲突，甚至可能没有(。
通过添加-x标志，关系被存储在注释中。