Kiểm soát phiên bản trong các dự án phần mềm. Hoàn nguyên các thay đổi từ bản sửa đổi này và những thay đổi đó sẽ được hoàn tác

Ivan Nemytchenko, GitLab
Làm cho cuộc sống của bạn dễ dàng hơn với sự phát triển chung của các sản phẩm phần mềm.

Alexander Makarchuk, qb
Tối ưu hóa phát triển nhóm.

Petr Urvaev SimbirSoft
Trong quá trình phát triển, mã dự án đang tích cực thay đổi. Đồng thời, cần phải ghi lại những gì đã được thực hiện và phối hợp hành động của từng người tham gia để thay đổi mã đồng thời để những cải tiến của những người tham gia dự án có tính đến tất cả những thay đổi đã thực hiện trước đó của những người tham gia khác. . Hệ thống kiểm soát phiên bản cho phép bạn tự động hóa quá trình này.

2. Những yếu tố nào ảnh hưởng đến việc lựa chọn hệ thống kiểm soát phiên bản?

Nikolai Fetyukhin.MST
Hỗ trợ cho lõi hệ thống kiểm soát phiên bản và việc triển khai cụ thể của nó, sự làm quen của nhóm với nó. Thông thường, một hệ thống được sử dụng cho tất cả các dự án. Các trường hợp ngoại lệ có thể là, ví dụ, các yêu cầu của khách hàng.

Ivan Nemytchenko, GitLab
Sự phổ biến của một hệ thống cụ thể, từ đó mọi thứ khác theo sau: hỗ trợ trong các ứng dụng và dịch vụ, số lượng và chất lượng của tài liệu, sự hiện diện của một chuyên gia "trong tầm tay", v.v.

Alexander Makarchuk, qb
Trong trường hợp của chúng tôi, lựa chọn dựa trên mức độ phổ biến của hệ thống kiểm soát phiên bản và mức độ sở hữu của các nhà phát triển.

Petr Urvaev SimbirSoft
Trước hết - sự tuân thủ của các khả năng của hệ thống kiểm soát phiên bản với quy trình phát triển được thông qua trong nhóm. Thứ hai, hệ thống kiểm soát phiên bản nào quen thuộc hơn đối với những người tham gia dự án để làm việc.

3. Làm thế nào để triển khai việc sử dụng hệ thống kiểm soát phiên bản trong một nhóm?

Nikolai Fetyukhin.MST
Giờ đây, ngay cả những sinh viên hiện đại cũng đã tốt nghiệp với hiểu biết chung, đòi hỏi hệ thống kiểm soát phiên bản, vì vậy câu hỏi về việc triển khai không hoàn toàn chính xác. Thông thường, theo mặc định, tất cả các dự án bắt đầu bằng việc tạo một kho lưu trữ. Nếu trong trường hợp chung, sau đó bạn nên nói chuyện với nhóm, tìm hiểu lý do tại sao không có hệ thống kiểm soát phiên bản trong dự án (đôi khi có nhiều trường hợp cực kỳ cụ thể khác nhau) và nếu vấn đề có thể khắc phục được, thì hãy tổ chức một vài cuộc hội thảo trong nhóm về một vấn đề cụ thể hệ thống kiểm soát phiên bản (nếu được yêu cầu) và chạy.

Ivan Nemytchenko, GitLab
Hãy cho họ cơ hội làm việc mà không có hệ thống kiểm soát phiên bản để họ cảm thấy tất cả những khó khăn. Sau đó “gửi” cho họ một bảng gian lận Git, và bản thân họ sẽ học và thực hiện mọi thứ. Nhưng đây là cách bạn có thể làm việc với học sinh và sinh viên. Các nhà phát triển trưởng thành thường không có câu hỏi này.

Alexander Makarchuk, qb
Chậm mà chắc, mọi người đều tự mình đạt được điều này.

Petr Urvaev SimbirSoft
Hầu hết dự án hiện đại nhu cầu sử dụng một hệ thống kiểm soát phiên bản không đặt ra câu hỏi. Khi học cách làm việc với nó, chỉ cần thiết lập nó cho hoạt động thuận tiện và đọc một bài giảng ngắn về các tính năng chính của hệ thống kiểm soát phiên bản được sử dụng, với các ví dụ về cách sử dụng.

4. Điều gì đã làm cho Git trở thành tiêu chuẩn trong thế giới kiểm soát phiên bản? Liệu ai đó có thể loại bỏ anh ta khỏi vị trí dẫn đầu?

Nikolai Fetyukhin.MST
Git ban đầu chứa một số điều hữu ích, chẳng hạn như cam kết cục bộ và cũng quyết định một số lượng lớn vấn đề với việc hợp nhất các nhánh, vốn có nhiều trong bộ tạo xu hướng trước đó - Subversion (SVN). Ngay từ đầu, anh ấy đã chiến đấu vì sự nổi tiếng với Mercurial (Hg), đơn giản hơn ở một số khía cạnh, nhưng cuối cùng đã dẫn đầu.

Ivan Nemytchenko, GitLab
Nhờ vào Linus Torvaldsđã tấn công vấn đề phát triển phân tán từ phía bên phải, có tính đến những thiếu sót của các hệ thống tiền nhiệm. Chuyển chỗ? Để làm gì?

Alexander Makarchuk, qb
Cảm ơn thực tế là Git - đã làm rất tốt. Trong một thời gian rất dài, không ai có thể loại bỏ anh ta.

Petr Urvaev SimbirSoft
Ưu điểm chính của Git là phát triển các công cụ để làm việc với nó và khả năng lưu trữ kết quả công việc trên một số nhiệm vụ mở song song trong đó để các kết quả trung gian không ảnh hưởng lẫn nhau, đồng thời kết quả cuối cùng có thể được kết hợp khá dễ dàng thành một phiên bản cuối cùng của ứng dụng. GitHub cũng đóng một vai trò quan trọng trong sự phổ biến chung của Git trong thế giới CVS, lưu trữ hàng nghìn kho lưu trữ bằng nhiều ngôn ngữ khác nhau.

5. Các nhà phát triển không thích điều gì ở Git? Tại sao một số lại chọn các giải pháp khác ít phổ biến hơn?

Nikolai Fetyukhin.MST
Hạn chế duy nhất của Git mà chúng tôi lo ngại là một số vấn đề với theo dõi thay đổi: các nhánh có thể bị xóa và chỉ còn lại một cam kết hợp nhất. Điều này phần lớn là do các nhánh Git gắn liền với các cam kết. Git cũng có đường cong học tập dốc hơn so với Mercurial hoặc Subversion đã nói ở trên.

Alexander Makarchuk, qb
Trong khuôn khổ nhiệm vụ của mình, mọi người đều hài lòng.

Petr Urvaev SimbirSoft
Git đủ tiện lợi, nhưng yêu cầu học hỏi (đối với những người chưa biết nó) và tích cực chuyển đổi sang nó, vì vậy một số nhóm thích ở trên hệ thống kiểm soát phiên bản mà họ sử dụng. Ngoài ra, sự lựa chọn của hệ thống kiểm soát phiên bản có thể được xác định bởi các công cụ phát triển được sử dụng.

6. Việc sử dụng hệ thống kiểm soát phiên bản để quản lý các tệp khác ngoài mã phổ biến như thế nào?

