Tìm hiểu về mô hình quản lý source GIT

Sơ lược lịch sử của Git

Cũng như nhiều thứ tuyệt vời khác trong cuộc sống, Git ra đời từ một chút của sự huỷ diệt/ phá sản/ kết thúc có tính sáng tạo và sự tranh cãi nảy lửa. Nhân của Linux là một dự án phần mềm mã nguồn mở của một phạm vi khá lớn. Trong phần lớn thời gian bảo trì của nhân Linux (1991-2002), các thay đổi của phần mềm được truyền đi dưới dạng các bản vá và các tập tin lưu trữ. Vào năm 2002, dự án nhân Linux bắt đầu sử dụng một DVCS độc quyền có tên là BitKeeper. Vào năm 2005, sự hợp tác giữa cộng đồng phát triển nhân Linux và công ty thương mại phát triển BitKeeper bị phá vỡ, và công cụ đó không còn được cung cấp miễn phí nữa. Chính điều này đã thúc đẩy cộng đồng phát triển Linux (chính xác hơn là Linus Torvalds, người sáng lập ra Linux) phát triển công cụ của riêng họ dựa trên những bài học từ việc sử dụng BitKeeper. Một số mục tiêu của hệ thống mới được vạch ra như sau: Nhanh Thiết kế đơn giản Hỗ trợ tốt cho “phát triển phi tuyến tính” (non-linear development) – (hàng ngàn nhánh song song) Phân tán toàn diện Có khả năng xử lý các dự án lớn giống như nhân Linux một cách hiệu quả (về mặt tốc độ và khối lượng dữ liệu) Kể từ khi ra đời năm 2005, Git đã tiến hoá và phát triển toàn diện để dễ dàng sử dụng hơn, tuy thế các tiêu chí ban đầu vẫn được đảm bảo. Nó nhanh một cách đáng kinh ngạc, vô cùng hiệu quả với các dự án lớn, và một hệ thống phân nhánh không thể tin được cho phát triển phi tuyến tính

Khái niệm

Git là hệ thống quản lý source phân tán, có lẽ nhiêu đó cũng đủ để nói lên “tinh thần” của hướnng tiếp cận mới của Git so với các hệ thống source control khác như SVN hay CVS Git là một phần mềm VCS dùng để quản lý và kiểm tra các phiên bản mã nguồn khác nhau trong quá trình phát triển mã nguồn

Đặc tính phi tập trung nhưng mang tính tập trung của Git

Trong khi mỗi lập trình triển khai một tính năng thuộc hệ thống rồi sau đó mới đẩy về kho trung tâm Mô hình rất hiệu quả trong các dựh viện đều sở hữu một kho code đầy đủ thì Git cho thiết lập một kho trung tâm thực sự, tất cả các lập trình viên đều có thể kéo (pull) các thay đổi từ đó về kho của mình, và đẩy (push) các thay đổi về kho trung tâm. Tuy nhiên, bên cạnh những mối quan hệ pull-push tập trung, mỗi nhà phát triển cũng có thể kéo (pull) thay đổi từ các đồng nghiệp để tạo thành các nhóm nhỏ hơn Ví dụ minh họa dưới đây cho thấy một dự án với 1 kho code trung tâm và 4 người, họ hình thành 3 nhóm nhỏ hơn là nhóm của A-B, A-C, B-D. Mỗi nhóm này có thể phụ trách phá án lớn

Hệ thống quản lý phiên bản (Version Control System)

Hệ thống quản lý phiên bản (Version control system – VCS) là một dạng phần mềm Quản lý mã nguồn (Source Code Management – SCM) Vì sao pải sử dụng VCS : VCS là hệ thống hỗ trợ làm việc theo nhóm rất hiệu quả. Khi một nhóm làm việc cùng trên một dự án (project), việc nhiều người cùng chỉnh sửa nội dung của một tệp tin là điều không thể tránh khỏi. Việc chỉnh sửa như vậy sẽ tạo ra các phiên bản (Versions/Revisions) khác nhau và phát sinh nhu cầu quản lý chúng. VCS ra đời để cung cấp các chức năng để có thể thực hiện việc này một cách đơn giản và an toàn Chức năng các VCS : Các Hệ thống Quản lí phiên bản cung cấp đồng thời ba chức năng quan trọng nhất:

• Ghi lại lịch sử : ghi lại các thông tin cần thiết của từng sửa đổi một, như tác giả, thời gian, các ghi chú giải trình thao tác thay đổi đó…
• Chức năng phục hồi : cho phép khôi phục trạng thái trước khi phát hiện ra có lỗi trong một thao tác sửa đổi đã làm.
• Chức năng đồng bộ : cho phép nhiều người cùng sửa một hoặc nhiều tệp tin cùng lúc vì các thao tác sửa đổi gây xung đột có thể được phát hiện và giải quyết sau đó.

Mô hình quản lý source phân tán (Distributed)

