Kojarzenie git popełnia z Team Foundation elementów roboczych

Question

Context

instalacji GitHub Enterprise wykorzystywane do rozwoju. Każdy programista ma własne publiczne repozytorium, a organizacja ma autorytatywne repozytorium. Wnioski o ciągnięcie są używane do sprawdzania kodu, a my luźno podążamy za modelem rozgałęzienia nviego git flow.

Instalacja TFS używana do śledzenia i wdrażania problemów (gałąź wydania). Reprezentujemy gałąź wydania w repozytorium TFS.

elementów roboczych

Teraz najtrudniejsza część brzmi: W jaki sposób powiązać Zobowiązuje git (które mogą być pierwotnie wykonywane na oddziałach publicznych deweloperów) z elementów roboczych TF?

Co zrobiłem

Szukałem w następujących projektach o pomoc:

• Git-TFS
• Git-TF (nodirt)
• Git-TF (microsoft)

czytałem referencyjnej s do łączenia zatwierdzeń z przedmiotem pracy w obu projektach Git-TF, ale nie jestem pewien, jakiego narzędzia użyć i jak go dokładnie wykonać.

Byłbym w porządku, gdybym musiał uruchomić skrypt w zatwierdzeniach gałęzi wydania, aby wyodrębnić odniesienia do elementów roboczych z komunikatu zatwierdzenia i powiązać je z zestawami zmian wysłanymi do TFS. Jednak preferowane byłoby rozwiązanie umożliwiające powiązanie w metadanych (zamiast komunikatów zatwierdzania).

Jakie są moje opcje kojarzenia elementów pracy w TFS z zatwierdzeniami git?

Answer 1

Z można powoływać workitems w komunikacie zatwierdzenia przy użyciu metadatas (a nawet wymuszać zasady commit!).

są automatycznie powiązane gdy commit są wykonywane na serwerze TFS (jeśli używasz rcheckin command)

I nie jest nawet git-note tworzone na git commit mieć tytuł workitem i link do workitem!

Ale aby użyć rcheckin w procesie synchronizacji między git i TFS, powinieneś (wcześniej całkowicie) zrozumieć, jak to działa!

Kiedy rcheckin git dokonuje zatwierdzenia w TFS, git-tfs, dla każdego zatwierdzenia utwórz odpowiedni zestaw zmian w tfs i pobierz zawartość tego zestawu zmian, aby odtworzyć commit git. Tak więc, nawet jeśli jest to (prawie) niewidzialne dla ciebie w normalnym przepływie pracy, masz git zobowiązuje się po rcheckin, które nie są takie same jak oryginalne (jest modyfikacja historii!).

To może być duży problem, jeśli ten repozytorium git jest wspierane jako centralne repozytorium, ponieważ każdy commiter będzie musiał zrobić rebase. W przeciwnym razie nie powinno to stanowić problemu, ponieważ jest całkowicie przezroczysty, z wyjątkiem szczególnych przypadków, ale łatwo można go rozwiązać.

Nie to idealne rozwiązanie ...

Answer 2

Bez konieczności wiele informacji na temat tych narzędzi Git-TFS, trzeba pamiętać, że można dodać w dowolnym czasie do metadanych commit (bez zmieniając Historia/SHA1 z repo) poprzez dodanie notatki.

Zobacz git notes (lub Git Tip of the Week: Git Notes).

Po dodaniu tych informacji w dedykowanej "przestrzeni nazw nut" można szybko zapisać/pobrać informacje, takie jak odniesienie do pozycji roboczej, z notatki skojarzonej z zatwierdzeniem Git.

Answer 3

Jeśli używasz # w git commit wiadomość jak w git commit -m'fixes # 123' TFS automatycznie doda commit jako połączonego elementu workitem określony.

Answer 4

Powinieneś być w stanie to zrobić w TF ms git:

git tf checkin --associate=27631,27637

Pomoc mówi:

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.