2015-02-27 30 views
10

Chúng tôi đang cố gắng áp dụng gitflow vào quá trình của chúng tôi tại nơi làm việc. Gitflow khá đơn giản khi nói đến hotfix. Tuy nhiên, tôi không rõ ràng làm thế nào tôi sẽ sửa chữa một lỗi trên một phiên bản trước của hệ thống của chúng tôi.Làm thế nào để bạn phát hành một bugfix đến một phiên bản trước đó và gắn thẻ nó?

Ví dụ: giả sử chúng ta đang ở phiên bản 8.1.3 và tôi cần tạo một bugfix thành 7.1.5. Tôi có thể tạo một chi nhánh dựa trên thẻ 7.1.5, nhưng sau đó làm cách nào để tôi lấy lại chi nhánh đó và gắn thẻ nó? Điều đó thậm chí có thể sử dụng Git? Tôi đã nghĩ đến việc chỉ giữ các nhánh phát hành và cam kết và gắn thẻ ở đó, nhưng tôi không chắc đó có phải là cách thích hợp để làm việc hay không.

+0

Theo Git Flow, bạn sẽ không sửa được 7.1.5 chút nào; đã quá muộn rồi. Thay vào đó, bạn sẽ tạo một nhánh hotfix xuất phát từ bản phát hành mới nhất của bạn (8.1.3), sửa lỗi ở đó và sau đó hợp nhất nhánh hotfix đó thành chính, do đó tạo bản phát hành mới (8.1.4?). Xem [cam kết màu đỏ trên sơ đồ nvie] (http://nvie.com/posts/a-successful-git-branching-model/). – Jubobs

+1

Đôi khi khách hàng muốn ở lại trên một phiên bản cụ thể của hệ thống của chúng tôi, nhưng đi từ 7,0 -> 8,0 sẽ giới thiệu những thay đổi lớn. Toàn bộ quá trình tạo ra một hotifx và sáp nhập để làm chủ/phát triển có ý nghĩa, tôi chỉ cảm thấy như đó là ví dụ phù hợp nhất. Tôi chỉ không chắc chắn làm thế nào để hỗ trợ khách hàng sử dụng các phiên bản chính trước đó của hệ thống của chúng tôi. – Robert

+0

Mô hình Git-Flow không đưa ra các điều khoản cho trường hợp đó. – Jubobs

Trả lời

8

Dòng Git trong mô hình ban đầu của nó không nói về các phiên bản chính được hỗ trợ cùng một lúc. Nó không mô tả một mô hình, nơi bạn có các phiên bản sau đây trong sản xuất:

  • 7.1.5: Hai khách hàng đang sử dụng này
  • 8.2.3: Ba khách hàng đang sử dụng này
  • 9.0.0: Đây là phiên bản chính tiếp theo mà bạn hiện đang làm việc.

Trong luồng Git, chi nhánhchính là phiên bản hiện tại của bạn được hỗ trợ, phát hành, mọi thứ khác cũ và được xem là cũ. Đã nói rằng, và vì chúng tôi đang ở trong tình trạng tương tự, nơi chúng tôi phải hỗ trợ nhiều phiên bản chính cùng một lúc (ít nhất một phiên bản chúng tôi cung cấp sửa lỗi và một trong những nơi chúng tôi cung cấp các tính năng mới), chúng tôi đã đưa ra như sau:

  • phát triểnchủ: đây là những chi nhánh cho công việc hiện tại. Bất cứ điều gì mà đi vào phiên bản lớn tiếp theo được thực hiện ở đây.
  • Một khi chúng ta làm một phiên bản ổn định mới (ví dụ 7.3.0), chúng tôi tạo ra các chi nhánh sau:
    • 7.3/phát triển
    • 7.3/master

Những chi nhánh giờ đây trở thành chi nhánh phát triểnchi nhánh chính cho bản phát hành được hỗ trợ này. Mọi bản sửa lỗi chúng tôi cần thực hiện trên v7.3.0 được thực hiện trong chi nhánh 7.3/phát triển và sau khi chúng tôi tạo bản phát hành v7.3.1, nó được thực hiện trên 7.3/phát triển7.3/master.

Những thay đổi mà cần phải được thực hiện trong cả hai phát triển chi nhánh thường cherry chọn kỹ lưỡng, vì chúng ta không muốn kết hợp các tính năng mới từ phát triển thành một già đi, nhưng vẫn duy trì phát triển chi nhánh.

Quá trình này mất một chút thiết lập, nhưng nó hoạt động khá tốt và miễn là bạn nhớ tạo các nhánh cần thiết khi bắt đầu làm việc trên phiên bản ổn định tiếp theo, không quá nhiều chi phí.

+0

chỉ để đảm bảo: trong cách tiếp cận bạn đề xuất, các nhánh 7.3/master và 7.3/develop sẽ không bao giờ được hợp nhất trở lại các nhánh phát triển chính, sẽ vẫn "tách" mãi mãi phải không? – rickyviking

+0

Vâng, đó là sự thật - chúng là các phiên bản phát hành riêng biệt. Đôi khi, chúng tôi chọn các cam kết riêng lẻ ở nơi có ý nghĩa, nhưng không bao giờ hợp nhất giữa '7.3/phát triển' và 'phát triển'. – nwinkler

1

một cách có thể là:

  • tạo ra một chi nhánh "7.1" mà bạn tạo sửa lỗi (7.1.6, ...)
  • cherry-chọn sửa đổi của bạn để đặt chúng trên đầu trang của thầy cũng như (bạn sẽ gắn thẻ lại, nhưng với một thẻ khác: 8.1.4)

không chắc chắn đây là cách tốt nhất, nhưng có thể.

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