Liên kết git cam kết với Team Foundation hạng mục công trình

Question

Context

Một cài đặt GitHub Doanh nghiệp sử dụng để phát triển. Mỗi nhà phát triển có repo công khai của riêng mình và tổ chức có repo ủy quyền. Yêu cầu kéo được sử dụng để đánh giá mã và chúng tôi theo dõi một cách lỏng lẻo mô hình phân nhánh git flow của nvie.

Cài đặt TFS được sử dụng để theo dõi và triển khai sự cố (chi nhánh phát hành). Chúng tôi phản chiếu nhánh phát hành vào repo TFS.

hạng mục công trình

Bây giờ là phần khó khăn là: Làm thế nào để chúng ta kết hợp các cam kết git (mà ban đầu có thể được thực hiện trên các ngành công cộng của các nhà phát triển) với hạng mục công trình TF?

Những gì tôi đã làm

Tôi đã xem xét các dự án sau để được giúp đỡ:

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

Tôi đã đọc tài liệu tham khảo s để kết hợp các cam kết với mục công việc trong cả hai dự án Git-TF, nhưng tôi không chắc chắn công cụ nào cần sử dụng và cách thực hiện chính xác nó.

Tôi sẽ ổn nếu tôi phải chạy tập lệnh trên nhánh phát hành cam kết trích xuất tham chiếu mục công việc từ thư cam kết và liên kết chúng với bộ thay đổi được gửi tới TFS. Tuy nhiên, một giải pháp cho phép liên kết trong siêu dữ liệu (thay vì tin nhắn cam kết) sẽ được ưu tiên.

Tùy chọn của tôi để kết hợp các mục công việc trong TFS với cam kết git là gì?

Answer 1

Với git-tfs, bạn có thể kết hợp workitems trong thông báo cam kết sử dụng metadatas (và thậm chí buộc chính sách cam kết!).

Họ đang automaticaly liên quan khi các cam kết được thực hiện trong máy chủ TFS (nếu bạn sử dụng rcheckin command)

Và thậm chí còn có một git-note tạo trên git commit để có tiêu đề của workitem và một liên kết với workitem!

Nhưng để sử dụng rcheckin trong quá trình đồng bộ hóa giữa git và TFS, bạn nên trước (abolutely) hiểu cách hoạt động!

Khi bạn rcheckin git cam kết trong TFS, git-tfs, cho mỗi cam kết tạo các thay đổi tương ứng trong tfs và tìm nạp nội dung của changeset này để tạo lại cam kết git. Vì vậy, ngay cả khi nó (gần như) vô hình cho bạn trong một worklow bình thường, bạn có git cam kết sau khi rcheckin mà không giống với những bản gốc (có một sửa đổi của lịch sử!).

Đó có thể là một vấn đề lớn nếu việc lặp lại git này được coi là kho lưu trữ trung tâm vì mọi người cam kết sẽ phải thực hiện rebase. Nếu không, nó không phải là một vấn đề bởi vì nó hoàn toàn minh bạch, ngoại trừ trong trường hợp đặc biệt nhưng dễ dàng giải được.

Không phải là một giải pháp hoàn hảo ...

Answer 2

Không có nhiều thông tin về những công cụ Git-TFS, lưu ý rằng bạn có thể thêm vào bất cứ siêu dữ liệu thời gian để một cam kết (mà không thay đổi lịch sử/SHA1 của repo) bằng cách thêm ghi chú.

Xem git notes (hoặc Git Tip of the Week: Git Notes).

Bằng cách thêm thông tin đó vào "không gian tên ghi chú" chuyên dụng, bạn có thể nhanh chóng lưu trữ/truy xuất thông tin như tham chiếu Hạng mục công việc từ ghi chú được liên kết với cam kết Git.

Answer 3

Nếu bạn sử dụng # trong git của bạn cam kết thông báo như trong git commit -m'fixes # 123' TFS sẽ tự động thêm các cam kết như là một mục liên kết trong workitem quy định.

Answer 4

Bạn sẽ có thể làm điều đó trong ms git tf:

git tf checkin --associate=27631,27637

Help nói:

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.