Asociar confirmaciones de git con elementos de trabajo de Team Foundation

Context

Una instalación de GitHub Enterprise utilizada para el desarrollo. Cada desarrollador tiene su propio repositorio público, y la organización tiene el repositorio autorativo. Las pull requests se usan para revisar el código, y seguimos libremente el modelo de ramificación de nvie git flow.

Una instalación TFS utilizada para el seguimiento de problemas y la implementación (la rama release). Reflejamos la rama release en un repositorio TFS.

Elementos de trabajo

Ahora la parte difícil es: ¿Cómo ¿asociamos las confirmaciones de git (que originalmente se pueden hacer en las ramas públicas de los desarrolladores) con elementos de trabajo TF?

Lo que hice

He buscado ayuda en los siguientes proyectos:

He leído referencias a la asociación de confirmaciones con elementos de trabajo en ambos proyectos Git-TF, pero no estoy seguro de qué herramienta usar y cómo hacerlo exactamente.

Estaría bien si tuviera que ejecutar un script en las confirmaciones de la rama release para extraer referencias de elementos de trabajo del mensaje de confirmación y asociarlas con conjuntos de cambios enviados a TFS. Sin embargo, se prefiere una solución que permita la asociación en metadatos (en lugar de mensajes de confirmación).

¿Cuáles son mis opciones para asociar elementos de trabajo en TFS con confirmaciones de git?

Author: Wilbert, 2013-02-18
Source

4 answers

Con git-tfs , puedes asociar workitems en un mensaje de confirmación usando metadatas (¡e incluso forzar la política de confirmación!).

Se asocian automáticamente cuando la confirmación se realiza en el servidor TFS (si utiliza el comando rcheckin)

E incluso hay una nota de git creada en la confirmación de git para tener el título del workitem y un enlace hacia el workitem!

Pero para usar rcheckin en un proceso de sincronización entre git y TFS, debe antes (abolidamente) entender cómo funciona!

Cuando rcheckin git commits en TFS, git-tfs, para cada commit crea el conjunto de cambios correspondiente en tfs y recupera el contenido de este conjunto de cambios para recrear un commit de git. Por lo tanto, incluso si es (casi) invisible para usted en un worklow normal, tiene las confirmaciones de git después del rcheckin que no son las mismas que las originales (¡hay una modificación del historial!).

Eso podría ser un gran problema si se supone que este reporte de git ser el repositorio central porque cada commiters tendrá que hacer un rebase. De lo contrario, no debería ser un problema porque es completamente transparente, excepto en casos especiales, pero fácilmente solucionable.

No es una solución perfecta...

 18
Author: Philippe,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-03-04 14:44:41

Si usas # en tu mensaje de confirmación de git como en git commit-m'fixes #123' TFS agregará automáticamente la confirmación como un elemento vinculado en workitem especificado.

 22
Author: mcstar,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-02-21 22:01:59

Sin tener mucha información sobre esas herramientas Git-TFS, tenga en cuenta que puede agregar metadatos en cualquier momento a una confirmación (sin cambiar el historial / SHA1 del repositorio) agregando notas.

Véase git notes (or Git Tip of the Week: Git Notes).

Al agregar esa información en un "espacio de nombres de nota" dedicado, puede almacenar / recuperar rápidamente una información como una referencia de elemento de trabajo de la nota asociada a una confirmación de Git.

 6
Author: VonC,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-02-18 10:09:23

Deberías poder hacerlo en el ms git tf:

git tf checkin --associate=27631,27637

La ayuda dice: 

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.
 3
Author: regisbsb,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-08-07 13:12:35