Kiểm soát nguồn - Là một nhánh riêng biệt cần thiết cho mỗi sản phẩm?

Question

Giả sử bạn có bốn sản phẩm đều có lịch phát hành riêng. Mỗi sản phẩm có 50% mã chia sẻ (chức năng phổ biến trên tất cả các sản phẩm) và 50% mã sản phẩm cụ thể.

Bạn có cần một nhánh kiểm soát nguồn riêng biệt cho từng sản phẩm không? Các chức năng thông thường có nên được phát triển ở một trong bốn ngành sản phẩm và sáp nhập với các sản phẩm khác sau này không?

Trường hợp điển hình: Sản phẩm A được phát hành vào tháng tới và yêu cầu nâng cấp lõi (chia sẻ) 1, sản phẩm B được phát hành trong bốn tháng và yêu cầu nâng cấp lõi (được chia sẻ) 2 (sẽ mất ba tháng để hoàn thành).

Answer 1

Đây là IMO một trong những điều tốt nhất mà tôi đã đọc về phân nhánh: Branching and merging in the face of agile development, extreme programming, team collaboration, and parallel releases

Tôi nghĩ rằng tôi muốn để tránh khớp nối các chi nhánh (và do đó tiến độ) của hai dự án: và vì vậy, thay vì một chi nhánh duy nhất trong đó bạn đang chỉnh sửa chức năng phổ biến và chỉnh sửa nhiều hơn một sản phẩm, có lẽ một trong hai phương thức sau:

1) Xây dựng các chức năng phổ biến một cách độc lập của bất kỳ sản phẩm

• Chi nhánh chung chức năng
• Thêm vào đó
• Đơn vị kiểm tra nó
• Commit nó trở lại vào
chi nhánh sản phẩm cụ thể
• Make đường chính của nó (Mainline) và sử dụng nó trong các sản phẩm

2) Phát triển các chức năng thông thường với một sản phẩm

• Thực hiện một chi nhánh sản phẩm
• trong ngành sản phẩm, thêm chức năng mới vào thư viện chung cũng như các thành phần dành riêng cho sản phẩm
• Kiểm tra đơn vị và kiểm tra hệ thống và cam kết trở lại vào đường chính
• Tạo các nhánh của đường chính mới mà bạn sử dụng mới chức năng phổ biến được cam kết trong các sản phẩm khác

Answer 2

Đặt tất cả trong một chi nhánh. Bạn muốn biết tại thời điểm phát triển nếu một sự thay đổi trong sản phẩm A phá vỡ sản phẩm B. Điều này là tốt hơn nhiều so với việc kết hợp một mớ hỗn độn khi bạn phát hiện ra rằng ProductB phải viết lại một nửa bộ mã nguồn phổ biến của bạn.

EDIT: Để làm rõ, tôi có nghĩa là tất cả họ nên chia sẻ một chi nhánh phát triển. Tôi sẽ tư vấn cho một chi nhánh sản xuất riêng để đại diện cho mã đang được sản xuất và chi nhánh bảo trì nếu bạn phát hành bản sửa lỗi thường xuyên.

Answer 3

Không phải là câu trả lời trực tiếp cho câu hỏi của bạn, bởi vì tôi không chắc chắn 100% có một câu trả lời "một kích thước phù hợp với tất cả" có thể được đưa ra. Nhưng Jeff đã viết một số tuyệt vời blog post around branching.

Answer 4

Chức năng phổ biến có thể được phát triển trong một nhánh nền tảng riêng biệt, với mỗi sản phẩm nhận được chi nhánh riêng để phát triển sản phẩm cụ thể.

Answer 5

Tôi giữ mã được chia sẻ trong thư mục sản phẩm của chính nó. Sau đó, sử dụng svn:externals để chia sẻ mã giữa các sản phẩm khác. Đó là hơi đau đớn để xử lý phân nhánh và sáp nhập, nhưng nó tốt hơn so với việc có bốn bản sao của mã được chia sẻ trong kho lưu trữ. Một cái gì đó như thế này (thay thế thân với /branches/RB-1.0.0 hoặc /tags/REL-1.0.0 cho ngành phát hành và được gắn thẻ phát hành):

