24

语境

用于开发的 GitHub Enterprise 安装。每个开发者都有自己的公共仓库，组织也有权威的仓库。拉取请求用于代码审查，我们松散地遵循 nvie 的git 流分支模型。

用于问题跟踪和部署的 TFS 安装（发布分支）。我们将发布分支镜像到 TFS 存储库中。

工作项目

现在困难的部分是：我们如何将 git 提交（最初可能在开发人员的公共分支上完成）与 TF 工作项相关联？

我做了什么

我查看了以下项目以寻求帮助：

我已经阅读了在两个 Git-TF 项目中将提交与工作项相关联的参考资料，但我不确定要使用什么工具，以及如何准确地使用它。

如果我必须在发布分支提交上运行脚本以从提交消息中提取工作项引用并将它们与发送到 TFS 的变更集相关联，我会很好。但是，允许在元数据中关联（而不是提交消息）的解决方案将是首选。

将 TFS 中的工作项与 git 提交相关联的选项有哪些？

4

4 回答 4

26

如果您在 git commit 消息中使用 # ，如 git commit -m'fixes #123' TFS 将自动将提交添加为指定工作项中的链接项。

于 2014-02-21T22:01:59.853 回答
19

With git-tfs, you can associate workitems in a commit message using metadatas (and even force commit policy!).

They are automaticaly associated when the commit are done in the TFS server ( if you use the rcheckin command )

And there is even a git-note created on the git commit to have the title of the workitem and a link toward the workitem!

But to use rcheckin in a synchronisation process between git and TFS, you should before (abolutely) understand how it works!

When you rcheckin git commits in TFS, git-tfs, for each commit create the corresponding changeset in tfs and fetch the content of this changeset to recreate a git commit. So, even if it's (nearly) invisible for you in a normal worklow, you have the git commits after the rcheckin that are not the same than the original ones (there is a modification of the history!).

That could be a big problem if this git reporitory is supposted to be the central repository because every commiters will have to do a rebase. Otherwise, it shouldn't be a problem because it's completly transparent, except in special cases but easily solvable.

Not a perfect solution...

于 2013-02-18T14:01:31.707 回答
6

在没有关于这些 Git-TFS 工具的大量信息的情况下，请注意，您可以随时通过添加注释将元数据添加到提交（无需更改存储库的历史记录/SHA1）。

请参阅git notes（或本周 Git 提示：Git Notes）。

通过在专用的“注释命名空间”中添加该信息，您可以从与 Git 提交关联的注释中快速存储/检索诸如工作项引用之类的信息。

于 2013-02-18T10:09:23.490 回答
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.
于 2015-08-07T13:12:35.653 回答