Nikolai Fetyukhin.MST
Hiện đang có mặt khắp nơi. Như nhau hệ thống đám mây như Một ổ đĩa, Yandex.Disk, Dropbox và Google Drive cốt lõi chứa đựng một hệ tư tưởng lặp lại các hệ thống kiểm soát phiên bản.

Trong thực tế, việc sử dụng các hệ thống kiểm soát phiên bản thông thường để lưu trữ tài liệu là phổ biến, nhưng không phổ biến lắm, các vấn đề phức tạp nảy sinh khi tính toán các thay đổi, vì hầu hết các định dạng tài liệu phổ biến hiện nay là nhị phân và các tập thay đổi của chúng không thể đọc được.

Alexander Makarchuk, qb
Được sử dụng liên tục.

Petr Urvaev SimbirSoft
Hệ thống kiểm soát phiên bản chủ yếu nhằm mục đích làm việc với số lượng lớn các tệp nhỏ, được sử dụng chủ yếu trong quá trình phát triển. Theo quy tắc, việc sử dụng các hệ thống như vậy cho các tệp không phải định dạng văn bản (nhị phân), là không hiệu quả và trong một số trường hợp thậm chí là không thể. Do đó, để lưu trữ các tệp khác thường được sử dụng hệ thống chuyên biệt thích ứng để làm việc với các định dạng dữ liệu nhất định.

Bạn có một ý tưởng kinh doanh phát triển phần mềm mới tuyệt vời?Bạn cần phát triển công nghệ quyết định khó khăn? Hay bạn có một nhóm lớn các lập trình viên làm việc cùng một nhiệm vụ? Sau đó, hãy nhớ ba từ sau:hệ thống kiểm soát phiên bản .

Hệ thống điều khiển phiên bản (cvs), 2017 - So sánh: Git, SVN, Mercurial

, hoặc vcs- đây là điều giúp dự án không bị đổ bể khi có nhiều người cùng làm. Các lập trình viên, quản lý, copywriter đều có thể tự làm việc với nhau mà không ảnh hưởng đến nhau và không gây ra thiệt hại không thể sửa chữa được.

Nếu bạn không quen thuộc với khái niệmhệ thống kiểm soát phiên bản, sau đó ở đây mọi thứ đều được thể hiện rất rõ ràng.

Hoặc xem video từ GitHub.

Vậy hệ thống kiểm soát phiên bản nào phù hợp với dự án của bạn?

Chúng tôi đã so sánh một số giải pháp phổ biến để giúp bạn đưa ra lựa chọn của mình.

Đây là một chủ đề kỹ thuật mang tính chuyên môn cao. Chúng tôi đã cố gắng làm cho bài đánh giá của chúng tôi dễ hiểu đối với mọi người. Nhưng nếu bạn không có kinh nghiệm lập trình, hãy nhớ kiểm tra với bộ phận phát triển của bạn trước khi đưa ra bất kỳ quyết định nào.

Hệ thống kiểm soát phiên bản, bao gồm cả SVN (Subversion) và Git nổi tiếng, ban đầu được tạo ra để các nhóm phát triển có thể làm việc trên các dự án hợp tác mà không tạo ra sự nhầm lẫn. Trong hệ thống điều khiển, bạn không cần phải theo dõi độc lập các nhánh mã và nghiên cứu các ghi chú về chúng. Thay vào đó, một kho lưu trữ trung tâm được sử dụng, nơi mọi thứ được sắp xếp, có cấu trúc. Ở đây rất tiện lợi để cập nhật tệp, thêm nhận xét, và thậm chí hợp nhất các nhánh của dự án.

Ý kiến ​​về cái gìhệ thống kiểm soát phiên bảntốt nhất, thay đổi rất nhiều, và điều này dẫn đến cuộc tranh luận sôi nổi giữa các lập trình viên. Lựa chọn và nghiên cứuhệ thống kiểm soát phiên bảncho dự án của bạn, hãy nhớ rằng lợi ích của giải pháp này hay giải pháp khác thường mang tính chủ quan. Ví dụ: sở thích cá nhân của lập trình viên, hoặc giả sử, các chỉ số như hiệu suất, khả năng của plugin IDE, v.v.

Sự khác biệt chính giữa các hệ thống kiểm soát phiên bản là chúng là máy khách-máy chủ hay phi tập trung (p2p). Họ có một kho lưu trữ trung tâm (máy chủ) nơi mã được lấy từ và nơi nó được trả về với những thay đổi được thực hiện hay không. Hay đó là một bản sao trong bộ nhớ cục bộ, được cập nhật thông qua các mạng ngang hàng: mạng phi tập trung hơn được sử dụng để đồng bộ hóa, chia sẻ các bản vá (tập hợp các thay đổi) và duy trì mã hiện tại.

Nó cũng đáng xem xét tốc độ, chức năng và ngưỡng để nhập / làm chủ mộthệ thống điều khiển. Xem xét điểm chung nhấthệ thống kiểm soát phiên bảnvà lý do tại sao các lập trình viên thích các giải pháp nhất định.

Hệ thống phiên bản đồng thời (CVS)

CVS xuất hiện vào những năm 1980 và vẫn còn phổ biến với các nhà phát triển sản phẩm thương mại và các nhà phát triển mã nguồn mở.

CVS tuân theo các điều khoảnGiấy phép Công cộng GNU và cho phép bạn lấy từ máy chủ phiên bản mong muốn dự định - "trả phòng "(trích xuất) và sau đó chuyển tiếp trở lại máy chủ, "đăng ký "(quay lại),với những thay đổi được thực hiện.

CVS ban đầu được tạo ra để tránh xung đột phiên bản. Tất cả những người tham gia chỉ được cung cấp phiên bản mã mới nhất để làm việc. Đó là hệ thống điều khiển phiên bản đầu tiên. Người dùng cần nhanh chóng thực hiện các thay đổi đối với kho lưu trữ trước khi những người khác vượt lên trước anh ta.

Hiện tại CVS có hỗ trợ làm việc trong các dự án với các nhánh mã. Nó chỉ ra một số biến thể của sản phẩm với đặc điểm khác nhau có thể được hợp nhất sau này.

Máy chủ CVS thường làm việc dưới Kiểm soát Unix, nhưng CVS -Clients cũng có sẵn trên các hệ điều hành phổ biến khác. CVS - "trưởng thành", đã qua kiểm tra thời gianhệ thống kiểm soát phiên bản. Nó vẫn là một hệ thống mã nguồn mở, nhưng những tính năng mới hiếm khi được thêm vào những ngày này.

Đồng thời, CVSNT là một phiên bản được tách ra thành một dự án riêng biệt CVS vì Máy chủ Windows, - hiện đang tích cực mở rộng chức năng.

Thuận lợi:

• Công nghệ đã được kiểm chứng theo thời gian đã có mặt trên thị trường trong nhiều thập kỷ.

Nhược điểm:

• Việc đổi tên hoặc di chuyển tệp không được phản ánh trong lịch sử
• Rủi ro bảo mật liên quan đến các liên kết tượng trưng đến tệp
• Không hỗ trợ các hoạt động nguyên tử, có thể dẫn đến lỗi mã
• Hoạt động chi nhánh Mã chương trìnhđắt vì cái nàyhệ thống điều khiểnkhông dành cho các dự án dài hạn với các nhánh mã

Apache Subversion (SVN)

SVN được tạo ra như một sự thay thế CVS để sửa chữa những thiếu sót CVS đồng thời đảm bảo tính tương thích cao với nó.

