Một số phương pháp hay nhất để duy trì nhiều phiên bản của một dự án là gì?

Question

Tôi đã có một dự án nơi chúng tôi triển khai phiên bản v1 và bắt đầu công việc trên phiên bản v2. Tôi sợ rằng chúng ta sẽ thấy các bản sửa lỗi và các thay đổi về tính năng nhỏ đối với v1 trong vài tháng tới, một số trong đó chúng ta sẽ cần phải chuyển sang v2, một số trong đó chúng ta sẽ cần phải giữ tách rời. (Chúng tôi cần duy trì bộ tính năng chính của v1 nhưng sửa bất kỳ lỗi nào khi chúng được tìm thấy.)

Chúng tôi đang sử dụng SVN tại thời điểm này. Tôi đã xem xét chuyển sang Git, nhưng tôi hơi miễn cưỡng khi thay đổi công cụ. Ngoài khả năng đó, một số chiến lược chung và thực tiễn tốt nhất để quản lý tình huống này dễ dàng nhất có thể là gì?

Cập nhật: mọi người đều đề xuất tôi phân nhánh mã trong Subversion. Điều đó rõ ràng đối với tôi rằng tôi nghĩ nó được ngụ ý bởi câu lệnh "chúng tôi đang sử dụng SVN". Rõ ràng là không. :) Tôi sẽ xem xét Mercurial và Bazaar cũng như Git. Còn gì nữa không?

Answer 1

Sử dụng SVN, tốt nhất bạn có thể làm là chi nhánh kho của bạn:

• Trong thân cây, giữ phiên bản mới nhất - không nhất thiết một ổn định.
• Bất cứ khi nào bạn cần tách phiên bản chính mới từ đó, phân nhánh thành 2.0, và bạn có thể giữ phiên bản mới nhất và phiên bản ổn định trong cùng một kho lưu trữ.
• Nếu bạn tìm thấy các thay đổi trong nhánh 2.0 cần được hợp nhất vào trong thân cây, bạn có thể làm điều đó một cách liền mạch.

Answer 2

Bạn nên sử dụng SVN để gắn thẻ mã v1. Bằng cách đó bạn có thể tạo một nhánh riêng biệt của mã để hỗ trợ các bản sửa lỗi cho cơ sở mã đó.

Answer 3

Bạn đã xem xét phân nhánh thân cây và phát triển v2 trên nhánh thứ hai khi nhánh v1 bị đóng băng? Nếu bạn sửa lỗi trên nhánh v2 ảnh hưởng đến v1 và bạn muốn phát hành bản cập nhật/bản vá cho v1, chỉ cần hợp nhất những thay đổi cụ thể đó lại với chi nhánh v1 từ nhánh v2.

Tất cả điều đó hoàn toàn có thể thực hiện được trong SVN, nhưng việc quản lý chi nhánh dễ dàng hơn với một công cụ như Mercurial hoặc Git. Tôi không thể nói với bạn nếu nó chắc chắn có giá trị chuyển đổi hay không vì tôi không biết công ty của bạn hoặc codebase, nhưng nó là một cái gì đó để xem xét nếu bạn có thể nhìn thấy tình trạng này phát sinh nhiều lần trong tương lai khi bạn phát hành nhiều phiên bản.

Answer 4

Đối với các phiên bản khác nhau, cách thực hành tốt nhất là lưu trữ các phiên bản có tên trong thư mục con "thẻ". (Tài liệu SVN khuyên bạn nên có một thân cây, thẻ và thư mục chi nhánh cho từng dự án).

Bất cứ khi nào bạn phát hành phiên bản, hãy sao chép thân cây vào thư mục thẻ và đặt tên cho nó. Phiên bản đó có thể tồn tại và các bản sửa lỗi có thể được thực hiện riêng biệt và sáp nhập qua lại.

SVN tài liệu về bố trí kho:

http://svnbook.red-bean.com/en/1.2/svn.branchmerge.maint.html

Answer 5

chúng tôi đang sử dụng TFS, nhưng đối với vấn đề cụ thể của bạn, giải pháp sẽ được khá tương tự: tạo ra một chi nhánh mới.
[Tùy theo môi trường ứng dụng mà bạn đang sử dụng, rõ ràng không phải Microsoft]
Chúng tôi đã được hưởng lợi từ TFS vì:

1. Bạn có thể làm kết hợp giữa các ngành [hòa trộn vô căn cứ]
2. Bạn có thể làm việc với workitems, [ để sửa lỗi]
3. Với hỗ trợ thêm, bạn có thể có tài liệu, tập lệnh thử nghiệm có thể sống cùng nhau vui vẻ tại một cổng.
4. Với kịch bản PowerShell, bạn có thể có đêm automerges

Answer 6

Sử dụng git bạn có thể sử dụng phương pháp sau đây:

kho git của bạn có thể có các chi nhánh sau. Mỗi chi nhánh hotfix chứa bản phát hành tính năng phải được duy trì.

master     - version: 3.0.0 (latest release) 
    \ 
    dev     - version: 4.0.0 (next release) 
    |\ 
    | hotfix-1.x   - version: 1.0.1 (current hotfix 1.x) 
    \ 
    | hotfix-2.x   - version: 2.0.1 (current hotfix 2.x) 
    \ 
    hotfix-3.x   - version: 3.0.1 (current hotfix 3.x) 

Fixes:

Sửa lỗi được thực hiện trong hotfix-1.x và sáp nhập "lên" thành hotfix-2.x và từ đó đến hotfix-3.x.

hotfix-1.x -> hotfix-2.x -> hotfix-3.x ...

Sửa lỗi cũng có thể được sử dụng git backported lệnh cherry-pick từ hotfix-3 .x tới hotfix-1.x (nếu cần). Với lệnh cherry-pick, bạn có thể chọn một commit duy nhất và áp dụng nó trong một nhánh khác. Git cũng sẽ phát hiện các tệp được di chuyển và đổi tên và vẫn áp dụng thay đổi chính xác.

Bạn cũng có thể thêm các nhánh phát hành song song với các nhánh hotfix của bạn để chuẩn bị các bản phát hành trong các nhánh đó (bỏ qua cho ví dụ này). Điều này rất hữu ích khi bạn không muốn chặn các nhánh hotfix cho các cam kết mới. Vui lòng thanh toán gitflow nếu bạn muốn biết thêm chi tiết về hotfix và các chi nhánh phát hành.

chí

Tính năng:

Các tính năng mới đều dựa trên các chi nhánh dev và sáp nhập trở lại vào chi nhánh dev sau khi hoàn thành. Chi nhánh hotfix mới được tạo cho mỗi bản phát hành tính năng mới.

bước:

• Merge thay đổi từ chi nhánh hotfix hiện tại vào dev
• ngành chức năng Merge trở lại vào dev
• Tạo chi nhánh hotfix mới từ dev
• phát hành từ hotfix mới chi nhánh
• Merge trở lại vào chủ

Ghi chú:

Tôi nghĩ rằng ngành thạc sĩ không còn rất quan trọng khi bạn quyết định để giữ cho chi nhánh hotfix của bạn. Tôi tin rằng các chương trình gitflow phổ biến hoạt động theo cách mà bạn thùng rác các chi nhánh hotfix của bạn và phát hành các ngành khi bạn đã hoàn tất. Tất cả các bản phát hành của bạn nên được gắn thẻ và do đó có thể truy cập được.