Tôi đã sử dụng Perforce trong một thời gian dài, và vì vậy nhận xét của tôi có thể là một chút Perforce-centric, nhưng các nguyên tắc cơ bản áp dụng cho bất kỳ phần mềm SCM nào có phân nhánh một nửa. Tôi là một người rất tin tưởng trong việc sử dụng các thực hành phát triển phân nhánh. Tôi có một "chính" (aka "mainline") đại diện cho codebase từ nay đến vĩnh cửu. Mục đích là, hầu hết thời gian, ổn định và, nếu đẩy đến xô, bạn có thể cắt một bản phát hành bất cứ lúc nào sẽ phản ánh chức năng hiện tại của hệ thống. Những người bán hàng pesky tiếp tục yêu cầu ....
Sự phát triển xảy ra trong các nhánh được phân nhánh từ MAIN (thông thường - đôi khi bạn có thể muốn phân nhánh từ chi nhánh nhà phát triển hiện có). Tích hợp từ MAIN đến các nhánh của bạn thường xuyên nhất có thể, để ngăn mọi thứ phân tán quá nhiều - hoặc bạn có thể đơn giản là ngân sách cho một giai đoạn tích hợp lớn hơn sau này. Chỉ tích hợp ass của bạn đá tính năng mới vào MAIN khi bạn chắc chắn rằng nó sẽ đi ra trong bản phát hành sắp tới.
Cuối cùng, bạn có một dòng RELEASE, tùy chọn của các nhánh khác nhau cho các bản phát hành khác nhau. Có một số lựa chọn tùy thuộc vào khả năng ghi nhãn của phần mềm SCM của bạn và các bản sửa đổi lớn/nhỏ khác nhau có thể như thế nào.Vì vậy, bạn có thể lựa chọn, ví dụ, cho một chi nhánh phát hành cho mỗi bản phát hành điểm, hoặc chỉ cho số rev chính. Số dặm của bạn có thể thay đổi.
Nói chung, chi nhánh từ MAIN phát hành chậm nhất có thể. Sửa lỗi và các thay đổi vào phút cuối có thể đi thẳng vào RELEASE để tích hợp sau vào MAIN hoặc vào MAIN để tích hợp ngay lập tức trở lại. Không có quy tắc cứng và nhanh - làm những gì hiệu quả nhất. Tuy nhiên, nếu bạn có các thay đổi có thể được gửi tới MAIN (ví dụ: từ chi nhánh nhà phát triển hoặc "chỉnh sửa nhỏ" của ai đó trên MAIN), hãy thực hiện các thay đổi trước đó. Tùy thuộc vào cách thức hoạt động của nhóm của bạn, chu kỳ phát hành của bạn là gì.
Ví dụ: Tôi sẽ có một cái gì đó như thế này:
//MYPROJECT/MAIN/... - the top level folder for a complete build of all the product in main.
//MYPROJECT/DEV/ArseKickingFeature/... - a branch from MAIN where developers work.
//MYPROJECT/RELEASE/1.0/...
//MYPROJECT/RELEASE/2.0/...
Một dự án không tầm thường có thể sẽ có một số nhánh DEV hoạt động cùng một lúc. Khi một sự phát triển đã được tích hợp vào MAIN để nó bây giờ là một phần của dự án cốt lõi, hãy tiêu diệt nhánh DEV cũ càng sớm càng tốt. Nhiều kỹ sư sẽ coi chi nhánh DEV là không gian cá nhân của riêng họ và sử dụng lại nó cho các tính năng khác nhau theo thời gian. Không khuyến khích điều này.
Nếu sau khi phát hành, bạn phải sửa lỗi, sau đó thực hiện điều đó trong nhánh phát hành tương ứng. Nếu lỗi đã được sửa trước đó trong MAIN, sau đó tích hợp trên, trừ khi mã đã thay đổi rất nhiều trong MAIN sửa chữa là khác nhau.
Điều gì thực sự phân biệt các dòng mã là các chính sách bạn sử dụng để quản lý chúng. Ví dụ: những thử nghiệm nào được chạy, người đánh giá trước/đăng thay đổi, hành động nào sẽ xảy ra nếu một phiên bản bị hỏng. Thông thường các chính sách - và do đó trên không - là mạnh nhất trong các nhánh phát hành và yếu nhất trong DEV. Có một bài viết here mà đi qua một số kịch bản, và liên kết đến những thứ hữu ích khác.
Cuối cùng, tôi khuyên bạn nên sử dụng cấu trúc đơn giản để bắt đầu và chỉ giới thiệu thêm dev & bản phát hành nếu cần.
Hy vọng điều đó sẽ hữu ích và không thể hiện rõ ràng quá nhiều.