Hệ thống quản lý phiên bản

Bùi Đức Hiệu 2012

1 Version 1.0

Hệ thống quản lý phiên bản

Trong công nghệ phần mềm, một hệ thống quản lý phiên bản (còn viết là VCS -

Version Control Systems) là một hệ thống lưu giữ các phiên bản của mã nguồn của sản

phẩm phần mềm, giúp các lập trình viên có thể dễ dàng lấy lại phiên bản mong muốn. Hệ

thống này có thể được sử dụng bởi một nhóm các lập trình viên, mỗi thành viên trong nhóm

thường không được phép thay đổi mã nguồn của các thành viên khác, mà chỉ có thể xem.

VCS cho phép người quản trị phân chia các tập cho từng thành viên tương ứng. Nó cũng

cho phép các thành viên chia sẻ một số tập tin cho nhau trong khi phát triển. Các thành viên

có thể phát hiện lỗi và sửa lỗi thuận tiện trong VCS. Trưởng nhóm phải có nhiệm vụ cập

nhật lại nội dung của các tập tin đó. VCS giúp cho công việc này được thực hiện một cách

tự động.

Khi các thành viên hiệu chỉnh mã của cùng một tập tin tại cùng một thời điểm, để

tránh sửa đổi mâu thuẫn, họ sẽ phải so sánh xem có gì khác biệt giữa các sửa đổi của các

thành viên hay không. VCS giúp cho việc này được thực hiện tự động.

Hiện nay, có hai mô hình được sử dụng phổ biến để hiện thực hóa việc triển khai

VCS đó là: mô hình quản lý tập trung và mô hình quản lý phân tán. Nhưng trước khi chúng

ta tìm hiểu về đặc điểm của chúng, tôi xin gửi đến bạn một đoạn trong cuốn sách Git Magic

của tác giả Ben Lynn – một cuốn sách khá đầy đủ về Git, hiện đã được dịch ra tiếng Việt

bởi Trần Ngọc Quân.

Công Việc giống như Trò Chơi Tôi đã chơi trò chơi trên máy tính suốt từ bé đến giờ. Ngược lại, tôi chỉ bắt đầu sử

dụng hệ thống quản lý mã nguồn khi đã trưởng thành. Tôi tin rằng không chỉ có tôi như thế,

và việc so sánh giữa hai điều đó sẽ làm cho các khái niệm trở nên dễ hiểu, dễ giải thích hơn.

Hãy nghĩ việc biên soạn mã nguồn, tài liệu cũng giống như việc chúng ta đang chơi trò chơi

trên máy tính.Một khi bạn đã làm được kha khá, bạn sẽ muốn ghi lại thành quả công việc

của mình. Để làm điều đó, bạn chỉ việc bấm vào nút Save trong chương trình biên soạn của

mình. Nhưng việc làm này sẽ ghi đè lên bản cũ. Điều này cũng giống như các trò chơi đã cũ

chỉ cho phép ghi trên một tệp tin: bạn phải chắc chắn là mình muốn ghi lại, nếu không thì

bạn không bao giờ có thể quay lại trạng thái cũ nữa. Và thật không may vì lần lưu trước đó

có thể là đúng tại một điểm rất hay trong lượt chơi và bạn muốn thăm lại về sau. Tệ hơn

nữa là khi bản ghi lại hiện tại lại không đúng, và thế là bạn sẽ phải bắt đầu lại từ đầu.

Quản Lý Mã Nguồn Khi biên soạn, bạn có thể chọn Save As... để ghi lại tệp tin hiện tại nhưng với một cái

tên khác, hay là sao chép tệp tin ra một chỗ khác trước khi bạn ghi lại, nếu như bạn muốn

dùng cả các bản cũ. Bạn có thể nén chúng lại để tiết kiệm dung lượng lưu trữ. Đây là dạng

thức nguyên thủy và tốn nhiều công sức cho việc quản lý dữ liệu. Trò chơi trên máy tính đã

cải tiến cách trên từ rất lâu rồi, rất nhiều trong số chúng cung cấp cho bạn khả năng tự động

ghi lại sau từng khoảng thời gian nhất định.


2 Version 1.0

