Các nguyên tắc của hệ thống kiểm soát phiên bản. Tất cả công việc trong Git diễn ra bên trong kho chứa tất cả các tệp công việc.

Gửi công việc tốt của bạn trong cơ sở kiến ​​thức là đơn giản. Sử dụng biểu mẫu bên dưới

Các sinh viên, nghiên cứu sinh, các nhà khoa học trẻ sử dụng nền tảng tri thức trong học tập và làm việc sẽ rất biết ơn các bạn.

đăng lên http://www.allbest.ru/

Bộ Giáo dục và Khoa học Liên bang Nga

Giáo dục Ngân sách Nhà nước Liên bang

Cơ sở giáo dục chuyên nghiệp cao hơn

"TOMSK STATE UNIVERSITY

HỆ THỐNG ĐIỀU KHIỂN VÀ ĐIỆN TỬ TRUYỀN THANH "(TUSUR)

Khoa Hệ thống Kỹ thuật Vô tuyến (RTS)

Khóa học làm việc

về khóa học "Công nghệ thông tin"

HỆ THỐNG KIỂM SOÁT PHIÊN BẢN

Học sinh gr. 121-3 Korolev D.O.,

Kuleshov M.V., Sadov D.A., Taimasov S.S.

Người đứng đầu Nozdrevatykh B.F

Bài tập 46, 31 hình, 2 bảng, nguồn.

HỆ THỐNG ĐIỀU KHIỂN PHIÊN BẢN, GIT, SVN, MERCURIAL.

Khóa học này thảo luận về các hệ thống kiểm soát phiên bản phổ biến nhất.

Mục đích của công việc là làm quen với các hệ thống điều khiển phiên bản, hiểu được công việc, cách cài đặt và cấu hình của chúng.

Trong quá trình làm việc, ba loại hệ thống kiểm soát phiên bản đã được cài đặt với cấu hình và thử nghiệm của chúng.

Kết quả là ba hệ thống điều khiển phiên bản hoàn toàn sẵn sàng sử dụng, các bảng so sánh chức năng của các hệ thống này được biên dịch và một từ điển thuật ngữ được sử dụng khi làm việc với các chương trình.

Bài tập của khóa học được thực hiện trong trình soạn thảo văn bản Microsoft Word 2010 và được trình bày dưới dạng bản in và điện tử.

giao diện hệ thống kiểm soát phiên bản

Giới thiệu

3.1 Bắt đầu với một dự án

3.2 Chu kỳ làm việc hàng ngày

3.3 Chi nhánh

3.4 Hợp nhất các phiên bản

3.5 Xung đột và cách giải quyết

3.6 Ổ khóa

3.7 Phiên bản dự án, thẻ

4.1 Hệ thống kiểm soát phiên bản cục bộ

4.2 Mô hình tập trung

5.1.1 Yêu cầu hệ thống

5.1.2 Khái niệm

5.1.3 Bắt đầu

5.2.1 Yêu cầu hệ thống

5.2.2 Cài đặt

5.2.3 Khái niệm cơ bản

5.2.4 Tạo kho lưu trữ

5.2.5 Nhập dự án

5.2.7 Thay đổi

5.2.8 Thêm tệp mới

5.2.9 Loại bỏ các thay đổi

5.3.1 Yêu cầu hệ thống

5.3.2 Khái niệm

5.3.3 Bắt đầu

Phần kết luận

Phụ lục A

Phụ lục B

Phụ lục B

Giới thiệu

Ngày nay, trong một thế giới có rất nhiều hệ thống phức tạp, cần phải sửa đổi các tài liệu điện tử ở các giai đoạn phát triển khác nhau của chúng. Trong suốt thời gian tồn tại của nó, một tài liệu điện tử có thể chịu một số lượng lớn các thay đổi. Tuy nhiên, điều thường xảy ra là các công việc tiếp theo không chỉ yêu cầu phiên bản mới nhất của tài liệu mà còn nhiều phiên bản trước đó.

Tất nhiên, bạn có thể lưu trữ một số phiên bản khác nhau của tài liệu được yêu cầu, nhưng phương pháp này không hiệu quả. Chúng ta phải tốn nhiều thời gian và công sức, cần đặc biệt chú ý và khả năng sai sót cao. Ngoài ra, chúng tôi phải lưu trữ một số lượng lớn các tài liệu gần như giống hệt nhau.

Do đó, các công cụ phần mềm đã được phát triển để đơn giản hóa cơ chế này. Những công cụ này được gọi là hệ thống kiểm soát phiên bản. Có một số hệ thống thuộc loại này, mỗi hệ thống đều có liên quan trong những điều kiện sử dụng nhất định của chúng.

Ý tưởng chính của hệ thống kiểm soát phiên bản là ghi nhớ tất cả các thay đổi được thực hiện, cũng như nhận xét của người dùng đã thực hiện chúng. Sau đó, nó trở nên rõ ràng là ai, khi nào và điều gì đã thay đổi, tại sao và tại sao. Và, quan trọng, tất cả những thay đổi này sau đó có thể được quay trở lại bất kỳ thời điểm nào.

Để đạt được mục tiêu đã đề ra, cần giải quyết các nhiệm vụ sau:

Xác định khái niệm về hệ thống kiểm soát phiên bản;

Hiểu cách thức hoạt động của các hệ thống như vậy;

Xem xét các quy tắc cài đặt và khởi chạy;

Phân tích các hệ thống kiểm soát phiên bản hiện có;

Hãy xem xét các loại chính của loại hệ thống này.

Các nhiệm vụ của công việc đã xác định trước cấu trúc của nó. Nội dung khóa học bao gồm năm chương, phần mở đầu, phần kết luận, phần tài liệu tham khảo và phần phụ lục.

1. Khái niệm về hệ thống kiểm soát phiên bản

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

2. Sử dụng hệ thống kiểm soát phiên bản

Hầu hết các hệ thống này được sử dụng trong phát triển phần mềm, do đó mã nguồn của các chương trình đang được phát triển có thể được lưu trữ. VCS cho phép các nhà phát triển lưu trữ các phiên bản trước của tệp từ quá trình phát triển và truy xuất chúng từ đó. Nó lưu trữ thông tin phiên bản cho mỗi tệp (và cấu trúc hoàn chỉnh của dự án) trong một bộ sưu tập thường được gọi là kho lưu trữ. Tuy nhiên, các hệ thống này có thể được sử dụng trong các lĩnh vực kiến ​​thức khác, bao gồm một số lượng lớn các tài liệu điện tử thường xuyên thay đổi. Ví dụ, chúng ngày càng được sử dụng nhiều hơn trong CAD, thường là một phần của hệ thống quản lý dữ liệu sản phẩm (PDM). Kiểm soát phiên bản được sử dụng trong các công cụ quản lý cấu hình.

Việc sử dụng SLE chắc chắn là điều bắt buộc đối với một nhà phát triển nếu dự án có hơn vài trăm dòng hoặc nếu một số nhà phát triển làm việc cùng nhau cho dự án.

Hệ thống kiểm soát phiên bản giải quyết các vấn đề sau:

Lưu trữ các phiên bản tệp;

Khả năng lấy bất kỳ phiên bản trước của tệp được lưu trữ;

Xem các thay đổi được thực hiện giữa các phiên bản được chỉ định trong yêu cầu;

3. Quy trình điển hình để làm việc với hệ thống

Mỗi VCS đều có những tính năng đặc trưng riêng trong bộ lệnh, cách thức làm việc và quản trị của người dùng. Tuy nhiên, quy trình vận hành chung cho hầu hết các SLE là hoàn toàn rập khuôn. Ở đây, người ta giả định rằng dự án, dù 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.

3.1 Bắt đầu với một dự án

Bước đầ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 bất kỳ phần nào của dự án để làm việc. Hành động này được thực hiện bằng cách sử dụng lệnh thanh toán tiêu chuẩn hoặc lệnh sao chép hoặc lệnh tùy chỉnh 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 phiên bản được quản trị viên chọn làm phiên bản chính) được sao chép theo mặc định.

Lệnh trích xuất thiết lập kết nối với máy chủ và dự án dưới dạng một cây gồm các thư mục và tệp được sao chép vào máy tính của nhà phát triển. Một thực tế phổ biến là sao chép một bản sao đang làm việc: ngoài thư mục chính với dự án, một bản sao khác của nó được ghi thêm vào đĩa cục bộ. Khi làm việc với một dự án, nhà phát triển chỉ sửa đổi các tệp trong bản sao làm việc chính. Bản sao cục bộ thứ hai được lưu trữ dưới dạng tham chiếu, cho phép bất kỳ lúc nào mà không cần liên hệ với máy chủ để xác định tổng thể những thay đổi nào đã được thực hiện đối với một tệp hoặc dự án cụ thể và từ phiên bản nào mà một bản sao đang hoạt động được tạo ra; theo quy định, bất kỳ nỗ lực nào để sửa đổi bản sao này theo cách thủ công sẽ dẫn đến lỗi hoạt động của phần mềm VCS.

3.2 Chu kỳ làm việc hàng ngày

Với một số thay đổi, được xác định bởi các đặc điểm của hệ thống và các chi tiết của quy trình kinh doanh được chấp nhận, chu kỳ công việc thông thường của một nhà phát triển trong ngày làm việc sẽ như sau:

1) 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ũ hơn: sự khác biệt của nó với 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 những thay đổi mâu thuẫn. Do đó, thuận tiện để giữ bản sao làm việc càng gần với phiên bản chính hiện tại càng tốt bằng cách nhà phát triển thực hiện thao tác cập nhật thường xuyên nhất có thể.

2) Sửa đổi dự án. Nhà phát triển sửa đổi dự án bằng cách 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.

3) Cam kết thay đổi. Sau khi hoàn thành giai đoạn tiếp theo của công việc trong 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. nhiệm vụ. VCS có thể yêu cầu nhà phát triển đảm bảo cập nhật bản sao làm việc trước khi cam kết. Nếu hệ thống có hỗ trợ giá đỡ, các thay đổi có thể được chuyển đến máy chủ mà không cần cam kết. Nếu chính sách công việc đã được phê duyệt trong SLE cho phép điều này, thì việc khắc phục các thay đổi có thể được thực hiện không phải hàng ngày, mà chỉ sau khi hoàn thành công việc của nhiệm vụ; trong trường hợp này, cho đến khi kết thúc công việc, tất cả các thay đổi liên quan đến công việc chỉ được lưu trong bản sao làm việc cục bộ của nhà phát triển.

3.3 Chi nhánh

Bạn có thể thực hiện các bản sửa lỗi nhỏ trong dự án bằng cách chỉnh sửa trực tiếp bản sao làm việc và sau đó thực hiện các thay đổi trực tiếp với nhánh chính (trung kế) trên máy chủ. Tuy nhiên, khi thực hiện bất kỳ khối lượng công việc đáng kể nào, quy trình này trở nên bất tiện: việc không thực hiện các thay đổi trung gian trên máy chủ không cho phép làm việc trên bất kỳ thứ gì trong chế độ nhóm, ngoài ra, nguy cơ mất các thay đổi trong trường hợp tai nạn cục bộ tăng lên và khả năng phân tích và quay lại những cái trước đó bị mất. Các biến thể mã trong công việc này. Do đó, đối với những thay đổi như vậy, thông thường là tạo các nhánh (branch), tạo phiên bản của một phiên bản mới của dự án hoặc một phần của dự án, phát triển trong đó được thực hiện song song với các thay đổi trong phiên bản chính. Khi công việc mà nhánh được tạo ra hoàn thành, nhánh này sẽ được hòa nhập lại vào nhánh chính. Điều này có thể được thực hiện bằng lệnh hợp nhất hoặc bằng cách tạo một bản vá chứa những thay đổi được thực hiện trong quá trình phát triển nhánh và áp dụng bản vá đó cho phiên bản chính hiện tại của dự án.

3.4 Hợp nhất các phiên bản

Ba loại hoạt động được thực hiện trong kiểm soát nguồn có thể dẫn đến nhu cầu hợp nhất các thay đổi:

Cập nhật bản sao làm việc;

Cam kết các thay đổi;

Hợp nhất các chi nhánh.

Mọi hệ thống đều có cơ chế hợp nhất tự động hoạt động dựa trên các nguyên tắc sau:

Các thay đổi có thể bao gồm sửa đổi nội dung của tệp, tạo tệp hoặc thư mục mới, xóa hoặc đổi tên tệp hoặc thư mục đã có từ trước trong dự án;

Nếu hai thay đổi đề cập đến các tệp và / hoặc thư mục khác nhau và không liên quan, chúng luôn có thể được hợp nhất tự động. Kết hợp chúng là những thay đổi được thực hiện trong mỗi phiên bản của dự án được sao chép vào phiên bản đã hợp nhất;

Việc tạo, xóa và đổi tên các tệp trong thư mục dự án có thể được hợp nhất tự động, miễn là chúng không xung đột với nhau. Trong trường hợp này, các thay đổi được thực hiện trong mỗi phiên bản của dự án được sao chép sang phiên bản đã hợp nhất.

Xung đột thường là:

Xóa và thay đổi cùng một tệp hoặc thư mục;

Xóa và đổi tên cùng một tệp hoặc thư mục;

Tạo các phiên bản khác nhau của tệp có cùng tên và nội dung khác nhau;

Các thay đổi trong cùng một tệp văn bản được thực hiện trong các phiên bản khác nhau có thể được hợp nhất nếu chúng nằm ở các vị trí khác nhau của tệp này và không chồng chéo. Trong trường hợp này, tất cả các thay đổi được thực hiện đối với phiên bản đã hợp nhất;

Các thay đổi trong cùng một tệp, nếu nó không phải là tệp văn bản, luôn xung đột và không thể được hợp nhất tự động.

Trong mọi trường hợp, phiên bản cơ sở cho hợp nhất là phiên bản trong đó các phiên bản hợp nhất được tách. Nếu đây là hoạt động cam kết, thì phiên bản cơ sở sẽ là phiên bản của bản cập nhật cuối cùng trước khi cam kết, nếu là bản cập nhật, thì phiên bản của bản cập nhật trước đó, nếu hợp nhất các nhánh, thì phiên bản mà nhánh tương ứng được tạo. Theo đó, các tập thay đổi được so sánh sẽ là các tập thay đổi được thực hiện từ đường cơ sở đến phiên bản hiện tại trong tất cả các biến thể được hợp nhất.

Phần lớn các hệ thống kiểm soát phiên bản hiện đại tập trung chủ yếu vào các dự án phát triển phần mềm trong đó loại nội dung tệp chính là văn bản. Theo đó, các cơ chế tự động kết hợp các thay đổi được hướng dẫn bởi quá trình xử lý các tệp văn bản.

Khi xác định khả năng chấp nhận các thay đổi hợp nhất trong cùng một tệp văn bản, cơ chế so sánh văn bản từng dòng điển hình sẽ hoạt động (ví dụ về cách triển khai của nó là tiện ích hệ thống khác biệt GNU), so sánh các phiên bản đã hợp nhất với cơ sở và xây dựng một danh sách các thay đổi, tức là các tập hợp dòng được thêm, xóa và thay thế ... Đã tìm thấy các tập hợp các đường đã thay đổi không giao nhau với nhau được coi là tương thích và được hợp nhất tự động. Nếu các tệp đã hợp nhất chứa các thay đổi ảnh hưởng đến cùng một dòng trong tệp, điều này dẫn đến xung đột. Các tệp như vậy chỉ có thể được hợp nhất theo cách thủ công. Bất kỳ tệp nào ngoài tệp văn bản đều là tệp nhị phân theo quan điểm SCV và không cho phép hợp nhất tự động.

3.5 Xung đột và cách giải quyết

