Tại sao tôi nên quan tâm đến các thẻ nhẹ so với chú thích?

Tôi đã chuyển từ Subversion sang Git thành VCS hàng ngày của tôi năm ngoái và tôi vẫn đang cố gắng nắm bắt những điểm tốt hơn của "Git-think".

Điều khiến tôi bận tâm gần đây là "nhẹ" so với chú thích so với thẻ đã ký. Có vẻ như mọi người đều chấp nhận rằng các thẻ chú thích vượt trội hơn so với các thẻ nhẹ cho tất cả các mục đích sử dụng thực tế, nhưng những lời giải thích mà tôi đã tìm thấy tại sao trường hợp đó dường như luôn sôi sục vì "vì thực tiễn tốt nhất" hoặc "bởi vì chúng khác nhau" . Thật không may, đó là những lý lẽ rất không thỏa mãn mà không hiểu tại sao đó là cách thực hành tốt nhất hoặc làm thế nào những khác biệt đó có liên quan đến việc sử dụng Git của tôi.

Khi tôi lần đầu tiên chuyển sang Git, các thẻ nhẹ dường như là thứ tốt nhất kể từ khi bánh mì cắt lát; Tôi chỉ có thể chỉ vào một cam kết và nói "đó là 1.0". Tôi gặp khó khăn trong việc nắm bắt một thẻ có thể cần nhiều hơn thế, nhưng tôi chắc chắn không thể tin rằng các chuyên gia Git trên thế giới thích các thẻ chú thích một cách tùy tiện! Vì vậy, tất cả các hubbub về là gì?

(Điểm thưởng: Tại sao tôi cần phải ký thẻ?)

BIÊN TẬP

Tôi đã bị thuyết phục thành công rằng các thẻ chú thích là một điều tốt - biết ai được gắn thẻ và khi nào là quan trọng! Theo dõi, bất kỳ lời khuyên về chú thích thẻ tốt? Cả hai git tag -am "tagging 1.0" 1.0và cố gắng tóm tắt nhật ký cam kết vì thẻ trước cảm thấy như mất chiến lược.

Điểm cộng lớn của thẻ chú thích là bạn biết ai đã tạo ra nó. Cũng giống như với các cam kết, đôi khi thật tuyệt khi biết ai đã làm điều đó. Nếu bạn là nhà phát triển và bạn thấy rằng v1.7.4 đã được gắn thẻ (tuyên bố sẵn sàng) và bạn không chắc chắn, bạn sẽ nói chuyện với ai? Người có tên trong thẻ chú thích! . phát hành.

Các siêu dữ liệu khác cũng có thể hữu ích - đôi khi thật tuyệt khi biết phiên bản đó được phát hành, không chỉ khi cam kết cuối cùng được thực hiện. Và đôi khi tin nhắn thậm chí có thể hữu ích. Có lẽ nó giúp giải thích mục đích của thẻ cụ thể đó. Có thể thẻ cho một ứng cử viên phát hành chứa một chút danh sách trạng thái / việc cần làm.

Ký thẻ khá giống như ký bất cứ thứ gì khác - nó cung cấp thêm một cấp độ bảo mật cho người hoang tưởng. Hầu hết chúng ta sẽ không bao giờ sử dụng nó, nhưng nếu bạn thực sự muốn xác minh mọi thứ trước khi bạn đặt phần mềm đó vào máy tính của mình, bạn có thể muốn nó.

Biên tập:

Đối với những gì cần viết trong chú thích thẻ, bạn nói đúng - không phải lúc nào cũng hữu ích để nói. Đối với thẻ số phiên bản, nó hoàn toàn hiểu rằng nó đánh dấu phiên bản đó và nếu bạn hài lòng với các thay đổi của mình ở nơi khác, thì không cần phải đặt nó ở đó. Trong trường hợp này, nó thực sự là thẻ và ngày quan trọng nhất. Điều khác duy nhất tôi có thể nghĩ đến là một loại tem phê duyệt từ một bộ thử nghiệm. Hãy xem các thẻ của git.git: tất cả họ chỉ nói một cái gì đó như "Git 1.7.3 rc1"; tất cả những gì chúng tôi thực sự quan tâm là tên của Junio ​​Hamano trên chúng.

Tuy nhiên, đối với các thẻ ít được đặt tên rõ ràng, thông điệp có thể trở nên quan trọng hơn nhiều. Tôi có thể hình dung việc gắn thẻ một phiên bản mục đích đặc biệt cụ thể cho một người dùng / khách hàng, một số mốc quan trọng không phải là phiên bản hoặc (như đã đề cập ở trên) một ứng cử viên phát hành có thêm thông tin. Thông điệp sau đó hữu ích hơn nhiều.