Chúng ta sẽ giải quyết một vấn đề hơi hóc búa một chút nhé! Bạn nói rằng bạn có

nhiều tệp tin có liên quan mật thiết với nhau, như mã nguồn cho một dự án chẳng hạn, hay

các tệp tin cho một website. Bây giờ nếu bạn muốn giữ một phiên bản cũ bạn phải lưu giữ

toàn bộ thư mục. Giữ nhiều phiên bản như thế bằng cách thủ công thật bất tiện, và sẽ nhanh

chóng trở nên tốn kém.

Đối với một số trò chơi, ghi lại một trò chơi thực tế là bao gồm toàn bộ thư mục.

Những trò chơi này thực thi việc này tự động và chỉ đưa ra một giao diện thích hợp cho

người chơi để quản lý các phiên bản của thư mục này.

Các hệ thống quản lý mã nguồn cũng hoạt động theo cách ấy. Chúng có một giao

diện tinh tế để quản lý một nhóm các thứ trong thư mục. Bạn có thể ghi lại trạng thái của

thư mục một cách thường xuyên, và bạn có thể tải lên bất kỳ một trạng thái nào đã được ghi

lại trước đó. Không giống như các trò chơi trên máy tính, chúng thường khôn khéo hơn về

việc tiết kiệm không gian lưu trữ. Thông thường, chỉ có một số ít tài liệu được sửa

đổi giữa các phiên bản, và cũng không nhiều. Nó chỉ lưu giữ những cái có thay đổi thay vì

toàn bộ tất cả.

Hệ Thống Phân Tán

Bây giờ hãy tưởng tượng có một trò chơi rất khó. Khó để hoàn thành đến mức là có

nhiều game thủ lão luyện trên toàn thế giới quyết định lập thành đội và chia sẻ những trò

chơi mà họ đã lưu lại với mục đích là để tất cả mọi người có thể theo dõi được nhau.

Speedruns là những ví dụ trong đời sống thực: các đấu thủ được phân hóa theo các mức của

cùng một trò chơi hợp tác với nhau để đạt được các kết quả đáng kinh ngạc.

Làm thế nào bạn có thể cài đặt một hệ thống mà chúng có thể lấy được từng bản ghi

của mỗi người một cách dễ dàng? Và tải lên cái mới hơn? Ngày xưa, mọi dự án đều sử

dụng hệ thống quản lý tập trung. Máy chủ ở một chỗ đâu đó và giữ tất cả các trò chơi đã

được ghi lại. Không còn ai khác làm điều đó nữa. Mọi người giữ phần lớn các trò chơi được

ghi lại trong máy của họ. Khi một đấu thủ muốn chơi, họ có thể tải về bản ghi lại cuối cùng

đã lưu lại ở máy chủ, chơi một lúc, ghi lại và tải trở lại máy chủ để mọi người có thể sử

dụng. Điều gì xảy ra khi một người chơi, vì một lý do nào đó, muốn có được lần chơi cũ

hơn? Lý do có thể là lần chơi hiện tại không ổn định hay có sai sót bởi vì một người chơi

nào đó quên không chỉnh lại trò chơi về mức 3, và họ muốn tìm lần chơi đã ghi lại cuối

cùng mà họ vẫn chưa hoàn thành. Hay có thể là họ muốn so sánh sự khác nhau giữa các lần

chơi để thấy được thành quả của từng người chơi.

Có rất nhiều lý do vì sao cần đến bản cũ hơn, nhưng kết cục là giống nhau. Họ phải

hỏi máy chủ trung tâm để lấy về trò chơi cũ đã được lưu lại. Càng ghi lại nhiều trò chơi, họ

càng cần phải liên lạc nhiều với nhau.

Những hệ thống quản lý mã nguồn thế hệ mới, Git cũng nằm trong số đó, được biết

đến như một hệ thống phân tán, và có thể coi nó là một hệ thống tập trung có mở rộng. Khi

người chơi tải về từ máy chủ chính, họ lấy toàn bộ tất cả các lần đã ghi lại, không chỉ mỗi

bản cuối cùng. Điều đó có nghĩa là họ trở thành bản sao của máy chủ trung tâm.Việc khởi