Tình huống khi hợp nhất một số phiên bản, những thay đổi được thực hiện trong chúng giao nhau với nhau, được gọi là xung đột. Nếu có xung đột về thay đổi, hệ thống kiểm soát nguồn không thể tự động tạo dự án hợp nhất và buộc phải liên hệ với nhà phát triển. Như đã đề cập ở trên, xung đột có thể phát sinh trong giai đoạn cam kết, cập nhật hoặc hợp nhất. Trong mọi trường hợp, khi xung đột được phát hiện, hoạt động tương ứng sẽ bị chấm dứt cho đến khi nó được giải quyết.

Để giải quyết xung đột, hệ thống nói chung cung cấp cho nhà phát triển ba tùy chọn cho các tệp xung đột: cơ sở, cục bộ và máy chủ. Các thay đổi xung đột được hiển thị cho nhà phát triển trong một mô-đun chương trình đặc biệt để hợp nhất các thay đổi hoặc chỉ được đánh dấu bằng đánh dấu đặc biệt ngay trong văn bản của tệp đã hợp nhất.

Xung đột trong hệ thống tệp được giải quyết dễ dàng hơn: chỉ xóa tệp bằng một trong các thao tác khác có thể xung đột ở đó và thứ tự của các tệp trong thư mục không quan trọng, vì vậy nhà phát triển chỉ có thể chọn thao tác để lưu trong hợp nhất. phiên bản.

3.6 Ổ khóa

Cơ chế khóa cho phép một trong các nhà phát triển chỉ sử dụng tệp hoặc nhóm tệp của riêng mình để thực hiện các thay đổi đối với chúng. Trong khi tệp bị khóa, tệp vẫn ở chế độ chỉ đọc đối với tất cả các nhà phát triển khác và mọi nỗ lực thực hiện thay đổi đối với tệp đều bị máy chủ từ chối. Về mặt kỹ thuật, việc chặn có thể được tổ chức theo nhiều cách khác nhau. Cơ chế sau đây là điển hình cho các hệ thống hiện đại:

Các tệp yêu cầu chặn để hoạt động được đánh dấu bằng cờ "có thể chặn" đặc biệt;

Nếu một tệp được đánh dấu là bị khóa, thì khi bản sao đang hoạt động được kiểm tra từ máy chủ, nó sẽ được gán một thuộc tính chỉ đọc trên hệ thống tệp cục bộ, điều này ngăn chặn việc chỉnh sửa ngẫu nhiên;

Nhà phát triển muốn thay đổi tệp bị khóa sẽ gọi lệnh khóa đặc biệt với tên của tệp này. Theo kết quả của lệnh này, điều sau xảy ra:

1. máy chủ kiểm tra xem tệp đã bị khóa bởi nhà phát triển khác chưa; nếu vậy, lệnh chặn không thành công.

2. tệp trên máy chủ được đánh dấu là "bị khóa", trong khi vẫn giữ mã định danh của nhà phát triển đã chặn nó và thời gian chặn;

3. Nếu khóa trên máy chủ thành công, thuộc tính chỉ đọc sẽ bị xóa khỏi tệp sao chép đang hoạt động trên hệ thống tệp cục bộ, cho phép bạn bắt đầu chỉnh sửa nó.

Nếu trong quá trình làm việc mà thấy file không cần thay đổi thì có thể gọi lệnh mở khóa (unlock , khóa phát hành). Tất cả các thay đổi đối với tệp sẽ bị hủy, tệp cục bộ sẽ trở về trạng thái chỉ đọc, thuộc tính “bị khóa” sẽ bị xóa khỏi tệp trên máy chủ và các nhà phát triển khác sẽ có thể sửa đổi tệp này;

Sau khi hoàn thành công việc với tệp bị khóa, nhà phát triển cam kết các thay đổi. Thông thường, điều này sẽ tự động phát hành khóa.

3.7 Phiên bản dự án, thẻ

Hệ thống kiểm soát phiên bản đảm bảo lưu trữ tất cả các biến thể tệp hiện có và do đó, tất cả các biến thể dự án nói chung, đã diễn ra kể từ khi bắt đầu phát triển. Nhưng chính khái niệm "phiên bản" trong các hệ thống khác nhau có thể được hiểu theo hai cách khác nhau.

Một số hệ thống hỗ trợ lập phiên bản tệp. Điều này có nghĩa là bất kỳ tệp nào xuất hiện trong dự án đều có số phiên bản của riêng nó. Mỗi khi nhà phát triển cam kết một thay đổi ảnh hưởng đến tệp, phần tương ứng của thay đổi đã cam kết sẽ được áp dụng cho tệp đó và tệp được cung cấp một số phiên bản mới, thường là tiếp theo.

Đối với các hệ thống khác, phiên bản không tham chiếu đến một tệp đơn lẻ, mà là toàn bộ kho lưu trữ. Kho lưu trữ trống mới được tạo có phiên bản 1 hoặc 0, bất kỳ cam kết thay đổi nào đều dẫn đến sự gia tăng số lượng này. Số phiên bản của một tệp riêng biệt không thực sự tồn tại ở đây.

Tuy nhiên, cả hai lựa chọn đều không thuận tiện cho lắm. Hệ thống kiểm soát phiên bản hỗ trợ khái niệm về thẻ để gắn thẻ các phiên bản dự án dễ dàng hơn.

Thẻ là một thẻ tượng trưng có thể được liên kết với một phiên bản cụ thể của tệp và / hoặc thư mục trong kho lưu trữ. Với sự trợ giúp của lệnh thích hợp, tất cả hoặc một phần của tệp dự án đáp ứng các điều kiện nhất định có thể được gán một nhãn nhất định. Do đó, bạn có thể xác định phiên bản của dự án, sửa chữa trạng thái của nó tại một số thời điểm mong muốn. Thông thường, hệ thống gắn thẻ đủ linh hoạt để gắn thẻ các phiên bản tệp và thư mục không đồng thời với một thẻ duy nhất. Điều này cho phép bạn xây dựng một "phiên bản dự án" theo bất kỳ cách nào tùy ý.

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

VCS được ưu tiên nhất để theo dõi sự phát triển của ngôi nhà sẽ là loại địa phương. Để giải quyết vấn đề này, các VCS đặc biệt với một cơ sở dữ liệu đơn giản đã được phát triển, trong đó tất cả các tệp cục bộ được lưu trữ.

Hình 4.1 Sơ đồ SCR địa phương

Một trong những ACS phổ biến hơn của loại này là RCS, vẫn được cài đặt trên nhiều máy tính ngày nay.

4.2 Mô hình tập trung

Hệ thống kiểm soát phiên bản truyền thống sử dụng mô hình tập trung trong đó có một kho tài liệu duy nhất được quản lý bởi một máy chủ chuyên dụng thực hiện hầu hết các chức năng kiểm soát phiên bản. Người dùng làm việc với tài liệu trước tiên phải lấy phiên bản của tài liệu mà anh ta cần từ kho lưu trữ; thường một bản sao cục bộ của tài liệu được tạo ra, cái gọi là "bản sao làm việc". Có thể lấy phiên bản mới nhất hoặc bất kỳ phiên bản nào trước đó, có thể được chọn theo số phiên bản hoặc ngày tạo, đôi khi theo các tiêu chí khác. Sau khi các thay đổi cần thiết đã được thực hiện đối với tài liệu, phiên bản mới được đặt trong kho lưu trữ. Không giống như chỉ lưu một tệp, phiên bản trước đó không bị xóa mà còn được lưu lại trong kho lưu trữ và có thể được truy xuất từ ​​đó bất kỳ lúc nào.

Các hệ thống 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ừ đó. Đây là tiêu chuẩn cho các hệ thống kiểm soát phiên bản trong nhiều năm.

Hình 4.2 Sơ đồ điều khiển phiên bản tập trung

Cách tiếp cận này có nhiều ưu điểm, đặc biệt là so với các SLE cục bộ. Ví dụ, mọi người đều biết ai đang làm những 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ý CSKV dễ dàng hơn nhiều so với cơ sở dữ liệu cục bộ trên mỗi máy khách.

Tuy nhiên, cách tiếp cận này có một số nhược điểm nghiêm trọng. Rõ ràng nhất là một máy chủ tập trung là một lỗ hổng trong toàn bộ hệ thống. Nếu máy chủ bị tắt 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. Các VCS cục bộ cũng gặp phải vấn đề tương tự: nếu toàn bộ lịch sử của một dự án được lưu trữ ở một nơi, bạn có nguy cơ mất mọi thứ.

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

Các hệ thống như vậy sử dụng mô hình phân tán thay vì mô hình máy khách / máy chủ truyền thống. Nói chung, chúng không cần bộ lưu trữ tập trung: toàn bộ lịch sử thay đổi tài liệu được lưu trữ trên mỗi máy tính, trong bộ lưu trữ cục bộ và nếu cần, các phân đoạn riêng lẻ của lịch sử lưu trữ cục bộ sẽ được đồng bộ hóa với bộ lưu trữ tương tự trên máy tính khác. Do đó, trong trường hợp máy chủ mà thông qua đó công việc bị trục trặc, bất kỳ kho lưu trữ ứng dụng khách 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. Trên một số hệ thống này, kho lưu trữ cục bộ nằm trực tiếp trong các thư mục bản sao đang hoạt động.

Hình 4.3 Mô hình SCR phân tán

Khi người dùng của một hệ thống như vậy thực hiện các hành động thông thường, chẳng hạn như kiểm tra phiên bản cụ thể của tài liệu, tạo phiên bản mới và tương tự, anh ta sẽ làm việc với bản sao cục bộ của kho lưu trữ. Khi các thay đổi được thực hiện, các kho lưu trữ thuộc các nhà phát triển khác nhau bắt đầu khác nhau và việc đồng bộ hóa chúng trở nên cần thiết. Việc đồng bộ hóa này có thể được thực hiện bằng cách trao đổi các bản vá hoặc cái gọi là bộ dụng cụ giữa những người dùng.

Mô hình được mô tả về mặt logic gần với việc tạo một nhánh riêng cho từng nhà phát triển trong hệ thống điều khiển phiên bản cổ điển. Sự khác biệt là các nhà phát triển khác không nhìn thấy nhánh này cho đến khi đồng bộ hóa. Miễn là một nhà phát triển chỉ thay đổi nhánh của riêng mình, công việc của anh ta không ảnh hưởng đến những người tham gia dự án khác và ngược lại. Sau khi hoàn thành phần riêng biệt của công việc, các thay đổi được thực hiện đối với các nhánh được hợp nhất với nhánh chính (chung). Cả khi hợp nhất các chi nhánh và khi đồng bộ hóa các kho lưu trữ khác nhau, xung đột phiên bản đều có thể xảy ra. Trong trường hợp này, tất cả các hệ thống cung cấp một hoặc một phương pháp khác để phát hiện và giải quyết xung đột hợp nhất.

Theo quan điểm của người dùng, hệ thống phân tán được phân biệt bởi sự cần thiết phải tạo một kho lưu trữ cục bộ và sự hiện diện của hai lệnh bổ sung trong ngôn ngữ lệnh: các lệnh để lấy một kho lưu trữ từ một máy tính từ xa và chuyển kho lưu trữ của nó đến một máy tính từ xa. Lệnh đầu tiên hợp nhất các thay đổi trong kho lưu trữ từ xa và cục bộ và đưa kết quả vào kho lưu trữ cục bộ; thứ hai, ngược lại, hợp nhất các thay đổi của hai kho lưu trữ và đưa kết quả vào một kho lưu trữ từ xa. Theo quy tắc, các lệnh hợp nhất trong hệ thống phân tán cho phép bạn chọn tập hợp thay đổi nào sẽ được chuyển đến hoặc kiểm tra từ một kho lưu trữ khác, khắc phục xung đột hợp nhất trực tiếp trong quá trình hoạt động hoặc sau khi hoàn thành không thành công, thực hiện lại hoặc tiếp tục quá trình hợp nhất chưa hoàn thành. Thông thường, việc đẩy các thay đổi của bạn sang kho lưu trữ của người khác chỉ thành công nếu không có xung đột. Nếu xung đột phát sinh, trước tiên người dùng phải hợp nhất các phiên bản trong kho lưu trữ của mình và chỉ sau đó chuyển chúng cho người khác.

Thường nên tổ chức công việc với hệ thống để người dùng luôn luôn hoặc chủ yếu hợp nhất trong kho của họ. Nghĩa là, không giống như các hệ thống tập trung, nơi người dùng gửi các thay đổi của họ đến một máy chủ trung tâm khi họ thấy phù hợp, trong các hệ thống phân tán, việc sắp xếp tự nhiên hơn khi hợp nhất các phiên bản được bắt đầu bởi người cần lấy kết quả (ví dụ: nhà phát triển quản lý máy chủ xây dựng) ...

Ưu điểm chính của các hệ thống phân tán là tính linh hoạt của chúng và tính tự chủ cao hơn đáng kể (so với các hệ thống tập trung) của một nơi làm việc riêng biệt. Trên thực tế, mỗi máy tính của nhà phát triển là một máy chủ độc lập và đầy đủ chức năng, từ những máy tính đó có thể xây dựng một hệ thống với bất kỳ cấu trúc và mức độ phức tạp nào bằng cách thiết lập thứ tự đồng bộ hóa mong muốn.

Những bất lợi của hệ thống phân tán bao gồm việc tăng dung lượng bộ nhớ đĩa cần thiết: mỗi máy tính phải lưu trữ lịch sử phiên bản hoàn chỉnh, trong khi trong hệ thống tập trung trên máy tính của nhà phát triển, chỉ một bản sao đang hoạt động thường được lưu trữ, tức là một phần của kho lưu trữ tại một số thời điểm và các thay đổi được thực hiện. Một nhược điểm ít rõ ràng hơn nhưng gây khó chịu là trong một hệ thống phân tán gần như không thể thực hiện một số chức năng được cung cấp bởi các hệ thống tập trung. Nó:

- Chặn một tệp hoặc một nhóm tệp (để lưu dấu hiệu chặn, cần có một máy chủ trung tâm trực tuyến công khai và vĩnh viễn). Điều này buộc bạn phải áp dụng các biện pháp hành chính đặc biệt nếu bạn phải làm việc với các tệp nhị phân không phù hợp để hợp nhất tự động;

- Theo dõi một tệp hoặc nhóm tệp cụ thể;

- Đánh số đầu cuối thống nhất của các phiên bản hệ thống và / hoặc tệp, trong đó số phiên bản tăng lên một cách đơn điệu. Trong các hệ thống phân tán, bạn phải thực hiện các chỉ định phiên bản cục bộ và các thẻ sử dụng, mục đích của chúng được xác định theo thỏa thuận giữa các nhà phát triển hoặc các tiêu chuẩn chung của công ty;

- Công việc cục bộ của người dùng với một mẫu riêng biệt, có kích thước nhỏ từ bộ lưu trữ, có kích thước đáng kể và độ phức tạp bên trong, trên một máy chủ từ xa.

Có thể phân biệt các tình huống điển hình sau đây, trong đó việc sử dụng hệ thống phân tán mang lại những lợi ích đáng chú ý:

- Đồng bộ hóa định kỳ một số máy tính dưới sự kiểm soát của một nhà phát triển. Sử dụng hệ thống phân tán loại bỏ nhu cầu phân bổ một trong các máy tính làm máy chủ;

- Làm việc chung trong một dự án của một nhóm nhỏ các nhà phát triển được phân bổ theo địa lý mà không phân bổ các nguồn lực chung. Như trong trường hợp trước, kế hoạch làm việc không có máy chủ chính được thực hiện, và tính liên quan của các kho lưu trữ được duy trì bằng cách đồng bộ hóa định kỳ theo sơ đồ "từng thứ với từng";