Như CVS , SVN là một hệ thống miễn phí kiểm soát phiên bản mở mã nguồn. Với sự khác biệt duy nhất là nó được phân phối theo giấy phép Apache và không theomở thỏa thuận cấp phép GNU.

SVN sử dụng cái gọi là hoạt động nguyên tử để duy trì tính toàn vẹn của cơ sở dữ liệu. Khi nào phiên bản mới hoặc tất cả các bản sửa lỗi hoặc không bản sửa lỗi nào trong số chúng được áp dụng cho sản phẩm cuối cùng. Do đó, mã được bảo vệ khỏi những thay đổi từng phần hỗn loạn không nhất quán với nhau và gây ra lỗi.

Nhiều nhà phát triển đã chuyển sangSVN, bởi vì công nghệ mới thừa hưởng những cơ hội tốt nhất CVS đồng thời mở rộng chúng.

Trong khi ở trong CVS các hoạt động với các nhánh mã rất tốn kém và không được cung cấp bởi kiến ​​trúc hệ thống, SVN được tạo ra chỉ để làm việc này. Đó là, để biết thêm dự án chính với mã phân nhánh và nhiều hướng phát triển.

Các nhược điểm của SVN được đề cập tương đối tốc độ thấp và thiếu kiểm soát phiên bản phân tán. Được phân phối kiểm soát phiên bản sử dụng mô hình ngang hàng thay vì máy chủ tập trung để lưu trữ các bản cập nhật mã. Mặc dù mô hình ngang hàng hoạt động tốt nhất trong các dự án mã nguồn mở, nhưng nó không lý tưởng trong các trường hợp khác. Nhược điểm của phương pháp tiếp cận phía máy chủ là khi máy chủ gặp sự cố, các máy khách không có quyền truy cập vào mã.

Thuận lợi:

• dựa trên hệ thống CVS
• Cho phép các hoạt động nguyên tử
• Hoạt động phân nhánh mã ít tốn kém hơn
• Nhiều plugin IDE
• Không sử dụng mô hình ngang hàng

Nhược điểm:

• Lỗi vẫn còn liên quan đến đổi tên tệp và thư mục
• Bộ lệnh không đạt yêu cầu để làm việc với kho lưu trữ
• Tốc độ tương đối thấp

git

Hệ thống này được tạo ra để quản lý sự phát triển Hạt nhân Linux và sử dụng một cách tiếp cận khác về cơ bản với CVS và SVN.

Điều cơ bản git các khái niệm đã được đặt ra để tạo ra một phân phối nhanh hơnhệ thống kiểm soát phiên bản, trái ngược với các quy tắc và giải pháp được sử dụng trong CVS . Vì Git được phát triển chủ yếu cho Linux nên trên hệ điều hành này, nó hoạt động nhanh nhất.

Git cũng hoạt động trên các hệ thống giống Unix (như MacOS) và hoạt động trên Nền tảng Windows Gói mSysGit được sử dụng.

Mã chương trình có thể không khả dụng khi sử dụng máy tính không có kho lưu trữ. Có những cách giải quyết cho vấn đề này và một số nhà phát triển tin rằng tốc độ của Git là một cái giá hợp lý để trả cho sự bất tiện này.

Ngoài ra, Git có nhiều công cụ để điều hướng trong lịch sử thay đổi. Mỗi bản sao làm việc của mã nguồn chứa toàn bộ lịch sử phát triển, điều này cực kỳ hữu ích khi lập trình mà không cần kết nối Internet.

Thuận lợi:

• Hoàn hảo cho những ai ghét CVS / SVN
• Tăng hiệu suất đáng kể
• Hoạt động giá rẻ với các nhánh mã
• Lịch sử phát triển đầy đủ có sẵn ngoại tuyến
• Mô hình phân tán, ngang hàng

Nhược điểm:

• Ngưỡng đầu vào (học tập) cao đối với những người đã sử dụng SVN trước đây
• Giới hạn Hỗ trợ Windows(so với Linux)

Không kiên định

Không kiên định được phát hành cùng lúc với Git. Nó giống nhau phân phối hệ thống kiểm soát phiên bản.

Mercurial được tạo ra như một sự thay thế cho Git để phát triển các mô-đun nhân Linux. Nhưng kể từ khi Git được chọn, Mercurial ít được sử dụng hơn. Tuy nhiên, nhiều nhà phát triển hàng đầu làm việc với hệ thống này, chẳng hạnopenoffice.org .

Hệ thống điều khiển phiên bản của Mercurial kháchệ thống kiểm soát phiên bảnvì nó chủ yếu được viết bằng Python (không phải C). Tuy nhiên, một số phần được triển khai dưới dạng mô-đun mở rộng trong C.

Bởi vì hệ thống được phân cấp và được viết bằng Python, nhiều lập trình viên Python đang nghiêng về Mercurial.

Người dùng lưu ý rằng Mercurial vẫn giữ một số đặc điểm của SVN khi là một hệ thống phân tán, và vì sự tương đồng này, nó có rào cản gia nhập thấp hơn đối với những người đã quen thuộc với SVN. Ngoài ra, tài liệu cho Mercurial đầy đủ hơn, giúp bạn làm quen với sự khác biệt nhanh chóng hơn.

Một trong những nhược điểm lớn của Mercurial là, không giống như Git, nó không thể hợp nhất hai nhánh mẹ, vì Mercurial sử dụng hệ thống plugin hơn là hỗ trợ tập lệnh. Điều này rất tốt cho một số lập trình viên, nhưng nhiều người không muốn từ bỏ sức mạnh của Git.

Thuận lợi:

• So với Git, nó dễ học hơn
• Tài liệu chi tiết
• mô hình phân tánhệ thống kiểm soát phiên bản

Nhược điểm:

• Không có tùy chọn để hợp nhất hai nhánh mẹ
• Sử dụng plugin, không phải tập lệnh
• Ít cơ hội hơn cho các giải pháp không chuẩn

Cái màhệ thống điều khiển phiên bản phù hợp với tôi?

Trong hầu hết các trường hợp, các nhà phát triển sử dụng CVS bởi vì họ đã quen với nó. Nếu nhóm đã làm việc trên một dự án, thì triển vọng chuyển tất cả các phát triển sang một dự án kháchệ thống điều khiểnbằng cách nào đó không truyền cảm hứng. Nếu họ vẫn phải thay đổi hệ thống, thì rất có thể họ sẽ chuyển sang SVN.

CVS đã đạt đến trạng thái “công nghệ trưởng thành”, có nghĩa là nó sẽ không còn giới thiệu các tính năng và giải pháp mới triệt để nữa. Động lực của thói quen mất đi khi mọi người chuyển sang SVN. Vì vậy CVS đang dần trở thành dĩ vãng.

Hôm nay SVN nắm trong tay máy chủhệ thống kiểm soát phiên bản. Nó bao gồm những lợi ích CVS và vượt qua họ. Nếu chúng ta nói về sự phổ biến, thì bạn có khả năng gặp phải thường xuyên hơn CVS hoặc SVN hơn là với Git hoặc Mercurial. Vì vậy, biết một công nghệ máy chủ, mặc dù không cần thiết, sẽ giúp bạn chuyển đổi dễ dàng hơn.

Nhờ vào sử dụng rộng rãi và sự phát triển vượt bậc của công nghệ, SVN có một kho kiến ​​thức lớn, giúp người dùng dễ dàng nhận được trợ giúp.