tạo bản sao như thế có vẻ hơi xa hoa, đặc biệt là nếu nó có lịch sử phát triển lâu dài, nhưng

cái giá phải trả cũng chỉ là việc cần nhiều thời gian để lấy về. Một lợi ích trực tiếp của việc

này là khi các tài liệu cũ cần đến, việc liên lạc với máy chủ trung tâm là không cần thiết nữa.


3 Version 1.0

Quan Niệm Cổ Hủ Một quan niệm phổ biến là hệ thống phân tán không thích hợp với các dự án có yêu

cầu một kho chứa trung tâm chính thức. Không điều gì có thể chà đạp lên sự thật. Chụp ảnh

ai đó không có nghĩa là lấy đi linh hồn họ. Cũng như thế, nhân bản kho chính cũng không

làm giảm đi sự quan trọng của nó.

Tóm lại, một hệ thống phân tán đã thiết kế tốt thì làm bất cứ công việc nào cũng khá

hơn một hệ thống quản lý mã nguồn tập trung. Tài nguyên mạng thường thì tốn kém hơn

các tài nguyên nội bộ. Chúng ta sẽ nói đến các hạn chế của hệ thống phân tán sau, sự so

sánh như sau thường đúng: hệ thống phân tán thường tốt hơn.

Một dự án nhỏ có thể chỉ cần dùng một phần nhỏ các đặc tính được đưa ra bởi một hệ

thống như thế, nhưng việc sử dụng một hệ thống không có khả năng mở rộng cho một dự án

nhỏ thì cũng giống như việc sử dụng hệ thống số La Mã để tính toán các số nhỏ.

Hơn thế nữa, dự án của bạn có thể lớn vượt ra ngoài dự kiến ban đầu. Việc sử dụng Git từ

lúc khởi sự thì cũng giống như việc sử dụng một bộ dao vạn năng chỉ để phục vụ cho mỗi

việc mở nút chai. Đến một ngày nào đó bạn cấn đến một cái chìa vít bạn sẽ vui sướng vì

mình không chỉ có mỗi cái mở nút chai.

Xung Đột Khi Trộn Với chủ đề này, dùng cách ví von nó với một trò chơi trên máy tính là hơi khó. Thay

vì thế, để chúng tôi dùng việc biên soạn một tài liệu để giải thích cho bạn. Giả sử Alice

chèn thêm một dòng vào đầu một tệp tin, và Bob nối một dòng vào cuối của bản sao của

mình.Cả hai đều tải lên các thay đổi của mình. Phần lớn các hệ thống sẽ tự động tìm ra hành

động hợp lý: chấp nhận và trộn các sự thay đổi của họ, do đó cả hai sự thay đổi mà Alice và

Bob tạo ra đều được dùng.Bây giờ giả sử cả Alice và Bob cùng sửa một dòng. Thế thì mâu

thuẫn này không thể sử lý được mà không có sự can thiệp của con người. Người thứ hai tải

lên sẽ được thông báo có xung đột xảy ra, merge conflict, và phải chọn một là sửa thêm nữa,

hay sửa lại toàn bộ dòng đó.

Nhiều tình huống phức tạp có thể nảy sinh. Hệ thống quản lý mã nguồn giữ phần dễ

dàng cho chúng, và để lại những tình huống khó khăn cho chúng ta. Nhưng thông thường

cách ứng xử của chúng có thể điều chỉnh.

Bây giờ, chúng ta sẽ cùng tìm hiểu về hai mô hình quản lý source code, và giới thiệu các

đại diện tiêu biểu của từng mô hình. Và tại sao chúng ta nên sử dụng Git.

CENTRALIZED (Mô hình quản lý source tập trung): 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).


4 Version 1.0

Subversion (viết tắt SVN) là một hệ thống quản lý version (version control

system - VCS) được giới thiệu vào năm 2000 bởi công ty CollabNet