Một dự án phân tán lớn, những người tham gia trong đó mỗi người có thể tự mình làm việc trong một thời gian dài, trong khi họ không có kết nối lâu dài với mạng. Một dự án như vậy có thể sử dụng một máy chủ tập trung mà các bản sao của tất cả những người tham gia của nó được đồng bộ hóa. Có thể làm việc mà không có máy chủ "nhóm", sau đó các nhà phát triển của một nhóm đồng bộ hóa các thay đổi với nhau, sau đó bất kỳ người nào trong số họ chuyển các thay đổi đến máy chủ trung tâm.

5. Ví dụ về hệ thống kiểm soát phiên bản

5.1 GIT

5.1.1 Yêu cầu hệ thống

Git chạy trên các hệ điều hành sau: Windows, Linux và Mac OS.

Để cài đặt Git trên Windows, bạn chỉ cần tải xuống tệp exe của trình cài đặt từ trang GitHub của dự án và chạy nó. Sau khi cài đặt, bạn sẽ có cả phiên bản console (bao gồm cả SSH client) và phiên bản đồ họa tiêu chuẩn.

5.1.2 Khái niệm

Git là một hệ thống kiểm soát phiên bản phân tán. Trong đó, các tệp có thể ở một trong ba trạng thái: cam kết, sửa đổi và chuẩn bị. "Đã cam kết" có nghĩa là tệp đã được lưu trong cơ sở dữ liệu cục bộ của bạn. Các tệp đã sửa đổi bao gồm các tệp đã thay đổi nhưng chưa được cam kết. Các tệp được cấp phép là các tệp đã sửa đổi được đánh dấu để đưa vào lần cam kết tiếp theo.

Do đó, các dự án sử dụng Git có ba phần: thư mục Git, thư mục làm việc và vùng dàn dựng.

Thư mục Git là nơi Git lưu trữ siêu dữ liệu và cơ sở dữ liệu đối tượng cho dự án của bạn, đây là phần quan trọng nhất của Git và được sao chép khi bạn sao chép kho từ một máy khác.

Thư mục làm việc là một bản sao của một phiên bản cụ thể của dự án được trích xuất từ ​​cơ sở dữ liệu. Các tệp này được lấy từ cơ sở dữ liệu nén trong thư mục Git và được đặt trên đĩa để bạn xem và chỉnh sửa.

Vùng dàn là một tệp thông thường, thường được lưu trữ trong thư mục Git, chứa thông tin về những gì sẽ đi vào lần cam kết tiếp theo. Đôi khi được gọi là chỉ mục, nhưng gần đây nó đã trở thành tiêu chuẩn để gọi nó là vùng dàn (vùng dàn) .

Quy trình làm việc Git điển hình trông giống như sau:

1. Bạn thực hiện các thay đổi đối với các tệp trong thư mục làm việc của mình.

2. Chuẩn bị tệp bằng cách thêm ảnh chụp nhanh của chúng vào vùng tệp đã chuẩn bị.

3. Thực hiện một cam kết, lấy các tệp đã chuẩn bị từ chỉ mục và đặt chúng vào thư mục Git để lưu trữ liên tục.

Nếu phiên bản làm việc của tệp khớp với phiên bản trong thư mục Git "a, thì tệp được coi là được cam kết. Nếu tệp được thay đổi nhưng được thêm vào vùng dữ liệu đã chuẩn bị thì nó được chuẩn bị. Nếu tệp đã thay đổi sau khi được tải xuống từ cơ sở dữ liệu, nhưng không được chuẩn bị, sau đó nó được coi là đã sửa đổi.

5.1.3 Bắt đầu

Tất cả đều hoạt động trong Git xảy ra bên trong một kho chứa tất cả các tệp công việc. Có nhiều cách khác nhau để tạo một kho lưu trữ.

1. Qua menu ngữ cảnh. Để thực hiện, bạn chỉ cần nhấp chuột phải vào thư mục mong muốn và chọn mục Git Init Here.

Hình 5.1.1 Tạo kho lưu trữ bằng menu ngữ cảnh

2. Sử dụng dòng lệnh. Để thực hiện việc này, theo cách tương tự, trong thư mục bắt buộc, hãy chọn Git Bash từ menu ngữ cảnh. Một dòng lệnh sẽ mở ra trong đó chúng ta tạo một kho lưu trữ bằng lệnh Git Init.

Hình 5.1.2 Tạo kho lưu trữ bằng dòng lệnh

Nếu bạn chưa từng sử dụng git trước đây, trước tiên bạn cần nhập tên và địa chỉ email với hầu hết các lệnh sau, tương ứng:

git config --global user.name "Tên của bạn"

git config --global user.email [email được bảo vệ]

Kho lưu trữ được tạo sẽ chứa một thư mục .git. Để thêm tệp vào kho lưu trữ, bạn chỉ cần sao chép tệp đó vào thư mục làm việc. Hãy thêm tệp ex.txt vào kho lưu trữ. Sử dụng lệnh git status để đảm bảo Git nhìn thấy tệp.

Hình 5.1.3 Thêm và kiểm tra một tệp trong kho lưu trữ

Hơn nữa, để thêm tệp dưới quyền kiểm soát phiên bản, bạn nên lập chỉ mục các tệp này và thực hiện cam kết thay đổi đầu tiên. Điều này có thể được thực hiện với một số lệnh git add chỉ định các tệp được lập chỉ mục, sau đó git commit.

Hình 5.1.4 Thêm tệp dưới quyền kiểm soát phiên bản

Lệnh git status là công cụ chính được sử dụng để xác định tệp đang ở trạng thái nào.

Để bắt đầu theo dõi (thêm dưới quyền kiểm soát phiên bản) một tệp mới, hãy sử dụng lệnh git add "filename". Lệnh này nhận như một tham số là đường dẫn đến một tệp hoặc thư mục, nếu đó là một thư mục, lệnh này sẽ thêm (lập chỉ mục) tất cả các tệp trong thư mục này một cách đệ quy.

Git commit -m "comment" - một lệnh để tạo một cam kết, cam kết một thay đổi.

Hãy lặp lại thao tác trước đó bằng Git Gui. Để thực hiện việc này, hãy chọn mục Git Gui trong menu ngữ cảnh.

Hình 5.1.5

Trong cửa sổ mở ra, chọn mục "Tạo kho lưu trữ mới". Tiếp theo, chúng tôi sẽ chỉ ra thư mục mà chúng tôi muốn đặt kho lưu trữ.

Hình 5.1.6 Tạo kho lưu trữ trong Git Gui

Thêm tệp Ex.txt vào thư mục. Sau đó, chúng tôi nhấn nút "Đọc lại". Để thêm tệp vào hệ thống kiểm soát phiên bản, bạn cần nhấp vào nút "Chuẩn bị tất cả". Tệp Ex.txt sẽ chuyển từ Đã sửa đổi sang Chuẩn bị. Để thực hiện thay đổi, hãy sử dụng nút "Lưu".

5.1.5 Tạo bản sao của kho lưu trữ

Ngày nay, bạn có rất nhiều tùy chọn lưu trữ để lựa chọn, tất cả đều cóưu điểm và nhược điểm.

Phần này sẽ hướng dẫn bạn quy trình tạo tài khoản và dự án mới trên GitHub. Phần này sẽ cung cấp cho bạn ý tưởng về những thứ liên quan.

GitHub là trang web lưu trữ Git lớn nhất dành cho các dự án mã nguồn mở hiện nay và là một trong số ít cung cấp cùng lúc cả dịch vụ lưu trữ công cộng và riêng tư.

Điều đầu tiên cần làm là thiết lập một tài khoản và tạo kho lưu trữ của bạn tại http://github.com/plans.

Tiếp theo, trên dòng lệnh Git, hãy nhập các lệnh mà chúng ta đã biết:

Git thêm ex.txt

Git cam kết -m "bình luận"

Git từ xa thêm nguồn gốc https://github.com/Arbuz-z-z/MyHomework.git

Git push -u origin master

Lệnh git remote add thêm các kho lưu trữ từ xa và lệnh git push đẩy các thay đổi cục bộ đến một máy chủ từ xa.

Hình 5.1.7

Nhập tên người dùng và mật khẩu được chỉ định trong quá trình đăng ký:

Hình 5.1.8

Bây giờ dự án của chúng tôi được lưu trữ trên GitHub, trong kho lưu trữ - MyHomework với tệp Tusur.txt và chúng tôi có thể liên kết đến nó với bất kỳ ai mà chúng tôi muốn chia sẻ dự án.

Hình 5.1.9 Kho lưu trữ GitHub

5.2 TortoiseSVN

5.2.1 Yêu cầu hệ thống

TortoiseSVN chạy trên Windows XP (với Gói Dịch vụ 3) trở lên và có sẵn ở cả hai phiên bản 32 bit và 64 bit. Trình cài đặt cho Windows 64-bit cũng bao gồm một phần 32-bit.

5.2.2 Cài đặt

TortoiseSVN xuất hiện dưới dạng một tệp cài đặt dễ sử dụng.

5.2.3 Khái niệm cơ bản

Kho. Subversion sử dụng một cơ sở dữ liệu trung tâm chứa tất cả các tệp được tạo phiên bản với lịch sử đầy đủ của chúng. Cơ sở dữ liệu này được gọi là kho lưu trữ. Kho lưu trữ thường nằm trên máy chủ tệp mà Subversion được cài đặt, phục vụ dữ liệu cho các máy khách Subversion theo yêu cầu (ví dụ: TortoiseSVN). Nếu bạn đang sao lưu, hãy sao chép vault của bạn, vì đây là bản gốc của tất cả dữ liệu của bạn.

Bản làm việc. Đây chính xác là nơi bạn làm việc. Mỗi nhà phát triển có bản sao làm việc của riêng họ, đôi khi được gọi là hộp cát, trên máy cục bộ của họ. Bạn có thể tải phiên bản tệp mới nhất từ ​​kho lưu trữ, làm việc trên đó cục bộ mà không cần tương tác với bất kỳ ai khác và khi bạn chắc chắn về các thay đổi, bạn có thể cam kết các tệp đó trở lại kho lưu trữ. Bản sao làm việc không chứa lịch sử của dự án, nhưng nó chứa bản sao của tất cả các tệp có trong kho lưu trữ trước khi bạn bắt đầu thực hiện thay đổi.

TortoiseSVN là một tiện ích mở rộng của Windows Explorer, vì vậy trước tiên bạn cần khởi chạy Explorer.

Hình 5.2.1 Xem trong Explorer

5.2.4 Tạo kho lưu trữ

Đối với một dự án thực, chúng ta cần một kho lưu trữ được thiết lập ở một nơi an toàn và một máy chủ Subversion để quản lý nó. Chúng tôi sẽ sử dụng tính năng kho lưu trữ cục bộ của Subversion, cho phép truy cập trực tiếp vào kho lưu trữ được tạo trên ổ cứng của bạn và không yêu cầu máy chủ.

Đầu tiên, hãy tạo một thư mục trống mới trên PC. Nó có thể ở bất cứ đâu, nhưng trong công việc này, chúng tôi sẽ gọi nó là: \ svn_repos. Bây giờ nhấp chuột phải vào thư mục mới và chọn TortoiseSVN> Tạo Kho lưu trữ Tại đây ... Kho lưu trữ được tạo bên trong thư mục đã sẵn sàng để sử dụng. Chúng tôi cũng sẽ tạo cấu trúc thư mục nội bộ bằng cách nhấp vào nút "Tạo cấu trúc thư mục".

Hình 5.2.2 Tạo kho lưu trữ

Hình 5.2.3 xem kho lưu trữ

5.2.5 Nhập dự án

Bây giờ chúng tôi có một kho lưu trữ, nhưng nó hoàn toàn trống rỗng vào lúc này. Giả sử chúng ta có một tập hợp các tệp trong E: \ \ TortoiseSVN mà chúng ta muốn thêm vào. Điều hướng đến thư mục TortoiseSVN trong Explorer và nhấp chuột phải vào nó. Bây giờ chọn TortoiseSVN> Nhập ... sẽ xuất hiện một hộp thoại.

Hình 5.2.4 Cửa sổ nhập

Một kho lưu trữ Subversion được truy cập bởi một URL cho phép chúng tôi trỏ kho lưu trữ ở bất kỳ đâu trên Internet. Trong trường hợp này, chúng ta cần trỏ đến kho lưu trữ cục bộ của mình, nơi có tệp url: /// s: / svn_repos và chúng ta thêm tên của dự án TortoiseSVN vào đó.

Một tính năng quan trọng khác của hộp thoại này là cửa sổ Nhập Thông báo, nơi bạn có thể thêm thông báo về những gì chúng tôi đang làm. Bất cứ khi nào chúng ta cần xem lại lịch sử của một dự án, những thông báo này sẽ là một công cụ có giá trị để xem những thay đổi nào đã được thực hiện và khi nào.

5.2.6 Kiểm tra một bản sao đang hoạt động

Bây giờ chúng tôi có một dự án trong kho lưu trữ của mình và chúng tôi cần tạo một bản sao hoạt động cho công việc hàng ngày của chúng tôi. Cần lưu ý rằng việc nhập một thư mục không tự động biến thư mục đó thành một bản sao đang hoạt động. Subversion sử dụng thuật ngữ "Checkout" để tạo một bản sao làm việc mới. Chúng tôi sẽ giải nén thư mục TortoiseSVN từ kho lưu trữ của chúng tôi vào một thư mục phát triển có tên e: \ \ TortoiseSVN \ svn_repos. Tạo thư mục này, sau đó nhấp chuột phải vào nó và chọn TortoiseSVN> Kiểm tra ... Nhập url để kiểm tra, trong trường hợp này là tệp: /// s: / svn_repos / TortoiseSVN và nhấp vào OK. Thư mục phát triển của chúng tôi sẽ chứa đầy các tệp từ kho lưu trữ.

Thư mục này trông khác với một thư mục thông thường. Mỗi tệp có một hộp kiểm màu xanh lá cây ở góc bên trái. Đây là các biểu tượng trạng thái TortoiseSVN chỉ có trong bản sao đang hoạt động. Trạng thái xanh có nghĩa là tệp không khác với phiên bản của tệp trong kho.

5.2.7 Thay đổi

Bạn có thể đi làm. Trong thư mục TortoiseSVN chúng tôi bắt đầu sửa đổi các tệp - giả sử chúng tôi thực hiện các thay đổi đối với các tệp TortoiseSVN.docx. Lưu ý rằng các biểu tượng trên các tệp này hiện có màu đỏ để cho biết rằng các thay đổi đã được thực hiện cục bộ.

Nhấp chuột phải vào một trong các tệp đã sửa đổi và chọn TortoiseSVN> Sự khác biệt. Thao tác này sẽ khởi chạy công cụ so sánh tệp TortoiseSVN và hiển thị cho bạn chính xác dòng nào trong tệp đã thay đổi.

Hình 5.2.5 So sánh tệp

Bây giờ chúng ta hãy cập nhật kho lưu trữ. Hành động này được gọi là Thay đổi cam kết. Nhấp chuột phải vào thư mục TortoiseSVN và chọn TortoiseSVN> Cam kết. Hộp thoại cam kết sẽ xuất hiện với danh sách các tệp đã thay đổi và sẽ có dấu kiểm bên cạnh mỗi tệp. Chúng tôi chỉ có thể chọn một vài tệp từ danh sách để cam kết.

Hình 5.2.6 Các tệp cam kết

5.2.8 Thêm tệp mới

Trong khi làm việc trong một dự án, chúng tôi cần thêm tệp mới, giả sử chúng tôi đã thêm các chức năng mới trong tệp và thêm trợ giúp trong tệp hiện có. Nhấp chuột phải vào thư mục và chọn TortoiseSVN> Thêm. Hộp thoại thêm hiển thị tất cả các tệp chưa được phiên bản và chúng tôi có thể chọn những tệp mà chúng tôi muốn thêm. Một cách khác để thêm tệp là nhấp chuột phải vào chính tệp đó và chọn TortoiseSVN> Thêm.