Git rõ ràng là nhanh hơn so với các đối thủ cạnh tranh của nó. Đối với các dự án được tạo theo phân phốihệ thống kiểm soát phiên bản, đây là một cải tiến rõ ràng.

Một nhược điểm đáng kể của Git là đôi khi rất khó để giải thích các sắc thái của cách nàyhệ thống điều khiển, và điều này làm chậm quy trình làm việc trong khi các lập trình viên đã quen với nó. Tuy nhiên, ngay sau khi “ngưỡng đầu vào” được vượt qua, năng suất tăng lên và sự tiện lợi của việc quản lý các nhánh mã sẽ hoàn trả đầy đủ cho thời gian đã bỏ ra.

Đối với những người ghét Git (và nó có những lời gièm pha trong cộng đồng nhà phát triển), Mercurial là sự thỏa hiệp giữa SVN và Git. Hệ thống này được sử dụng trong nhiều dự án nổi tiếng và nó cũng có tài liệu tốt.

Tương thích với Phiên bản Windows Git cũng đang tiến tới tốc độ nhanh như phiên bản Linux, vì vậy hệ thống này có thể được sử dụng cho bạn ngay cả khi bạn không phát triển trên Linux.

Để hiểu cái nào phù hợp nhất với bạn, hãy xem xét các chi tiết cụ thể của dự án và nhóm của bạn. Nói chuyện với các nhà phát triển!

Nếu dự án của bạn yêu cầu một cây nguồn duy nhất mà một nhóm nhỏ các lập trình viên sẽ làm việc, thì SVN là lựa chọn của bạn. Nó đáng tin cậy và được thiết kế chỉ dành cho những trường hợp như vậy.

Nếu bạn đang chạy một dự án mã nguồn mở, trên đó thời điểm khác nhau một số lập trình viên sẽ làm việc hoặc, nếu nó được cho là cập nhật liên tục mã, chọn Git. Tốc độ và quản lý cây nguồn ở đây tốt hơn nhiều so với ở SVN.

Nếu bạn đang ở ngã ba đường hoặc không thích cách SVN hoặc Git hoạt động, thì Mercurial là dành cho bạn.

Tất cả các hệ thống này đều hoạt động đầy đủ. Và cũng miễn phí. Chúng được sử dụng để tạo phần mềm, các trang web và thậm chí cả hệ điều hành mà bạn sử dụng và biết.

Trước hết, hãy quyết định xem cái này hay cái kia phù hợphệ thống điều khiểnphiên bản dành cho doanh nghiệp của bạn, và sau đó - cũng quan trọng không kém - đảm bảo rằng lựa chọn này không làm các lập trình viên tức giận.

Bắt đầu với SVN

Nếu bạn chưa bao giờ làm việc với SVN hoặc Git và không biết cách bắt đầu, thìgiải pháp lưu trữ kết hợp với GUI giúp bạn bắt kịp tốc độ một cách nhanh chóng.

Như trong hầu hết các trường hợp, điều quan trọng nhất là bắt đầu làm việc, và rồi sự hiểu biết sẽ đến. Điều hành hệ thống kiểm soát phiên bản rất giống với việc làm việc với các tệp trên máy chủ bằng máy khách FTP.

GHI CHÚ:Có nhiều giải pháp lưu trữ chohệ thống kiểm soát phiên bản, bao gồm cả miễn phí giai đoạn thử nghiệm. Bạn có thể tạo kho lưu trữ đầu tiên của mình dựa trên chúng (một nơi dành cho làm việc với các tệp mã) hoàn toàn miễn phí. Dưới đây là một số dịch vụ sau:

Lưu trữ SVN & GIT

Tạo kho lưu trữ đầu tiên

Sau khi bạn đã tạo tài khoản, bạn cần tạo một kho lưu trữ - cho từng nền tảng riêng biệt. Nó thường trông như thế này:

• Đăng nhập vào tài khoản của bạn, nhấp vào các dự án của bạn.
• Tạo dự án:

• Trong dòng "Tạo dự án mới", hãy nhập tên dự án của bạn
• Nhấp vào nút "Tạo dự án"

• Kết nối SVN:

• Sau khi tạo dự án, hãy chọn tab "Kiểm soát Nguồn" (các phiên bản mã nguồn)
• Nhấp vào liên kết "Bật kiểm soát nguồn"
• Đặt tên cho kho lưu trữ
• Nhấp vào để lưu"

Ứng dụng khách đồ họa SVN và GIT

Vì vậy, kho lưu trữ được tạo ra. Bây giờ điều cần thiết là mọi thứ được hiển thị trong đó một cách đơn giản và rõ ràng. Để làm điều này, bạn sẽ cần một giao diện đồ họa.

— chương trình tiện dụng làm việc vớihệ thống kiểm soát phiên bảntrong Microsoft Windows và được cho là ứng dụng Apache Subversion tốt nhất từ ​​trước đến nay. TortoiseSVN được triển khai dưới dạng một phần mở rộng của Windows shell, giúp bạn dễ dàng tích hợp nó vào trình duyệt. Ngoài ra, nó là một chương trình mã nguồn mở có sẵn 34 gói ngôn ngữ.

SmartGit

- Ứng dụng khách đồ họa Git ( mã nguồn mở phân phốihệ thống kiểm soát phiên bản). Hoạt động trên Windows, Mac OS X và Linux.Chi phí giấy phép - $ 39

Kho "Checkout" ("Thủ tục thanh toán")

Vì vậy, khách hàng được chọn. Bây giờ bạn cần tạo một kho lưu trữ cho hệ thống điều khiển. Cần nhậpURL kho lưu trữ, tên người dùng và mật khẩu của bạn.

URL thường có dạng như sau:https: // svn .hostname.com / svn / > (bạn có thể sử dụng https: // (SSL) nếu bạn có tài khoản được thanh toán)

1. Đi đến thư mục gốc, nhấp vào nút "Check Out" và tạo một thư mục làm việc cho khách hàng. Bây giờ bạn có thể thêm tệp vào đó.
2. Sau khi giải nén các tệp dự án, bạn sẽ có thể chỉnh sửa chúng trong một thư mục cục bộ trên máy tính của mình.

Sau khi thực hiện các thay đổi đối với tệp, hãy nhấp vào nút "Đăng ký" trên thanh công cụ để lưu chúng. Bạn có thể xem các thay đổi và thêm nhận xét vào chúng - nó khá ý tưởng tốt, bởi vì trong tương lai, bạn sẽ biết chính xác những gì bạn đang làm, những thay đổi nào đã được thực hiện và sẽ thông báo cho những người tham gia dự án khác.

Khách hàng của bạn cũng phải có khả năng bắt đầu làm việc với các bản sửa đổi bất kỳ lúc nào bằng cách mở nhật ký sửa đổi hoặc lịch sử thay đổi - sau đó, nếu cần, bạn có thể "quay lại" phiên bản trước cho từng tệp riêng biệt. Bây giờ bạn đã quen với các khái niệm cơ bản, tài liệu

Hệ thống kiểm soát phiên bản ghi lại và lưu nhiều thay đổi vào tệp. Điều này cho phép bạn trở lại điểm nhất định lịch sử thay đổi của một tệp hoặc dự án. Một số hệ thống, chẳng hạn như Subversion, theo dõi lịch sử của các tệp riêng lẻ. Những người khác, như Git và Mercurial, theo dõi lịch sử của toàn bộ kho lưu trữ.