(http://subversion.tigris.org). Đây 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 trên cùng một project, việc nhiều người cùng chỉnh sửa nội dung

của một file là điều không thể tránh khỏi. SVN 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. Subversion là hệ thống quản lý phiên bản mạnh mẽ,

hữu dụng, và linh hoạt. Subversion quản lý tập tin và thư mục theo thời gian.

SVN giống như một hệ thống file server mà các client có thể download và upload file

một cách bình thường. Điểm đặt biệt của SVN là nó lưu lại tất cả những gì thay đổi trên hệ

thống file: file nào đã bị thay đổi lúc nào, thay đổi như thế nào, và ai đã thay đổi nó. SVN

cũng cho phép recover lại những version cũ một cách chính xác. Các chức năng này giúp

cho việc làm việc nhóm trở nên hiệu quả và an toàn hơn rất nhiều.

Thông thường, client và server kết nối thông qua mạng LAN hoặc Internet. Client và

server có thể cùng chạy trên một máy nếu SVN có nhiệm vụ theo vết lịch sử của dự án do

các nhà phát triển phần mềm phát triển trong nội bộ.

Subversion hỗ trợ khá nhiều giao thức để kết nối giữa client và server.

Ví dụ bạn có thể dùng các giao thức của ứng dụng web như http:// hoặc https://, hay

các giao thức của svn như svn:// hoặc svn+ssh://, hoặc nếu phần mềm client và server

cài chung trên 1 máy thì có thể dùng file://.

Việc cho phép server hỗ trợ giao thức nào phụ thuộc vào lúc cấu hình.

Một số khái niệm trong SVN Subversion dựa trên mô hình quản lí tập trung kiểu client/server. Mô hình này có 2

khái niệm cơ bản: Repository và Working Copies.


5 Version 1.0

- Repository đặt ở server là nơi tập trung quản lý các phiên bản của dự án phần mềm.

- Các thư mục và tập tin của dự án được đặt vào trong kho lưu trữ trung tâm này. Nó

giống như một máy chủ tập tin thông thường, ngoại trừ việc nó ghi lại được mọi

thông tin thay đổi theo thời gian của hệ thống tập tin và thư mục.

Repository cho phép khôi phục lại phiên bản cũ của dữ liệu, hoặc kiểm tra lịch sử của

dữ liệu thay đổi như thế nào.Working Copies đặt ở client là các phiên bản làm việc copy

của các tập tin trong repository. Repository thì chỉ có một, trong khi working copies có thể

có nhiều (tương ứng với repository đó).


6 Version 1.0

Checkout: là khái niệm dùng để chỉ một thành viên của dự án ở client sẽ lấy một

phiên bản copy của các file thuộc project trên server về máy cục bộ.

Commit: thành viên của dự án đưa các thay đổi trên các file của project tại máy client

lên server.

Update: khi một thành viên muốn cập nhật những thay đổi của các file thuộc thành

viên khác trên Repository về máy cục bộ của mình.

Merge: nhiều thành viên cùng tiến hành cập nhật trên một tập tin.

Revision Để quản lí các phiên bản khác nhau, Subversion đưa ra khái niệm revision. Nói một

cách đơn giản, để hệ thống có thể quản lý được sự thay đổi của các tập tin, mỗi tập tin sẽ có

dạng Name-Revision.

Ví dụ: cnpm.doc-rev1 và cnpm.doc-rev2 là 2 revision của tập tin cnpm.doc.

Cứ mỗi lần commit, toàn bộ Repository sẽ có một con số revision mới (mỗi con số

này là duy nhất và số revision sau lớn hơn revision trước).Dù chỉ thay đổi một tập tin sau

khi commit, nhưng toàn bộ hệ thống tập tin của Repository sẽ có cũng một con số revision.

Hình ảnh minh họa về các revision của một Repository


7 Version 1.0

CVS (Concurrent Versions System) CVS (Concurrent Versions System) tương tự như SVN là mô hình mô hình quản lý

source code tập trung (Centralized).

CVS ra đời năm 1986, là hệ thống quản lý phiên bản đầu tiên, sau đó đến sự bùng 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:

Atomic Commit : 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ể.

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 Repository cha mà chỉ có

thể đẩy lên Repository con của nó, trong khi một số công cụ SVN có khả năng làm


8 Version 1.0

việc 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.

Về mặt cơ bản cả 2 đều hoạt động như nhau: tất cả source code sẽ được đặt trên một

server trung tâm, mọi thành viên đều làm việc trên source code đó.

DISTRIBUTED (Mô hình quản lý source phân tán) Đại diện tiêu biểu cho mô hình quản lý phân tán là Git. Git - Hệ thống quản lý source

phân tán, có lẽ nhiêu đó đủ để nói lên "tinh thần" của hướng 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. (Thật ra xu hướng Git không phải là mới,

vì nó đang phát triển trên cộng động lập trình thế giới, cả Facebook, Twitter, Yahoo cũng

đang dùng github: http://github.com để quản lý source code của họ) .

Git là phần mềm quản lý mã nguồn phân tán được phát triển bởi Linus Torvalds

dành cho việc phát triển Linux kernel. Git là phần mềm mã mở được phân phối theo giấy

phép công GPL2.

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.

http://github.com/


9 Version 1.0

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.


10 Version 1.0

Các hệ thống quản lý phiên bản khác Mercurial: là hệ thống quản lý phiên bản mã nguồn mở, giống như GIT, nhưng đơn

giản hơn nhiều. Mercurial được thiết kế để sử dụng cho các dự án lớn.

Bazzar: là hệ thống quản lý phiên bản phân tán, như GIT và Mercurial, được đánh

giá là khá thân thiện với người dùng, có khả năng quản lý bất kỳ dự án nào.

LibreSource: là một Web Portal dùng để quản lý nhiều dự án cộng tác với nhau,

được thiết kế cho những người dùng không cần có nhiều hiểu biết về kỹ thuật, công

nghệ.

Monotone: là một nhánh nhỏ của hệ thống quản lý phân tán, ít phổ biến hơn các hệ

thống khác.


11 Version 1.0

Lý do nên sử dụng Git

1. Linh động, phong phú và đa dạng phiên bản Với nhiều workflow làm việc khác nhau, tạo ra nhiều phiên bản phong phú, đa dạng,

từ đó thúc đẩy những hướng đi mới từ 1 source code gốc trong cộng đồng mã nguồn mở.

Với việc có nhiều repo trong Git, các thành viên có thể kết hợp code của họ với nhau thông

qua việc merge repo local của họ với nhau, từ đó tạo ra nhiều phiên bản, nhiều tính năng

phong phú và.

Ta có thể thấy qua ví dụ sau: Với SVN phiên bản cuối cùng của ta nằm ở server và là

phiên bản duy nhất tích hợp tất cả các tính năng mà dev commit lên. Ta không thấy được

tính phong phú và đa dạng của các phiên bản ở đây. Hãy xem GIT làm gì với mô hình của

nó: Đây là mơ ước của cộng đồng mã nguồn mở bấy lâu. Các dev có thể tự do tích hợp

những tính năng hoặc source code của mình với nhau, để tạo ra rất nhiều phiên bản đa dạng

từ một phiên bản gốc. Mỗi phiên bản có thể có một hướng đi mới, độc lập nhau.

Sau đây là một số workflow phổ biến:

a) SVN Style: Với Git ta vẫn có thể dùng nó theo cách hoạt động của SVN: Các developer đều đồng bộ dữ

liệu và commit thay đổi trên một repo duy nhất

b) Integration Manager Workflow: Đây là mô hình khá phổ biến hiện nay, GitHub và nhiều open source cũng đang áp dụng nó:

