Hệ Thống Quản Lý Phiên Bản Theo Mô Hình Phân Tán

(Distributed Version Control System)

GVHD :NGUYỄN MINH ĐỨC

SINH VIÊN :

NGUYỄN NGỌC LAN ĐÀI

TRẦN TIẾN LONG

NGUYỄN ĐỨC ANH

1. Tổng quan về hệ thống quản lý phiên bản

a.Tại sảo phải có các hệ thống quản lý phiên bản (Version control system)

Trong công nghệ phần mềm các lập trình viên ,nhóm làm việc với nhiều dự án ,mỗi dự án lại có nhiều phiên bản khác nhau , trong mỗi phiên bản việc liên tục chỉnh sửa mã nguồn là điều không chánh khỏi .Khi các dự án và các phiên bản đã làm việc có số lượng lớn thì việc quản lý các phiên bản phải liên tục sử đổi và dự án trở nên phức tạp

VD: Mỗi khi cần lấy lại một số mã nguồn cũ để phát triển thêm lập trình viện lại phải nhớ vị trí nơi lưu trữ bản sao , hoặc khi cần một đoạn mã nguồn trước đó hiện tại

đã bị chỉnh sửa thì lập trình viên lại phải viết lại , việc chia sẻ,phân chia mã nguồn giữa các thành viên mất thời gian …

Chính vì vậy cần phải có một hệ thống quản lý phiên bản (VCS - version control system),

- Nó lưu giữ các phiên bản của mã nguồn của sản phẩm phần mềm một cách ngăn nắp,trình tự bên trong một thư mục được gọi là Repository

- Theo dõi ,sao lưu,đồng bộ hóa các thay đổi ,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

