コンテキスト
開発に使用されるGitHubEnterpriseインストール。すべての開発者には独自の公開リポジトリがあり、組織には信頼できるリポジトリがあります。プルリクエストはコードレビューに使用され、nvieの git flow 分岐モデルに大まかに従います。
問題の追跡と展開に使用されるTFSインストール(リリースブランチ)。リリースブランチをTFSリポジトリにミラーリングします。
作業項目
ここで難しいのは、git commit(元々は開発者のパブリックブランチで行われる可能性があります)をTF作業項目にどのように関連付けるかです。
私がしたこと
私は助けを求めて次のプロジェクトを見てきました:
両方のGit-TFプロジェクトでコミットを作業項目に関連付けるための参照を読みましたが、使用するツールとその正確な方法がわかりません。
リリースブランチのコミットでスクリプトを実行して、コミットメッセージから作業項目の参照を抽出し、それらをTFSに送信された変更セットに関連付ける必要がある場合は問題ありません。ただし、(コミットメッセージの代わりに)メタデータでの関連付けを可能にするソリューションが推奨されます。
TFSの作業項目をgit commitに関連付けるための私のオプションは何ですか?
git-tfs を使用すると、 metadatas を使用してコミットメッセージ内の作業項目を関連付けることができます(さらに、コミットポリシーを強制することもできます!)。
これらは、TFSサーバーでコミットが実行されると自動的に関連付けられます( rcheckinコマンド を使用する場合)
また、作業項目のタイトルと作業項目へのリンクを含めるためにgitcommitで作成されたgit-noteもあります。
ただし、gitとTFS間の同期プロセスでrcheckinを使用するには、それがどのように機能するかを(絶対に)理解する必要があります。
TFSでgitcommitをrcheckinすると、git-tfsは、コミットごとに対応する変更セットをtfsに作成し、この変更セットのコンテンツをフェッチしてgitcommitを再作成します。したがって、通常のワークフローでは(ほとんど)見えない場合でも、rcheckinの後に元のコミットと同じではないgitコミットがあります(履歴の変更があります!)。
すべてのコミッショナーがリベースを実行する必要があるため、このgitリポジトリが中央リポジトリであると想定されている場合、これは大きな問題になる可能性があります。それ以外の場合は、特別な場合を除いて完全に透過的であるため、問題にはなりませんが、簡単に解決できます。
完璧な解決策ではありません...
Git commit -m'fixes#123 'のようにgit commitメッセージで#を使用すると、TFSは指定された作業項目のリンクされた項目としてコミットを自動的に追加します。
これらのGit-TFSツールに関する多くの情報がなくても、メモを追加することで、いつでもメタデータをコミットに追加できることに注意してください(リポジトリの履歴/ SHA1を変更せずに)。
git notes
(または 今週のGitヒント:Gitノート )。
その情報を専用の「メモの名前空間」に追加することで、Gitコミットに関連付けられたメモからワークアイテム参照などの情報をすばやく保存/取得できます。
あなたはmsgittfでそれを行うことができるはずです:
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.