Git, phiên bản ngữ nghĩa và làm thế nào nó phù hợp với (của tôi) một dòng thời gian phát triển điển hình?

Tôi đang làm việc trên hệ thống Hỏi & Đáp và sắp gắn thẻ ứng dụng hiện tại của mình với "1.0.0" cho phiên bản / thẻ chính thức đầu tiên. Nó sắp được triển khai để thử nghiệm beta cho đối tượng thử nghiệm hạn chế tiếp theo. "1.0.0" có đúng ở giai đoạn này không?

Ngoài ra, không có nghi ngờ sẽ có nhiều lỗi được tìm thấy ở giai đoạn đó. Tôi có giữ nó là "1.0.0" nhưng di chuyển mạnh mẽ thẻ cho đến khi phát hành. Hoặc sau khi sửa các lỗi, tôi sẽ cung cấp cho nó một thẻ mới "1.0.1". Sau một vòng thử nghiệm khác có lẽ "1.0.2"

Vì vậy, khi làm việc với các cải tiến (ví dụ: các tính năng mới như menu mới, trường nhập tìm kiếm mới), đây có phải là những thay đổi nhỏ như trong "1.0.0" đến "1.1.0" không?

Bạn đề cập rằng bạn đang xem xét sử dụng phiên bản ngữ nghĩa, vì vậy hãy xem xét thông số phiên bản ngữ nghĩa tại http://semver.org/ :

Cho số phiên bản MAJOR.MINOR.PATCH, tăng:

1. Phiên bản CHÍNH khi bạn thực hiện các thay đổi API không tương thích,
2. Phiên bản MINOR khi bạn thêm chức năng theo cách tương thích ngược và
3. Phiên bản PATCH khi bạn thực hiện sửa lỗi tương thích ngược.

Các nhãn bổ sung cho siêu dữ liệu trước khi phát hành và xây dựng có sẵn dưới dạng các phần mở rộng cho định dạng MAJOR.MINOR.PATCH.

và xa hơn một chút:

Phiên bản tiền phát hành CÓ THỂ được biểu thị bằng cách nối thêm dấu gạch nối và một loạt số nhận dạng được phân tách bằng dấu chấm ngay sau phiên bản vá. Mã định danh PHẢI chỉ bao gồm chữ và số gạch ngang ASCII [0-9A-Za-z-]. Định danh PHẢI KHÔNG được để trống. Số nhận dạng PHẢI KHÔNG bao gồm các số 0 đứng đầu. Các phiên bản tiền phát hành có mức độ ưu tiên thấp hơn phiên bản bình thường đi kèm. Phiên bản tiền phát hành cho biết phiên bản không ổn định và có thể không đáp ứng các yêu cầu tương thích dự định như được biểu thị bằng phiên bản bình thường được liên kết. Ví dụ: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

Vì vậy, nếu bạn phát hành bản beta thực sự của bản phát hành 1.0, bạn nên gắn thẻ nó 1.0.0-beta(hoặc tương tự theo thông số kỹ thuật). Nếu bạn đang đi để có nhiều phiên bản beta như bạn sửa lỗi, sau đó 1.0.0-beta.1, 1.0.0-beta.2vv

Khi bạn thêm các tính năng tương thích ngược, bạn nên tăng số MINOR. Nếu bạn thực hiện nhiều thay đổi nội bộ sẽ gây ra thay đổi đột phá ở nơi khác trong ứng dụng của bạn, thì đó là thay đổi CHÍNH. Nếu bạn đang thực hiện các thay đổi ít nghiêm trọng hơn (ví dụ: bạn chỉ thêm mã và không thay đổi hành vi của mã hiện tại), thì đây sẽ là một thay đổi nhỏ. Nếu bạn có một ứng dụng nặng UI và thay đổi hoàn toàn UI đó, tôi cũng sẽ nói rằng đó cũng là một thay đổi CHÍNH (UI có thể được coi là API cho người dùng cuối).