- Integration manager là bộ phận sẽ tập hợp các function được các dev commit lên để

kiểm tra xem có nên cập nhật function đó vào bản gốc không ?

- Blessed Repo: là source code ổn định sau những thay đổi được Integration manager

quản lý và tích hợp các function mới từ dev vào.

Ví dụ một cộng đồng có nhiều dev cùng phát triển một open source:

- Khi một dev private muốn thêm function mà mình nghĩ ra, họ sẽ download source

code ổn định từ Blessed Repo về. Sau khi hoàn thành function mong muốn dựa trên

source code down về họ đưa lên Developer public của mình.

- Các function trên Developer public được tập họp ở Integrate Manager cho việc chọn

lọc, testing và cuối cùng sẽ được tích hợp lên Blessed Repo thành bản ổn định.

c) Dictator and Lieutenants Workflow:

Mô hình này được mở rộng từ Integration Manager Workflow. Thay vì với

"Integration Manager Workflow" thì mỗi dev làm việc độc lập với nhau, không hợp tác với

các thành viên khác. Với "Dictator and Lieutenants Workflow" thì các dev có thể làm việc

với nhau, họ có thể merge trực tiếp repo của họ (thông qua share SSH) với người khác

thành một lieutenant.

Một lieutenant là một phiên bản tích hợp nhiều tính năng của nhiều dev. Các

