Làm thế nào để bạn đặt các phiên bản khác nhau của thư viện của bạn dưới sự kiểm soát phiên bản? Bạn có sử dụng thẻ? Hay chi nhánh? Hay phương pháp khác?


24

Gần đây tôi đã bắt đầu đặt mã của mình dưới sự kiểm soát phiên bản (trong phòng thí nghiệm tôi đang làm việc, dưới SVN và mã của riêng tôi trong github (rõ ràng là với git)). Trước khi sử dụng kiểm soát phiên bản, tôi đã từng làm một cái gì đó như thế này. Tôi đã có một thư mục với tên của thư viện, bên trong nhiều thư mục có số phiên bản. Mỗi lần tôi muốn bắt đầu làm việc với phiên bản mới hơn, tôi sẽ tạo một bản sao của phiên bản cuối cùng, đổi tên thành phiên bản mới và bắt đầu thực hiện.

Tuy nhiên, điều này có vẻ dư thừa khi thư mục được đặt dưới sự kiểm soát phiên bản. Ngoài sự dư thừa, nếu ai đó muốn có phiên bản mới nhất, họ sẽ tải xuống tất cả các phiên bản nếu anh ta chỉ imports / clones.

Bây giờ tôi thấy nhiều cách để làm điều này với kiểm soát phiên bản nhưng vì tôi chưa quen với nó, tôi không biết cái nào sẽ dễ bảo trì hơn.

Phương pháp 1: Sử dụng thẻ

Nếu tôi hiểu thẻ chính xác, bạn sẽ có chi nhánh chính của mình, bạn cam kết bất kỳ thay đổi nào bạn có và gắn thẻ chúng với một phiên bản. Sau đó, khi bạn muốn có một bản sao hoạt động của nó, bạn sẽ có được một bản sao với một thẻ nhất định. (sửa tôi nếu tôi sai)

Phương pháp 2: Phiên bản phân nhánh

Trong phương pháp này, nhánh chính sẽ là nhánh phát triển. Thỉnh thoảng một phiên bản ổn định được tạo ra (giả sử v1.2.0), bạn tạo một nhánh cho phiên bản đó và không bao giờ cam kết với nó. Bằng cách đó, nếu bạn muốn tải xuống một phiên bản nhất định, bạn sẽ nhận được mã từ chi nhánh đó. Mặc dù tôi đã nói rằng bạn không bao giờ cam kết với nó, nhưng có thể sửa lỗi và cam kết với chi nhánh của phiên bản cũ để duy trì phiên bản cũ. Ví dụ: nếu phiên bản hiện tại là v2.0, nhưng có những người muốn sử dụng v1.2, bạn có thể lấy một chi nhánh khác v1.2, cụ thể là v1.2.1và sửa lỗi, hoặc chỉ giữ phiên bản giống như v1.2và chỉ sửa lỗi.

Vì vậy, các chi nhánh sẽ trông như thế này:

                  v1.2.1  v1.2.2
                 /       /
 v1.0.0   v1.2.0---------     v2.0.0
/        /                   /
-------------------------------------- dev

Bằng cách này, bạn có chi nhánh cho mỗi bản cập nhật phiên bản nhỏ. (Lưu ý rằng trong biểu đồ trên, v1.2.1 và v1.2.2 hoặc được tạo sau khi v2.0.0 được phát hành, vì vậy chúng không phải là một phần của sự phát triển giữa v1.2.0 và v2.0.0. Hãy nghĩ về nó như là hỗ trợ cho các phiên bản cũ hơn)

Phương pháp 3: Phát triển chi nhánh

Phương pháp này ngược lại với trước đây. Chi nhánh chính sẽ là phiên bản ổn định mới nhất. Bất cứ khi nào bạn đang làm việc trên một phiên bản mới, bạn tạo một nhánh (để phát triển), làm việc với mã của bạn và khi nó ổn định, hãy hợp nhất nó với nhánh chính.

Trong trường hợp này, các nhánh sẽ trông như thế này:

 ________  ____  ________________  _____ dev
/        \/    \/                \/
---------------------------------- latest_version

Có lẽ điều này cần phải được thực hiện kết hợp với các thẻ phải không?

Câu hỏi!

Dù sao, câu hỏi của tôi là dựa trên kinh nghiệm của bạn, phương pháp nào trong số những phương pháp này chứng tỏ thực tế hơn? Có một phương pháp tốt nhất được biết đến ngoài đó (mà có lẽ tôi đã không tự mình tìm ra)? Làm thế nào là những điều thường được thực hiện?

Câu trả lời:


17

Thẻ và chi nhánh không tương hỗ, bạn có thể (và IMO thường nên) sử dụng cả hai. Thẻ ở đó để đánh dấu các mốc phát triển. Ví dụ như bạn mở một chi nhánh cho phiên bản 1.2 của sản phẩm của bạn, và bạn đánh dấu v1.2 Beta, RC1, RC2, Final(và sau đó, nếu cần thiết, SP1vv) với thẻ trên cùng chi nhánh.

