背景
一个用于开发的 GitHub Enterprise 安装。每个开发人员都有自己的公共存储库，组织拥有权威存储库。我们使用拉取请求进行代码审查，并松散地遵循 nvie 的 git flow 分支模型。
一个用于问题跟踪和部署（发布分支）的 TFS 安装。我们将发布分支镜像到一个 TFS 存储库中。
工作项
现在困难的部分是：我们如何将可能最初在开发人员的公共分支上完成的 git 提交与 TF 工作项关联起来？
我的做法
我查看了以下项目以寻求帮助：
我已经阅读了关于在Git-TF项目中将提交与工作项相关联的参考资料，但我不确定要使用什么工具以及如何确切地进行操作。当在 TFS 服务器上完成提交（如果使用 rcheckin 命令 ）时，它们会自动关联。
甚至会在 git 提交上创建一个 git-note，包含工作项的标题和指向工作项的链接！
但是，在 git 和 TFS 之间同步过程中使用 rcheckin，您必须（绝对）先了解其工作原理！
当您将 git 提交 rcheckin 到 TFS 中时，git-tfs 会为每个提交在 tfs 中创建相应的变更集，并获取该变更集的内容以重新创建 git 提交。因此，即使在正常工作流程中几乎看不到，在 rcheckin 之后有与原始提交不同的 git 提交（历史记录有所修改！）。
如果此 git 存储库被假定为中央存储库，则可能会出现大问题，因为每个提交者都必须进行变基。否则，它不应该是一个问题，因为它完全透明，除了特殊情况但很容易解决。
这不是一个完美的解决方案...
git notes（或Git本周提示：Git笔记）。通过在专用的“注释名称空间”中添加信息，您可以快速地存储/检索像工作项引用之类的信息，这些信息与Git提交相关联。您应该可以在ms git tf中完成它：
git tf checkin --associate=27631,27637
帮助文档如下：
usage: git-tf checkin [--help] [--quiet|-q|--verbose] [--message|-m=<msg>] [--metadata|--no-metadata] [--renamemode=<all|justFiles|none>] [--deep|--shallow] [--squash=<commit id>|--autosquash]
[--resolve=<workitem id>] [--associate=<workitem id>] [--mentions] [--no-lock] [--preview|-p] [--bypass|--gated|-g=<definition>] [--keep-author|--ignore-author] [--user-map=[<file path>]]
Arguments:
--help Displays usage information
--quiet, -q, --verbose
Determines the output detail level
--message, -m=<msg> Use the given <msg> as the changeset comment
--metadata, --no-metadata
Determine whether to include git commit meta data in the changeset comment when checking in deep. If omitted, value provided during configure is used.
--renamemode=<all|justFiles|none>
The rename mode to use when pending changes. Specify either "all", "justFiles" or "none" (default: justFiles)
--deep, --shallow Creates a "deep" check-in, checking in a TFS changeset for each git commit since the latest TFS changeset(requires linear history or "--squash" or "--autosquash"), or
"shallow", checking in a single changeset for all commits.If omitted, the depth value provided during clone or configure is used.
--squash=< commit id>, --autosquash
Specifies how check in should operate in the deep mode if one commit has more than one parent
--resolve=< workitem id>
ID of the TFS work item to resolve during check-in
--associate=< workitem id>
ID of the TFS work item to associate during check-in
--mentions Add references in the commit comments for any work items linked to the corresponding changeset.
--no-lock Does not take a lock on the server path before committing (dangerous)
--preview, -p Displays a preview of the commits that will be checked in TFS
--bypass, --gated, -g=<definition>
Bypass gated check-in or specify a gated build<definition> to use
--keep-author Use the commit author as the changeset owner when checking in deep.The commit author should be known to TFS either by his name or e-mail address.To use this option you should
be either a TFS project administrator or have the "Check in other users' changes" permission.
--ignore-author Use the current authenticated user as the changeset owner.
--user-map=[< file path >]
Specifies an absolute or relative path to a file providing mapping between Git repository commit authors and TFS user identities. (default: ./USERMAP) To generate a template
mapping file, run the checkin command in preview mode with the --keep-author and --deep options specified.
Creates a check-in of the changes in the current master branch head, provided it is parented off a commit converted from a TFS changeset.