带有单独存储库的 git-tf

Posted 2023-03-22

【中文标题】带有单独存储库的 git-tf

【英文标题】：git-tf with separate repositories

【发布时间】：2017-02-06 13:52:38

【问题描述】：

我所在的组织不幸地使用 TFS/TFVC 进行源代码控制。我的小团队的任务是使用 git 运行一种“概念证明”，但我们必须能够将我们的更改推送到 TFS。幸运的是，存在 git-tf 和 git-tfs。但是，我们的 TFS 存储库是一个具有 20 多个不同项目/应用程序的单一存储库。在 git 中执行此操作的正确方法是让每个项目成为自己的 git 存储库。我知道我可以使用带有 git-tf 的桥从 TFS 签出单个项目，如果我们永久转换为 git，我会这样做。

我担心的是如果我们仍然需要推回 TFVC，如果我将每个项目都作为自己的 git 存储库签出，当我们将更改推回时，TFVC 会不会因为每个项目都是独立更改而变得混乱？也就是说，如果我从变更集 123 中签出项目 A，也从 123 中签出项目 B，在 A 中进行更改，然后将其作为变更集 124 推送回 TFVC，当我们稍后进行更改时，TFVC 是否会认为存在合并冲突或其他问题到 B 并将它们向上推，因为它是 TFVC 下的一个大存储库。

git-tf 或 git-tfs 是否能正确处理这个问题？或者我是否需要将整个 TFS 存储库作为单个 git 存储库检查并按原样使用？或者在这种情况下，最好将各种 TFS 项目签出到单个本地工作区中，并使用 git 创建存储库而不使用 git-tf 桥，然后将更改签回 TFS，就好像它们是在直接工作区（基本上忽略所有 git 历史记录和提交日志，仅将其用于本地更改跟踪）？

【问题讨论】：

应该可以了。仅当两个 gt 存储库中的文件都已更改时，您才会遇到冲突。就像您在同一 git 存储库的两个分支尝试将同一文件的更改推送到同一上游远程时一样。

【参考方案1】：

是的，您可以为每个 TFS 团队项目创建多个 Git 存储库。这就像在一个团队项目中统治许多 Git 存储库一样。

更多详情你可以看看这个链接：Many Git Repositories, but one Team Project to rule them all

如果我从变更集 123 中签出项目 A，也从变更集中签出项目 B 123，在 A 中进行更改，然后将它们作为变更集推送回 TFS 124，当我们使用 TFS 时，TFS 是否会认为存在合并冲突或其他问题？ 稍后对 B 进行更改并将它们推高，因为它都是一个大 TFS 上的存储库。

正如 jessehouwing 评论的那样，TFS 只会检测相应的文件和代码。仅当两个 git 存储库中的文件都已更改时，您才会遇到冲突。例如变更集 123 中的文件具有版本 a，并在变更集 124 中使用来自 git rep1 的版本 b 进行了编辑。此文件还使用 repB 的版本 a 签出。如果您没有在 git rep2 中将其更改为版本 b。当您推送更改时，您肯定会遇到冲突。

---

更新

git-tfs 是 TFS 和 git 之间的双向桥梁。比如使用git tfs checkintool命令通过tfs checkin窗口提交。因此结果与在一个 GIT 团队项目中使用多个 git 存储库相同。唯一的区别是一个推送提交，另一个签入更改。您上面提到的所有三种方法都应该有效。最好的方法是使用 git-tfs 来跟踪所有历史记录。

【讨论】：

回过头来，我突然想到我不清楚（混合使用 TFS 和 TFVC 术语）。澄清一下，我确实知道一个给定的项目可以有多个 git repos。然而，在我们的例子中，TFS 中的源代码控制将暂时保持 TFVC。这个想法是将单体 TFVC 项目分割为本地团队的多个 git repos，然后使用 git-tf/git-tfs 推回 TFVC 源代码控制。也许这不会改变你的答案，它仍然是可能的，但我想澄清一下。

git-tfs 是 TFS 和 git 之间的双向桥梁。比如使用git tfs checkintool命令通过tfs checkin窗口提交。所以结果是一样的。您上面提到的所有三种方法都应该有效。最好的方法是使用 git-tfs 来跟踪所有历史记录。