Do đó Git có thể nói là một hướng tiếp cận hoàn toàn mới so với SVN (CVS và SVN theo hướng CENTRALIZED – quản lý source code tập trung, còn Git theo hướng DISTRIBUTED – quản lý source code phân tán). Chúng ta thường dùng SVN chắc đã hiểu khái niệm CENTRALIZED là gì rùi, vậy thì DISTRIBUTED sẽ như thế nào đây: Với một vài hệ thông như Git và ngay cả CVS và SVN, repository gốc sẽ được lưu trữ trên server và lập trình viên sẽ checkout về một bản copy mới nhất từ source code trên server đó để làm việc. Và khi ta muốn apply thay đổi của ta từ local ta sẽ send yêu cầu đó lên server. Đó chính là nguyên tắc chung của source control. Source control ra đời để phục vụ nhu cầu cho nhiều hơn một developer để họ có thể làm việc với nhau trên cùng một project. Mỗi một developer sẽ có một source code và làm việc với nó, và cập nhật thay đổi của mình cho những người khác trong team biết. Việc cập nhật thay đổi của bạn đến server là theo nguyên lý của SVN và CVS, tức là không phân tán vì tất cả thay đổi đều tập trung ở server. Việc quản lý tập trung yêu cầu quyền truy cập đến server khi ta commit hoặc update từ những thành viên khác, chính họ cũng đưa thay đổi của mình lên server (để tránh conflic hoặc out of update). Git hoàn toàn đối lập: Quản lý phân tán của Git là một repositories không cần có chung một nơi để lưu trữ, mà mỗi thành viên sẽ có một repository ở local của họ. Tất cả thao tác ta làm việc với Git đều ở trên máy của ta, local repository, khi quyết định đưa những thay đổi đó lên server ta chỉ cần một thao tác “push” nó lên server. Chúng ta vẫn có thể share thay đổi của chúng ta cho thành viên khác, bằng cách commit hoặc update trực tiếp từ máy của họ mà không phải thông qua repositories gốc trên server (thông qua share ssh cho nhau). Và dĩ nhiên là mọi thao tác đều mang theo thông tin history với Git. Tính phân tán thì an toàn hơn so với tập trung, vì mỗi bản copy của thành viên đều là full copy từ repository gốc, khi server bị down, các thành viên vẫn có thể làm việc offline, họ vẫn có thể commit và update trên local của họ hoặc thậm chí với nhau mà không cần thông qua server. Khi server hoạt động trở lại, họ có thể cập nhật tất cả lên lại server. Với mô hình Git, Mỗi thành viên tham gia git sẽ có một repository trên local của họ : máy John’s Mac ở đây có thể trở thành một repository server, sau khi copy source code từ repository server, với 2 repository client khác là John’s Linux và John’s Solairs, 2 máy này sẽ làm việc hoàn toàn với máy John’s Mac như một mô hình Git con khác.

So sánh mô hình quản lý source CVS – SVN

CVS (Concurrent Versions System) và SVN (SubVersioN) với mô hình quản lý source code tập trung, là hai phiên bản được sử dụng phổ biến hiện nay. Các hệ thống này cho phép các cộng tác viên theo dõi sự thay đổi đang thực hiện và biết ai đang phát triển nhánh nào của source code. CVS ra đời trước, sau đó đến sự bùn nổ của SVN. SVN bản chất vẫn là CVS được cải tiến, nhưng có nhiều công cụ hỗ trợ hơn. Cả CVS và SVN đều có tư tưởng chung về cách làm việc chung giữa các thành viên theo mô hình (quản lý source code tập trung) như sau :

• Có lẽ sự cải thiện lớn nhất của SVN từ CVS là bổ sung việc commit của các thành viên được gọi là Atomic Commit. Atomic Commit cho phép mỗi commit từ thành viên được upate đầy đủ hoặc không có gì cả, điều này rất có ý nghĩa khi máy chủ bị treo trong lúc commit. Với CVS khi máy chủ bị treo hay kết nối bị trục trặc thì việc commit có thể bị dở dang, không đầy đủ.
• Với SVN, các commit có thể được roll-back lại trạng thái trước đó, trong khi CVS thì không thể undo.
• Ngoài ra SVN tiện lợi hơn CVS trong việc đổi tên và di chuyển các tập tin, thư mục. Với SVN các tập tin được đổi tên hoặc loại bỏ vẫn mang theo đầy đủ history và meta data của nó trước đó, trong khi đó với CVS thì tập tin bị đổi tên hoặc di chuyển sẽ bị mất history trước đó. CVS cũng không thể đẩy bất cứ những thay đổi mới đến repositories cha mà chỉ có thể đẩy lên repositories con của nó, trong khi một số công cụ SVN có khả năng này.
• Cả hai sử dụng giao thức độc quyền qua một kết nối SSH để đảm bảo an toàn thông tin đang được truyền đi trên mạng. SVN bổ sung WebDAV DeltaV, giao thức này được dựa trên HTTP và HTTPS cung cấp cho người dùng một tùy chọn để kết nối với các SVN qua web. Dù đây là những tính năng đơn giản nhưng đến nay CVS vẫn không thể hổ trợ vì bản thân kiến trúc của nó có thể gây lỗi trên một số thành viên trong dự án. Đối với hầu hết mọi người khi bắt đầu với source control, SVN là lựa chọn tốt hơn và hợp lý hơn (nó cung cấp cho người dùng các tính năng cần thiết đủ để đáp ứng nhu cầu cơ bản hằng ngày của một developer như: checkout, update, commit …) Lý do duy nhất để tiếp tục sử dụng CVS là nếu bạn đang bị mắc kẹt với một hệ thống source code cũ trên CVS mà không có cách nào để move nó qua SVN

Kết luận

• SVN mới hơn và tiên tiến hơn so với CVS.
• SVN cho phép atomic commit, CVS thì không.
• SVN có thể roll-back việc commit, SVN cho phép đổi tên và di chuyển file hoặc folder mà vẫn giữ nguyên history của nó, trong khi CVS thì không.
• SVN cho phép đẩy thay đổi lên repositories cha, trong khi CVS không
• SVN hỗ trợ hai giao thức mạng (trong số đó có HTTP và HTTPS trên nền web) trong khi CVS không hỗ trợ HTTP và HTTPS Như vậy ta thấy SVN thật chất chỉ là phiên bản cải tiến so với CVS, về mặt cơ bản cả 2 đều hoạt động như nhau: tất cả source code sẽ được đặt trên 1 server trung tâm, mọi thành viên đều làm việc trên source code đó.