Phiên bản giống như một hệ thống bảo mật. Nếu bạn thực hiện các thay đổi sau đó gây ra sự cố, bạn có thể hoàn nguyên tệp hoặc toàn bộ dự án về một điểm cụ thể thay vì bắt đầu lại từ đầu.

Một trong những tùy chọn được sử dụng phổ biến nhất là lập phiên bản cục bộ. Vì vậy, hầu hết người dùng chỉ đơn giản là không chú ý đến nó, vì nó là một trong nhiều tính năng của ứng dụng.

Mọi ứng dụng đều có ít nhất một mức độ cơ bản của Kiểm soát địa phương phiên bản, bao gồm các chức năng "hoàn tác" và "làm lại". Một số chương trình như Microsoft Office và Google Tài liệu, chứa nhiều tính năng nâng cao hơn như so sánh phiên bản và nhận xét.

Hệ thống kiểm soát phiên bản ứng dụng bị giới hạn bởi loại tệp mà chúng hỗ trợ và số lượng lịch sử thay đổi mà chúng có thể lưu trữ. Đến lượt nó hệ thống tự trị kiểm soát phiên bản có thể tập trung vào nhiều hơn chức năng phức tạp, lưu trữ lịch sử phiên bản vô tận và không giới hạn ở các định dạng cụ thể. Mặc dù một số hệ thống phù hợp hơn với các tập tin cụ thể. Vì lý do này, chúng phổ biến hơn trong lập trình. Mặc dù chúng có thể được sử dụng để kiểm soát các phiên bản của bất kỳ tệp nào, từ cơ sở tài liệu văn bảnđến các tệp đồ họa lớn.

Hệ thống kiểm soát phiên bản được chia thành hai loại: phân tán và tập trung. Mỗi người trong số họ có những ưu điểm và nhược điểm riêng khiến chúng trở nên lý tưởng cho các quy trình làm việc khác nhau. Mỗi loại có nhiều các hệ thống khác nhau. Các hệ thống kiểm soát phiên bản phổ biến nhất là Git, Subversion và Mercurial. Hãy xem xét sự khác biệt chính giữa kiểm soát phiên bản phân tán và tập trung.

Phiên bản phân tán

Kiểm soát phiên bản phân tán còn được gọi là kiểm soát phiên bản phân tán. Nó được xây dựng trên nguyên tắc bình đẳng của các nút. Hơn nữa, mỗi đồng đẳng có bản sao kho lưu trữ của riêng mình. Với cách tiếp cận này, lịch sử của cơ sở mã được sao chép, do đó, bất kỳ thiệt hại nghiêm trọng nào đối với kho lưu trữ gốc phía máy chủ có thể được khôi phục hoàn toàn từ bất kỳ bản sao có sẵn nào. Tuy nhiên, trong quy trình làm việc tiêu chuẩn, các thay đổi đối với kho lưu trữ không dẫn đến đổi mới hoàn toàn kho. Thay vào đó, chỉ những thay đổi được thực hiện đối với các ứng dụng ngang hàng được hiển thị, cho phép bạn nhanh chóng thực hiện các thao tác mà không cần phải liên hệ với máy chủ.

Kiểm soát phiên bản phân tán được phổ biến nhờ các hệ thống như Git và Mercurial. Chúng được sử dụng rộng rãi để tổ chức cộng tác trong các dự án mã nguồn mở. Do bản chất của việc tùy chỉnh, việc sao chép toàn bộ cơ sở mã dự án cho mỗi người ngang hàng cho phép tự do hơn khi nói đến quy trình làm việc và cộng tác.

Phiên bản tập trung

Không giống như hệ thống kiểm soát phiên bản phân tán và kiểm soát phiên bản cục bộ, dữ liệu trong hệ thống kiểm soát phiên bản tập trung ( CVC), chẳng hạn như Perforce và Subversion, được lưu trữ trong các kho lưu trữ back-end. Điều này có nghĩa là mỗi nút sẽ kiểm tra các tệp và cam kết các thay đổi đối với cơ sở dữ liệu trung tâm.

Vấn đề là sự sẵn có của dữ liệu. Bởi vì các tệp được lưu trữ trong một cửa hàng trung tâm, nếu máy chủ bị treo, không thể thực hiện được công việc nào cho đến khi máy chủ được khởi động lại. Hơn nữa, nếu máy chủ bị hỏng, thì trong trường hợp không có bản cập nhật sao lưu tất cả dữ liệu có thể bị mất hoàn toàn.

Ưu điểm chính của các hệ thống như vậy là dữ liệu được lưu trữ ở một nơi. Điều này giúp đơn giản hóa việc bảo trì và hạn chế quyền truy cập của người dùng vào chúng.

Sự kết luận

Kiểm soát phiên bản là Một cách thuận tiện giám sát các thay đổi trong tệp và dự án. Mặc dù hệ thống kiểm soát phiên bản chủ yếu được tiếp thị như là công cụ để quản lý các dự án phát triển phần mềm, chúng có thể hữu ích để quản lý bất kỳ loại tệp nào.

Bản dịch của bài báo "Kiểm soát phiên bản là gì" bởi một nhóm dự án thân thiện.

Tốt xấu

Hệ thống kiểm soát phiên bản(từ tiếng Anh. Hệ thống Kiểm soát Phiên bản - VCS, hoặc Hệ thống Kiểm soát Bản sửa đổi) - phần mềm đặc biệt để làm việc với thông tin thường xuyên thay đổi, cho phép bạn lưu trữ nhiều phiên bản của cùng một tài liệu và nếu cần, hãy quay lại nhiều hơn phiên bản đầu tiên, xác định ai và khi nào thực hiện điều này hoặc thay đổi đó, và hơn thế nữa.

Các hệ thống như vậy được sử dụng rộng rãi nhất trong phát triển phần mềm để lưu trữ các tệp của chương trình đang được phát triển.

Nó thường xảy ra rằng một số người đang làm việc trên cùng một dự án cùng một lúc và nếu hai người thay đổi cùng một tệp, thì một trong số họ có thể vô tình hoàn tác các thay đổi do người kia thực hiện. Hệ thống kiểm soát phiên bản theo dõi các xung đột đó và đưa ra các công cụ để giải quyết chúng. Hầu hết các hệ thống này có thể tự động hợp nhất (merge) các thay đổi đã thực hiện các nhà phát triển khác nhau. Tuy nhiên, việc hợp nhất các thay đổi tự động như vậy thường chỉ có thể thực hiện được đối với các tệp văn bản và với điều kiện là các phần khác nhau (không chồng chéo) của tệp này đã được thay đổi. Hạn chế này là do hầu hết các hệ thống kiểm soát phiên bản đều tập trung vào việc hỗ trợ quá trình phát triển phần mềm và mã nguồn của các chương trình được lưu trữ trong tập tin văn bản. Nếu quá trình hợp nhất tự động không thành công, hệ thống có thể đề xuất giải quyết vấn đề theo cách thủ công.

Một số hệ thống kiểm soát phiên bản cung cấp cho bạn tùy chọn khóa tệp trong vault. Chặn ngăn người dùng khác truy cập bản sao làm việc hoặc ngăn không cho sửa đổi bản sao đang hoạt động của tệp (ví dụ: bằng cách hệ thống tập tin) và do đó chỉ cung cấp quyền truy cập độc quyền cho người dùng làm việc với tài liệu.