Cá nhân tôi, quan điểm hơi khác về chủ đề đó:

• Các thẻ được chú thích là những thẻ có nghĩa là được xuất bản cho các nhà phát triển khác, hầu hết là các phiên bản mới (cũng nên được ký). Không chỉ để xem ai được gắn thẻ và khi nào nó được gắn thẻ, mà còn tại sao (thường là một thay đổi).
• Trọng lượng nhẹ phù hợp hơn cho sử dụng cá nhân, điều đó có nghĩa là gắn thẻ các cam kết đặc biệt để có thể tìm lại chúng. Có thể là để xem xét chúng, kiểm tra chúng để kiểm tra một cái gì đó hoặc bất cứ điều gì.

Theo mặc định, Git chỉ xem các thẻ chú thích làm đường cơ sở cho các lệnh như git describe. Hãy nghĩ về các thẻ chú thích như các biển chỉ dẫn có ý nghĩa lâu dài đối với chính bạn và những người khác, trong khi các thẻ nhẹ giống như dấu trang để bạn tự tìm kiếm sau này. Do đó, các thẻ chú thích có giá trị sử dụng làm tài liệu tham khảo, trong khi các thẻ nhẹ thì không nên.

Ký một thẻ là một sự đảm bảo về danh tính của người ký. Nó cho phép người dùng xác minh, ví dụ, mã hạt nhân Linux mà họ đã chọn là cùng mã mà Linus Torvalds thực sự phát hành. Chữ ký cũng có thể là một xác nhận rằng người ký đang chứng minh cho chất lượng và tính toàn vẹn của phần mềm theo cam kết đó.

Ký một thẻ là một cách dễ dàng để khẳng định tính xác thực của một bản phát hành.

Điều này đặc biệt hữu ích trong DVCS vì bất kỳ ai cũng có thể sao chép kho lưu trữ và sửa đổi lịch sử (ví dụ: thông qua git-filter-Branch). Nếu thẻ được ký, chữ ký sẽ không tồn tại trong hoạt động của chi nhánh bộ lọc git, vì vậy nếu bạn có chính sách rằng mọi bản phát hành đều được gắn thẻ và ký bởi người ủy quyền, có thể phát hiện thẻ phát hành không có thật trong kho lưu trữ.

Nếu nó không được ký, tôi cũng sẽ không thấy nhiều điểm trong các thẻ chú thích.

Đẩy các thẻ chú thích, giữ nhẹ cục bộ

Một số hành vi Git nhất định phân biệt giữa chúng theo cách mà khuyến nghị này hữu ích, ví dụ:

• các thẻ chú thích có thể chứa một thông điệp, người tạo và ngày khác với cam kết mà họ trỏ đến. Vì vậy, bạn có thể sử dụng chúng để mô tả một bản phát hành mà không cần thực hiện một cam kết phát hành.

  Các thẻ nhẹ không có thêm thông tin đó và không cần nó, vì bạn sẽ chỉ sử dụng nó để phát triển.

• git push --follow-tags sẽ chỉ đẩy các thẻ có chú thích
• git describe không có tùy chọn dòng lệnh chỉ thấy các thẻ chú thích

man git-tag nói:

Các thẻ được chú thích có nghĩa là để phát hành trong khi các thẻ nhẹ có nghĩa là cho các nhãn đối tượng riêng tư hoặc tạm thời.

Sự khác biệt nội bộ

• cả thẻ nhẹ và thẻ chú thích đều là một tệp .git/refs/tagschứa SHA-1

• đối với các thẻ nhẹ, SHA-1 trỏ trực tiếp vào một cam kết:

  git tag light
  cat .git/refs/tags/light
  

  in giống như SHA-1 của ĐẦU.

  Vì vậy, không có gì lạ khi họ không thể chứa bất kỳ siêu dữ liệu nào khác.

• các thẻ chú thích trỏ đến một đối tượng thẻ trong cơ sở dữ liệu đối tượng.

  git tag -as -m msg annot
  cat .git/refs/tags/annot
  

  chứa SHA của đối tượng thẻ chú thích:

  c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef
  

  và sau đó chúng ta có thể lấy nội dung của nó với:

  git cat-file -p c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef
  

  đầu ra mẫu:

  object 4284c41353e51a07e4ed4192ad2e9eaada9c059f
  type commit
  tag annot
  tagger Ciro Santilli <your@mail.com> 1411478848 +0200
  
  msg
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1.4.11 (GNU/Linux)
  
  <YOUR PGP SIGNATURE>
  -----END PGP SIGNAT
  

  Và đây là cách nó chứa siêu dữ liệu bổ sung. Như chúng ta có thể thấy từ đầu ra, các trường siêu dữ liệu là:

  • đối tượng mà nó trỏ đến
  • loại đối tượng mà nó trỏ đến. Có, các đối tượng thẻ có thể trỏ đến bất kỳ loại đối tượng nào khác như đốm màu, không chỉ cam kết .
  • tên của thẻ
  • nhận dạng thẻ và dấu thời gian
  • thông điệp. Lưu ý cách chữ ký PGP chỉ được thêm vào tin nhắn

  Một phân tích chi tiết hơn về định dạng được trình bày tại: Định dạng của đối tượng thẻ git là gì và cách tính SHA của nó?

