Có phải là một cách thực hành tốt để sử dụng các nhánh để duy trì các phiên bản khác nhau của cùng một phần mềm?

Chúng tôi có một sản phẩm có một vài phiên bản khác nhau. Sự khác biệt là nhỏ: các chuỗi khác nhau ở đây và ở đó, rất ít logic bổ sung trong một, rất ít sự khác biệt trong logic khác. Khi phần mềm đang được phát triển, hầu hết các thay đổi cần được thêm vào mỗi phiên bản; tuy nhiên, có một số không và một số ít cần phải khác nhau. Đây có phải là một nhánh sử dụng hợp lệ nếu tôi có các nhánh phát hành phiên bảnA và phiên bản phát hànhB (..etc) không? Có bất kỳ vấn đề nào không? Thực hành tốt?

Cập nhật: Cảm ơn mọi người vì cái nhìn sâu sắc, rất nhiều câu trả lời hay ở đây. Sự đồng thuận chung dường như là một ý tưởng tồi khi sử dụng các chi nhánh cho mục đích này. Đối với bất kỳ ai thắc mắc, giải pháp cuối cùng của tôi cho vấn đề này là bên ngoài các chuỗi như cấu hình và bên ngoài logic khác nhau như các plugin hoặc tập lệnh.

Điều này phụ thuộc vào mức độ thay đổi, nhưng tôi sẽ không coi đó là thông lệ tốt cho những khác biệt bạn mô tả.

Nói chung, bạn muốn một nhánh Git là một cái gì đó sẽ được hợp nhất trong tương lai hoặc được lưu trữ chỉ đọc để tham khảo. Các nhánh Git cùng tồn tại vô thời hạn có nghĩa là công việc cho tất cả mọi người: Các thay đổi cần được tuyên truyền và sáp nhập, các xung đột được giải quyết, tất cả đều vui vẻ. Nếu không có gì khác, mọi nhà phát triển phải nhớ đẩy các thay đổi lên năm kho thay vì một.

Nếu bạn có những thay đổi nhỏ, toàn bộ nỗ lực sáp nhập và giữ chi nhánh dường như quá mức cần thiết khi so sánh với vấn đề. Sử dụng bộ tiền xử lý hoặc hệ thống xây dựng của bạn để phân biệt giữa các phiên bản. Liệu một đơn giản #ifdeflàm thủ thuật? Sau đó, không giải quyết vấn đề với git, đó là quá mức cần thiết.

Đó không thực sự là những gì các chi nhánh dành cho. Các nhánh được cho là các đường dẫn ngắn đến trung hạn cho dòng phát triển của bạn, không phải là các phiên bản song song dài hạn của cùng một mã.

Tôi đã đặt tất cả các phiên bản khác nhau vào cùng một nhánh, với thư mục con cho các phần khác nhau giữa các phiên bản và thiết lập quy trình xây dựng của bạn (bạn có bản dựng tự động, phải không?) Để nó có thể xuất bản theo yêu cầu (hoặc tất cả chúng cùng một lúc).

Rốt cuộc, bạn muốn giữ một "nguồn chân lý duy nhất"; với các nhánh, bạn sẽ sao chép một số mã, nhưng không phải tất cả và một số kết hợp nhất định trên thực tế sẽ phá vỡ thiết lập của bạn.

Một giải pháp - như mọi người đã chỉ ra - là cấu hình hệ thống xây dựng để hỗ trợ các phiên bản khác nhau.

Tôi cũng sẽ xem xét triển khai nó như là các tính năng bật và sử dụng tệp cấu hình. Bạn càng ít phải xây dựng, càng tốt.

Có một cái nhìn vào trang web này.

