Bạn có nên bận tâm với các chi nhánh SVN nếu bạn chỉ có một?

Nếu chúng ta chỉ làm việc với một nhánh trong Subversion, chúng ta có nên bận tâm không? Chúng ta không thể làm việc trên thân cây để tăng tốc mọi thứ sao?

Đây là cách chúng tôi phát triển với Subversion:

• Có một thân cây
• Chúng tôi tạo ra một nhánh phát triển mới
• Chúng tôi phát triển một tính năng mới trên chi nhánh đó
• Khi tính năng được thực hiện, nó được hợp nhất trong thân cây, nhánh bị loại bỏ và một nhánh phát triển mới được tạo từ thân cây

Khi chúng tôi muốn phát hành để sản xuất, chúng tôi tạo một thẻ từ thân cây. Sửa lỗi được thực hiện trên một nhánh từ thẻ đó. Lỗi này sau đó được hợp nhất trong thân cây.

Đây là lý do tại sao chúng tôi tạo một nhánh phát triển mới sau khi một tính năng được thực hiện. Bằng cách này, lỗi được bao gồm đủ sớm trong mã mới của chúng tôi.

Dưới đây là một sơ đồ cần làm rõ:

Bây giờ, có một cảm giác đây không phải là cách làm việc hiệu quả nhất. Chúng tôi xây dựng tại địa phương trước khi chúng tôi cam kết, mất khoảng 5-10 phút. Bạn có thể hiểu rằng đây là một thời gian chờ đợi khá lâu.

Ý tưởng của một nhánh phát triển là thân cây luôn sẵn sàng phát hành. Nhưng điều này không còn đúng trong tình huống của chúng ta nữa. Đôi khi, một tính năng gần như đã sẵn sàng và một số nhà phát triển sẽ bắt đầu mã hóa tính năng tiếp theo (nếu không, họ sẽ ngồi chờ đợi một hoặc hai nhà phát triển hoàn thành và hợp nhất).

Sau đó, khi tính năng 1 kết thúc, nó được hợp nhất vào thân cây, nhưng có một số cam kết của tính năng 2 đi kèm.

Vì vậy, chúng ta thậm chí có nên bận tâm với nhánh phát triển, vì chúng ta chỉ có một nhánh? Tôi đã đọc về sự phát triển dựa trên thân cây và sự trừu tượng hóa chi nhánh, nhưng hầu hết các bài viết tôi thấy tập trung vào phần trừu tượng hóa chi nhánh. Tôi có ấn tượng rằng những thay đổi lớn sẽ kéo dài qua một số bản phát hành. Đây không phải là vấn đề chúng ta gặp phải.

Bạn nghĩ sao? Chúng ta chỉ có thể làm việc trên thân cây? Trường hợp xấu nhất là (tôi nghĩ) rằng chúng ta sẽ phải tạo một thẻ từ thân cây và chọn những cam kết mà chúng ta cần, bởi vì một số cam kết / tính năng chưa sẵn sàng sản xuất.

IMHO làm việc trực tiếp trên thân cây là tốt nếu bạn có thể cam kết với số lượng nhỏ và bạn có tích hợp liên tục tại chỗ, do đó bạn có thể đảm bảo (ở mức độ hợp lý) rằng các cam kết của bạn không phá vỡ chức năng hiện có. Chúng tôi cũng làm điều đó trong dự án hiện tại của chúng tôi (thực tế tôi chưa từng làm việc trong bất kỳ dự án nào sử dụng các nhánh cụ thể theo nhiệm vụ theo mặc định).

Chúng tôi chỉ tạo một nhánh trước khi phát hành hoặc nếu một tính năng mất nhiều thời gian để thực hiện (nghĩa là kéo dài nhiều lần lặp / phát hành). Kích thước thô của một nhiệm vụ hầu như luôn có thể được ước tính đủ tốt để chúng ta biết trước liệu chúng ta có cần một nhánh riêng cho nó hay không. Chúng tôi cũng biết thời gian còn lại trước khi phát hành tiếp theo (chúng tôi xuất bản các bản phát hành khoảng 2 tháng một lần) để dễ dàng xem liệu một nhiệm vụ có phù hợp với thời gian có sẵn trước khi phát hành tiếp theo hay không. Nếu nghi ngờ, chúng tôi hoãn nó cho đến khi nhánh phát hành được tạo, thì bạn có thể bắt đầu làm việc với nó trên thân cây. Cho đến nay chúng tôi chỉ cần tạo một nhánh cụ thể theo nhiệm vụ một lần (trong khoảng 3 năm). Tất nhiên dự án của bạn có thể khác nhau.

Những gì bạn đang mô tả với sự phát triển tính năng của bạn là phát triển song song (phát triển đồng thời nhắm mục tiêu phát hành sản phẩm khác nhau) và nó đòi hỏi các chi nhánh phải xử lý nó đúng cách. Bạn có thể có một nhánh cho mỗi bản phát hành hoặc cho mỗi tính năng nếu bạn thường phải soạn lại các tính năng sẽ tạo một bản phát hành cụ thể.

Một cách khác để làm điều này, sẽ là làm việc ngoài thân cây theo mặc định nhưng tạo một nhánh nếu bạn mong muốn nhiệm vụ của mình kéo dài qua phiên bản tiếp theo. Bạn luôn luôn gắn thẻ phát hành của khóa học.

Cách tiếp cận nào bạn thực sự phụ thuộc vào mức độ quản lý bạn có thể làm trước. Nếu bản phát hành điển hình không thực sự có sự phát triển song song thì tôi sẽ thực hiện cách tiếp cận thứ hai.