Hầu hết các hệ thống kiểm soát phiên bản đều cung cấp các tính năng sau:

• cho phép bạn tạo các biến thể khác nhau một tài liệu (nhánh) có lịch sử thay đổi chung trước điểm nhánh và các tài liệu khác sau nó;
• giúp bạn có thể tìm ra ai và khi nào đã thêm hoặc thay đổi một tập hợp các dòng cụ thể trong một tệp;
• giữ một bảng thay đổi trong đó người dùng có thể viết giải thích về những gì và lý do họ thay đổi trong phiên bản này;
• kiểm soát quyền truy cập của người dùng, cho phép hoặc từ chối đọc hoặc sửa đổi dữ liệu, tùy thuộc vào người đang yêu cầu hành động này.

Mỗi phiên bản hệ thống điều khiển có các tính năng cụ thể trong tập lệnh, hành vi người dùng và quản trị. Tuy nhiên, cách làm việc chung của hầu hết các VCS đều hoàn toàn rập khuôn. Ở đây, giả định rằng dự án, bất kể nó có thể là gì, đã tồn tại và kho lưu trữ của nó được lưu trữ trên máy chủ mà nhà phát triển có quyền truy cập.

Bắt đầu với hệ thống. Hành động đầu tiên mà nhà phát triển phải thực hiện là kiểm tra bản sao đang hoạt động của dự án hoặc phần dự án sẽ được làm việc. Hành động này được thực hiện với lệnh thanh toán tiêu chuẩn (thanh toán hoặc sao chép) hoặc với đội đặc biệt, mà thực sự thực hiện cùng một hành động. Nhà phát triển chỉ định phiên bản sẽ được sao chép, theo mặc định, phiên bản mới nhất (hoặc lựa chọn của quản trị viên làm phiên bản chính) thường được sao chép.

chu kỳ làm việc hàng ngày. Chu kỳ làm việc điển hình của nhà phát triển trong ngày làm việc như sau:

• cập nhật bản sao làm việc: khi các thay đổi được thực hiện đối với phiên bản chính của dự án, bản sao làm việc trên máy tính của nhà phát triển sẽ cũ đi và sự khác biệt giữa nó và phiên bản chính của dự án tăng lên, điều này làm tăng nguy cơ xảy ra các thay đổi xung đột (xem bên dưới) và nó sẽ trở thành cần thiết để duy trì bản sao hoạt động ở trạng thái càng gần với các phiên bản chính hiện tại càng tốt, do đó nhà phát triển thực hiện thao tác cập nhật thường xuyên nhất có thể, được xác định bởi tần suất thay đổi, tùy thuộc vào hoạt động phát triển, số lượng nhà phát triển , và cả về thời gian dành cho mỗi bản cập nhật;
• sửa đổi dự án: nhà phát triển sửa đổi dự án, thay đổi các tệp có trong đó trong bản sao làm việc phù hợp với nhiệm vụ của dự án, công việc này được thực hiện cục bộ và không yêu cầu các cuộc gọi đến máy chủ VCS;
• cam kết thay đổi: sau khi hoàn thành giai đoạn công việc tiếp theo của nhiệm vụ, nhà phát triển cam kết (cam kết) các thay đổi của mình, chuyển chúng đến máy chủ (hoặc đến nhánh chính, nếu công việc của nhiệm vụ được hoàn thành hoàn toàn hoặc đến một nhánh phát triển riêng biệt của nhiệm vụ này ).

Khái niệm cơ bản về VCS

Giới thiệu

Trước khi nói về bất kỳ hệ thống kiểm soát phiên bản cụ thể nào, bạn cần hiểu nó là gì, chúng là gì và tại sao chúng lại xuất hiện. Bài giảng này nhằm mục đích giới thiệu về hệ thống kiểm soát phiên bản và kiểm soát phiên bản, và trước tiên tôi sẽ nói về nguồn gốc của các công cụ kiểm soát phiên bản, những hệ thống kiểm soát phiên bản nào đang phổ biến hiện nay và những điểm khác biệt chính của chúng.

Giới thiệu về kiểm soát phiên bản

Kiểm soát phiên bản là gì và tại sao bạn cần nó?

Có lẽ nên bắt đầu bằng định nghĩa về hệ thống kiểm soát phiên bản (VCS) - một hệ thống đăng ký các thay đổi trong một hoặc nhiều tệp để trong tương lai có thể quay lại một số phiên bản cũ của các tệp này.

TẠI thời gian gần đây tệp là kết quả cuối cùng cho nhiều nghề (ví dụ: viết, công việc khoa học và, tất nhiên, phát triển phần mềm). Rất nhiều thời gian và công sức được dành để phát triển và duy trì các tệp này, và không ai muốn dành nhiều thời gian và nỗ lực hơn nữa để khôi phục dữ liệu bị mất do bất kỳ thay đổi nào.

Hãy tưởng tượng rằng một lập trình viên đang phát triển một dự án bao gồm một tệp nhỏ (nhân tiện, ví dụ này khá thực tế, không phải tổng hợp, chúng ta đã gặp trong đời thực). Sau khi phát hành phiên bản đầu tiên của dự án, nó phải đối mặt với một sự lựa chọn khó khăn: cần phải khắc phục các sự cố được báo cáo bởi người dùng của phiên bản đầu tiên và đồng thời, phát triển một cái gì đó mới cho phiên bản thứ hai. Ngay cả khi bạn chỉ muốn khắc phục các vấn đề phát sinh, thì rất có thể sau bất kỳ thay đổi nào, dự án sẽ ngừng hoạt động và bạn cần xác định những gì đã được thay đổi để dễ dàng tách vấn đề hơn. Bạn cũng nên giữ một số loại nhật ký thay đổi và sửa chữa, để không thực hiện cùng một công việc nhiều lần.

Trong trường hợp đơn giản nhất, vấn đề trên có thể được giải quyết bằng cách giữ một số bản sao của tệp, ví dụ: một bản để sửa lỗi trong phiên bản đầu tiên của dự án và bản thứ hai cho các thay đổi mới. Vì các thay đổi thường không lớn lắm so với kích thước của tệp, nên chỉ có thể lưu trữ các dòng đã thay đổi bằng cách sử dụng tiện ích khác và hợp nhất chúng sau với tiện ích vá. Nhưng điều gì sẽ xảy ra nếu dự án bao gồm vài nghìn tệp và hàng trăm người làm việc trên đó? Nếu trong trường hợp này, chúng tôi sử dụng phương pháp có bộ nhớ bản sao riêng lẻ các tệp (hoặc thậm chí chỉ là những thay đổi) thì dự án sẽ bị đình trệ rất nhanh. Trong các bài giảng tiếp theo, tôi sẽ sử dụng mã nguồn của các chương trình để làm ví dụ, nhưng trên thực tế, hầu hết mọi loại tệp đều có thể được đặt dưới sự kiểm soát của phiên bản.

Nếu bạn là một nhà thiết kế đồ họa hoặc web và muốn lưu trữ mọi phiên bản của hình ảnh hoặc bố cục - mà bạn có thể muốn - thì sử dụng hệ thống kiểm soát phiên bản sẽ là một quyết định rất khôn ngoan. SLE giúp bạn có thể quay trở lại các tập tin riêng lẻđến quan tâm, trở lại trạng thái trước đó toàn bộ dự án, xem các thay đổi theo thời gian, xác định ai đã thực hiện thay đổi lần cuối đối với một mô-đun đột ngột ngừng hoạt động, ai và khi đưa một số loại lỗi vào mã, và hơn thế nữa. Nói chung, nếu sử dụng VCS, bạn làm hỏng mọi thứ hoặc mất tệp, mọi thứ có thể được khôi phục dễ dàng. Ngoài ra, chi phí chung cho mọi thứ bạn nhận được sẽ rất nhỏ.

