Khi nào một cam kết không được gắn thẻ phiên bản?

Bối cảnh: Gần đây tôi đã tìm hiểu về Phiên bản ngữ nghĩa và đang cố gắng xác định cách sử dụng nó tốt nhất thực tế cho các dự án của riêng tôi.

Cho rằng semver có những thay đổi lớn, những thay đổi nhỏ và các bản vá vào tài khoản để tạo phiên bản, khi nào thì một cam kết không được gắn thẻ với một phiên bản cập nhật? Dường như với tôi, mọi thay đổi sẽ phù hợp với một trong những loại này, và vì vậy mọi thay đổi nên được phiên bản, nhưng khi tôi xem các dự án phổ biến khác nhau trên GitHub thì đây dường như không phải là cách mọi thứ được thực hiện (chỉ nhìn vào Thực tế là các dự án lớn có hàng chục ngàn cam kết, chỉ với hàng trăm thẻ).

SemVer liên quan đến phiên bản phát hành , không cam kết . Nếu mô hình kiểm soát phiên bản của bạn xảy ra để yêu cầu mọi cam kết thành thạo phải là một bản phát hành, thì có, mọi cam kết sẽ cần phải được gắn thẻ theo mức độ thay đổi.

Tuy nhiên, nhìn chung, các dự án phát triển một sản phẩm chủ yếu ổn định trên bản chính và gắn thẻ các bản phát hành mà họ cho là xứng đáng để hỗ trợ. Khi họ làm như vậy, họ sẽ gắn thẻ theo sơ đồ phiên bản của họ, mà không nhất thiết phải là SemVer nói riêng.

Số phiên bản được phân bổ để phát hành. Nói chung không phải mọi cam kết nên là một bản phát hành. Cái này có một vài nguyên nhân.

Đầu tiên, trong khi bạn nói rằng bạn "kiểm tra" mọi cam kết đều có các cấp độ kiểm tra. Chạy thử nghiệm tự động trên một máy là tốt và tốt, nhưng trong phần mềm phức tạp, nó chắc chắn sẽ không nắm bắt được mọi vấn đề. Một số vấn đề có thể là phần cứng hoặc cấu hình cụ thể, một số vấn đề có thể liên quan đến sự cân nhắc chủ quan của con người hơn là về các yêu cầu khó kiểm tra.

Thứ hai va chạm số phiên bản chính nên là một hành động hiếm. Về cơ bản, điều đó có nghĩa là mọi thứ phụ thuộc vào phần mềm của bạn cần được kiểm tra thủ công để xem liệu nó có phụ thuộc vào bất kỳ tính năng bị xóa nào không.

Hậu quả của việc này là bạn chỉ nên thêm các tính năng vào "API công khai" trong các bản phát hành đầy đủ (không phải alpha / beta) nếu bạn chuẩn bị hỗ trợ các tính năng đó ở dạng hiện tại lâu dài.

Thứ ba, thật hữu ích để giảm số lượng phiên bản được sử dụng rộng rãi. Ngay cả trên một nhánh ổn định, tốt hơn là tập hợp một số bản sửa lỗi lại với nhau và tạo một bản phát hành duy nhất hơn là tạo một bản phát hành cho mỗi bản sửa lỗi.

Có vẻ như rõ ràng để nói, nhưng: mục đích số phiên bản là để cho phép bạn dễ dàng xác định phiên bản phần mềm mà bất kỳ ai đang chạy.

Nếu có bất kỳ ai có quyền truy cập vào một lần lặp mã cụ thể và không dễ dàng xác định một mã định danh duy nhất, thì lần lặp đó sẽ có một số phiên bản duy nhất. Tôi thấy đây là 'quy tắc đầu tiên'. Kết quả là, các bản phát hành riêng biệt rõ ràng sẽ muốn số phiên bản riêng biệt.

Tuy nhiên, nhiều hơn vào chơi:

Một cách để chắc chắn về điều này là tăng số phiên bản với mỗi lần xác nhận nhưng đây thường không phải là một ý tưởng hay. Có thể phải thực hiện một số lần cam kết / lặp lại để có một thay đổi tương đối nhỏ hoạt động và thật khó hiểu với thế giới bên ngoài để xem phiên bản 0.0.1 -> 0.0.2 do một số lượng lớn các thay đổi tích lũy sau đó 0,0.2 -> 0,0 .56 vì ai đó đã cam kết không gian trắng sửa một tệp tại một thời điểm và không thay đổi bất kỳ chức năng nào.

Khoảng cách từ "một phiên bản cho mỗi bản phát hành đầy đủ" đến "một phiên bản cho mỗi cam kết" thực sự tùy thuộc vào: bạn, những người dùng khác và những hệ thống nào bạn sẵn sàng sử dụng để lấp đầy các khoảng trống.

Cá nhân tôi đã từng làm việc trong các dự án nhỏ và rất vui khi sử dụng git băm cho đến khi một phiên bản mà người khác sử dụng và một phiên bản cho mỗi người trong số họ (cho dù tôi có mong đợi có bao nhiêu người để có được nó). Tuy nhiên, trong các công ty lớn hơn và các dự án lớn hơn, một số phiên bản ngữ nghĩa, nhưng độ trung thực thấp hơn so với từng cam kết, như đánh số ứng viên phát hành được sử dụng. Những cái này có lợi thế nhưng thêm phức tạp.

Mỗi yêu cầu kéo được hợp nhất thành chủ nên được phiên bản.

Nếu nó không phải là một phiên bản mới (ít nhất là một bản vá), thì có khả năng nó không nên được hợp nhất thành chủ vì tính năng / sửa chữa / vv chưa hoàn tất.

Tuy nhiên, tùy thuộc vào quy trình làm việc của nhóm bạn, bạn vẫn có thể kết thúc với nhiều cam kết thành thạo mà không có phiên bản. Nếu có một số cam kết trong yêu cầu kéo mà không bị xóa (Theo ý kiến ​​của chúng thì không nên), bạn vẫn có thể kết thúc với 10 lần xác nhận và chỉ 1 phiên bản mới.