Về cách thêm chỉ số vào repo git của bạn, tôi khuyên bạn trước tiên nên tạo một 1.xnhánh. Điều này sẽ cho phép bạn dễ dàng theo dõi mọi thứ trong phiên bản 1 trong khi cho phép tiếp tục phát triển phiên bản 2 trên bản chính. Sau đó, bạn gắn thẻ bản phát hành beta bằng một thẻ 1.0.0-beta(hoặc -beta.1nếu có nhiều betas). Khi bạn sửa tất cả các lỗi bạn cần sửa, hãy gắn thẻ 1.0.0bản phát hành thực tế . Sau đó gắn thẻ mỗi bản phát hành khi cần thiết.

Bạn có thể xem một số quy trình công việc đã thử và đúng cho git như luồng git và luồng github để biết ý tưởng về cách bạn muốn thiết lập quy trình công việc đang diễn ra.

Ngoài ra, nếu bạn muốn có thêm một chút bối cảnh về phiên bản ngữ nghĩa cho các chương trình không có API, câu trả lời này sẽ đi sâu hơn.

Có, cập nhật số phiên bản mọi lúc nó vượt khỏi tầm kiểm soát của bạn và chuyển sang số của người khác.

Lý do là bạn cần ot biết họ đang làm việc với cái gì. Khi kiểm tra quay lại và nói "chúng tôi đã tìm thấy một lỗi trong phiên bản 1.0.0", điều cuối cùng bạn muốn nói là "phiên bản 1.0.0 nào, phiên bản chúng tôi đã đưa cho bạn vào thứ Hai hoặc bản cập nhật tôi đã cung cấp cho bạn vào thứ Sáu? "

Cập nhật số thứ 3 thực sự được thiết kế cho điều này, sự khác biệt về chức năng giữa 1.0.0 và 1.0.999 nên được giới hạn, khi bạn thêm các tính năng mới lớn, sau đó bạn cập nhật số thứ hai. Mặc dù, việc thêm trường nhập tìm kiếm mới thực sự không được tính là một thay đổi đủ lớn để đảm bảo cập nhật số thứ 2, nhưng YMMV.

Cá nhân, tôi có xu hướng sử dụng số thứ 2 không nhiều cho các bản cập nhật tính năng nhưng để đánh dấu một "bản phát hành đầy đủ", tức là một bản đã qua thử nghiệm và đã qua. Sau đó, tôi cập nhật giá trị đó và lặp lại qua lại giữa dev và test, tăng số thứ 3 mỗi lần cho đến khi tất cả vượt qua.

Câu trả lời tốt đã được đưa ra, nhưng tôi cũng sẽ tìm cách kết hợp git sha1 trong ứng dụng của bạn, vì vậy bạn có thể thấy rằng đó là git commit 1b5619273127398123, đây là cách được sử dụng trong bản phát hành cụ thể này. Bằng cách đó, nếu ông Smith từ BigCo gọi và phàn nàn rằng ứng dụng của ông không hoạt động chính xác, bạn có thể hỏi "hàng dài chữ số và chữ cái trên wor thứ hai khi bạn nhấp vào Giới thiệu là gì?" Và git checkout NNNNNNđể biết chính xác điều đó phiên bản, sau đó thực hiện các bước tương tự như ông Smith đã làm và (hy vọng) tái tạo vấn đề. Không có gì tệ hơn là cố gắng tìm ra một vấn đề mà bạn không thể tái tạo vì bạn đang sử dụng một phiên bản khác biệt tinh tế (trong trường hợp bạn tình cờ hoặc cố tình tránh vấn đề cụ thể đó).

Ngoài ra, hãy đảm bảo rằng hệ thống xây dựng của bạn được bao gồm trong phiên bản - tốt nhất là bao gồm phiên bản trình biên dịch, v.v. - được mã hóa hoặc lưu trữ công cụ xây dựng nào bạn sử dụng khi bạn xây dựng sản phẩm bên trong repo git của mình.