- Cho phép nhiều developer cộng tác với nhau để cùng phát triển dự án ( http://vi. wikipedia.org/wiki/h ệ_ thống _ quản _ lý _ phiên _ bản )

b. Một số khái niệm sử dụng trong các hệ thống quản lý phiên bản

(Theo http://vi.wikipedia.org/wiki/VCS )

- Repository:Thư mục lưu trữ tất cả các phiên bản của tất cả các file và những thay đổi của chúng ,nó có thể là nơi chứa các file mã nguồn , hỉnh ảnh ,âm thanh …

(Repository của Egit – một plug in của Eclipse)

- Phiên bản: Mỗi tập tin có thể có nhiều phiên bản (version). Các phiên bản được đánh số khác nhau. Mỗi lần chúng ta hiệu chỉnh nội dung tập tin và cập nhật vào nơi chứa của VCS, phiên bản sẽ được cập nhật.

Một số VCS sử dụng hệ thống phiên bản 1, 2, 3, ... trong khi có một số khác sử dụng hệ thống 1.0, 1.1, 1.2, ... Các VCS thường lưu phiên bản cuối cùng và các thay đổi của các phiên bản trước so với phiên bản cuối đó.

Các số phiên bản (như 1.0, 1.1, hay 1.2,...) còn được gọi là revision. Đi đôi với số phiên bản, VCS lưu thêm các thông tin về ngày giờ cập nhật, người cập nhật và một số ghi chú nếu có.

Một vấn đề nhỏ trong cách đánh số này là làm sao các thành viên trong nhóm biết được các phiên bản của dự án. Số phiên bản trong dự án sẽ thay đổi khi phiên bản của tập tin thay đổi. Các VCS do đó sử dụng thêm một cách ghi nhận phiên bản là đánh nhãn (labeling, tag). Khi đó, cho dù số phiên bản của dự án thay đổi, nhãn của dự án vẫn không đổi.

- Branch (phân nhánh) : Khi làm việc nhóm, mọi thành viên đều có một phần mã chung, gọi là nhánh chính (mainline). Và các thành viên đều làm việc với một phần của nhánh chính. Khi có yêu cầu tách một phần mã chung đó, ví dụ như để tạo một phiên bản để thử nghiệm, các thành viên của nhóm phân phối thử nghiệm đó cần mã độc lập với nhánh chính. Giải pháp là dùng phân nhánh.

Chia nhánh (branching) là một cơ chế của hệ thống quản lý phiên bản cho phép tách một phần của dự án ra riêng. Phần này sẽ hoạt động độc lập với dự án chung. Khi đó, việc đánh phiên bản cũng thay đổi.

Ví dụ: nếu một tập tin A trong nhánh chính có số phiên bản là 1.14 và một nhánh mới được tạo ra, A sẽ có số phiên bản trong nhánh là 1.14.1.1. Việc hiệu chỉnh tập tin đó trong nhánh chính sẽ

cho chỉ số phiên bản mới trong nhánh chính là 1.15 tuy nhiên nếu hiệu chỉnh tập tin đó trong nhánh thì nó có số phiên bản mới là 1.14.1.2

- Check out: Download một hoặc nhiều file từ Repository về thư Repository client ở máy mình.Quá trình này bắt đầu đưa một phiên bản của project từ trên Server để làm việc

Vi dụ về quá trình Check out sử sụng Subversion một hệ thống quản lý phiên bản

- Commit: Lưu những sửa đổi của phiên bản trong Repository

Hình ảnh minh họa quá trình commit

- Merge (Gộp): Nhóm nội dung của 2 file lại với nhau thay ,trong một số trường hợp cần thiết thay vì tạo thêm một phiên bản mới có nội dung của 2 file .Khi gộp 2 file lại với nhau vì mỗi phiên bản có những dòng code không giống nhau vì thế có thể xảy ra xung đột như hình :

http://www.benefitsflex.net/perl_tools/

- Push: Việc đưa tất cả các commit lên Repository ở Server .Phương thức này chỉ sử dụng cho mô hình phân phối (DVCS)

- Pull: Cập nhật những thay đổi của Repository ở Server .Phương thức này chỉ sử dụng cho mô hình phân phối (DVCS).

c. Các loại mô hình của hệ thống quản lý phiên bản.

- Mô hình tập trung: Centralized version control system (CVCs) :các hệ thống sử dụng mô hình này đang được sử dụng chủ yếu như CVS , Subversion (SVN)…(Hình ảnh được lấy trong ebook: Pro Git – Scott chacon)

Mô hình tập trung sử dụng kiến trúc Client - Server trong đó

server chứa tất cả các files phiên bản ,hiện tại của dự án và lịch sử các thay đổi chỉnh sửa trên các file đó ,

các client kết nối tới server để lầy về một phiên bản copy đầy đủ dự án(check out) , hoặc cập nhật những thay đổi mới nhất từ dự án (update) ,làm việc trên phiên bản đó và sau đó lưu lại những thay đổi của họ (commit).

Client và server có thể 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 CVS có nhiệm vụ theo vế 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ộ.

Phần mềm server thường chạy trên Unix trong khi CVS client có thể chạy trên nhiều hệ điều hành khác nhau

(trích từ : http://vi.wikipedia.org/wiki/CVS)

Kiến trúc client – server là đặc trưng của VCS , cả 2 hệ thống tập trung và phân bố đều sử dụng kiến trúc này .

- Mô hình phân tán : Distributed version control system (DVCs) Các hệ thống sử dụng mô hình này hiện nay là Git, Mercurial, Bazaar,Darcs

Mỗi thành viên sẽ có một repository ở local và tất cả các thao tác như commit, add… đều làm việc trực tiếp với nó giống như bản nó vừa là client vừa là một server.Các thành viên

trong local có thể share trực tiếp với giao thông qua share SSH.Và nó cũng cũng hoạt động được với kiến trúc client – server như trong CVCs

2. Ứng dụng của DVCs Một số ứng dụng của DVCs

http://code.google.com/

Google code đã sử dụng 2 hệ thống quản lý để người dùng lựa chọn là Subversion của hệ thống tập trung và Mercurial của hệ thống phân tán

Git cũng là một DVCs và hiện tại Git được rất nhiều các cộng đồng lập trình viên thế giới sử dụng.

https://qt.gitorious.org/ (Đây cũng là một mạng xã hội lập cho trình viên sử dụng Git để quản lý các project)

Các Repository của Linux Kernel

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary

http://android.git.kernel.org/

http://android.git.kernel.org/?p=device/common.git;a=summaryBên trong một Repo đầu tiên tên là “common” có các thông tin về URL để làm việc với Repo trên server nhà nhật kí các commit

https://www.ohloh.net/repositories/compare

Đây là bản đồ thống kế các công cụ được sử dụng để quản lý mã nguồn các project trên trang ohloh.net .Cho thấy các hệ thống quản lý phân tán (Git + mercurial + Bazaar ) mặc dù ra sau nhưng đang ngày càng được quan tâm và sử dụng, đặc biệt là Git

Ảnh chụp số người tham gia github.com (một mạng xã hội cho lập trình viên sử dụng Git để quản lý mã nguồn) và các Repository được sử dụng vào khoảng cuối tháng 10/2010 (ảnh trên trang : http://namheo.com/blog) . Git cũng được rất nhiều cộng đồng lập trình viên trên toàn thế giới sử dụng như Twitter,facebook,yahoo,….

Ảnh chụp số người tham gia github và số lượng các Repository được sử cho thấy hiện tại số lượng người sử dụng dịch vụ sử dụng Git tăng rất nhanh.

Việt Nam:

https://github.com/DrupalVietNam

https://github.com/sanglt

Chỉ với một từ khóa tiếng việt có thể tìm kiếm rất nhiều các lập trình viên Việt Nam của các công ty phần mềm hiện đang sử dụng github để quản lý mã nguồn

Một số Git hosting (Nơi lưu trữ source code hỗ trợ quản lý bằng Git)https://git.wiki.kernel.org/index.php/GitHosting

3. Kết quả nghiên cứu của một số nhóm trước đó

Các nghiên cứu của một số nhóm trước đó đã giới thiệu về hệ thống phân bố qua qua việc tìm hiểu về Git một VCS sử dụng hệ thống phân bố và Github (mạng xã hội cho lập trình viên) nhưng hầu hết chỉ ở mức ngắn gọn chưa khái quát hết .Có thể xem bài viết được đánh giá cao tại

http://namheo.com/blog/share/phần-i-git-hệ-thống-quản-ly-source-phan-tan

4. Nội dung thực hiệna. Mô hình của DVCS:

(ebook Pro Git – Scott Chacon –Publishes:APRESS)

DVCS cũng là một server ,có một Repository để mọi người gửi những thay đổi lên, mỗi client có một Repo nằm ở máy họ ,vì vậy họ chỉ cần kết nối đến Repository trung tâm khi cảm thấy thích chia sẻ những thay đổi.Và các hoạt động như commit , update xảy ra ở Repository nằm ở trên máy , chúng được đồng bộ với Repository trung tâm thông qua push/pull.Nhưng trong mô hình phân phối bất cứ ai cũng có thể là một máy chủ nên có thể Push/pull với nhau.

http://docs.joomla.org/Dvcs

b. Một số Workflow Của hệ thống phân tán(Theo ebook: Pro Git – Scoot chacon)

Centralized Workflow:

Trong hệ thống tập trung ,có chung một mô hình hợp tác duy nhất Centralized Workflow “Share repository” là một Repo trung tâm mà mọi người có thể gửi các thay đổi và cập nhật, đồng bộ hóa .Những developer là những node của Repo trung tâm đó.Khi 2 developer cùng gửi (Push) những thay đổi lên một Repo , thì người gửi lên sau phải cập nhật (Pull) những thay đổi mà người trước đó đã gửi lên và giải quyết các xung đột mã sau đó mới gửi lên được

Integration-Manager Workflow:

Vì DVCs cho phép có nhiều Repository trung tâm,nên nó có thể có một Workflow mà mỗi developer truy cập và gửi những thay đổi lên Repo public và đọc từ những Repo khác .Kịch bản này thường bao gồm một Repo chuẩn đại diện cho dự án .Để một developer đóng góp vào dự án thì developer tạo cho riêng mình một bản sao dự ánvà đưa (push) những thay đổi lên.Sau đó có thể gửi những yêu cầu cập nhật những thay đổi đó vào dự án chính và nếu được dự án chính sẽ cập nhật (pull) những thay đổi đó.Và người kiểm soát dự án chính có thể test những thay đổi và gộp (merge) những thay đổi đó ở trong nhánh làm việc của họ ở máy của họ và push trở lại Repo chính.

(Ebook: “Pro git”,tác giả : scott chacon,NXB:APPRES )

Kịch bản:

1. Người chủ dự án chính Push những thay đổi vào Public Repository của họ

http://Github.com

2. Người đóng góp sao (Clone) sao Publick Repository đó và phát triển thêm

3. Người đóng góp sẽ Push những thay đổi đó lên copy Public Repository4. Người đóng góp sẽ gửi một mail hói họ có muốn update thêm những thay đổi

mà họ tạo ra không5. Người chủ dự án Add Repo của người đóng góp giống như họ remote Repo

đó từ xa và gộp (Merge) nội dung thay đổi vào nhánh làm việc chính 6. Chủ dự án Push những thay đổi đó lên nhánh chính

Đây là Workflow phổ biến với những trang như github.com

Một trong những ưu điểm chính của phương pháp này là bạn có thể tiếp tục làm việc và người chủ của dự án chính có thể cập nhật những thay đổi trong của bạn tại bất kì thời điểm nào .Người đóng góp không phải đợi project tích hợp những thay đổi của họ,mỗi bên có thể làm việc với nhịp độ của riêng họ

Dictator and Lieutenants Workflow

(Ebook: “Pro git”,tác giả : scott chacon,NXB:APPRES )

Đây là một biến thể của Integration Manager Workflow .Nó thường được sử dụng bời các dự án lớn với hàng trăng cộng tác viên;một ví dụ nổi tiếng là Linux Kernel.Các integration managers được phụ trách phần nhất định của Repository, họ được gọi là “lieutenants”- phụ tá.Tất cả các lieutenants có một integration manager được gọi như nhà độc tài (dictator)nhân từ. Các repo của các dictator đóng vai trò như Repo tham khảo mà từ đó tất cả các cộng tác viên cần để cập nhật (pull)

Kịch bản:

1. Các nhà phát triển thông thường làm việc trên nhánh chủ đề (topic branch) của họ và tái cơ sở (rebase) công việc của họ trên cùng của tổng thể (master).Nhánh master là của dictator

2. Các lieutenant gộp (merge) các nhánh chủ đề của các developer vào nhánh chính (main branch) củ dictator.

3. Dictator push master của họ đến Repo tham khảo vì thế những Dev khác có thể rebase(căn cứ lại) trên nó

Loại Workflow này không phổ biến nhưng có thể hữu ích trong các dự án rất lớn hoặc các môi trường phân cấp cao vì nó cho phép các trưởng dự án (dictator) ủy nhiệm nhiều công việc và thu thập một tập lớn các mã tại nhiều điểm trước khi tích hợp chúng. a

c. So sánh giữa hệ thống phân tán và hệ thống tập trung

CVCS DVCS

Mục đích(http://stackoverflow.com/questions/111031/comparison-between-centralized-and-distributed-version-control-systems)

Được thiết kế với mục đích có một Source chuẩn nhất và tất cả các developer làm việc (check out) từ source đó,và sau đó lưu (commit) những thay đổi .Chỉ có sự khác biệt thực sự giữa CVS ,SVN,ClearCase,Perforce ,VisualSourceSafe và tất cả các CVCS khác là trong Workflow, hiệu xuất và tích hợp mỗi sản phẩm cung cấp

Hệ thống được thiết kế với mục đích là một Repo tốt tương đương với bất kì Repo khác,và merge từ một repo đến repo kahcs là chỉ khác hình thức giao tiếp.Bất kì giá trị ngữ nghĩa đáng tin cậy được áp đặt từ bên ngoài chứ không phải bản thân chương trình

Mô hình làm việc(http://namheo.com/blog/share/ph%E1%BA%A7n-i-git-h%E1%BB%87-th%E1%BB%91ng-qu%E1%BA%A3n-ly-source-phan-tan/)

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

Quản lý phân 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)

An toàn (http://namheo.com/blog/share/ph%E1%BA%A7n-i-git-h%E1%BB%87-th%E1%BB%91ng-qu%E1%BA%A3n-ly-source-phan-tan/)

Khi server bị dow hoặc lỗi sẽ không làm việc được hoặc mất dữ liệu

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 (push)tất cả lên lại server

Tốc độ(http://whygitisbetterthanx.com/#cheap-local-branching)

CVCS làm việc giữa client và server nên tốc độ chậm

Git làm việc với mọi thao tác trực tiếp trên Repository của Local nên nhanh hơn.

Kích thước Repository(http://nguontrithuc.net/mybb/thread-2318-post-8470.html#pid8470)

Kích thước repository thường chỉ bằng 1.5 lần kích thước project nó chứaRepository của Mozilla chiếm khoảng 12GB khi dùng SVN

khi chuyển sang Git thì chỉ chiếm khoảng 400MB.

Phạm vi ứng dụng Có thể sử dụng trong các dự án private ,các công ty ,tổ chức vì có mô hình Client – Server nên việc thực hiện các Workflow cho các cộng đồng mã nguồn mở như “mạng xã hội cho lập trình viên” như github hoặc dự án lớn đông người như linux kernel là rất khó khăn,

Có thể sử dụng ở mọi phạm vi ,rất thích hợp cho việc phát triển cộng đồng mã nguồn mở và với các dự án lớn đông người tham gia cùng phát triển

Dung lượng Repository ở client

Nhỏ vì client khi làm việc chỉ lấy về một phiên bản từ server nếu muốn phiên bản khác họ có thể cập nhật ,nên cũng chính vì thế mà khởi đầu nó nhanh hơn DVCS

Repository của DVCS là một bản sao của Repository trên server ,nó chúa tất cả các phiên bản và lịch sử làm việc nên nó sẽ tốn nhiều dung lượng nếu developer làm việc với dự án lớn. Khời đầu chậm hơn

Cơ chế khóa Là một phần của hầu hết CVCS Thiếu cơ chế khóa

d. Git và Github Giới thiệu về Git

Git - Hệ thống quản lý source phân tán (DVCS) được dùng phổ biến nhất trong số các DVCS hiện có.Một trong những lợi thế của Git đó là nó được xây dựng để làm việc trên Linux kernel, nghĩa là nó được dùng để giải quyết hiệu quả với các Repository lớn .Thêm vào đó Git được viết bằng C, giảm thời gian chạy so với các chương trình khác viết bằng ngôn ngữ bậc cao hơn.Một lý do cho tốc độ quá nhanh so với các chương trình khác đó là các nhà phát triển chính đã thực hiện mục tiêu này để thiết kế một số ứng dụng (mạng xã hội cho lập trình viên)

Đây là kết quả test khi sử dụng các DVCS khác nhau với cũng một mã nguồn

http://whygitisbetterthanx.com/#git-is-fast

Ngoài việc nhanh hơn Git cũng tiết kiệm được không gian lưu trữ trên hosting hơn các công cụ khác

Đây là kết quả test khi push một project lên hosting

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 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 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) 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)

(http://namheo.com/blog/share/ph%E1%BA%A7n-iii-git-%E2%80%93-t%E1%BA%A1i-sao-nen-s%E1%BB%AD-d%E1%BB%A5ng-git/)

Cài đặt Git

Vào trang http://git-scm.com/ chọn hệ điều hành và download:

Các bước cài đặt:

Sử dụng Git thông qua GitHub

GitHub là mạng xã hội dành cho lập trình viên lớn nhất và dễ dùng nhất. Một số tính năng hấp dẫn , cách tiếp cận dễ nhất để học Git là sử dụng Github vì khi sử dụng Github sẽ được học từng bước sử dụng git để làm việc với github một cách đơn giản và dễ hiểu

https://github.com/

http://help.github.com/win-set-up-git/

Wiki, issue, thống kê, đổi tên project, project được đặt vào namespace là user. Watch project: theo dõi hoạt động của project của người khác, xem quá trình người ta

phát triển phầm mềm thế nào, project tiến hoá ra sao. Follow user: theo dõi hoạt động của người khác, biết người ta làm project gì mới, người

ta follow user nào, xu hướng quan tâm cái gì (= công nghệ gì).

(http://lilylnx.wordpress.com/2010/06/10/github-com-mang-xa-hoi-danh-cho-lap-trinh-vien/)

Các công cụ hỗ trợ dao diện đồ họa cho Git

Khi Git mới xuất hiện thì hiện chưa có nhiều công cụ dao diện hỗ trợ cho nó khi làm việc trên nhiều công cụ lập trình thậm chí đến hiện giờ nhiều người chưa tìm hiểu về Git cũng vẫn còn nghĩ như vậy.Nhưng chó đến thời điểm này Git đã có khá nhiều công cụ dao diện hỗ trợ thay cho việc dùng Git tool chạy bằng các dòng lệnh Linux như trong hướng dẫn của github.Sau đây là một số công cụ hỗ trợ dao diện

Nbgit (Cho Netbeans)

http://nbgit.org/

http://code.google.com/docreader/#p=nbgit&s=nbgit&t=nbgit

http://eecchhoo.wordpress.com/

Git Extension (Cho Visual 2005/2008/2010)

http://stackoverflow.com/questions/97704/what-to-use-for-version-control-with-visual-studio-2008-for-inhouse-projects

https://sourceforge.net/projects/gitextensions/

Thông tin chi tiết xem tại:

http://code.google.com/p/gitextensions/

Egit (Cho Eclipse)

Đây là công cụ có nhiều hướng dẫn chi tiết và dễ sử dụng

http://www.eclipse.org/egit/

Hướng dẫn chi tiết từng bước thực hành và giải thích một số khái niệm trong Egit:

http://wiki.eclipse.org/EGit/User_Guide#Getting_Started

Hoặc có thể xem thêm một số hướng dẫn ở :

http://www.vogella.de/articles/EGit/article.html