Hệ thống kiểm soát phiên bản địa phương

Như đã đề cập trước đó - một ví dụ về VCS cục bộ cực kỳ đơn giản: nhiều người thích kiểm soát các phiên bản bằng cách sao chép tệp vào thư mục khác (thường thêm ngày hiện tại vào tên của thư mục). Cách làm này rất phổ biến vì nó đơn giản, nhưng nó cũng thường xuyên thất bại hơn. Bạn rất dễ quên rằng mình đang ở sai thư mục và vô tình thay đổi tệp sai hoặc sao chép tệp vào sai vị trí và ghi đè lên các tệp phù hợp. Để giải quyết vấn đề này, các lập trình viên từ lâu đã phát triển VCS cục bộ với một cơ sở dữ liệu đơn giản lưu trữ tất cả các thay đổi đối với các tệp mong muốn.

Một trong những VCS phổ biến nhất của loại này là RCS (Revision Control System, Revision Control System), vẫn được cài đặt trên nhiều máy tính. Ngay cả trong một phòng mổ hiện đại Hệ thống Mac Tiện ích OS X rcs được cài đặt với Công cụ dành cho nhà phát triển. RCS được phát triển vào đầu những năm 1980 bởi Walter F. Tichy. Hệ thống cho phép bạn lưu trữ các phiên bản của một tệp duy nhất, vì vậy bạn phải quản lý nhiều tệp theo cách thủ công. Đối với mỗi tệp dưới sự kiểm soát của hệ thống, thông tin phiên bản được lưu trữ trong tập tin đặc biệt với tên của tệp gốc mà các ký tự ", v" được thêm vào cuối. Ví dụ: đối với tệp tin file.txt, các phiên bản sẽ được lưu trữ trong tệp tin file.txt, v. Tiện ích này dựa trên việc làm việc với các tập hợp bản vá giữa các cặp phiên bản (bản vá là một tệp mô tả sự khác biệt giữa các tệp). Điều này cho phép bạn tạo lại bất kỳ tệp nào tại bất kỳ thời điểm nào, áp dụng các bản vá theo trình tự. Hệ thống sử dụng tiện ích khác biệt để lưu trữ các phiên bản. Mặc dù RCS tuân thủ Yêu cầu tối thiểuđối với hệ thống kiểm soát phiên bản, nó có những nhược điểm chính sau đây, điều này cũng được coi là động cơ để tạo ra hệ thống sau đây đang được xem xét:

• Chỉ làm việc với một tệp, mỗi tệp phải được kiểm soát riêng biệt;
• Một cơ chế bất tiện cho công việc đồng thời của một số người dùng với hệ thống, bộ nhớ chỉ bị chặn cho đến khi người dùng đã chặn nó mở khóa nó;
• Không ai giải phóng bạn khỏi các bản sao lưu, bạn có nguy cơ mất tất cả.

Hệ thống kiểm soát phiên bản tập trung

Vấn đề lớn tiếp theo là nhu cầu cộng tác với các nhà phát triển trên các máy tính khác. Để giải quyết nó, hệ thống kiểm soát phiên bản tập trung (TSKV) đã được tạo ra. Các hệ thống như vậy, chẳng hạn như CVS, Subversion và Perforce, có một máy chủ trung tâm lưu trữ tất cả các tệp được tạo phiên bản và một số máy khách nhận bản sao của tệp từ đó. Trong nhiều năm, đây là tiêu chuẩn cho các hệ thống điều khiển phiên bản.

Cách tiếp cận này có nhiều ưu điểm, đặc biệt là so với SLE cục bộ. Ví dụ, mọi người đều biết ai làm gì trong dự án. Quản trị viên có quyền kiểm soát rõ ràng ai có thể làm những gì và tất nhiên, việc quản lý CCCS dễ dàng hơn nhiều so với căn cứ địa phương trên mỗi khách hàng. Tuy nhiên, có một số hạn chế nghiêm trọng đối với cách tiếp cận này. Dễ thấy nhất là máy chủ tập trung chính là điểm yếu của cả hệ thống. Nếu máy chủ gặp sự cố trong một giờ, thì trong một giờ, các nhà phát triển không thể tương tác và không ai có thể lưu phiên bản mới của công việc của họ. Nếu đĩa có cơ sở dữ liệu trung tâm bị hỏng và không có bản sao lưu, bạn sẽ mất hoàn toàn mọi thứ - toàn bộ lịch sử của dự án, có lẽ ngoại trừ một vài phiên bản đang hoạt động đã được lưu trên máy làm việc của người dùng.

CVS

CVS (Hệ thống các phiên bản đồng thời) vẫn là hệ thống được sử dụng rộng rãi nhất, nhưng đang nhanh chóng mất đi tính phổ biến do những thiếu sót, mà tôi sẽ thảo luận dưới đây. Dick Grune đã phát triển CVS vào giữa những năm 1980. Để lưu trữ các tệp riêng lẻ, CVS (giống như RCS) sử dụng các tệp ở định dạng RCS, nhưng cho phép bạn quản lý các nhóm tệp nằm trong thư mục. CVS cũng sử dụng kiến ​​trúc máy khách-máy chủ, trong đó tất cả thông tin phiên bản được lưu trữ trên máy chủ. Việc sử dụng kiến ​​trúc máy khách-máy chủ cho phép CVS được sử dụng ngay cả bởi các nhóm người dùng được phân bổ theo địa lý, trong đó mỗi người dùng có thư mục làm việc của riêng mình với bản sao của dự án. Như tên cho thấy, người dùng có thể chia sẻ hệ thống.

Các xung đột có thể xảy ra khi thay đổi cùng một tệp được giải quyết do hệ thống chỉ cho phép bạn thực hiện các thay đổi đối với phiên bản mới nhất tập tin. Do đó, bạn nên cập nhật bản sao làm việc của tệp trước khi thực hiện các thay đổi trong trường hợp có thể xảy ra các thay đổi xung đột. Khi cập nhật, hệ thống sẽ tự động thực hiện các thay đổi đối với bản sao đang làm việc và chỉ trong trường hợp có các thay đổi xung đột ở một trong các vị trí trong tệp được yêu cầu sửa chữa thủ công những nơi xung đột.

CVS cũng cho phép bạn duy trì nhiều dòng phát triển cho một dự án bằng cách sử dụng các nhánh phát triển. Vì vậy, như đã đề cập ở trên, có thể sửa lỗi trong phiên bản đầu tiên của dự án và phát triển chức năng mới song song.

CVS đã được sử dụng bởi một số lượng lớn các dự án, nhưng chắc chắn không phải là không có những thiếu sót của nó mà sau này dẫn đến hệ thống tiếp theo đang được xem xét. Xem xét những nhược điểm chính:

