【问题标题】:One-to-one mapping of git commits to TFS changesets using git-tfs rcheckin使用 git-tfs rcheckin 将 git 提交一对一映射到 TFS 变更集
【发布时间】:2013-02-22 17:57:09
【问题描述】:

背景

  • 我们有一个带有发布分支的 git 存储库。
  • 我们有一个 TFS 存储库(当前为空)。

我的任务是将 git repo 的发布分支镜像到 TFS 中,以便 git 中的每个提交都映射到 TFS 中的变更集。所有开发人员都只承诺使用 git,并且(假设)不知道 TFS。

阅读documentation for rcheckinrelated issue 的答案让我相信rcheckin 能够做到这一点。

问题

git 中的所有提交都被压缩到一个单一的变更集中。

复制顺序:

git tfs clone http://tfs:8080 $/tfsrepo
cd tfsrepo
git remote add github git@github.com:REPO/Repo.git
git fetch github
git merge github/release
git tfs rcheckin

这会导致单次签入包含所有提交的 TFS。

解决问题的其他尝试

  • 克隆后,合并来自源(git)repo的第一个提交,rcheckin以创建共享库

    • 这有效,但随后的git pull github release 后跟git-tfs rcheckin 导致再次提交压缩。
  • 对于原始存储库中的前几个提交,我将它们一个接一个地合并到 git-tfs 共享存储库中,并在每个提交后重新检查。

    • 这种方法很有效,对于每次提交,TFS 中都有一个变更集。但是,原始提交消息位于“merged c02436de4f..”消息下方。
    • 对每个变更集都进行处理是不现实的,即使使用脚本也是如此。
    • 正如patthoyts 指出的那样,就 TFS 而言,这将使我成为该更改的提交者。

我的问题

我必须做些什么来使 TFS 与 git-repo 的发布分支保持最新,以便 git 中的每个提交都有相应的 TFS 变更集?

附加信息

我确实对这两个 repos 有管理控制权,如果有必要,我可以重新设置 git repo 的基础,这意味着所有后果。我只是不想失去我们已经创造的历史。

【问题讨论】:

    标签: git version-control tfs git-tfs


    【解决方案1】:

    我认为您所看到的是 git-tfs 仅使用 HEAD 和 tfs/default 之间最短路径的提交。 TFS 的历史是一个变化列表,而 git 是一个图表,你遇到了两者之间的阻抗不匹配。要了解 git-tfs 所看到的内容,请在使用 rcheckin 之前尝试 git log --graph --oneline --decorate HEAD tfs/default

    如果你想要 1:1::commit:changeset 的东西,试试这个:

    git tfs clone http://tfs:8080 $/tfsrepo
    cd tfsrepo
    git remote add github git@github.com:REPO/Repo.git
    git fetch github
    git tfs rcheckin github/release
    

    另一种方法是使用cherry-pick 或rebase

    git tfs clone http://tfs:8080 $/tfsrepo
    cd tfsrepo
    git remote add github git@github.com:REPO/Repo.git
    git fetch github
    git checkout -b about-to-be-rewritten-twice github/release
    git rebase tfs/default
    git tfs rcheckin
    

    查看rebase docs 了解更多关于 rebase 可以做的事情的示例。

    不要git push github about-to-be-rewritten-twice:release

    【讨论】:

    • ... 编辑添加了明显的“让 git-tfs 为你做 rebase”的解决方案。
    • 第一个示例的最后一行 (git tfs rcheckin github/release) 不起作用。似乎 rcheckin 不采用分支参数。如果我基于 github/release 创建一个新分支,并尝试重新检查,我会得到“没有找到 TFS 父母”。
    • 您的第二个示例似乎有效,但如果我查看 TFS 中的历史记录,所有变更集都归于我而不是原作者...
    • 所有变更集都将归属于您... git-tfs 使用您的凭据连接到 TFS,并且在签入时没有“将其归因于其他人”参数(至少,我不知道的)。
    • 要保留原始提交者名称,您必须使用 rcheckin--authors="c:\path\to\authors.txt" 参数。 authors.txt 应该包含 tfs 和 git 用户之间的映射。
    【解决方案2】:

    我认为这不会很好。如果您确实修复了提交,则每个提交都将具有您向 TFS 提交的那一刻的时间戳和用户 ID。将这些提交到 TFS 时,您无法保留原始作者或时间。微软已经宣布 TFS 将在未来支持 Git,你可能最好等待。所以不久之后,任何需要使用 tfs 的人都可以升级他们的工具并访问您真正的 git 存储库。

    我怀疑您的合并进行了合并提交,这导致了壁球。您可以尝试将 git-tfs 分支重置为您的 git master,然后推送提交。我们在共享存储库是 TFS 的地方使用 git-tfs 的另一种方式,我们都使用 git 和 git tfs 进行提交。如果我创建一个分支并添加一些提交,那么git tfs rcheckin 不会将它们压缩成一个,而是会创建一个与我在本地 git 中的内容相匹配的系列。我确实发现使用“阶段”然后在 tfs 中取消暂存以进行提交会将所有内容压缩为一个。您没有说明为什么必须镜像到 TFS,但我建议您尝试将他们指向最近的 microsoft 公告并告诉他们 git 是未来!即使使用 TFS。 :)

    【讨论】:

    • 感谢您对情况的评价。但是,我必须解决这个问题,我不知道如何解决。我给了你+1,但由于这个答案不能解决我的问题,所以我不会接受。
    猜你喜欢
    • 2016-01-02
    • 1970-01-01
    • 2020-09-14
    • 2014-02-23
    • 1970-01-01
    • 2014-09-02
    • 2020-02-24
    • 2018-05-21
    • 2014-02-24
    相关资源
    最近更新 更多