Trước hết, như @AndrewFinnell và @KenLiu chỉ ra, trong SVN, tên thư mục không có nghĩa gì - "thân cây, nhánh và thẻ" chỉ đơn giản là một quy ước phổ biến được sử dụng bởi hầu hết các kho lưu trữ. Không phải tất cả các dự án đều sử dụng tất cả các thư mục (khá hợp lý khi không sử dụng "thẻ"), và trên thực tế, không có gì ngăn cản bạn gọi chúng bất cứ điều gì bạn muốn, mặc dù việc phá vỡ quy ước thường gây nhầm lẫn.
Tôi sẽ mô tả kịch bản sử dụng phổ biến nhất của các nhánh và thẻ và đưa ra một kịch bản ví dụ về cách chúng được sử dụng.
Trunk : Khu vực phát triển chính. Đây là nơi phát hành mã tiếp theo chính của bạn và thường có tất cả các tính năng mới nhất.
Chi nhánh : Mỗi khi bạn phát hành một phiên bản chính, nó sẽ tạo ra một chi nhánh. Điều này cho phép bạn thực hiện sửa lỗi và tạo một bản phát hành mới mà không phải phát hành các tính năng mới nhất - có thể chưa hoàn thành hoặc chưa được kiểm tra -.
Thẻ : Mỗi khi bạn phát hành một phiên bản (bản phát hành cuối cùng, phát hành ứng cử viên (RC) và betas), bạn tạo một thẻ cho phiên bản đó. Điều này cung cấp cho bạn một bản sao mã theo thời gian như ở trạng thái đó, cho phép bạn quay lại và tái tạo bất kỳ lỗi nào nếu cần trong phiên bản trước hoặc phát hành lại phiên bản quá khứ chính xác như cũ. Các nhánh và thẻ trong SVN rất nhẹ - trên máy chủ, nó không tạo một bản sao đầy đủ của các tệp, chỉ là một điểm đánh dấu "các tệp này đã được sao chép tại phiên bản này" chỉ chiếm một vài byte. Với suy nghĩ này, bạn không bao giờ nên quan tâm đến việc tạo thẻ cho bất kỳ mã được phát hành nào. Như tôi đã nói trước đó, các thẻ thường bị bỏ qua và thay vào đó, một thay đổi hoặc tài liệu khác làm rõ số sửa đổi khi phát hành được thực hiện.
Ví dụ: giả sử bạn bắt đầu một dự án mới. Bạn bắt đầu làm việc trong "thân cây", về những gì cuối cùng sẽ được phát hành dưới dạng phiên bản 1.0.
- trunk / - phiên bản phát triển, sắp có 1.0
- cành / - trống
Khi 1.0.0 kết thúc, bạn rẽ nhánh vào nhánh "1.0" mới và tạo thẻ "1.0.0". Bây giờ làm việc trên những gì cuối cùng sẽ là 1.1 tiếp tục trong thân cây.
- trunk / - phiên bản phát triển, sắp có 1.1
- chi nhánh / phiên bản 1.0 - 1.0.0
- tags / 1.0.0 - Phiên bản phát hành 1.0.0
Bạn gặp một số lỗi trong mã và sửa chúng trong thân cây, sau đó hợp nhất các bản sửa lỗi với nhánh 1.0. Bạn cũng có thể làm ngược lại và sửa các lỗi trong nhánh 1.0 và sau đó hợp nhất chúng trở lại trung kế, nhưng thông thường các dự án chỉ gắn với việc hợp nhất một chiều để giảm nguy cơ bỏ lỡ điều gì đó. Đôi khi một lỗi chỉ có thể được sửa trong 1.0 vì nó đã lỗi thời trong 1.1. Điều đó không thực sự quan trọng: bạn chỉ muốn đảm bảo rằng bạn không phát hành 1.1 với cùng một lỗi đã được sửa trong 1.0.
- trunk / - phiên bản phát triển, sắp có 1.1
- chi nhánh / 1.0 - phát hành 1.0.1 sắp tới
- tags / 1.0.0 - Phiên bản phát hành 1.0.0
Khi bạn tìm thấy đủ lỗi (hoặc có thể là một lỗi nghiêm trọng), bạn quyết định thực hiện bản phát hành 1.0.1. Vì vậy, bạn tạo một thẻ "1.0.1" từ nhánh 1.0 và giải phóng mã. Tại thời điểm này, thân cây sẽ chứa những gì sẽ là 1.1 và nhánh "1.0" chứa mã 1.0.1. Lần tiếp theo bạn phát hành bản cập nhật lên 1.0, nó sẽ là 1.0.2.
- trunk / - phiên bản phát triển, sắp có 1.1
- chi nhánh / 1.0 - phát hành 1.0.2 sắp tới
- tags / 1.0.0 - Phiên bản phát hành 1.0.0
- tags / 1.0.1 - phiên bản phát hành 1.0.1
Cuối cùng, bạn gần như đã sẵn sàng để phát hành 1.1, nhưng trước tiên bạn muốn thực hiện bản beta. Trong trường hợp này, bạn có thể thực hiện một nhánh "1.1" và thẻ "1.1beta1". Bây giờ, làm việc trên những gì sẽ là 1.2 (hoặc 2.0 có thể) tiếp tục trong thân cây, nhưng công việc trên 1.1 vẫn tiếp tục trong nhánh "1.1".
- trunk / - phiên bản phát triển, sắp có 1,2
- chi nhánh / 1.0 - phát hành 1.0.2 sắp tới
- chi nhánh / 1.1 - phát hành 1.1.0 sắp tới
- tags / 1.0.0 - Phiên bản phát hành 1.0.0
- tags / 1.0.1 - phiên bản phát hành 1.0.1
- thẻ / 1.1beta1 - 1.1 beta 1 phiên bản phát hành
Khi bạn phát hành 1.1 cuối cùng, bạn thực hiện thẻ "1.1" từ nhánh "1.1".
Bạn cũng có thể tiếp tục duy trì 1.0 nếu bạn muốn, chuyển các bản sửa lỗi giữa cả ba nhánh (1.0, 1.1 và thân cây). Điểm quan trọng là đối với mọi phiên bản chính của phần mềm bạn đang bảo trì, bạn có một nhánh chứa phiên bản mã mới nhất cho phiên bản đó.
Một cách sử dụng khác của các chi nhánh là cho các tính năng. Đây là nơi bạn phân nhánh thân cây (hoặc một trong các nhánh phát hành của bạn) và làm việc trên một tính năng mới trong sự cô lập. Khi tính năng được hoàn thành, bạn hợp nhất lại và xóa chi nhánh.
- trunk / - phiên bản phát triển, sắp có 1,2
- chi nhánh / 1.1 - phát hành 1.1.0 sắp tới
- cành / ui-viết lại - nhánh tính năng thử nghiệm
Ý tưởng của việc này là khi bạn đang làm việc gì đó gây rối (điều đó sẽ cản trở hoặc cản trở người khác thực hiện công việc của họ), một điều gì đó thử nghiệm (thậm chí có thể không thực hiện được), hoặc có thể chỉ là một việc gì đó mất nhiều thời gian (và bạn sợ nếu nó giữ bản phát hành 1.2 khi bạn sẵn sàng phân nhánh 1.2 từ thân cây), bạn có thể làm điều đó một cách tách biệt trong nhánh. Nói chung, bạn luôn cập nhật nó với thân cây bằng cách hợp nhất các thay đổi vào nó mọi lúc, điều này giúp bạn dễ dàng tích hợp lại (hợp nhất trở lại thân cây) khi bạn kết thúc.
Cũng lưu ý, sơ đồ phiên bản tôi sử dụng ở đây chỉ là một trong số rất nhiều. Một số nhóm sẽ thực hiện các bản phát hành sửa lỗi / bảo trì như 1.1, 1.2, v.v. và các thay đổi lớn là 1.x, 2.x, v.v ... Cách sử dụng ở đây là như nhau, nhưng bạn có thể đặt tên cho nhánh là "1" hoặc "1 .x "thay vì" 1.0 "hoặc" 1.0.x ". (Ngoài ra, phiên bản ngữ nghĩa là một hướng dẫn tốt về cách làm số phiên bản).