Bây giờ, nếu chúng ta mở thư mục để cam kết, tệp mới sẽ được hiển thị là Đã thêm và tệp hiện có là Đã sửa đổi.

5.2.9 Loại bỏ các thay đổi

Một chức năng chung của tất cả các hệ thống kiểm soát sửa đổi là chức năng cho phép chúng tôi hoàn tác các thay đổi mà chúng tôi đã thực hiện trước đó.

Nếu chúng ta muốn loại bỏ những thay đổi mà chúng ta chưa có thời gian để cam kết và khôi phục tệp yêu cầu ở dạng trước khi bắt đầu thay đổi, thì hãy chọn lệnh TortoiseSVN> Hoàn nguyên Thay đổi. Thao tác này sẽ hoàn tác các thay đổi của chúng tôi và trả về phiên bản cố định của tệp mà chúng tôi đã bắt đầu. Nếu chúng ta chỉ muốn loại bỏ một số thay đổi, thì chúng ta có thể sử dụng công cụ TortoiseMerge để xem các thay đổi và loại bỏ chọn lọc các dòng đã thay đổi.

Nếu chúng tôi muốn hoàn tác các hành động của một bản sửa đổi cụ thể, chúng tôi bắt đầu từ hộp thoại nhật ký và tìm bản sửa đổi có vấn đề. Chọn Menu ngữ cảnh> Hoàn tác thay đổi từ lệnh sửa đổi này và những thay đổi đó sẽ bị hủy.

5.2.10 Các tính năng của TortoiseSVN. Tích hợp vỏ

TortoiseSVN tích hợp trực tiếp vào Windows shell (tức là Explorer). Điều này có nghĩa là bạn có thể làm việc với các công cụ bạn đã biết mà không cần phải chuyển sang ứng dụng khác mỗi khi bạn cần các tính năng kiểm soát phiên bản!

Và bạn thậm chí không cần sử dụng Explorer. Các menu ngữ cảnh của TortoiseSVN hoạt động trong nhiều trình quản lý tệp khác và hộp thoại mở tệp được sử dụng trong hầu hết các ứng dụng Windows tiêu chuẩn. Tuy nhiên, bạn nên lưu ý rằng TortoiseSVN ban đầu được thiết kế như một tiện ích mở rộng cho Windows Explorer và, có thể, trong các ứng dụng khác, việc tích hợp sẽ không hoàn chỉnh, chẳng hạn như các lớp phủ trên các biểu tượng có thể không được hiển thị.

Trạng thái của từng tệp và thư mục được tạo phiên bản được hiển thị bằng một lớp phủ nhỏ trên biểu tượng chính. Bằng cách này, bạn có thể thấy ngay trạng thái của bản sao đang làm việc của mình.

5.2.11 Giao diện người dùng đồ họa

Khi xem danh sách các thay đổi đối với một tệp hoặc thư mục, bạn có thể nhấp vào một bản sửa đổi để xem các nhận xét cho cam kết đó. Danh sách các tệp đã sửa đổi cũng có sẵn - chỉ cần nhấp đúp vào tệp để xem những thay đổi cụ thể nào đã được thực hiện.

Hộp thoại cam kết là một danh sách liệt kê tất cả các tệp và thư mục sẽ được bao gồm trong cam kết. Mỗi mục danh sách có một hộp kiểm để bạn có thể chọn chính xác những gì bạn muốn đưa vào cam kết. Các tệp đã đảo ngược cũng có thể xuất hiện trong danh sách này, vì vậy bạn đừng quên thêm tệp hoặc thư mục mới vào cam kết.

Tất cả các lệnh Subversion đều có sẵn từ menu ngữ cảnh của Explorer. TortoiseSVN thêm menu con của riêng nó ở đó.

5.3 Mercurial

5.3.1 Yêu cầu hệ thống

NS Gói Mercurial có sẵn cho mọi hệ điều hành phổ biến: Windows, Mac OS, Linux (Ubuntu, Debian, Fedora, OpenSUSE, Gentoo), Solaris.

Phiên bản tốt nhất của Mercurial dành cho Windows là TortoiseHg, bạn có thể tìm thấy phiên bản này tại http://tortoisehg.org. Gói này cho phép bạn sử dụng dòng lệnh và giao diện người dùng đồ họa.

5.3.2 Khái niệm

Mercurial là một hệ thống kiểm soát phiên bản phân tán (phi tập trung). Điều này có nghĩa là quy trình làm việc thường giống như sau:

1. Kho lưu trữ mới được tạo trên máy tính cá nhân (bằng cách nhân bản kho lưu trữ hiện có, tạo mới, v.v.);

2. Các tệp trong thư mục làm việc của kho này bị thay đổi / thêm / bớt;

3. Các thay đổi được cam kết đối với kho lưu trữ nhất định (nghĩa là đối với kho lưu trữ cục bộ trên máy tính cá nhân);

4. Bước 2 và 3 được lặp lại nhiều lần nếu cần;

5. Nếu cần thiết, các thay đổi sẽ được đồng bộ hóa với các kho khác: các tập thay đổi của người khác được lấy (kéo) và / hoặc tập thay đổi của chính họ được đưa ra (đẩy).

Có nghĩa là, tất cả công việc hàng ngày đều diễn ra trong kho lưu trữ cục bộ và khi có nhu cầu, kết quả công việc của họ sẽ được gửi đến một hoặc nhiều kho lưu trữ khác. Bạn có thể giảm số bước liên quan đến việc làm việc với các kho lưu trữ từ xa bằng cách định cấu hình Mercurial để tự động đẩy các thay đổi sang các kho lưu trữ khác khi bạn cam kết.

5.3.3 Bắt đầu

Bạn có thể làm việc trong Mercurial thông qua menu ngữ cảnh của trình thám hiểm, cửa sổ không gian làm việc TortoiseHg Workbench (chương trình tạo lối tắt thích hợp trong quá trình cài đặt) hoặc dòng lệnh sử dụng lệnh hg.

5.3.4 Tạo kho lưu trữ và làm việc với các tệp

Trong Mercurial, mọi thứ diễn ra bên trong một kho lưu trữ. Kho lưu trữ dự án chứa tất cả các tệp "thuộc về" dự án, cũng như lịch sử thay đổi đối với các tệp này. Có ba cách khác nhau để tạo một kho lưu trữ.

Để tạo kho thông qua menu ngữ cảnh của trình thám hiểm, chỉ cần nhấp chuột phải vào thư mục mong muốn và chọn mục thích hợp.

Hình 5.3.1 Tạo kho lưu trữ

Trong cửa sổ xuất hiện, bạn có thể xác nhận vị trí của thư mục kho lưu trữ và mở kho lưu trữ đã tạo trong môi trường làm việc.

Hình 5.3.2 Vị trí của thư mục kho lưu trữ

Tương tự, kho lưu trữ được tạo trực tiếp trong cửa sổ Bàn làm việc TortoiseHg: trình tự kho lưu trữ File \ New gọi cửa sổ cùng tên ở trên. Trên dòng lệnh, để tạo một kho lưu trữ trong thư mục hiện tại, hãy sử dụng lệnh hg init<имя хранилища>... Kho lưu trữ được tạo sẽ chứa thư mục .hg.

Hình 5.3.3 Tạo một thư mục kho lưu trữ thông qua dòng lệnh

Nếu chúng tôi muốn thêm các tệp hiện có vào kho lưu trữ, chúng tôi sao chép chúng vào bên trong thư mục làm việc và sử dụng lệnh hg add để yêu cầu Mercurial bắt đầu giám sát chúng. Hãy thêm tệp vào kho lưu trữ và tạo một bản sửa đổi mới.

Hình 5.3.4 Thêm tệp vào kho lưu trữ và tạo bản sửa đổi mới

Đảm bảo rằng Mercurial nhìn thấy tệp đã lưu. Lệnh trạng thái hiển thị trạng thái của bản sao đang làm việc so với trạng thái của kho lưu trữ cục bộ. Mercurial cho thấy rằng nó nhìn thấy tệp example.txt, nhưng tệp đó vẫn chưa được kiểm soát phiên bản (ký hiệu "?" Ở bên trái của tên tệp). Để yêu cầu Mercurial phiên bản nó, chúng tôi chạy hg add. Dấu "A" xuất hiện ở bên trái của tên tệp, có nghĩa là tệp readme.txt sẽ được thêm vào kiểm soát nguồn vào lần tiếp theo một cam kết (khi tạo bản sửa đổi mới) được thực thi bởi lệnh cam kết hg.

Lần đầu tiên thực hiện lệnh cam kết hg có thể không thành công. Mercurial ghi lại tên và địa chỉ của bạn trong mỗi bản sửa đổi để bạn hoặc những người khác có thể liên hệ với tác giả của mỗi bản thay đổi. Để đặt tên người dùng, hãy thay đổi tệp hgrc nằm trong thư mục .hg bên trong thư mục làm việc. Nội dung ban đầu của tệp này sẽ giống như sau:

# Đây là tệp cấu hình Mercurial.

tên người dùng = Firstname Lastname [email được bảo vệ]

Dòng "" khai báo một phần của tệp cấu hình. Bạn có thể đọc "tên người dùng = ..." là "đặt giá trị của biến tên người dùng trong phần ui". Các phần tiếp tục cho đến khi bắt đầu các phần mới. Các dòng trống và dòng bắt đầu bằng "#" bị bỏ qua. Bạn có thể sử dụng bất kỳ văn bản nào làm giá trị tên người dùng, vì thông tin này dành cho người khác chứ không phải để giải thích cho Mercurial. Trong ví dụ trên, một quy ước chung đã được sử dụng cho điều này: kết hợp tên và địa chỉ email.

Khi chúng tôi thực hiện các thay đổi, Mercurial đưa chúng tôi vào trình soạn thảo văn bản để nhập nhận xét mô tả các sửa đổi mà chúng tôi đã thực hiện đối với tập thay đổi này. Mô tả này được gọi là thông báo thay đổi (mô tả thay đổi, mô tả sửa đổi). Đây sẽ là một mục cho người đọc về những gì chúng tôi đã làm và lý do, và sẽ được hiển thị khi chạy lệnh hg log sau khi chúng tôi hoàn thành xuất bản bản sửa đổi.

Trình soạn thảo mở bằng lệnh cam kết hg sẽ chứa một dòng trống và một số dòng bắt đầu bằng "HG:".

HG: Nhập thông báo cam kết. Các dòng bắt đầu bằng "HG:" bị xóa.

HG: Để trống thông báo để hủy bỏ cam kết.

HG: -

HG: user: người dùng

HG: nhánh "mặc định"

HG: đã thay đổi example.txt

Mercurial bỏ qua các dòng bắt đầu bằng "HG:". Anh ấy chỉ sử dụng chúng để cho chúng tôi biết những tập tin nào anh ấy sẽ viết các thay đổi. Việc chỉnh sửa hoặc xóa những dòng này sẽ không ảnh hưởng gì. Nếu bạn thay đổi ý định về việc đăng trong khi chỉnh sửa nhận xét, chỉ cần thoát khỏi trình chỉnh sửa mà không lưu tệp bạn đang chỉnh sửa. Điều này sẽ không gây ra các thay đổi đối với kho lưu trữ hoặc thư mục làm việc.

Theo mặc định, lệnh hg log chỉ in dòng đầu tiên của mô tả thay đổi. Do đó, tốt hơn là bạn nên viết chú thích sao cho dòng đầu tiên được tách biệt. Không có quy tắc cứng và nhanh cho phần còn lại của mô tả sửa đổi. Bản thân Mercurial không xử lý hoặc quan tâm đến nội dung của các thông báo thay đổi, mặc dù dự án của bạn có thể có các quy tắc chỉ định một số định dạng nhất định.

Hãy lặp lại các thao tác này bằng cách sử dụng GUI Bàn làm việc TortoiseHg. Trước khi thêm tệp vào thư mục làm việc, cửa sổ trông như thế này.

Hình 5.3.5 Thêm tệp vào thư mục làm việc

Hãy chuyển tệp vào kho lưu trữ và cập nhật cửa sổ bằng cách nhấp vào nút ở bên trái trên thanh công cụ. Hãy thêm tệp vào hệ thống điều khiển phiên bản bằng cách sử dụng lệnh tương ứng của menu ngữ cảnh (tương tự như hg add).

Hình 5.3.6 Lệnh menu ngữ cảnh

Hình 5.3.7 Thêm tệp

Sau khi tệp được thêm vào, mô tả của bản sửa đổi được viết trong cửa sổ phía trên bên phải và một bản sửa đổi mới được tạo bằng cách nhấp vào nút "Cam kết". Bản ghi về những thay đổi đã thực hiện xuất hiện trong cửa sổ phía dưới bên phải. Bạn sẽ nhận thấy rằng những thay đổi được trình bày dưới dạng đồ thị.

Hình 5.3.8 Biểu đồ thay đổi

Bạn cũng có thể cam kết các thay đổi bằng cách sử dụng lệnh Hg commit trong menu ngữ cảnh của tệp được đặt trong kho lưu trữ mà không cần khởi động Workbench.

Hình 5.3.9 Cam kết các thay đổi

Lệnh hg log hoặc hg diff ở đây tương ứng với "So sánh các bản sửa đổi tệp" (nhấp chuột phải vào tên tệp).

Hình 5.3.10 So sánh các bản sửa đổi tệp

Trong cùng một cửa sổ, bạn có thể quay lại một trong các bản sửa đổi trước đó bằng cách sử dụng lệnh "Quay lại bản sửa đổi ..." hoặc "Đảo ngược các thay đổi ..." trong cửa sổ chính. Hãy chứng minh với một ví dụ, trước đó đã thực hiện một số thay đổi đối với tệp example.txt. Dòng được đánh dấu màu đỏ là các thay đổi được đảo ngược.

Hình 5.3.11 Loại bỏ các thay đổi

5.3.5 Tạo bản sao của kho lưu trữ

Mặc dù bạn có thể sao chép kho lưu trữ như một thư mục thông thường, nhưng tốt hơn là bạn nên sử dụng lệnh tích hợp sẵn của Mercurial. Nó được gọi là bản sao hg vì nó tạo ra một bản sao giống hệt của kho lưu trữ hiện có. Một trong những lợi ích của việc sử dụng hg clone là nó cho phép các kho lưu trữ được sao chép qua mạng. Một điểm khác là nó ghi nhớ nơi chúng tôi đã nhân bản nó từ đâu.

Mỗi kho lưu trữ Mercurial đều hoàn chỉnh, khép kín và độc lập. Nó chứa bản sao của các tệp dự án và lịch sử của chúng. Kho lưu trữ nhân bản ghi nhớ nơi nó được nhân bản, nhưng không giao tiếp với kho lưu trữ đó hoặc với bất kỳ nơi nào khác, cho đến khi bạn nói với nó. Do đó, bạn có thể tự do thử nghiệm với kho lưu trữ của mình. Điều này là an toàn vì kho lưu trữ của bạn là một “hộp cát đóng”, những thay đổi đối với nó sẽ không ảnh hưởng đến bất kỳ điều gì khác ngoài chính nó.

Hãy tạo một bản sao từ xa của kho lưu trữ của chúng tôi (chúng tôi sẽ sử dụng thư mục Google Drive, bản thân nó là một dịch vụ đám mây) bằng cách thực hiện chuỗi lệnh của kho lưu trữ File \ Clone trong TortoiseHg Workbench. Kết quả được hiển thị trong hình sau.

Hình 5.3.12 Tạo bản sao lưu trữ từ xa

