2013-01-07 18 views
5

Tại công ty chúng tôi, chúng tôi đang chuyển từ SvN sang Git (vâng, tốt hơn muộn hơn bao giờ hết). Cùng với đó, chúng tôi cũng cố gắng hợp lý hóa quá trình versioning. Để làm điều đó tôi đã tìm thấy một bài viết thú vị: Mô hình phân nhánh Git thành công của Vincent Driessen.Hỗ trợ nhiều phiên bản với Mô hình Chi nhánh Git Thành công

Theo như tôi có thể đọc từ bài viết, nhà phát triển giả định các bản phát hành tuyến tính. Để rõ ràng:

v1.0.0 --> v1.0.1 --> v1.0.2 --> v1.1.0 --> v1.1.1 etc 

Hỗ trợ cho các bản phát hành cũ hơn không được đề cập. Ví dụ: chúng tôi hỗ trợ tối đa ba phiên bản chính vì một số khách hàng không muốn nâng cấp. Hãy tưởng tượng chúng ta có các phiên bản sau:

v7.0.0 --> v8.0.0 --> v9.0.0 --> v10.0.0 

Khi có một lỗi nghiêm trọng được tìm thấy trong v8.0.0sau việc phát hành v9.0.0, chúng tôi kiểm tag v8.0.0, sửa chữa lỗi, và hợp nhất nó trở lại vào developmaster chi nhánh. Hợp nhất vào master nhận thẻ v8.0.1.

Dường như với tôi bằng cách nào đó lạ vì hai điều:

  1. Các timeline master sẽ trông giống như v7.0.0 --> v8.0.0 --> v9.0.0 --> v8.0.1 --> v10.0.0. Tôi hoàn toàn nhận thức được điều đó là có thể, nhưng liệu nó có chấp nhận được không?
  2. Khi tôi nhập hotfix-master (và master là vào thời điểm đó tại v9.0.0) và thẻ nó với v8.0.1, tôi cũng có được các tính năng được giới thiệu giữa v8.0.0v9.0.0?

Cảm ơn bạn trước!

Trả lời

4

Với tôi, thẻ v8.0.1 phải là cam kết trước khi hợp nhất master. Nếu bạn muốn vá các phiên bản mới, sau đó bạn hợp nhất các thẻ khác ở đó.

v8.0.0 --> v9.0.0 --> v10.0.0 
    \   \   \ 
    v8.0.1 --> v9.0.1 --> v10.0.1/master 
+0

Cảm ơn! Tôi có thể hiểu lầm các khái niệm về gắn thẻ trong Git ở vị trí đầu tiên :) Did'nt nhận ra tôi có thể gắn thẻ các hotfix chính nó, như trái ngược với sáp nhập vào phát triển/chủ và sau đó gắn thẻ. Cảm ơn! – Ivan

Các vấn đề liên quan