上下文
用于开发的GitHub Enterprise安装。每个开发人员都有自己的公共回购，组织拥有authorative repo。 Pull请求用于代码审查，我们松散地遵循nvie的git flow分支模型。
用于问题跟踪和部署的TFS安装（发布分支）。我们将发布分支镜像到TFS存储库中。
工作项
现在困难的部分是：我们如何将git提交（最初可能在开发人员的公共分支上完成）与TF工作项相关联？
我做了什么
我看了下面的项目寻求帮助：
我已经阅读了在两个Git-TF项目中将提交与工作项相关联的参考文献，但我不确定使用什么工具，以及如何完全解决它。
如果我必须在发布分支上运行脚本提交从提交消息中提取工作项引用并将它们与发送到TFS的变更集相关联，我会没事的。但是，优选允许元数据（而不是提交消息）中的关联的解决方案。
我有什么选择将TFS中的工作项与git提交相关联？
答案 0 :(得分：24)
如果你在git commit消息中使用＃，就像在git commit -m'fixes＃123中一样，TFS会自动将提交添加为指定的workitem中的链接项。
答案 1 :(得分：19)
使用git-tfs，您可以使用metadatas（甚至强制提交策略！）在提交消息中关联工作项。
在TFS服务器中完成提交时，它们会自动关联（如果使用rcheckin command）
在git提交中甚至创建了一个git-note，以获得工作项的标题和工作项的链接！
但是要在git和TFS之间的同步过程中使用rcheckin，你应该（绝对）理解它是如何工作的！
当您在TFS中使用git -tfs进行rcheckin git时，对于每次提交，在tfs中创建相应的变更集并获取此变更集的内容以重新创建git commit。所以，即使它在正常工作流中（几乎）对你不可见，你在rcheckin之后的git提交与原始提交不同（对历史进行修改！）。
如果这个git reporitory被认为是中央存储库，这可能是一个大问题，因为每个委员都必须做一个rebase。否则，它应该不是问题，因为它完全透明，除非在特殊情况下，但很容易解决。
不是一个完美的解决方案......
答案 2 :(得分：6)
如果没有关于这些Git-TFS工具的大量信息，请注意您可以随时通过添加注释将元数据添加到提交（不更改存储库的历史记录/ SHA1）。
请参阅 git notes （或Git Tip of the Week: Git Notes）。
通过在专用的“注释命名空间”中添加该信息，您可以从与Git提交相关联的注释中快速存储/检索诸如工作项引用之类的信息。
答案 3 :(得分：3)
您应该可以在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.