Связывание git связывается с рабочими элементами Team Foundation

Ответ 1

С git-tfs вы можете связать рабочие элементы с сообщением фиксации с помощью metadatas (и даже принудительная политика фиксации!).

Они автоматически связаны, когда фиксация выполняется на сервере TFS (если вы используете команду rcheckin)

И есть даже git -нота, созданная в фиксации git, чтобы иметь заголовок рабочего элемента и ссылку на рабочий элемент!

Но использовать rcheckin в процессе синхронизации между git и TFS, прежде чем (полностью) понять, как это работает!

Когда вы выполняете rcheckin git в TFS, git -tfs, для каждой фиксации создайте соответствующий набор изменений в tfs и выберите содержимое этого набора изменений, чтобы воссоздать фиксацию git. Таким образом, даже если это (почти) невидимое для вас в нормальном worklow, вы git совершают после rcheckin, которые не совпадают с оригинальными (есть модификация истории!).

Это может быть большой проблемой, если этот репозиторий git supposted будет центральным репозиторием, потому что каждый участник должен будет выполнить rebase. В противном случае это не должно быть проблемой, потому что она полностью прозрачна, за исключением особых случаев, но легко разрешима.

Не идеальное решение...

Ответ 2

Если вы используете # в своем сообщении git commit, как в git commit -m'fixes # 123 ', TFS автоматически добавит фиксацию в качестве связанного элемента в указанном рабочем файле.

Ответ 3

Не имея большой информации об этих инструментах Git -TFS, обратите внимание, что вы можете добавлять в любое время метаданные к фиксации (без изменения истории /SHA 1 репо) путем добавления заметок.

См. git notes (или Git Совет недели: Git Примечания).

Добавив эту информацию в выделенное пространство имен заметок, вы можете быстро сохранить/получить информацию, такую ​​как ссылка рабочего элемента, из примечания, связанной с фиксацией Git.

Ответ 4

Вы должны иметь возможность сделать это в 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.