Mercurial cho phép bạn đẩy các thay đổi sang một kho lưu trữ khác từ kho lưu trữ mà chúng tôi hiện đang có. Thêm bản sửa đổi mới (dưới chú thích thay đổi cục bộ) vào kho lưu trữ ban đầu và thực hiện lệnh Storage \ Synchronization \ Push. Giao diện bàn làm việc cho phép bạn chỉ chọn những bản sửa đổi cần được "đẩy". Lưu ý rằng một nhánh mới đã được tạo trong kho lưu trữ từ xa cho bản sửa đổi kết quả.

Tài liệu tương tự

Các tính năng của hệ thống kiểm soát phiên bản - một chương trình được thiết kế để làm việc với các tài liệu thay đổi. Thuộc tính và cách sử dụng của nó. Thiết bị lưu trữ nội bộ. Bản sao làm việc của các tài liệu đã được phiên bản. Tập trung và phân phối tiền tệ cứng.

thêm bản trình bày 01/05/2014


Phân tích các phương pháp và công cụ kiểm soát quyền truy cập vào tệp. Vấn đề bảo mật khi làm việc với tệp, công cụ kiểm soát truy cập. Tư tưởng xây dựng giao diện, yêu cầu đối với kiến ​​trúc. Công việc của các lớp của hệ thống. Ước tính chi phí của một sản phẩm phần mềm.

luận án, bổ sung 21/12/2012


Phân tích kiến ​​trúc của Windows 8. So sánh với các phiên bản trước (Giao diện người dùng hiện đại, làm việc với tài khoản, mô hình bảo mật, trình quản lý tác vụ, lịch sử tệp, khôi phục hệ thống, Không gian lưu trữ). Các tính năng của các phiên bản Windows 8 khác nhau.

hạn giấy, được bổ sung 25/01/2016


Các giai đoạn phát triển hệ thống tự động nhận và đặt bàn trong cơ sở. Phân tích môi trường phát triển Công cụ phát triển Android. Đặc điểm chung của sơ đồ thành phần ứng dụng IOS. Xem xét hệ thống kiểm soát phiên bản máy chủ.

hạn giấy bổ sung ngày 14/05/2014


Giao diện đồ họa và phần mở rộng cho DOS. Lịch sử phát triển của hệ điều hành Microsoft Windows. Những đổi mới trong các phiên bản hiện đại của nó: giao diện người dùng, tích hợp ngôn ngữ, hệ thống bảo mật. Niên đại phát triển và kiến ​​trúc của hệ thống GNU / Linux.

tóm tắt, thêm 10/25/2010


Bộ công cụ phát triển DirectX cho Microsoft Windows, các đặc điểm của tập hợp các đối tượng tương thích với COM trong thành phần của nó. Các tính năng chính của các phiên bản, ngôn ngữ đổ bóng. Mô tả các chức năng chính được sử dụng. Mã nguồn của chương trình, ví dụ về công việc của nó.

giấy hạn bổ sung 16/02/2015


Windows với vai trò trung gian giữa người dùng và hệ điều hành, tạo điều kiện thuận lợi cho quá trình giao tiếp giữa chúng, lịch sử hình thành và phát triển của những phiên bản đầu tiên của nó. Các tính năng chức năng và sự khác biệt giữa Windows 95/98 / ME và Windows NT / 2000 / XP / Vista / 7, các giải pháp kiến ​​trúc của chúng.

bản trình bày được thêm vào ngày 23 tháng 10 năm 2013


Giảm chi phí cho công việc sửa chữa nhằm loại bỏ các khuyết tật đạt được khi sử dụng hệ thống thông tin để kiểm soát chúng. Phân tích vùng môn học và phần mềm. Tính toán tiết kiệm bằng cách tăng năng suất của người dùng.

luận án, bổ sung 19/01/2017


Khái niệm, bản chất, cấu trúc và các loại hệ điều hành. Đặc điểm của hệ điều hành Windows XP, yêu cầu cài đặt, phân tích so sánh các phiên bản, tính năng tùy chỉnh, cập nhật phiên bản, cài đặt trình điều khiển thiết bị và thêm mới.

tóm tắt, bổ sung 20/10/2009


Sự xuất hiện của các phiên bản Windows đầu tiên, giao diện đồ họa và phần mở rộng của chúng cho DOS. Họ Windows 3.x và Windows 9.x, các tính năng và chức năng chính của chúng. Sự phát triển của công nghệ Plug and Play. Những cải tiến đáng kể nhất trong các phiên bản Windows hiện đại.

Vì đội ngũ lập trình viên của chúng tôi đang phát triển một số dự án cùng một lúc nên nhu cầu về hệ thống kiểm soát phiên bản nảy sinh khá nhanh.

Đương nhiên, cuộc tìm kiếm bắt đầu với việc nghiên cứu về Habr - và dẫn đến một kết quả bất ngờ. Mặc dù thực tế là các hệ thống kiểm soát phiên bản đã xuất hiện từ năm 1986, hầu hết các hướng dẫn về cách làm việc với hiện đại hệ thống điều khiển phiên bản hóa ra chưa hoàn thiện và bị ràng buộc nhiều vào dòng lệnh.

Chúng tôi không có gì chống lại dòng lệnh nói chung, nhưng trong nhóm phát triển nhỏ của chúng tôi (4 người) không có người hâm mộ dòng lệnh :).

Tại sao chúng ta nghĩ rằng làm việc với dòng lệnh là không hiệu quả?

1. Lãng phí thời gian nhập dữ liệu. Mất nhiều thời gian để điền các lệnh hơn là nhấp bằng chuột.
2. Lãng phí thời gian học tập. Học cú pháp mới trong thời đại giao diện dễ sử dụng chắc chắn lâu hơn học giao diện người dùng đồ họa.
3. Xác suất sai sót. Dễ xảy ra sai sót khi nhập dữ liệu qua dòng lệnh (yếu tố con người chưa bị hủy bỏ).
4. Sự vi phạm nguyên tắc tự động hóa... Có lẽ đây là điểm quan trọng nhất. Máy tính được thiết kế để tăng tốc độ công việc và thay thế một người khi thực hiện các hoạt động thường ngày. Trong trường hợp của dòng lệnh, chúng tôi luôn làm việc thủ công, trên thực tế, người ta phải mỗi lần viết như nhau mã chương trình (mặc dù nguyên thủy).

1. Sẽ có hướng dẫn từng bước (các lập trình viên của chúng tôi cũng sẽ làm việc trên đó).
2. Nó sẽ hoạt động từ đầu đến cuối (nghĩa là bạn sẽ nhận được một kết quả nhỏ, nhưng đầy đủ - một hệ thống kiểm soát phiên bản phân tán đang hoạt động).
3. Sẽ hoạt động chỉ khi sử dụng giao diện đồ họa (xem ở trên để biết lý do).

Giới thiệu

Nếu bạn không phải là fan của sách hướng dẫn "For Dummies", thì bạn có thể bỏ qua việc đọc bài viết này và đi theo con đường của riêng bạn trong việc giải quyết vấn đề nâng cao VCS.

Các chương trình và dịch vụ đã sử dụng

• Mercurial là một hệ thống kiểm soát phiên bản phân tán đa nền tảng được thiết kế để hoạt động hiệu quả với kho mã rất lớn.
• TortoiseHg là giao diện đồ họa cho hệ thống điều khiển phiên bản Mercurial.
• Bitbucket là một dịch vụ web để lưu trữ dự án và hợp tác phát triển dựa trên hệ thống kiểm soát phiên bản Mercurial và Git.

Triển khai hệ thống kiểm soát phiên bản - hướng dẫn từng bước

Ứng dụng khách này sẽ cần được cài đặt trên tất cả các máy tính mà từ đó việc phát triển chung của các dự án sẽ được thực hiện.

Trong sách hướng dẫn này, tất cả các bước cấu hình và làm việc với hệ thống kiểm soát phiên bản sẽ được thực hiện bằng Phiên bản TortoiseHg: 2.10.1 dành cho Windows 64-bit với Mercurial 2.8.1.

2. Đăng ký với dịch vụ web Bitbucket: https://bitbucket.org/
Toàn bộ quá trình đăng ký được rút gọn trong việc điền thông tin liên hệ (Tên người dùng, Email, v.v.) và xác nhận địa chỉ email được chỉ định trong quá trình đăng ký bằng cách nhấp vào nút "Xác nhận địa chỉ email này" trong thư nhận được sau khi đăng ký.

Tất cả các thành viên trong nhóm phát triển của bạn cũng sẽ cần đăng ký với Bitbucket. May mắn thay cho các công ty khởi nghiệp, dịch vụ này có một tài khoản miễn phí cho phép bạn tạo kho lưu trữ riêng với 5 người dùng. Cũng có thể tăng số lượng tối đa thành viên trong nhóm tham gia phát triển theo gói miễn phí lên 8 người.

Bạn có thể tìm thấy danh sách đầy đủ các biểu thuế theo liên kết: https://bitbucket.org/plans

3. Đăng nhập vào tài khoản của bạn trong dịch vụ Bitbucket, bạn có thể ngay lập tức thay đổi ngôn ngữ giao diện của tài khoản sang tiếng Nga.

Để thực hiện việc này, ở góc trên bên phải của menu chính từ danh sách thả xuống, hãy chọn phần "Quản lý tài khoản" và trên trang mở ra, hãy chọn ngôn ngữ giao diện bạn cần từ danh sách thả xuống "Ngôn ngữ"

