Zuordnen von Git-Commits zu Team Foundation-Arbeitselementen

Kontext

Einen GitHub-Enterprise-installation für die Entwicklung verwendet. Jeder Entwickler hat sein eigenes öffentliches repo, und die Organisation hat die authorative repo. Pull-requests werden verwendet für code-reviews, und wir Locker Folgen, nvie die git-flow Verzweigung Modell.

Einer TFS installation verwendet für issue tracking und Bereitstellung der release-Zweig). Wir spiegeln den release-Zweig in einen TFS-repo.

Arbeitsaufgaben

Nun der schwierige Teil ist: Wie verbinden wir eine git-commits (möglicherweise ursprünglich durchgeführt werden, die auf den öffentlichen Zweigen der Entwickler) mit TF Arbeitsaufgaben?

Was ich Tat

Ist, habe ich mich an die folgenden Projekte für die Hilfe:

Ich gelesen habe, Verweise zu verknüpfen verpflichtet, die mit der Arbeit Artikel in den beiden Git-TF-Projekte, aber ich bin unsicher, welches Werkzeug zu verwenden, und wie Sie es genau.

Ich wäre in Ordnung, wenn ich hatte, um ein Skript auf dem release-branch commits zu extrahieren Arbeitsaufgabe Hinweise aus der commit-Nachricht, und ordnen Sie diese änderungen geschickt TFS. Aber eine Lösung, mit der der Verein in den Metadaten (anstatt von commit-Nachrichten) bevorzugt.

Was sind meine Optionen für associate work-items im TFS mit git-commits?

InformationsquelleAutor der Frage Wilbert | 2013-02-18

  1. 18

    Mit git-tfsdie Sie zuordnen können workitems in einer commit-Nachricht mit metadatas (und auch Kraft commit-Politik!).

    Sie werden automatisch zugeordnet, wenn der commit erfolgt in der TFS-server ( wenn Sie die rcheckin Befehl )

    Und es gibt auch ein git-Hinweis erstellt, auf der git commit, um den Titel des workitem und einen link in Richtung der workitem!

    Aber rcheckin in einer synchronisation zwischen git und TFS, sollten Sie vor dem (absolut) zu verstehen, wie es funktioniert!

    Wenn Sie rcheckin git commits in TFS, git-tfs, für jeden commit erstellen Sie die entsprechenden änderungen in tfs und Holen sich die Inhalte dieser änderungssatz erstellen Sie ein git commit. Also, auch wenn es (fast) unsichtbar für Sie in einem normalen Workflows, müssen Sie den git-commits nach dem rcheckin, dass sind nicht die gleichen als die Originale (es ist eine Modifikation der Geschichte!).

    Werden könnte, ein großes problem, wenn das git-Archiv ist supposted zum zentralen repository, da alle Committern zu tun haben, Stellungswechsel. Ansonsten sollte es kein problem sein, weil es komplett transparent, außer in speziellen Fällen, aber leicht lösbar ist.

    Nicht die perfekte Lösung...

    InformationsquelleAutor der Antwort Philippe

  2. 22

    Wenn Sie mit # in Ihrem git commit-Nachricht wie in git commit -m'fixes #123' TFS automatisch den commit als ein verknüpftes Element in der workitem angegeben.

    InformationsquelleAutor der Antwort mcstar

  3. 6

    Zimmerreserviereung, ohne das Sie viel information über die Git-TFS-Werkzeuge, beachten Sie, dass Sie hinzufügen können jederzeit Metadaten zu einem commit (ohne änderung der Geschichte /SHA1-Hash des repo) durch hinzufügen von Notizen.

    Sehen git notes (oder Git-Tipp der Woche: Git Notes).

    Durch hinzufügen, dass die Informationen in einem speziellen "Hinweis namespace" können Sie schnell speichern /abrufen von Informationen, wie die Work-Item-Referenz aus dem Hinweis verbunden, um ein Git-commit.

    InformationsquelleAutor der Antwort VonC

  4. 3

    Sollten Sie in der Lage sein, es zu tun in der ms-git-tf:

    git tf checkin --associate=27631,27637

    Hilfe sagt:

    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.

    InformationsquelleAutor der Antwort regisbsb

Schreibe einen Kommentar