lieutenant sẽ được tập hợp về dictator, dictator sẽ làm nhiệm vụ giống Integration manager:

quản lý, testing, chọn lọc và tích hợp lieutenant vào blessed repo khi đạt yêu cầu.

2. Local Branching Phần này nói về việc tạo branch của Git tốt hơn các source control khác. Hầu hết các

source control việc tạo branch đều clone một phiên bản mới nhất từ repository gốc thành


12 Version 1.0

một thư mục mới trên server.

Git cho phép bạn tạo nhiều branch độc lập ở máy local, từ đó các thao tác create,

merge, delete các dòng code trong source code diễn ra rất nhanh, trong vài giây.Điều này có

nghĩa là bạn có thể làm như sau:

- Tạo một branch mới trên local của bạn để thử nghiệm ý tưởng của , commit thử

nghiệm một vài lần lên branch đó, bùn bùn trở lại trạng thái trước khi tạo branch, rồi

sau đó có thể trở lại branch đó hoặc merge code thử nghiệm đó vào trunk chính.

- Bạn có thể tạo một branch chỉ chứa những gì cần đưa lên production site, hoặc là nơi

bạn merge code cho việc testing và commit hằng ngày trên brach đó, xem nó như là

một phòng thí nghiệm local.

- Bạn có thể tạo nhiều brach mới cho mỗi tính năng mới mà bạn đang làm, vì vậy bạn

có thể chuyển đổi qua lại giữa chúng dễ dàng hoặc xóa branch đó đi khi nó được sát

nhập vào branch chính hoặc không còn sử dụng nữa

- Trong khi tạo một brach để thử nghiệm, bạn nhận ra nó không hữu dụng nữa và chỉ

cần xóa nó đi, không ai khác ngoài bạn thấy nó (ngay cả khi bạn đã đẩy các branch

khác trong khi chờ đợi)

Bạn có thể làm tất cả các điều trên với Git nhưng cần lưu ý khi push lên server gốc, bạn

không được push tất cả các brach mà bạn tạo ra để thử nghiệm.

Việc này thúc đẩy developer thử nghiệm các nhánh mới mà họ không cần phải lo

lắng về việc phải lên kế hoạch như thế nào hay khi nào để sát nhập nhánh của họ vào nhánh

chính, trong quá trình thử nghiệm mọi history của họ đều được lưu trữ ở local. Nếu branch

thử nghiệm thành công thì tốt, không được thì họ đơn giản chỉ delete đi là xong.

Khi tham gia phát triển một dự án mã nguồn mỡ, nếu dùng svn một người đóng góp khi

mới tham gia sẽ không có quyền tạo branch trên server của họ, với Git bạn có thể tạo

branch local cho những thử nghiệm của mình và có thể sát nhập nó vào trunk chính trên

server khi thử nghiệm thành công.

Lưu ý: tất cả các điều trên không phải các source control khác không làm đươc, mà

đều có cách để làm nhưng chi phí thực hiện cao, có khả năng gây lỗi trong quá trình thực

hiện hoặc làm phìn kích thước source ở server. Git được sinh ra theo mô hình quản lý phân

tán thì đây là ưu điểm mà nó thực hiện được dễ dàng.


13 Version 1.0

Tài liệu tham khảo

[1] Git Magic, Ben Lynn

Bản dịch của Trần Ngọc Quân tại http://vnwildman.users.sourceforge.net/gitmagic/

[2] Hệ Thống Quản Lý Phiên Bản Theo Mô Hình Phân Tán, ĐH Sài Gòn

[3] Hệ thống quản lý phiên bản dự án phần mềm Subversion, Nguyễn Khắc Trọng

Phạm Duy Sơn, Dương Văn Tuyến.

http://vnwildman.users.sourceforge.net/gitmagic/

Documents

Hệ thống quản lý phiên bản