4. Để tạo kho lưu trữ cho dự án của bạn, bạn cần truy cập trang chính trong tài khoản của mình (https://bitbucket.org/dashboard/overview) và nhấp vào nút "Tạo kho lưu trữ đầu tiên của bạn"

5. Trên trang để tạo một kho lưu trữ mới, hãy chỉ định các cài đặt sau:

Tên - Nhập tên của kho lưu trữ mới của bạn. Tên này được sử dụng để xây dựng một liên kết truy cập đến kho lưu trữ của bạn.
Quan trọng! Tốt hơn là chỉ ra tên bằng chữ cái Latinh, nếu không liên kết đến kho lưu trữ sẽ kết thúc bằng dấu gạch ngang và có hình thức khó hiểu: https: //[email protected]/yourlogin/--------

Mô tả - Cung cấp mô tả ngắn gọn về kho lưu trữ của bạn (tùy chọn)
- Mức độ truy cập - Chọn hộp nếu bạn muốn chỉ các thành viên trong nhóm phát triển của bạn có quyền truy cập vào kho lưu trữ của bạn (kho lưu trữ riêng tư).
- Forks - Chọn "Chỉ cho phép fork riêng"
- Loại kho lưu trữ - Chọn "Mercurial"
- Quản lý dự án - Kiểm tra "Task Tracker" và "Wiki"
- Ngôn ngữ - Chọn ngôn ngữ phát triển mà dự án của bạn được viết. Trong trường hợp của tôi, đây là PHP.

Sau khi hoàn thành việc chỉ định tất cả các cài đặt, trang sẽ trông giống như sau:

Kiểm tra lại dữ liệu đã nhập và nếu mọi thứ được nhập chính xác, hãy nhấp vào nút "Tạo kho lưu trữ".

6. Sau khi tạo một kho mới, bạn sẽ được đưa đến trang "Bắt đầu":

7. Trên máy tính của bạn, tạo một thư mục trống nơi các tệp dự án của bạn được kết nối với hệ thống kiểm soát phiên bản Mercurial sẽ được lưu trữ trong tương lai.

Quan trọng! Thư mục phải trống. Ví dụ, để kết nối một thư mục với một dự án hiện có (một đống mã chương trình), tôi phải tạm thời di chuyển tất cả các tệp sang một thư mục khác (tạo một bản sao lưu - backup). Sau đó, chúng tôi sẽ trả lại tất cả các tệp về vị trí của chúng, nhưng bây giờ chúng tôi cần phải làm trống hoàn toàn thư mục để kết nối.

8. Trong cửa sổ mở ra, bạn cần chỉ định trong trường "Nguồn" một liên kết để kết nối với kho lưu trữ bạn đã tạo từ trang 6

Và nhấn nút "Sao chép".

9. Hệ thống sẽ yêu cầu bạn nhập mật khẩu từ tài khoản của bạn trong dịch vụ Bitbucket, hãy nhập mật khẩu đó vào.

10. Nếu mọi thứ đã được thực hiện mà không sai lệch so với hướng dẫn này, thì một thư mục mới ".hg" với các tệp dịch vụ của kho lưu trữ đã tạo sẽ xuất hiện trong thư mục.

11. Bây giờ bạn có thể kiểm tra an toàn các tệp (mã chương trình) của dự án của bạn vào thư mục dành để lưu trữ các tệp dự án được kết nối với hệ thống kiểm soát phiên bản Mercurial.

Quan trọng! Không chạm vào thư mục dịch vụ ".hg". Nó cần thiết để VCS hoạt động.

12. Nhấp lại bằng nút chuột phải vào thư mục dự án của chúng tôi và từ trình đơn thả xuống, hãy chọn mục "Cam kết Hg ..."

13. Bạn sẽ thấy một hộp thoại được thiết kế để cam kết tất cả các thay đổi được thực hiện đối với dự án của bạn (trong trường hợp này, chúng tôi đã thêm mã chương trình của mình vào thư mục dự án trống ban đầu).

Bạn cần chọn tất cả các tệp đã thay đổi (đã thêm), cho biết nhận xét (ví dụ: Phiên bản 1.00) cho thay đổi và nhấp vào nút "Cam kết".

Hệ thống sẽ yêu cầu bạn xác nhận việc bổ sung, nhấn “Thêm”.

14. Nếu mọi thứ được thực hiện chính xác, hệ thống sẽ ghi lại những thay đổi được thực hiện và bạn sẽ thấy thông báo như sau:

Trên thực tế, trong tương lai, khi bạn đang phát triển, sau khi hoàn thành một đoạn mã nhỏ, bạn sẽ thực hiện hành động từ điều khoản 12 (nhấn "Hg commit ...") để cam kết thay đổi được thực hiện đối với hệ thống điều khiển phiên bản. Điều này sẽ cung cấp cho bạn khả năng khôi phục hệ thống về cam kết trước đó tại bất kỳ thời điểm nào.

Xem xét những điều trên, trên thực tế, bạn nên viết bình luận chi tiết hơn "Phiên bản 1.00" cho mỗi cam kết.

16. Trong cửa sổ mở ra, bạn có thể xem toàn bộ lịch sử của các thay đổi đã lưu (cam kết) trong mã, bạn có thể khôi phục về cam kết mong muốn và cũng có thể gửi các thay đổi đến kho lưu trữ mà bạn đã tạo trước đó.

Để thực hiện việc này, trong bảng điều khiển, hãy chọn nút Đẩy các Thay đổi Đến.

Sau đó, bạn sẽ thấy các hộp thoại yêu cầu bạn xác nhận "lần đẩy" và yêu cầu bạn cung cấp mật khẩu cho tài khoản Bitbucket của mình. Đồng ý và cung cấp mật khẩu.

Hệ thống sẽ bắt đầu sao chép các tệp vào kho lưu trữ của bạn trên máy chủ Bitbucket. Hãy dành thời gian của bạn và đợi quá trình hoàn tất.

17. Một bản sao của các tệp dự án của bạn hiện được lưu trữ trong kho lưu trữ của bạn trên các máy chủ Bitbucket. Trong tài khoản Bitbucket của mình, bạn có thể xem toàn bộ lịch sử dự án của mình.

Kết quả trung gian của kết nối hệ thống kiểm soát phiên bản (VCS)

Quá trình kết nối máy tính thứ hai của bạn là sao chép các tệp từ kho lưu trữ sang máy tính thứ hai. Bạn cần thực hiện các bước 1 - Cài đặt TortoiseHg và 7 - Nhập tệp kho lưu trữ để sao chép tệp vào máy tính làm việc thứ hai, thứ ba và tiếp theo của bạn.

Kết nối nhân viên với kho lưu trữ của bạn.

Do đó, bây giờ chúng ta hãy kết nối một lập trình viên khác vào dự án của chúng ta (mời một người tham gia) và thiết lập một nơi làm việc cho anh ta.

Kết nối nhân viên với kho lưu trữ của chúng tôi

Làm thế nào để đăng ký trên dịch vụ và cài đặt TortoiseHg, tôi đã nói với bạn một chút trước đó trong hướng dẫn này. Vì vậy, quá trình này sẽ không gây ra bất kỳ khó khăn nào cho bạn và đồng nghiệp của bạn.

19. Đăng nhập vào tài khoản Bitbucket của bạn:

Nhấp vào nút Gửi lời mời nằm trong phần Mời cộng tác viên vào Kho lưu trữ này.

20. Hệ thống sẽ hiển thị hộp thoại yêu cầu bạn chỉ định địa chỉ email của người dùng mà bạn muốn cấp quyền truy cập vào kho lưu trữ. Ngoài ra, bạn sẽ cần chỉ định các quyền truy cập ("đọc" hoặc "viết"). Tại vì trong hướng dẫn này, chúng tôi chỉ ra cách kết nối một nhà phát triển khác với kho lưu trữ, sau đó chỉ định "bản ghi".

Sau khi bạn đã nhập email của nhân viên và chỉ định quyền truy cập, hãy nhấp vào nút "Chia sẻ".

21. Người tham gia được mời sẽ nhận được một email có liên kết đến lời mời. Anh ấy sẽ cần phải theo liên kết này và chấp nhận lời mời để truy cập vào kho lưu trữ của bạn.

Một lần nữa, tất cả các thành viên trong kho lưu trữ của bạn phải được đăng ký với dịch vụ Bitbucket.

22. Sau khi lời mời được chấp nhận, người tham gia mới sẽ thấy kho này trong tài khoản của mình và liên kết của anh ta để truy cập nó bằng TortoiseHg.

Tất cả các thay đổi do bạn và trợ lý của bạn thực hiện sẽ được lưu trong kho lưu trữ của bạn. Bạn sẽ có thể thấy những gì đã được thay đổi và khi nào, và nếu bạn muốn, hãy khôi phục dự án của bạn về phiên bản yêu cầu bất kỳ lúc nào.

Tôi nghĩ rằng bài viết giới thiệu này về việc triển khai kiểm soát phiên bản mà không sử dụng dòng lệnh có thể kết thúc ở đó. Vượt qua các bước được mô tả ở trên sẽ cho phép bạn triển khai VCS chính thức trong dự án của mình, tức là sau khi đi qua tất cả các bước, bạn sẽ nhận được, mặc dù không lớn, nhưng là một kết quả hoàn chỉnh.

Chúng tôi đã sử dụng cách tiếp cận này để phát triển dự án.

Đối với mọi hoạt động tôi đã đo, Mercurial hoạt động tốt hơn Subversion. Tốc độ nhanh hơn 2-6 lần khi nói đến địa phương Kho Subversion 1.4.3 (phương pháp truy cập nhanh nhất). Trong một trường hợp sử dụng thực tế hơn, một kho lưu trữ trực tuyến, Subversion ở một vị trí tồi tệ hơn nhiều. Bởi vì các lệnh Subversion phải giao tiếp với máy chủ và Subversion thiếu các phương tiện sao chép hữu ích, hiệu suất máy chủ và băng thông mạng trở thành tắc nghẽn ngay cả đối với các dự án nhỏ.

Ngoài ra, Subversion yêu cầu thêm dung lượng đĩa để tránh các yêu cầu mạng khi thực hiện một số thao tác: tìm các tệp đã sửa đổi (trạng thái) và hiển thị các thay đổi (khác biệt). Kết quả là một bản sao làm việc Subversion có cùng kích thước (nếu không lớn hơn) với kho lưu trữ Mercurial và thư mục làm việc kết hợp, mặc dù kho lưu trữ Mercurial chứa toàn bộ lịch sử của dự án.

Subversion có hỗ trợ rộng rãi cho các bộ công cụ của bên thứ ba. Về mặt này, Mercurial hiện đang bị tụt lại phía sau. Mặc dù khoảng cách đang được thu hẹp, một số tiện ích GUI cho Mercurial hoạt động tốt hơn các đối tác Subversion của chúng. Giống như Mercurial, Subversion có một hướng dẫn sử dụng tuyệt vời.

Bởi vì Subversion không lưu giữ lịch sử thay đổi trên máy khách, nó rất thích hợp để quản lý các dự án có chứa một số lượng lớn các tệp nhị phân. Nếu bạn thực hiện 50 thay đổi đối với tệp mười megabyte không thể nén, dung lượng đĩa được Subversion sử dụng sẽ không thay đổi. Không gian được sử dụng bởi bất kỳ hệ thống kiểm soát phiên bản phân tán nào sẽ phát triển nhanh chóng tương ứng với số lượng thay đổi, bởi vì sự khác biệt giữa các phiên bản là lớn.

Ngoài ra, thường rất khó, nếu không muốn nói là không thể, để hợp nhất các phiên bản khác nhau của một nhị phân. Subversion cho phép người dùng khóa một tệp, điều này cung cấp cho người dùng độc quyền để sửa đổi nó tạm thời. Đây có thể là một lợi ích đáng kể cho một dự án sử dụng rộng rãi các mã nhị phân.

Mercurial có thể nhập lịch sử thay đổi từ kho Subversion. Quá trình ngược lại cũng có thể xảy ra. Điều này giúp bạn có thể kiểm tra vùng nước và sử dụng cả Mercurial và Subversion cùng một lúc trước khi quyết định có nên di cư hay không. Chuyển đổi một câu chuyện là một quá trình từng bước, vì vậy bạn có thể thực hiện chuyển đổi ban đầu và sau đó thực hiện các thay đổi mới.

1.6.2. Git

Git là một hệ thống kiểm soát phiên bản phân tán được thiết kế để quản lý mã nguồn của nhân Linux. Như với Mercurial, thiết kế ban đầu của hệ thống bị ảnh hưởng bởi Monotone.

Git cung cấp một danh sách lớn các lệnh, với 139 lệnh duy nhất trong phiên bản 1.5.0. Nó có tiếng là khó học. So với Git, Mercurial nhấn mạnh sự đơn giản.

Khi nói đến hiệu suất, Git rất nhanh. Trong một số trường hợp, nó nhanh hơn Mercurial (ít nhất là trên Linux), và trong những trường hợp khác, nó nhanh hơn Mercurial. Tuy nhiên, trên Windows, cả hiệu suất và mức độ hỗ trợ chung tại thời điểm viết bài này đều kém hơn nhiều so với Git so với Mercurial.

Trong khi kho lưu trữ Mercurial không yêu cầu hoạt động bảo trì, kho lưu trữ Git yêu cầu hướng dẫn sử dụng thường xuyên "Đóng gói lại" siêu dữ liệu riêng. Nếu điều này không được thực hiện, hiệu suất bắt đầu suy giảm, cùng với sự gia tăng dung lượng ổ đĩa được sử dụng. Một mảng đĩa của máy chủ có chứa một số kho lưu trữ Git, theo đó quy tắc nghiêm ngặt về thường xuyên "Đóng gói lại", sớm hay muộn cũng bị tắc nghẽn về dung lượng, với kết quả là quá trình sao lưu hàng ngày có thể dễ dàng mất hơn 24 giờ. Vừa rồi "Đóng gói" kho lưu trữ Git chiếm dung lượng ít hơn một chút so với kho lưu trữ Mercurial, nhưng kho lưu trữ chưa được đóng gói sẽ lớn hơn một vài bậc.

Phần lõi của Git được viết bằng C. Nhiều lệnh Git được triển khai dưới dạng tập lệnh Shell hoặc tập lệnh Perl, và chất lượng của các tập lệnh này rất khác nhau. Tôi đã thấy một số cài đặt trong đó các tập lệnh tiếp tục thực thi một cách ngu ngốc, bất chấp sự hiện diện của các lỗi nghiêm trọng.

Mercurial cung cấp khả năng nhập lịch sử phiên bản từ kho lưu trữ Git.

1.6.3. CVS

CVS có lẽ là hệ thống kiểm soát phiên bản được sử dụng rộng rãi nhất trên thế giới. Nhờ vào tuổi đời đáng kính của nó, cũng như sự hỗn loạn ngự trị bên trong, nó đã được duy trì rất kém trong nhiều năm.

CVS dựa trên kiến ​​trúc tập trung, khách hàng-máy chủ. Nó không nhóm các thay đổi tệp thành các cam kết nguyên tử, do đó cho phép mọi người dễ dàng "Phá vỡ công trình": Một người có thể cam kết thành công một số thay đổi đối với kho lưu trữ, sau đó bị chặn vì cần thực hiện hợp nhất. Điều này sẽ dẫn đến tình huống những người tham gia còn lại sẽ chỉ thấy một phần của những thay đổi mà lẽ ra họ phải thấy. Tính năng này cũng ảnh hưởng đến cách bạn sẽ làm việc với lịch sử thay đổi. Nếu bạn muốn nhận tất cả các thay đổi mà một thành viên trong nhóm đã thực hiện để giải quyết một vấn đề cụ thể, bạn cần nghiên cứu thủ công các mô tả và ngày thực hiện thay đổi cho từng tệp bị ảnh hưởng (nếu bạn biết tệp nào bị ảnh hưởng).

CVS hoạt động với một khái niệm khá phức tạp về các nhánh và thẻ, mà tôi thậm chí sẽ không mô tả trong cuốn sách này. Nó không hỗ trợ đổi tên cả tệp và thư mục, vì vậy kho lưu trữ có thể bị hỏng khá dễ dàng. Vì thực tế không có cơ chế kiểm soát tính toàn vẹn nội bộ, thậm chí không thể nói chắc chắn liệu một kho lưu trữ có bị hỏng hay không, và nếu có thì làm thế nào. Vì vậy, tôi sẽ không giới thiệu CVS cho bất kỳ dự án hiện có hoặc mới nào.

Mercurial cung cấp khả năng nhập lịch sử phiên bản CVS. Tuy nhiên, có một số cạm bẫy ở đây mà bất kỳ công cụ nhập CVS nào khác cũng sẽ gặp phải. Việc thiếu các thay đổi nguyên tử và phiên bản của dữ liệu phân cấp của hệ thống tệp khiến không thể tái tạo lại hoàn toàn lịch sử của các thay đổi CVS, do đó, trong một số trường hợp, các giả định được sử dụng và các tên thường không được hiển thị. Vì nhiều tác vụ quản trị CVS phải được thực hiện theo cách thủ công, điều này làm tăng nguy cơ xảy ra lỗi, nên thông thường trình nhập CVS sẽ trả lại nhiều lỗi toàn vẹn kho lưu trữ (ngày sửa đổi hoàn toàn không thực tế và các tệp vẫn bị khóa trong thập kỷ qua chỉ là một vài những vấn đề ít thú vị nhất mà tôi có thể nhớ được từ kinh nghiệm của chính mình).

1.8. Sơ lược về lịch sử kiểm soát phiên bản

Nổi tiếng nhất trong số các tiện ích kiểm soát phiên bản cũ là SCCS (Hệ thống kiểm soát mã nguồn), được viết bởi Marc Rochkind của Bell Labs vào đầu những năm 70. SCCS hoạt động trên các tệp riêng biệt và yêu cầu mỗi người làm việc trong một dự án phải có quyền truy cập vào một không gian làm việc chung duy nhất. Mỗi lần chỉ có một người có thể chỉnh sửa một tệp; xung đột truy cập tệp đã được giải quyết bằng khóa. Một tình huống phổ biến là quên mở khóa sau khi chỉnh sửa, điều này khiến người khác không thể truy cập tệp mà không cần sự trợ giúp của quản trị viên.

Walter Tichy đã phát triển một giải pháp thay thế miễn phí cho SCCS vào đầu những năm 1980; ông đặt tên chương trình của mình là RCS (Hệ thống kiểm soát sửa đổi). Giống như SCCS, RCS yêu cầu các nhà phát triển phải làm việc trong một không gian làm việc chung duy nhất và khóa các tệp để ngăn những người khác nhau sửa đổi tệp cùng một lúc.

Sau đó, vào những năm 1980, Dick Grune sử dụng RCS làm nền tảng cho một tập hợp các tập lệnh shell, ban đầu được gọi là cmt và sau đó được đổi tên thành CVS (Hệ thống các phiên bản đồng thời). Một sự đổi mới lớn trong CVS là nó cho phép các nhà phát triển làm việc đồng thời và ở một mức độ nào đó, độc lập trong không gian làm việc cá nhân của họ. Chính những khoảng trống này đã ngăn cản các nhà phát triển liên tục dẫm gót nhau, điều thường thấy ở SCCS và RCS. Mỗi nhà phát triển có một bản sao của mỗi tệp dự án, các nhà phát triển có thể sửa đổi các bản sao của họ một cách độc lập. Họ chỉ phải hợp nhất các chỉnh sửa của riêng mình trước khi gửi các thay đổi đến kho lưu trữ trung tâm.

Brian Berliner đã lấy các kịch bản gốc của Grün và viết lại chúng bằng C, phát hành mã vào năm 1989 mà sau này sẽ phát triển thành phiên bản CVS hiện đại. CVS sau đó có được khả năng làm việc qua mạng, đạt được kiến ​​trúc máy khách-máy chủ. Kiến trúc CVS ​​là tập trung: chỉ máy chủ mới có bản sao lịch sử dự án. Các bản sao làm việc của máy khách chỉ chứa các phiên bản tệp mới nhất và siêu dữ liệu nhỏ để định vị máy chủ. CVS đã đạt được thành công chưa từng có: nó có lẽ là hệ thống điều khiển phiên bản được sử dụng rộng rãi nhất trên thế giới.

Vào đầu những năm 1990, Sun Microsystems đã phát triển một hệ thống kiểm soát phiên bản phân tán sớm được gọi là TeamWare. Mỗi bản sao TeamWare làm việc chứa một bản sao hoàn chỉnh của lịch sử sửa đổi dự án. Khái niệm kho lưu trữ trung tâm trong TeamWare đã không có. (Tương tự như CVS, sử dụng RCS để lưu trữ lịch sử, TeamWare sử dụng SCCS.)

Khi những năm 1990 tiến triển, nhận thức về một số vấn đề CVS đã tăng lên. Hệ thống ghi lại các thay đổi đồng thời cho nhiều tệp một cách riêng biệt, thay vì nhóm chúng thành một hoạt động nguyên tử về mặt logic. Cách bạn quản lý hệ thống phân cấp tệp của mình không tốt lắm; rất dễ làm xáo trộn kho lưu trữ của bạn bằng cách đổi tên tệp và thư mục. Hơn nữa, mã nguồn CVS không dễ hiểu và dễ bảo trì, khiến nó gần như không thể cưỡng lại được. "Ngưỡng chịu đau" các bản sửa lỗi cho các vấn đề kiến ​​trúc này.

Năm 2001, Jim Blandy và Karl Fogel - hai nhà phát triển trước đây đã làm việc trên CVS - bắt đầu một dự án thay thế nó bằng một công cụ có kiến ​​trúc tốt hơn và mã sạch hơn. Kết quả - Subversion - đã không rời khỏi mô hình máy khách / máy chủ tập trung của CVS, nhưng đã thêm các cam kết nguyên tử cho nhiều tệp, quản lý không gian tên tốt hơn và các tính năng khác khiến Subversion trở thành một công cụ tốt hơn để làm việc với CVS. Kể từ khi phát hành phiên bản đầu tiên, Subversion đã trở nên phổ biến nhanh chóng.

Đồng thời, Graydon Hoare bắt đầu làm việc trên một hệ thống điều khiển phiên bản đầy tham vọng có tên là Monotone. Hệ thống này không chỉ loại bỏ nhiều vấn đề nội bộ CVS và có kiến ​​trúc phân tán, mà còn vượt xa một số hệ thống kiểm soát phiên bản trước (và sau đó) trong một số cải tiến của nó. Monotone sử dụng các hàm băm mật mã làm số nhận dạng và có sự hiểu biết vốn có về “ Lòng tin " mã từ nhiều nguồn khác nhau.

Cuộc đời của Mercurial bắt đầu vào năm 2005. Trong khi một số khía cạnh trong kiến ​​trúc của nó bị ảnh hưởng bởi Monotone, Mercurial tập trung vào tính dễ sử dụng, hiệu suất cao và khả năng mở rộng cho các dự án rất lớn.

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ó cần phát triển một giải pháp công nghệ phức tạp không? 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ó rất nhiều người đang làm việc trên đó. Các lập trình viên, quản lý, copywriter đều có thể tự làm việc với nhau, không ảnh hưởng lẫn nhau và không gây ra thiệt hại không thể sửa chữa được.

Nếu bạn chưa quen 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 lựa chọn dễ dàng hơn.

Đâ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ó bất kỳ kinh nghiệm lập trình nào, hãy nhớ kiểm tra với bộ phận phát triển của bạn trước khi đưa ra quyết định.

Hệ thống kiểm soát phiên bản, bao gồm 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 chung 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. Thật thuận tiện để cập nhật tệp ở đây, 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 nàohệ thống kiểm soát phiên bảntốt nhất, chúng khác nhau rất nhiều, và điều này dẫn đến các cuộc tranh luận sôi nổi giữa các lập trình viên. Nhặt và họchệ 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 một giải pháp thường mang tính chủ quan. Ví dụ: sở thích cá nhân của lập trình viên, chẳng hạn như 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ã đến từ và nơi nó được trả về với những thay đổi được thực hiện. Hoặc nó là một bản sao kho lưu trữ cục bộ được cập nhật bởi các đồng nghiệp: một mạng phi tập trung hơn được sử dụng để đồng bộ hóa, trao đổi các bản vá (tập thay đổi) và để duy trì mã hiện tại.

Nó cũng đáng xem xét hiệu suất, chức năng và ngưỡng để nhập / làm chủ mộthệ thống điều khiển... Hãy 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 các 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á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 áp dụng theo các điều khoảnTrong Thỏa thuận Giấy phép Mở GNU và cho phép bạn tải phiên bản yêu cầu của dự án từ máy chủ - “Thủ tục thanh toán " và sau đó chuyển tiếp nó trở lại máy chủ, "đăng ký "(quay lại),như đã được sửa đổi.

CVS ban đầu được tạo ra để tránh xung đột phiên bản. Tất cả những người đóng góp chỉ được cung cấp phiên bản mã mới nhất để làm việc cùng. Đây 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 trên các dự án với các nhánh mã. Điều này dẫn đến một số biến thể sản phẩm với các đặc tính khác nhau, có thể được kết hợp sau này.

Máy chủ CVS thường chạy trên 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", được kiểm tra theo 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 ngày nay các tính năng mới hiếm khi được thêm vào.

Đồng thời, CVSNT, là một phiên bản đã được phát hành thành một dự án riêng biệt. CVS cho 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 rất tốn kém, vì điều 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ã nguồn mở. Sự khác biệt duy nhất là nó được phân phối theo giấy phép Apache chứ không phải theoThỏa thuận Giấy phép Mở GNU.

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

Nhiều nhà phát triển đã chuyển sangSVN, vì công nghệ mới đã kế thừa các tính năng tốt hơn 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 điều này. Đó là, đối với các dự án lớn hơn với phân nhánh mã và nhiều lĩnh vực phát triển.

Nhược điểm của SVN là tốc độ tương đối chậm 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 hơn 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 cách 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 í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:

• Sai lầm 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 của nhân Linux và có 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à quyết định đượ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ó chạy nhanh nhất.

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

Mã 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 để giải quyết vấn đề này và một số nhà phát triển tin rằng hiệu suất 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òn có nhiều công cụ để điều hướng 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 chi nhánh giá rẻ
• 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 dành cho những người đã sử dụng SVN trước đây
• Hỗ trợ Windows hạn chế (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 họ chọn Git, Mercurial được sử dụng ít hơn. Tuy nhiên, nhiều nhà phát triển hàng đầu làm việc với hệ thống cụ thể 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ảntrong đó 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.

Vì hệ thống được phân cấp và viết bằng Python nên 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, trong khi là một hệ thống phân tán, và do sự tương đồng này, nó có ngưỡng đầu vào 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 nhanh chóng làm quen với sự khác biệt.

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, không 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ỏ khả năng của Git.

Thuận lợi:

• Dễ học hơn so với Git
• 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ó cách nào để hợp nhất hai nhánh cha
• Sử dụng plugin, không phải tập lệnh
• Ít chỗ cho các giải pháp tùy chỉnh

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

Hầu hết thời gian các nhà phát triển sử dụng CVS vì nó quen thuộc hơn với họ. 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ọ 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ủa một "công nghệ trưởng thành", có nghĩa là nó sẽ không còn có các tính năng và giải pháp hoàn toàn mới. Sức ì của thói quen mất đi khi mọi người chuyển sang SVN. Điều này có nghĩa là 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ề mức độ phổ biến, thì bạn có nhiều khả năng gặp phải CVS hoặc SVN hơn là với Git hoặc Mercurial. Do đó, kiến ​​thức về một công nghệ máy chủ, mặc dù không cần thiết, nhưng sẽ giúp bạn chuyển đổi dễ dàng hơn.

Do việc sử dụng rộng rãi và hoàn thiện 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 đối thủ. Đối với các dự án được tạo để 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 hạn chế đáng kể của Git là đôi khi rất khó để giải thích các sắc thái của công việc nàyhệ thống điều khiểnvà nó 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ự thuận tiện của việc quản lý các nhánh mã sẽ hoàn toàn trả hết thời gian đã bỏ ra.

Đối với những người ghét Git (và hệ thống này có đối thủ trong cộng đồng 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à cũng có tài liệu tốt.

Phiên bản Git tương thích với Windows cũng đang tiến gần hơn với phiên bản Linux về hiệu suất, vì vậy hệ thống này có thể phù hợp với 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 được thực hiện bởi một nhóm nhỏ lập trình viên, thì SVN là lựa chọn của bạn. Nó đáng tin cậy và được thiết kế 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ở, trong đó một số lập trình viên sẽ làm việc vào những thời điểm khác nhau hoặc nếu bạn có ý định liên tục cập nhật mã, hãy 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 luôn sẵn sàng phục vụ 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 để xây dựng phần mềm, trang web và thậm chí cả hệ điều hành mà bạn sử dụng và quen thuộc.

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 - đả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 từng 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 giao diện đồ họagiú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, 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ả những người có thời gian dùng thử miễn phí. Bạn có thể tạo kho lưu trữ đầu tiên của mình (nơi làm việc với các tệp mã) trên cơ sở chúng miễn phí. Một số dịch vụ này là:

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"

Máy khách SVN và GIT đồ họa

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

—chương trình thuận tiện để làm việc vớihệ thống kiểm soát phiên bảntrên Microsoft Windows và được cho là ứng dụng Apache Subversion tốt nhất hiện có. 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 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 Git đồ họa (Nguồn mở được 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

"Kiểm tra" kho lưu trữ ("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. Bạ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 trả phí)

1. Chuyển đế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 máy khách. 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 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ề chúng - đây là một ý tưởng khá hay, vì trong tương lai bạn sẽ biết chính xác những gì bạn đã 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 khác trong dự án.

Khách hàng của bạn cũng có thể 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 điều khiển phiên bản phân tán Git. Phần 1

Giới thiệu

Chuỗi nội dung:

1. Giới thiệu

Trong quá trình làm việc trên một dự án, những người tham gia dự án thường gặp phải các vấn đề về đồng bộ hóa và duy trì lịch sử của tệp, điều này có thể được giải quyết bằng hệ thống kiểm soát phiên bản (VCS). Mục đích của loạt bài viết này là giới thiệu cho người đọc các nguyên tắc của VCS và tìm hiểu kỹ hơn về một trong số chúng, đó là Git. Tại sao Git? Gần đây, hệ thống này đã trở nên phổ biến và tầm quan trọng của nó đối với phần mềm miễn phí (và đối với dự án GNU / Linux nói riêng) khó có thể được đánh giá quá cao.

Chúng tôi sẽ tuần tự, nói chung, phân tích các đặc điểm của hệ thống điều khiển, nói về kiến ​​trúc của chúng và các tính năng chính của ứng dụng được đề cập. Ngoài ra, chúng tôi sẽ xem xét các giao diện hiện có để làm việc với Git.

Tác giả cố tình lược bỏ thuật ngữ chức năng, phím và các phần tinh tế khác để trình bày rõ ràng, rõ ràng và khái quát bức tranh cho các bạn xem. Bài báo này giả định rằng người đọc đã quen thuộc với hệ điều hành (OS) giống Unix, đồng thời cũng có kiến ​​thức cơ bản về thuật toán và khoa học máy tính nói chung.

Trong các tài liệu sau đây, chúng ta sẽ đi sâu vào cấu trúc và triết lý của Git, các chi tiết cụ thể của hệ thống này và sự tinh tế trong công việc thực tế với nó. Chu kỳ sẽ kết thúc bằng một bài viết về cách Git tương tác với các VCS khác (chẳng hạn như Subversion, CVS, Mercurial, v.v.).

2. Git là ...

Git là một hệ thống kiểm soát phiên bản tệp phân tán. Mã chương trình được viết chủ yếu bằng ngôn ngữ C. Dự án được Linus Torvalds tạo ra vào năm 2005 để quản lý sự phát triển của nhân Linux và giống như GNU / Linux, là phần mềm tự do (phần mềm), trong khi việc sử dụng của bên thứ ba được cấp phép theo GNU GPL phiên bản 2. Tóm lại, thỏa thuận này có thể được mô tả như một phần mềm mã tự do, phải được phát triển một cách công khai, tức là bất kỳ lập trình viên nào cũng có quyền tiếp tục cải thiện dự án ở bất kỳ giai đoạn nào. Trong thời gian tồn tại ngắn ngủi, hệ thống này đã được giới thiệu bởi nhiều nhà phát triển hàng đầu. Git được sử dụng trong các dự án được cộng đồng Linux biết đến như Gnome, GNU Core Utilities, VLC, Cairo, Perl, Chromium, Wine.

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

Hệ thống kiểm soát phiên bản là phần mềm được thiết kế để tự động hóa lịch sử của tệp (hoặc nhóm tệp), theo dõi các thay đổi, đồng bộ hóa dữ liệu và tổ chức kho dự án an toàn. Nói tóm lại, mục đích chính của hệ thống kiểm soát phiên bản là làm cho việc thay đổi thông tin trở nên dễ dàng hơn. Hãy xem cái nhìn chung của sự phát triển bằng cách sử dụng một ví dụ.

Giả sử có một dự án mà bạn đang phát triển, một số bộ phận gồm các lập trình viên và bạn là người điều phối (hoặc lãnh đạo). Liên quan đến hệ thống điều khiển, cho dù đó là máy chủ (nếu chúng ta đang nói về hệ thống tập trung) hay máy cục bộ, bất kỳ nhà phát triển dự án nào cũng chỉ bị giới hạn bởi quyền truy cập để thay đổi và / hoặc đọc các phiên bản của tệp của kho lưu trữ này . Bất kỳ lúc nào, bạn có thể khôi phục dữ liệu về phiên bản bạn cần. Bạn, với tư cách là người điều phối, có thể hạn chế quyền truy cập đối với một số người dùng nhất định để cập nhật phiên bản tệp. VCS cũng cung cấp một giao diện để quan sát và tìm kiếm các phiên bản tệp. Ví dụ: bạn có thể tạo một truy vấn: “Đoạn mã này được thay đổi ở đâu và khi nào?”.

Hệ thống giả định lưu trữ dữ liệu an toàn, tức là bất kỳ khối nào được lưu trữ trong nó đều có nhiều bản sao. Vì vậy, ví dụ, nếu một tập tin bị hỏng, bạn có thể nhanh chóng thay thế nó bằng một bản sao. Để giảm số lượng dữ liệu dự án, nén delta thường được sử dụng - một kiểu lưu trữ trong đó không lưu trữ bản thân các phiên bản tệp mà chỉ thay đổi giữa các lần sửa đổi liên tiếp.

4. Sự khác biệt giữa các hệ thống điều khiển phiên bản phân tán

Hệ thống kiểm soát phiên bản phân tán là VCS, mô hình chính của nó là bản địa hóa dữ liệu của từng nhà phát triển dự án. Nói cách khác, nếu trong một VCS tập trung, tất cả các hành động, theo cách này hay cách khác, phụ thuộc vào đối tượng trung tâm (máy chủ), thì trong một VCS phân tán, mỗi nhà phát triển giữ nhánh phiên bản của toàn bộ dự án của riêng mình. Sự tiện lợi của một hệ thống như vậy là mỗi nhà phát triển có cơ hội làm việc độc lập, thỉnh thoảng trao đổi các phiên bản trung gian của tệp với những người tham gia dự án khác. Hãy xem xét tính năng này, tiếp tục ví dụ trước.

Mỗi nhà phát triển trên máy có kho lưu trữ cục bộ của riêng mình - nơi lưu trữ các phiên bản tệp. Công việc với dữ liệu dự án được thực hiện trên kho lưu trữ cục bộ của bạn và vì điều này, bạn không cần phải giữ liên lạc với phần còn lại (ngay cả những dữ liệu chính) của các nhánh phát triển. Giao tiếp với các kho khác chỉ cần thiết khi thay đổi / đọc các phiên bản của tệp từ các nhánh khác. Đồng thời, mỗi người tham gia dự án phân quyền đọc và ghi cho kho lưu trữ của riêng họ. Do đó, tất cả các nhánh trong VCS được phân phối đều bình đẳng với nhau, và nhánh chính được phân bổ bởi người điều phối. Sự khác biệt duy nhất giữa nhánh chính là các nhà phát triển sẽ bình đẳng về mặt tinh thần với nó.

5. Các tính năng và đặc điểm chính của Git

Điều đáng nói là hệ thống này, nếu nó không gây được tiếng vang lớn, thì nó đã khuấy động cộng đồng VCS một chút bằng sự mới lạ của nó và đưa ra một cách phát triển mới. Git cung cấp các công cụ linh hoạt và dễ sử dụng để lưu giữ lịch sử dự án.

Điểm đặc biệt của Git là công việc trên các phiên bản của dự án có thể không diễn ra theo thứ tự thời gian. Quá trình phát triển có thể diễn ra theo nhiều nhánh song song, có thể được hợp nhất và tách ra bất cứ lúc nào trong quá trình thiết kế.

Git là một hệ thống khá linh hoạt và phạm vi của nó không chỉ giới hạn trong phạm vi phát triển. Ví dụ, các nhà báo, tác giả của tài liệu kỹ thuật, quản trị viên, giáo sư đại học có thể sử dụng nó trong hoạt động của họ. Các nhiệm vụ này bao gồm kiểm soát phiên bản của bất kỳ tài liệu, báo cáo, bài tập về nhà nào.

Hãy nêu những điểm khác biệt chính giữa Git và các VCS phân tán và tập trung khác.

Kiến trúc Git

SHA1 (Thuật toán băm an toàn 1) là một thuật toán băm mật mã. Mỗi tệp trong dự án Git của bạn bao gồm một tên và một nội dung. Tên là 20 byte dữ liệu đầu tiên, nó được viết rõ ràng bằng bốn mươi ký tự trong ký hiệu thập lục phân. Khóa này có được bằng cách băm nội dung của tệp. Vì vậy, ví dụ, so sánh hai tên, chúng ta có thể nói với xác suất gần một trăm phần trăm rằng chúng có cùng nội dung. Ngoài ra, tên của các đối tượng giống nhau trong các nhánh khác nhau (kho lưu trữ) cũng giống nhau, điều này cho phép bạn thao tác trực tiếp trên dữ liệu. Một bổ sung tốt cho những điều trên cũng là thực tế rằng hàm băm cho phép bạn xác định chính xác thiệt hại cho các tệp. Ví dụ, bằng cách so sánh hàm băm của nội dung với tên, chúng ta có thể biết khá chính xác liệu dữ liệu có bị hỏng hay không. Trong phần sau, chúng ta sẽ hiểu tên của tệp là tên, và chuỗi ký tự sẽ được gọi là SHA1-hash.

Điều đáng nói là cái gọi là va chạm. "Việc xác định thiệt hại là khá chính xác" có nghĩa là có những tệp như vậy, khác nhau về nội dung, hàm băm SHA1 của cái nào giống nhau. Xác suất của những vụ va chạm như vậy là rất nhỏ, và theo ước tính sơ bộ, nó bằng 2 đến lũy thừa -80 (~ 10 đến lũy thừa -25). Không có đánh giá chính xác, vì hiện tại cộng đồng thế giới vẫn chưa thể giải mã hiệu quả sơ đồ mật mã này.

Đối tượng Git

Làm việc với các tệp lập phiên bản trong Git có thể được so sánh với các hoạt động hệ thống tệp bình thường. Cấu trúc bao gồm bốn loại đối tượng: Blob, Tree, commit và References; một số trong số chúng, đến lượt nó, được chia thành các đối tượng con.

Blob (Đối tượng lớn nhị phân) là kiểu dữ liệu chỉ chứa nội dung của tệp và hàm băm SHA1 của riêng nó. Blob là sóng mang dữ liệu chính và duy nhất trong cấu trúc Git. Có thể vẽ một song song giữa đối tượng này và các inodes trong hệ thống tệp, vì cấu trúc và mục đích của chúng rất giống nhau.

Cây

• băm SHA1 riêng;
• SHA1 băm của các đốm màu và / hoặc cây;
• quyền truy cập hệ thống Unix;
• tên tượng trưng của đối tượng (tên dùng trong nội bộ hệ thống).

Về cốt lõi, một đối tượng tương tự như một thư mục. Nó xác định thứ bậc của các tệp dự án.

Làm- kiểu dữ liệu chứa:

• băm SHA1 riêng;
• một liên kết đến chính xác một cây;
• một liên kết đến cam kết trước đó (có thể có một số trong số chúng);
• tên của tác giả và thời điểm tạo cam kết;
• tên của người cam kết (người cam kết là người đã áp dụng cam kết vào kho lưu trữ, nó có thể khác với tác giả) và thời điểm khi cam kết được áp dụng;
• một phần dữ liệu tùy ý (khối có thể được sử dụng cho chữ ký điện tử hoặc, ví dụ, để giải thích các thay đổi đối với một cam kết).

Đối tượng này được thiết kế để lưu trữ ảnh chụp nhanh (phiên bản) của một nhóm tệp tại một thời điểm nhất định, bạn có thể so sánh nó với một trạm kiểm soát. Cam kết có thể được hợp nhất, phân nhánh hoặc, ví dụ, được đặt trong một cấu trúc tuyến tính, do đó phản ánh hệ thống phân cấp phiên bản của dự án.

Tham chiếu là kiểu dữ liệu chứa tham chiếu đến bất kỳ đối tượng nào trong bốn đối tượng (Blob, Tree, commit và References). Mục đích chính của nó là trỏ trực tiếp hoặc gián tiếp đến một đối tượng và là một từ đồng nghĩa với tệp mà nó đề cập đến. Điều này làm tăng sự hiểu biết về cấu trúc dự án. Rất bất tiện khi hoạt động với một bộ ký tự vô nghĩa trong tên, trong khi liên kết, không giống như hàm băm SHA1, có thể được đặt tên vì nó thuận tiện hơn cho nhà phát triển.

Từ các liên kết, lần lượt, một số subobject có thể được phân biệt có một số khác biệt: Nhánh, Thẻ. Hãy xem xét chúng.

Chi nhánh (Trưởng ban, Chi nhánh)- một liên kết tượng trưng (Symbolic link), liên kết này trỏ đến cam kết cuối cùng trong trình tự thời gian của một nhánh nhất định và lưu trữ SHA1-hash của đối tượng. Nó là một kiểu dữ liệu cho các hệ thống tệp nhật ký. Loại đối tượng này không được định nghĩa trong chính Git, mà được kế thừa từ hệ điều hành và hệ thống tệp. Một nhánh được sử dụng như một từ đồng nghĩa với tệp mà nó đề cập đến, tức là Git cho phép bạn thao tác trực tiếp. Bạn có thể không cần phải suy nghĩ về việc liệu bạn có đang làm việc với phiên bản mới nhất hay không.

Nhãn- một kiểu dữ liệu, không giống như các nhánh, luôn tham chiếu đến cùng một đối tượng của kiểu blob, cây, cam kết hoặc thẻ. Đến lượt nó, nó có thể được chia thành nhẹ (thẻ nhẹ) và nặng hoặc được chú thích (thẻ chú thích). Một thẻ nhẹ, ngoài tính bất biến của liên kết, không khác gì các nhánh thông thường, tức là chỉ chứa hàm băm SHA1 của đối tượng được tham chiếu trong chính nó. Thẻ được chú thích có hai phần:

• phần đầu tiên chứa hàm băm SHA1 của riêng nó;
• phần thứ hai bao gồm:
  • SHA1 của đối tượng được trỏ đến bởi thẻ chú thích;
  • loại đối tượng đang được tham chiếu (blob, cây, cam kết hoặc thẻ);
  • tên tượng trưng của thẻ;
  • ngày và giờ khi thẻ được tạo;
  • tên và e-mail của người tạo thẻ;
  • một phần dữ liệu tùy ý (khối này có thể được sử dụng cho chữ ký điện tử hoặc để giải thích một thẻ).

Nói cách khác, một dự án Git là một tập hợp các đốm màu được liên kết bởi một mạng lưới các cây. Cấu trúc phân cấp kết quả có thể, tùy thuộc vào thời gian, được phản ánh dưới dạng các phiên bản của cam kết, và để hiểu cấu trúc của chúng, Git chứa các đối tượng như liên kết. Loại trừ các hành động có liên kết, hầu hết tất cả các hoạt động với các đối tượng hệ thống đều được tự động hóa hết mức có thể từ bên trong. Bắt đầu từ cơ chế liên kết, chúng tôi đi đến ý tưởng tiếp theo - làm việc trên các nhóm tệp. Theo tác giả, tư tưởng là trọng tâm của triết học Git. Ví dụ, thiết lập một hoạt động cho một cam kết nhất định, nó sẽ thực thi đệ quy phần của nó dọc theo cây mà nó tham chiếu. Là một phần mở rộng của quan điểm được chấp nhận chung về “hành động trên mọi tệp”, sự đổi mới đơn giản hóa việc triển khai và cách tiếp cận của lập trình viên đối với các tác vụ VCS hàng ngày như hợp nhất / tách các nhánh, một lần nữa tự động hóa quy trình một cách đệ quy. Cách tiếp cận này dễ hiểu, nhanh chóng và linh hoạt trong việc đạt được mục tiêu. Nhiều tính năng trong số này đạt được do tính tập trung Unix của hệ thống, tức là về các thiết bị tiêu chuẩn, Git dựa trên các giải pháp đã có sẵn trong hệ điều hành.

Hãy làm rõ quan điểm của lưu trữ dữ liệu. Nội dung của các tập tin thuộc các phiên bản khác nhau trong lịch sử chiếm khá nhiều bộ nhớ. Vì vậy, ví dụ: trong một dự án gồm hai mươi tệp của hai mươi phiên bản, bản lưu trữ sẽ nặng hơn 20 lần (có lẽ theo thứ tự hàng trăm megabyte), nhưng điều gì sẽ xảy ra nếu số lượng của cả hai đều nhiều hơn 10 lần (dường như không nhiều )? Kích thước của không gian đã sử dụng sẽ tăng lên 100 lần (tức là khoảng 1 GB). Trong các bài toán thực tế, tốc độ phát triển của bộ nhớ bị chiếm dụng không phụ thuộc tuyến tính vào thời gian. Có một số tối ưu hóa để giải quyết vấn đề này:

• mọi đối tượng Git được lưu trữ dưới dạng kho lưu trữ thông thường (tar.gz);
• nén delta tuần tự được áp dụng cho toàn bộ hệ thống phân cấp tệp.

Hãy lấy một ví dụ.

Bạn có lịch sử ba năm về dự án của mình, có khoảng một nghìn tệp và một trăm phiên bản trong đó. Nếu một lúc nào đó bạn cần lên phiên bản sớm nhất, Git sẽ phải giải nén phần nén delta của toàn bộ lịch sử của tệp. Thật thất vọng, quá trình này có thể mất đến buổi trưa. Git đề xuất thực hiện cái gọi là điểm ngắt, tức là lưu trữ một tệp được lưu trữ hàng tuần sau một số phiên bản nhất định, mà chúng tôi sẽ gọi là độ sâu nén. Sau đó, trong ví dụ của chúng tôi, toàn bộ lịch sử được thu hẹp lại thành một số nén delta nhất định được xác định trước, sau khi giải nén chúng, bạn có thể xem bất kỳ phiên bản nào trong niên đại. Lưu ý rằng nén delta thích hợp nhất để sử dụng trên một số loại đối tượng gần nhất trong hệ thống phân cấp; đối với điều này, kho lưu trữ phải được sắp xếp tương ứng theo loại và kích thước. Chuỗi hoạt động được mô tả trong mệnh đề này được thực hiện bởi hàm git-repack (và git-gc chứa nó).

Sáp nhập và tách chi nhánh

Câu hỏi này rất tốn công sức và bão hòa, liên quan đến vấn đề này chúng tôi sẽ giới thiệu các khái niệm về sáp nhập và chia tách chỉ nói chung chung. Hãy xem lại một ví dụ.

Hãy tưởng tượng thời điểm phát triển dự án, khi mục tiêu chính là tốc độ của chương trình. Một trong những giải pháp chiến thuật khả thi là chia các nhà phát triển thành hai nhóm, mỗi nhóm sẽ giải quyết cùng một vấn đề. Trong trường hợp này, nhánh lịch sử của dự án nên được tách thành hai. Thủ tục này được gọi là phân nhánh. Hành động phân nhánh một nhánh là một tạo đơn giản của một bản sao của nó, sau đó sẽ có lịch sử riêng của nó.

Giả sử chúng ta nhận được hai kết quả đã hoàn thành của cùng một nhiệm vụ, trong đó hai nhóm lập trình viên đã làm việc. Làm thế nào để chúng ta trở thành? Xem mã nào nhanh hơn và đáng tin cậy hơn? Nó quá dễ dàng, nhưng không phải lúc nào cũng là giải pháp tốt nhất. Một giải pháp tốt là, sau khi hiểu một chút về mã và tệp, hãy chia chúng thành các nhiệm vụ con hoặc khối mã. Và chỉ khi đó, chúng ta mới có thể xác định được điểm mạnh và điểm yếu của những quân cờ này. Tất nhiên, tùy chọn này chỉ phù hợp nếu bạn đã thấy trước rằng sau này bạn có thể thu thập tất cả các hạt này lại với nhau. Trường hợp bạn tự phát triển mã, cải thiện và sửa một số lỗi, tương đương với ví dụ đã cho. Quá trình kết hợp hai số nguyên thành một được gọi là hợp nhất. Quá trình kết hợp hai phiên bản là điểm mấu chốt của dự án. Nếu có thể, bạn nên tránh thực hiện tự động hoạt động này. Một tính năng đặc biệt của Git là cách đáng tin cậy nhất và khá nhanh để giải quyết vấn đề phân nhánh.

Những ưu điểm của hệ thống bao gồm:

1. Hướng Unix.
2. Tính nhất quán về mặt tư tưởng (tuân theo các quy tắc sử dụng hệ thống, bạn sẽ rất khó rơi vào tình huống vô vọng hoặc nhận được thứ mà mình không ngờ tới).
3. Hiệu suất cao (đây là một trong những ưu điểm rõ ràng nhất của hệ thống, cái giá phải trả cho nó là "Tính nhất quán về mặt lý tưởng" và "Tính định hướng Unix").
4. Tích hợp Git với VCS của bên thứ ba như Subversion, Mercurial, ...
5. Quản lý một nhóm tệp (hệ thống không cần phải xem xét các thay đổi trong từng tệp riêng biệt, nó ghi nhớ bất kỳ thay đổi nào trong toàn bộ dự án và nếu bạn đột nhiên cần theo dõi các thay đổi đơn lẻ, hệ thống sẽ hiển thị chính xác phần được liên kết với điều này tập tin).
6. Hợp nhất hoạt động (thực hiện tự động nhất của một nhiệm vụ phức tạp).

Những bất lợi bao gồm:

1. Hướng Unix (cần lưu ý rằng việc thiếu triển khai Git thành thục trên các hệ thống không phải Unix).
2. Sự cần thiết phải thực thi định kỳ lệnh git-gc (gói các nhóm tệp và loại bỏ những nhóm không được liên kết bằng liên kết).
3. Xung đột băm (khớp băm SHA1 của các tệp có nội dung khác nhau).

6. Giao diện Git

"Có bao nhiêu người, rất nhiều ý kiến." Chúng ta hãy thử làm nổi bật một số kiểu giao diện để làm việc với hệ thống. Đối với một số mục đích nhất định, mỗi loại ứng dụng sau đây sẽ tốt hơn theo cách riêng của nó.

Đối với những người không tham gia chặt chẽ vào quá trình phát triển, đối với "những người bảo thủ" - những người yêu thích "nút và tích tắc" và có ý thức muốn bảo vệ bản thân khỏi những nỗ lực cắt cổ của việc ghi nhớ các chức năng, phím và nhiều tính năng tinh vi, tùy chọn theo phong cách của TortoiseGit hoặc Phần mở rộng Git phù hợp hơn - giao diện đơn giản. Chúng cho phép bạn thao tác chủ yếu bằng chuột và hoạt động trong Windows thông thường cho nhiều hệ điều hành.

Chính xác là kiểu giao diện ngược lại. Đối với các lập trình viên thường xuyên cần tương tác với nhân viên, để giải quyết các tác vụ điển hình là kiểm soát mã, đối với những người quen làm việc trong các hệ thống giống Unix sử dụng thiết bị đầu cuối, giao diện điều khiển của các ứng dụng là phù hợp nhất. Chúng cũng dễ sử dụng, nhanh hơn một chút và nhiều chức năng hơn, nhưng họ sẽ phải mất thời gian để tìm ra cách sử dụng chúng.

Ngoài ra còn có một loại giao diện thứ ba - trộn hai loại đầu tiên. Những thứ kia. bạn có một ứng dụng bảng điều khiển như trình bao git gốc. Bạn có thể sử dụng một số tiện ích bổ sung, chẳng hạn như Gitk hoặc QGit, để hiển thị cây, giúp dễ dàng duyệt qua hệ thống phân cấp phiên bản, phân biệt giữa các phiên bản và tìm đối tượng bạn muốn.