Tiền thưởng

• Xác định nếu một thẻ được chú thích:

  git cat-file -t tag
  

  Đầu ra commitcho nhẹ, tagcho chú thích.

• Chỉ liệt kê các thẻ nhẹ: Làm thế nào tôi có thể liệt kê tất cả các thẻ nhẹ?

Tôi đã tìm thấy một cách sử dụng tốt cho các thẻ nhẹ - tạo bản phát hành tại GitHub theo cách hồi cứu.

Chúng tôi đã phát hành phần mềm của mình và chúng tôi đã có những cam kết cần thiết, chúng tôi chỉ không buồn duy trì phần 'Phát hành' trên GitHub. Và khi chúng tôi chú ý một chút, chúng tôi đã nhận ra rằng chúng tôi cũng muốn thêm một số bản phát hành trước đó, với ngày phát hành cũ chính xác cho chúng.

Nếu chúng ta chỉ tạo một thẻ chú thích trên một cam kết cũ, GitHub sẽ lấy ngày phát hành từ đối tượng thẻ. Ngược lại, khi chúng tôi tạo một thẻ nhẹ cho cam kết cũ này, bản phát hành bắt đầu hiển thị ngày (cũ) chính xác. Nguồn @ GitHub trợ giúp, 'Giới thiệu về bản phát hành'

Dường như cũng có thể chỉ định ngày mong muốn của bạn cho một cam kết được chú thích, nhưng nó không đơn giản đối với tôi: https://www.kernel.org/pub/software/scm/git/docs/git-tag. html # _on_backdating_tags

Trong văn phòng của tôi, chúng tôi sẽ đặt địa chỉ trang web phát hành trong thân thẻ. Trang web phát hành chi tiết tất cả các tính năng mới và sửa lỗi kể từ lần phát hành cuối cùng. Ban quản lý sẽ không tìm kiếm trong repo git để tìm hiểu những thay đổi đã xảy ra và thật tuyệt khi có một danh sách ngắn gọn về những gì trong bản phát hành đó.

Các thẻ được chú thích lưu trữ siêu dữ liệu bổ sung như tên tác giả, ghi chú phát hành, thông báo thẻ và ngày dưới dạng các đối tượng đầy đủ trong cơ sở dữ liệu Git. Tất cả dữ liệu này rất quan trọng đối với việc phát hành công khai dự án của bạn.

thẻ git -a v1.0.0

Thẻ nhẹ là cách đơn giản nhất để thêm thẻ vào kho git của bạn vì chúng chỉ lưu trữ hàm băm của cam kết mà chúng tham chiếu. Chúng có thể hoạt động như "dấu trang" cho một cam kết, vì vậy, chúng rất tuyệt để sử dụng riêng.

thẻ git v1.0.0

Bạn có thể sắp xếp, liệt kê, xóa, hiển thị và chỉnh sửa các thẻ cũ. Tất cả các chức năng này sẽ giúp bạn xác định các phiên bản phát hành cụ thể của mã của bạn. Tôi thấy bài viết này có thể giúp bạn hiểu rõ hơn về những gì các thẻ có thể làm.

Đối với tôi sự khác biệt quan trọng là thẻ nhẹ không có dấu thời gian. Giả sử bạn đã thêm một số thẻ nhẹ:

git tag v1
git tag v2
git tag v3

và sau đó, có thể sau này, bạn muốn nhận thêm thẻ nhẹ cuối cùng. Không có cách nào để làm điều đó. Cả "git description" hay "git tag" đều không cung cấp cho bạn thẻ nhẹ cuối cùng về mặt thời gian. "Git tag -l" có thể trả về tất cả chúng hoặc sắp xếp chúng theo thứ tự lex, nhưng không phải theo ngày / giờ. "Git description --tags" sẽ trả về "v1", đây chắc chắn không phải là thẻ được thêm lần cuối.

Mặt khác, nếu bạn thêm các thẻ chú thích:

git tag v1 -m v1
git tag v2 -m v1
git tag v3 -m v1

bạn luôn có thể lấy dấu thời gian của mỗi thẻ và "git description" chắc chắn sẽ trả về "v3", đây thực sự là thẻ được thêm vào cuối cùng.