Nên phát hành chi nhánh bao giờ được sáp nhập để làm chủ

Nhóm của tôi đang sử dụng mô hình phân nhánh Git Stable Mainline và chúng tôi sắp tạo ra nhánh phát hành đầu tiên. Từ những gì tôi đã đọc cho đến nay, có vẻ như các nhánh phát hành bị bỏ lại từ nhánh chính và không bao giờ được hợp nhất hoàn toàn trở lại chủ. Thay vào đó, nếu một bản sửa lỗi được thực hiện trên nhánh phát hành, thì nó thường được chọn trở lại nhánh chính. Điều này có ý nghĩa với tôi vì bạn muốn giữ bản phát hành hiện tại tách biệt hoàn toàn với bản phát hành của bản phát hành tiếp theo, trong khi vẫn có thể phát triển bộ tính năng tiếp theo trên bản gốc cùng lúc với bản phát hành hiện tại.

Những nhánh phát hành này nên được giữ trong bao lâu? Có trường hợp nào trong đó họ nên được sáp nhập hoàn toàn trở lại thành chủ?

git release-management

Chiến lược phân nhánh bạn sử dụng phụ thuộc hoàn toàn vào quy trình làm việc của tổ chức và các yêu cầu cụ thể.

— Robert Harvey

How long should these release branches be kept around for?Miễn là bạn mong đợi nhận được một lỗi sai cho bản phát hành mà bạn muốn sao chép từ mã nguồn. Tôi sẽ không loại bỏ bất kỳ nhánh phát hành nào vì một nhánh có dấu chân kilobyte nhỏ trên máy chủ. chỉ đồng bằng chi phí bộ nhớ ổ cứng

— k3b

cherry pickingmỗi và mọi cam kết trên nhánh phát hành thành chủ hoặc merging phát hành thành chủ về mặt kỹ thuật đều giống nhau về mặt kỹ thuật chấp nhận rằng bạn không "nhìn thấy" cherry pickstrong lịch sử git. Vì vậy, tôi muốn mergingmỗi bản sửa lỗi trở lại thành chủ sử dụng --no-fftùy chọn gits để lịch sử hiển thị nhánh phát hành thêm.

— Timothy Truckle

ý bạn là thế này: bitsnbites.eu/a-urdy-mainline-branching-model-for-git anh ấy nói rằng đừng bao giờ hợp nhất các nhánh phát hành trở lại

— Ewan

Cảm ơn các ý kiến phản hồi tất cả mọi người. @Ewan Có, nhưng tôi cũng đã đọc một số tài liệu Git chung do Microsoft viết và có vẻ như họ chưa bao giờ hợp nhất toàn bộ chi nhánh phát hành trở lại để làm chủ.

Những nhánh này nên giữ trong bao lâu?

Câu trả lời đầu tiên xuất hiện trong tâm trí tôi ở đây là:

Tại sao bạn tạo chi nhánh phát hành ở nơi đầu tiên?

Nếu bạn đang nhắm đến việc có thể cung cấp hỗ trợ cho một phiên bản trong sử dụng sản xuất thì nó sẽ tồn tại miễn là phiên bản đó tồn tại với khách hàng của bạn. (giả sử hỗ trợ LTS, bạn có thể có nhiều chi nhánh như vậy, khiến mọi thứ trở nên phức tạp hơn một chút)

Nếu bạn đang tách công việc ổn định khỏi sự phát triển mới đang diễn ra thì một khi phiên bản được triển khai, bạn không thực sự cần chi nhánh đó nữa. Ở đây điều này sẽ gợi ý tại một đường ống giao hàng liên tục. Bất kỳ lỗi nào được sửa chữa trong phiên bản tiếp theo sẽ xảy ra thường xuyên nhất có thể. Một số người đẩy điều này để coi nhánh chính là nhánh ổn định triển khai nhiều lần mỗi ngày. Những người khác sẽ đồng bộ hóa với nước rút của họ và phát hành hai đến ba tuần một lần.

Bạn có nên hợp nhất nó hoàn toàn trở lại thành chủ?

Như bạn đoán, tất cả phụ thuộc vào lý do tại sao bạn áp dụng chiến lược phân nhánh này. đối với kiểu phân phối liên tục, vì nhánh sẽ không bao giờ được sử dụng nữa, nên bạn nên xử lý nó giống như bất kỳ nhánh tính năng hoặc lỗi nào, có khả năng bạn sẽ hợp nhất nó lại với chủ và quên nó đi.

Tuy nhiên, nếu bạn đang nhắm đến phong cách LTS thì có khả năng bạn sẽ không hợp nhất lại, đặc biệt nếu bạn có nhiều chi nhánh như vậy. Tại đây, bạn sẽ áp dụng bản sửa lỗi cho tất cả các nhánh phát hành và chọn cherry từ một trong số chúng để hợp nhất bản sửa lỗi đó trong bản gốc. Trong kịch bản này, điều cuối cùng bạn muốn làm là coi nó giống như bất kỳ nhánh tính năng nào khác, nơi các thay đổi từ chủ được kéo vào đó và xung đột được giải quyết ở đó thay vì trong chủ.

Nếu không biết thêm về vòng đời sản phẩm của bạn và quy trình làm việc của nhóm bạn, thật khó để đưa ra một lời khuyên chính xác hơn ở đây.

— Newtopian
nguồn

Điều này ngụ ý rằng chi nhánh bị mất sau khi sáp nhập, đó không phải là một trường hợp. Chi nhánh phát hành cũng nên được hợp nhất trong chế độ LTS. Không có lý do để không hợp nhất các nhánh phát hành.

— Basilevs

Đó không phải là về việc các chi nhánh bị mất mà nhiều hơn là buộc người ta phải suy nghĩ, việc hợp nhất một cách có hệ thống các chi nhánh LTS sẽ khiến chúng hợp nhất các bản sao cho mỗi chi nhánh LTS đang hoạt động. Một bản sửa lỗi chỉ cần được hợp nhất trở lại một lần với chính và có thể không phải từ một nhánh LTS vì phiên bản gần đây nhất có thể chưa có trong LTS và sẽ gần với trạng thái của nhánh chính hơn. Trong kịch bản này, người ta sẽ chọn anh đào từ phiên bản gần đây nhất, bản thân chi nhánh LTS sẽ gần như không bao giờ được đẩy lên chủ. Rằng chi nhánh bị mất hoặc không sau khi hợp nhất là không liên quan.

— Newtopian

Tại sao người ta thích sao chép cherry-picks không an toàn để sao chép hợp nhất an toàn? Theo "an toàn", tôi có nghĩa là theo dõi và tuyên truyền thay đổi được bảo vệ bằng mật mã.

— Basilevs

Cách tiếp cận tương tự hoạt động mà không cần chọn cherry bằng cách áp dụng bản sửa lỗi cho nhánh cũ nhất và hợp nhất từ cũ hơn sang mới hơn. Nếu anh đào có thể tránh được tại sao sử dụng chúng? Tôi dường như hiểu nhầm một cái gì đó trong mô hình Mainline ổn định ...

— Basilevs