/core/trunk 
/product_a/trunk 
    /core (svn:externals 'core /core/trunk') 
/product_b/trunk 
    /core (svn:externals 'core /core/trunk') 
/product_c/trunk 
    /core (svn:externals 'core /core/trunk') 
/product_d/trunk 
    /core (svn:externals 'core /core/trunk') 

UPDATE0: Lưu ý rằng/PRODUCT_A/thẻ/REL-1.0.0 có thể sử dụng /core/tags/REL-1.0.0 trong khi /product_b/tags/REL-1.0.0 có thể sử dụng /core/tags/REL-1.1.0

Answer 6

Chúng tôi có kịch bản tương tự. Chúng tôi có các thư viện chung để ghi nhật ký, truy cập dữ liệu và bảo mật nhưng các thư viện này được sử dụng trên nhiều dự án. Những gì chúng tôi làm là tạo ra một bộ riêng biệt của các chi nhánh cho mỗi sản phẩm và sau đó sử dụng SVN externals để liên kết với các thư viện phổ biến. Vì vậy, các thư viện chung được duy trì trong một nhánh "được chia sẻ" trên tất cả các dự án, trong khi tất cả các dự án đều có các nhánh độc lập.

Bằng cách này, chúng tôi có thể đảm bảo rằng tất cả các sản phẩm đang xây dựng dựa trên phiên bản mới nhất của các thư viện chung, trong khi các dự án cũng có thể duy trì độc lập.

Answer 7

Chúng tôi đã xây dựng một loạt các trang web có cơ sở chung và một lượng lớn mã tùy chỉnh sử dụng git bằng cách cấu trúc nó dưới dạng một loạt các nhánh.

Chi nhánh chính chứa mã lõi và mỗi chi nhánh của chủ đó là một tùy chỉnh cụ thể của lõi. Khi thực hiện thay đổi cho lõi, thật dễ dàng đẩy chúng xuống các nhánh, trong khi vẫn giữ riêng từng phiên bản tùy chỉnh.

18 trang web và dự án 12 tháng với nhóm 7 người và nó vẫn được kiểm soát tốt!

Answer 8

Chi nhánh tại điểm cao nhất có thể trong cây của bạn. IE, nó nên bao gồm mã cho tất cả các dự án của bạn, mô-đun được chia sẻ ... và có thể là những thứ như tài liệu/xây dựng kịch bản/trình cài đặt/v.v. Tại sao? Tại sao không! Các chi nhánh có giá rẻ trong tất cả các hệ thống được đề cập cho đến nay (SVN, TFS, Perforce, git).

Chiến thuật này đặc biệt quan trọng trong các hệ thống sử dụng phân nhánh "không gian đường dẫn" (TFS, Perforce). Nếu không, tạo một bản dựng bộ sản phẩm hoàn chỉnh phù hợp với không gian làm việc của những người khác nhau sẽ trở thành cơn ác mộng bảo trì.

Khi bạn đã đưa điều này vào thực tế, bạn được tự do sửa đổi càng nhiều hoặc ít phần mã theo ý muốn của bạn trong một nhánh cụ thể. Bạn luôn có thể thực hiện một bản dựng đầy đủ để xác minh các vấn đề tích hợp; tùy chọn hợp nhất bất kỳ thành phần nào giữa bất kỳ nhóm chi nhánh nào vẫn mở cho bạn. Nhưng câu hỏi của Chiến lược SDLC hoàn toàn trực giao. Bạn có thể phân nhánh cho mỗi tính năng, mỗi nhóm, mỗi lần phát hành hoặc bất kỳ kết hợp nào ở trên; * Thực tế là mỗi chi nhánh xảy ra là một superset chứng minh thuận lợi trong nhiều chiến lược, và không bao giờ nên là một con miễn là các công cụ của bạn là đến thách thức.

* Chọn chiến lược là một vấn đề riêng lẻ phụ thuộc vào nhiều yếu tố. Những người khác đã đề xuất một số tài liệu nổi tiếng giúp bạn quyết định. Tôi sẽ đưa bản sửa đổi mới nhất của Microsoft's TFS guidance lên đó với bản sửa đổi tốt nhất của chúng.