Tôi nghĩ rằng đó là một ý tưởng tốt với điều kiện bạn không thể thực hiện nó trong một nhánh mà không cần phân cụm mã thành nhiều.
Tôi muốn có thể giữ nó trong một nhánh và sử dụng các tệp cấu hình và cục bộ, đặc biệt nếu bạn nói sự khác biệt là nhỏ.
Một cách khác có thể là các bản dựng khác nhau, ví dụ: tệp xây dựng của bạn gói các tệp khác nhau cho các khách hàng khác nhau nhưng tôi cũng có thể thấy công cụ xây dựng kiểm tra các nhánh khác nhau. Khi bạn sử dụng git, tôi sẽ nói không có vấn đề thực sự. Một chiến lược phân nhánh có thể là phát triển trên các nhánh khác nhau cho các nhiệm vụ khác nhau, đăng nhập vào nhánh chính và hợp nhất từ ​​master sang phiên bảnX và Y.

Điều này nghe có vẻ giống như một công việc cho các cấu hình xây dựng khác nhau. Câu trả lời của thiton đi theo hướng này nhưng tôi sẽ đưa nó đi xa hơn #ifdef:

Sử dụng các mục tiêu xây dựng khác nhau để xây dựng các phiên bản khác nhau của phần mềm. Mục tiêu có thể khác nhau bởi

• cấu hình họ bao gồm,
• các đối tượng hoặc tệp nguồn mà chúng bao gồm, hoặc
• tiền xử lý của mã nguồn.

Quá trình tiền xử lý này rõ ràng có thể bao gồm bộ tiền xử lý C cổ điển nhưng nó cũng có thể đòi hỏi phải sử dụng bộ tiền xử lý tùy chỉnh, công cụ mẫu để xây dựng chế độ xem tùy chỉnh,

Bằng cách này, bạn tránh phải chủ động đẩy từng thay đổi ra nhiều nhánh, vi phạm DRY (tất nhiên điều đó cũng có thể được tự động hóa nhưng tôi không thấy lợi thế).

Tôi sẽ chỉ sử dụng các chi nhánh cho các thay đổi quan trọng, nếu không, cuối cùng bạn sẽ thêm từng thay đổi nhỏ vào nhiều chi nhánh, điều này không vui chút nào và rất dễ bị lỗi, đặc biệt là nếu bạn làm việc với nhiều người hơn.

Nếu bạn đang phát hành tất cả chúng dưới dạng các sản phẩm khác nhau thì nên có nhiều chi nhánh. Nếu không, thì vẫn nên sử dụng một cái gì đó như thân cây hoặc nhánh chính.

Ngoài ra, tôi nghĩ rằng điều này sẽ phụ thuộc vào quá trình phát triển mà bạn có, đặc biệt là triển khai. Nếu bạn có một quy trình chỉ cho phép một chi nhánh được đưa vào sản xuất và các chi nhánh đang được coi là "bản dựng gia tăng" nghĩa là bản phát hành B không thể được đưa vào sản xuất trừ khi bản phát hành A được đưa ra trước, vì tất cả các thay đổi của A đã có trong B, sau đó có nhiều chi nhánh là con đường để đi. Điều này sẽ hoạt động nếu bạn có các nhóm nằm rải rác trên toàn cầu và bạn thường có các thay đổi theo thứ tự ưu tiên.

Giải pháp với ba nhánh khác nhau (cho sản xuất, phát triển và tính năng) hoạt động thực sự tốt. Hãy nói rằng bạn phát hiện ra một số lỗi trong mã sản xuất của bạn sau đó bạn có thể áp dụng một bản vá cho nó sau đó phát hành nó. Chỉ cần đảm bảo rằng bạn không thực hiện bất kỳ bổ sung tính năng nào cho nhánh sản xuất hoặc bất kỳ thay đổi lớn nào đối với nhánh sản xuất. Bạn và nhóm của bạn sẽ phải tự kỷ luật để không thêm bất kỳ thay đổi tính năng chính nào vào chi nhánh sản xuất của bạn. Chi nhánh sản xuất chỉ dành cho các sửa lỗi nhỏ không bảo đảm một thay đổi lớn trong cơ sở mã sản xuất của bạn.