• Vì các phiên bản được lưu trữ trong các tệp RCS, không có cách nào để lưu các phiên bản thư mục. Cách tiêu chuẩnđể vượt qua trở ngại này là lưu một số tệp (ví dụ: README.txt) trong một thư mục;
• Việc di chuyển hoặc đổi tên tệp không phụ thuộc vào sự kiểm soát của phiên bản. Cách tiêu chuẩn để thực hiện việc này là trước tiên sao chép tệp, xóa tệp cũ bằng lệnh cvs remove, sau đó thêm tệp với tên mới bằng lệnh cvs add;

lật đổ

Subversion (SVN) được phát triển vào năm 2000 bởi CollabNet. SVN ban đầu được thiết kế để trở thành "CVS tốt nhất" và mục tiêu chính của các nhà phát triển là sửa chữa những lỗi mắc phải trong quá trình thiết kế CVS trong khi vẫn duy trì một giao diện tương tự. SVN, giống như CVS, sử dụng kiến ​​trúc máy khách-máy chủ. Trong số những thay đổi đáng kể nhất so với CVS là:

• Sửa đổi nguyên tử (cam kết). Nếu cam kết bị hủy bỏ, sẽ không có thay đổi nào được thực hiện.
• Đổi tên, sao chép và di chuyển tệp sẽ lưu toàn bộ lịch sử thay đổi.
• thư mục, liên kết tượng trưng và siêu dữ liệu phải chịu sự kiểm soát của phiên bản.
• Lưu trữ thay đổi hiệu quả cho các tệp nhị phân.

Hệ thống kiểm soát phiên bản phân tán

Và trong tình huống này, hệ thống kiểm soát phiên bản phân tán (RSV) phát huy tác dụng. Trong các hệ thống như Git, Mercurial, Bazaar hoặc Darcs, khách hàng không chỉ kiểm tra các phiên bản mới nhất của tệp mà còn sao chép toàn bộ kho lưu trữ. Do đó, trong trường hợp máy chủ mà qua đó công việc sẽ "chết", bất kỳ kho lưu trữ khách hàng nào cũng có thể được sao chép trở lại máy chủ để khôi phục cơ sở dữ liệu. Mỗi khi khách hàng kiểm tra một phiên bản tệp mới, nó sẽ tạo ra một bản đầy đủ tất cả dữ liệu.

Ngoài ra, trong hầu hết các hệ thống này, có thể làm việc với một số kho lưu trữ từ xa, do đó, có thể làm việc đồng thời với các các nhóm khác nhau những người trong cùng một dự án. Vì vậy, trong một dự án, bạn có thể tiến hành đồng thời nhiều loại quy trình công việc, điều này là không thể trong các hệ thống tập trung.

Tại sao cần có hệ thống phân tán?

Như tên của nó, một trong những ý tưởng chính của các hệ thống phân tán là sự thiếu vắng của một kho lưu trữ trung tâm được xác định rõ ràng về các phiên bản - một kho lưu trữ. Trong trường hợp hệ thống phân tán, một tập hợp các phiên bản có thể được phân phối hoàn toàn hoặc một phần giữa các kho lưu trữ khác nhau, bao gồm cả các kho lưu trữ ở xa. Một mô hình như vậy rất phù hợp với công việc của các nhóm phân tán, ví dụ, một nhóm các nhà phát triển phân tán làm việc trên cùng một dự án mã nguồn mở trên khắp thế giới. Nhà phát triển của một nhóm như vậy có thể tải xuống tất cả thông tin phiên bản cho chính mình và sau đó chỉ hoạt động trên máy cục bộ. Ngay sau khi đạt được kết quả của một trong các giai đoạn công việc, các thay đổi có thể được tải lên một trong các kho lưu trữ trung tâm hoặc xuất bản để xem trên trang web của nhà phát triển hoặc trong danh sách gửi thư. Đến lượt mình, các thành viên khác của dự án sẽ có thể cập nhật bản sao của kho phiên bản với các thay đổi mới hoặc thử các thay đổi đã xuất bản trên một nhánh phát triển thử nghiệm, riêng biệt. Thật không may, nếu không có một tổ chức dự án tốt, việc thiếu một kho lưu trữ trung tâm có thể là một bất lợi của các hệ thống phân tán. Nếu trong trường hợp hệ thống tập trung luôn có một kho lưu trữ chung mà từ đó bạn có thể tải phiên bản mới nhất của dự án, thì trong trường hợp hệ thống phân tán, bạn cần phải quyết định về mặt tổ chức xem nhánh dự án nào sẽ là nhánh chính. Tại sao một hệ thống kiểm soát phiên bản phân tán lại được quan tâm đối với những người đã sử dụng hệ thống kiểm soát phiên bản tập trung - chẳng hạn như Subversion? Bất kỳ công việc nào cũng liên quan đến việc đưa ra quyết định và trong hầu hết các trường hợp, cần phải thử các lựa chọn khác nhau: khi làm việc với hệ thống kiểm soát phiên bản cần xem xét Các tùy chọn khác nhau và làm việc với những thay đổi lớn đóng vai trò là các nhánh phát triển. Và trong khi nó là một khái niệm đủ tự nhiên, nó không dễ sử dụng trong Subversion. Hơn nữa, mọi thứ trở nên phức tạp hơn trong trường hợp nhiều hợp nhất liên tiếp từ chi nhánh này sang chi nhánh khác - trong trường hợp này, bạn cần chỉ ra chính xác phiên bản ban đầu và cuối cùng của mỗi thay đổi để tránh xung đột và lỗi. Đối với hệ thống kiểm soát phiên bản phân tán, các nhánh phát triển là một trong những khái niệm cơ bản - trong hầu hết các trường hợp, mỗi bản sao lưu trữ phiên bản là một nhánh phát triển. Do đó, cơ chế hợp nhất các thay đổi từ nhánh này sang nhánh khác trong trường hợp hệ thống phân tán là một trong những cơ chế chính, cho phép người dùng ít nỗ lực hơn khi sử dụng hệ thống.

Mô tả tóm tắt về các mẫu SUV được phân phối phổ biến

• Git là một hệ thống điều khiển phiên bản phân tán được phát triển bởi Linus Torvalds. Ban đầu, Git được dự định sử dụng trong quá trình phát triển nhân Linux, nhưng sau đó nó được sử dụng trong nhiều dự án khác, chẳng hạn như X.org và Ruby on Rails, Drupal. Trên khoảnh khắc này Git là hệ thống phân tán nhanh nhất, sử dụng kho lưu trữ các phiên bản nhỏ gọn nhất. Nhưng đồng thời, đối với người dùng di chuyển từ Subversion, chẳng hạn, giao diện Git có vẻ phức tạp;
• Mercurial là một hệ thống phân tán được viết bằng Ngôn ngữ Python với một số phần mở rộng C. Các dự án sử dụng Mercurial bao gồm Mozilla và MoinMoin.
• Bazaar - một hệ thống do Canonical phát triển - được biết đến với Phân phối Ubuntu và trang web https://launchpad.net/. Hệ thống chủ yếu được viết bằng Python và được sử dụng bởi các dự án như MySQL.
• Codeville là một hệ thống phân tán được viết bằng Python sử dụng thuật toán hợp nhất sáng tạo. Ví dụ, hệ thống được sử dụng trong quá trình phát triển khách hàng ban đầu bittorrent.
• Darcs là một hệ thống kiểm soát phiên bản phân tán được viết bằng Haskell được sử dụng bởi dự án Buildbot chẳng hạn.
• Monotone là một hệ thống được viết bằng C ++ và sử dụng SQLite làm kho sửa đổi.