Cá nhân tôi thích Phương pháp 2 là cách tiếp cận mặc định (mặc dù tôi cố gắng tránh nhiều cấp nhánh, để giữ cho cuộc sống đơn giản nhất có thể). Phương pháp 1 sẽ không hoạt động trong cuộc sống thực - thẻ không đủ, bạn cần các chi nhánh. Và phương pháp 3 không linh hoạt ở chỗ nó chỉ có một phiên bản ổn định duy nhất, vì vậy (trừ khi bạn kết hợp nó với Phương pháp 2), bạn không thể duy trì song song nhiều phiên bản (mới nhất và cũ hơn). Điều này là bắt buộc đối với hầu hết tất cả các dự án trong cuộc sống thực - trong khi bạn đang làm việc trên phiên bản 2, bạn vẫn có thể xuất bản các bản vá / nâng cấp cho v1.9 và thường là các phiên bản trước đó. Rất nhiều phụ thuộc vào loại ứng dụng của khóa học. Chúng tôi phát triển một ứng dụng web, do đó chỉ có một phiên bản sản xuất tại bất kỳ thời điểm cụ thể nào, chúng tôi vẫn thường tung hứng với 3 phiên bản khác nhau (một phiên bản đang sản xuất, một trong UAT đã sẵn sàng để triển khai, một là phiên bản mới nhất trên thân cây). Nó có thể trở nên phức tạp hơn đối với ứng dụng máy tính để bàn / máy khách với nhiều phiên bản cũ hơn được sử dụng - và được duy trì - song song.


Vâng, như tôi đã nói Phương pháp 3 có thể kết hợp với các thẻ, vì vậy bạn có các thẻ để cam kết ổn định. Tôi không chắc chắn, nếu tôi có thẻ đúng, nhưng bạn gắn thẻ một cam kết và sau đó bạn có thể lấy kho lưu trữ với cam kết có thẻ đó không? Nếu vậy, bạn có nhiều phiên bản ổn định, nhưng chúng ở cùng một nhánh (dưới các thẻ khác nhau)
Shahbaz

@Shahbaz, vâng, nhưng vấn đề là các phiên bản được gắn thẻ chỉ được đọc, bạn không thể thay đổi chúng. Điều này có nghĩa là bạn không thể sửa lỗi trong các phiên bản cũ hơn trong khi phát triển các tính năng mới trên thân cây.
Péter Török

Đừng quên, bạn chỉ có thể sử dụng thẻ và nếu bạn cần quay lại và sửa một cái gì đó cho phiên bản cũ, bạn có thể chuyển đổi thẻ đó thành một chi nhánh khi bạn cần.
Chloe

6

Tôi đã có một thư mục với tên của thư viện, bên trong nhiều thư mục có số phiên bản.

Đây là cách hiệu quả, như bạn lưu ý, một cách tiếp cận sai, vì bạn đã kiểm soát phiên bản để ... kiểm soát các phiên bản.

Bây giờ, các kỹ thuật khác nhau mà bạn liệt kê dường như đều đúng. Bạn có thể đọc một bài viết rất chi tiết, Kiểm soát nguồn được thực hiện đúng , bao gồm thông tin về thẻ và chi nhánh.


Có, phương pháp đầu tiên là những gì tôi đã từng làm trước khi nhận được mã của mình dưới sự kiểm soát phiên bản. Tôi sẽ đọc liên kết của bạn và cho bạn biết
Shahbaz

Các liên kết là tuyệt vời. Tôi có cảm giác rằng Phương pháp 2 tốt hơn (ít nhất là đối với tôi, về cơ bản là nhà phát triển duy nhất của các thư viện)
Shahbaz

3

Ba phương pháp này không loại trừ lẫn nhau và bạn nên kết hợp cả ba để tận dụng tối đa quyền kiểm soát phiên bản của mình.

Về phần tôi, tôi sẽ sử dụng kết hợp phương pháp 1 và 3 theo mặc định, nghĩa là phát triển trong một tính năng hoặc nhánh phát triển cho đến khi một tính năng sẵn sàng sản xuất và sau đó hợp nhất trở lại vào thân cây. Bằng cách này, thân cây luôn thể hiện trạng thái phát triển ổn định, được sử dụng hiện tại và có thể được liên kết một cách an toàn bởi svn: các dự án bên ngoài. Khi bạn phát hành một phiên bản, gắn thẻ nó.

Tôi chỉ muốn chi nhánh theo yêu cầu, có nghĩa là, khi phiên bản cũ của thư viện của bạn có một lỗi mà được cố định. Bạn có thể dễ dàng tạo nhánh đó từ thẻ của phiên bản bị hỏng. Bằng cách không phân nhánh một cách không cần thiết, bạn giữ số lượng nhánh thấp và có cái nhìn tổng quan nhanh về các cạnh chảy máu phải được duy trì (thân cây và tất cả các nhánh).


2

Tôi sẽ sử dụng Phương pháp 2 . Tôi đã sử dụng điều này và thấy nó là một cách hiệu quả để quản lý và duy trì nhiều phiên bản trong khi vẫn cho phép sự phát triển hiện tại tiến lên. Bạn cũng có thể sử dụng các thẻ kết hợp với phương pháp này nếu bạn cần chúng.

Xem câu trả lời của tôi ở đây để biết thêm thông tin về việc sử dụng phân nhánh để duy trì nhiều phiên bản phát hành.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.