| blob | 185d5bfbf070b5baa4d47317cb9fc4f6efaa1f22 |
1 == Nhân Bản ==
3 Trong các hệ thống quản lý mã nguồn trước đây, checkout là tác vụ cơ bản để lấy các tập tin về. Bạn lấy về toàn bộ các tập tin được lưu giữ trong từng phiên bản riêng biệt.
5 Với Git và các hệ thống quản lý mã nguồn phân tán, clone là tác vụ cơ bản. Để lấy các tập tin, bạn lấy về toàn bộ kho chứa. Nói cách khác, bạn thực tế là một bản sao của máy chủ trung tâm. Bất kỳ cái gì bạn thể làm được với kho chứa chính thì cũng làm được ở đây.
7 === Đồng bộ hóa Các Máy tính ===
9 Tôi có thể tạo gói *tarball* hay sử dụng lệnh *rsync* để sao lưu dự phòng và đồng bộ hóa dữ liệu. Nhưng thỉnh thoảng, tôi biên tập trên máy tính xách tay của mình, nhưng lúc khác lại trên máy tính để bàn, và chúng có thể không có sự trao đổi được với nhau.
11 Khởi tạo kho chứa Git và commit các tập tin trên một máy tính. Sau đó trên máy tính kia chạy lệnh:
13 $ git clone other.computer:/path/to/files
15 để tạo một bản sao thứ hai cho các tập tin và kho chứa. Từ giờ trở đi,
17 $ git commit -a
18 $ git pull other.computer:/path/to/files HEAD
20 sẽ lấy về một trạng thái của các tập tin trên máy tính khác về máy bạn đang làm việc. Nếu bạn vừa tạo ra một sự chỉnh sửa xung đột trong cùng một tập tin, Git sẽ cho bạn biết và bạn có thể chuyển giao sau khi đã sửa chữa chúng.
22 === Quản lý theo cách Cũ ===
24 Khởi tạo kho Git cho các tập tin của bạn:
26 $ git init
27 $ git add .
28 $ git commit -m "Lần commit khởi tạo"
30 Trên máy chủ trung tâm, khởi tạo kho 'thuần' ở một thư mục nào đó:
32 $ mkdir proj.git
33 $ cd proj.git
34 $ git --bare init
35 $ touch proj.git/git-daemon-export-ok
37 Khởi động dịch vụ Git nếu cần:
39 $ git daemon --detach # nó có thể đã hoạt động rồi
41 Để làm một máy chủ chạy dịch vụ Git, làm theo các chỉ dẫn sau để cài đặt
42 và khởi tạo kho Git. Cách thường thấy nhất là điền vào mẫu có sẵn trên trang web.
44 'Push' dự án của bạn lên máy chủ trung tâm bằng lệnh:
46 $ git push central.server/path/to/proj.git HEAD
48 Để lấy về mã nguồn, các nhà phát triển phần mềm chỉ cần gõ:
50 $ git clone central.server/path/to/proj.git
52 Sau khi thay đổi, các nhà phát triển phần mềm sẽ lưu lại các thay đổi trên máy tính của mình:
54 $ git commit -a
56 Để cập nhật lên bản mới nhất:
58 $ git pull
60 Mọi xung đột phải được xử lý trước, sau đó mới chuyển giao:
62 $ git commit -a
64 Gửi thay đổi của mình lên máy chủ trung tâm:
66 $ git push
68 Nếu máy chủ trung tâm có thay đổi bởi hành động của một người phát triển phần mềm khác, quá trình
69 push sẽ bị lỗi, và anh ta phải pull về bản mới nhất, xử lý các xung đột khi trộn, sau đó thử lại.
71 Người dùng phải có quyền truy cập SSH mới có thể thực hiện được lệnh pull và push ở trên.
72 Tuy nhiên, ai cũng có thể lấy mã nguồn về bằng lệnh:
74 $ git clone git://central.server/path/to/proj.git
76 Giao thức git nguyên bản thì cũng giống như là HTTP: ở đây không cần xác thực, do vậy ai cũng có thể
77 lấy về dự án. Do vậy, theo mặc định, việc push thông qua giao thức git là
78 không được phép.
80 === Mã nguồn riêng tư ===
82 Với một dự án nguồn-đóng, bỏ quên lệnh touch, và chắc chắn là chưa từng
83 tạo ra file nào có tên `git-daemon-export-ok`. Kho chứa từ giờ trở đi không thể lấy về
84 thông qua giao thức git; chỉ những người có khả năng truy cập bằng SSH mới có thể thấy nó. Nếu tất cả
85 các kho chứa đều đóng, việc chạy git daemon là không cần thiết nữa bởi vì tất cả
86 việc truyền thông bây giờ đều thông qua SSH.
88 === Kho thuần ===
90 Kho thuần (bare) được đặt tên như vậy vì nó không chứa thư mục làm việc; nó 'thuần túy' chứa các tập tin thường là ẩn trong thư mục con `.git`. Hay nói cách khác, nó chứa lịch sử mã nguồn của một dự án, và không bao giờ giữ các tập tin bất kỳ phiên bản nào.
92 Kho thuần có vai trò hoạt động giống như máy chủ trung tâm trong các hệ thống
93 quản lý mã nguồn tập trung: thư mục chủ dự án của bạn. Các nhà phát triển phần mềm nhân bản
94 dữ liệu dự án của bạn ở đây, và 'push' các thay đổi chính thức lên đó. Thông thường nó
95 đặt tại máy chủ mà máy này đôi khi còn làm một số việc khác nữa. Sự biên soạn mã nguồn
96 xảy ra trên bản sao, vì vậy thư mục chủ của kho chứa có thể hoạt động mà không cần
97 thư mục làm việc.
99 Nhiều lệnh Git gặp lỗi trên kho thuần trừ phi biến môi trường `GIT_DIR` được đặt với giá trị là đường dẫn đến kho chứa, hay tùy chọn `--bare` được áp dụng.
101 === Push ngược với pull ===
103 Tại sao chúng tôi lại giới thiệu lệnh 'push', thay vì trông cậy vào lệnh 'pull'
104 quen thuộc? Trước hết, việc pull gặp lỗi trên kho thuần: thay vào đó bạn phải dùng lệnh 'fetch',
105 lệnh này chúng ta sẽ nói sau. Nhưng dù là chúng ta giữ kho chứa thông thường trên
106 máy chủ trung tâm, việc 'pull' lên nó hơi cồng kềnh. Chúng ta phải
107 đăng nhập vào máy chủ trước, và cung cấp cho lệnh 'pull' địa chỉ mạng
108 của máy chúng ta đang 'pull' từ đó. Chương trình tường lửa có thể gây trở ngại, và điều gì xảy ra khi chúng ta không
109 có khả năng truy cập 'hệ vỏ' máy chủ trong chỗ đầu tiên đó?
111 Tuy nhiên, ngoài trường hợp này ra, chúng ta còn nản lòng với việc push lên kho chứa, bởi vì tình trạng hỗn loạn có thể xảy khi thư mục đích có chứa thư mục làm việc.
113 Tóm lại, khi bạn học Git, chỉ 'push' khi đích là kho thuần; nếu không thì dùng 'pull'.
115 === Rẽ nhánh một dự án ===
117 Bạn chán ngấy cách mà dự án mà bạn đang làm việc chạy? Bạn nghĩ mình có thể làm tốt hơn thế? Thế thì trên máy chủ của mình:
119 $ git clone git://main.server/path/to/files
121 Tiếp theo, nói với mọi người về việc nhánh rẽ từ dự án tại máy chủ của bạn.
123 Từ bây giờ trở đi, bạn có thể trộn các sự thay đổi từ dự án gốc với lệnh:
125 $ git pull
127 === Sao lưu không giới hạn ===
129 Bạn muốn lưu trữ dự án của mình ở nhiều nơi khác nhau ư? Nếu dự án của bạn có nhiều người cùng phát triển, bạn không cần phải làm gì cả! Mỗi một bản sao đều đồng thời có tác dụng như một bản sao lưu dự phòng. Mỗi bản sao không chỉ lưu trạng thái hiện hành mà toàn bộ lịch sử trong dự án. Nhờ có giá trị băm bằng mật mã, nếu bản sao của người nào đó bị hỏng, nó sẽ được phát hiện ngay sau khi họ liên lạc với những người khác.
131 Nếu dự án của bạn không phổ biến, hãy tìm máy chủ lưu giữ bản sao của mình càng nhiều càng tốt.
133 Người mắc bệnh hoang tưởng sẽ luôn luôn ghi ra 20-byte giá trị băm SHA1 cuối cùng của HEAD ở đâu đó an toàn. Nó phải an toàn, không riêng tư. Ví dụ, xuất bản nó lên báo giấy cũng tốt, bởi vì rất khó để thay đổi tất cả các bản sao của nó.
135 === Làm nhiều việc cùng lúc ===
137 Bạn muốn làm nhiều việc cùng một lúc trên một dự án. Thế thì hãy commit dự án của bạn và chạy:
139 $ git clone . /some/new/directory
141 Nhờ có http://en.wikipedia.org/wiki/Hard_link[liên kết cứng], việc nhân bản nội bộ
142 yêu cầu ít không gian và thời gian hơn so với việc sao lưu thông thường.
144 Bây giờ bạn có thể làm hai công việc độc lập nhau cùng một lúc. Ví dụ như, bạn
145 có thể biên soạn trên bản sao này trong khi bản sao kia đang được biên dịch. Tại bất kỳ thời điểm nào, bạn cũng có thể commit
146 và pull các thay đỏi từ một bản sao khác:
148 $ git pull /the/other/clone HEAD
150 === Song hành cùng các hệ thống SCM khác ===
152 Bạn đang làm việc cho một dự án có sử dụng hệ thống quản lý mã nguồn cũ, và bạn lại muốn sử dụng Git? Thế thì hãy khởi tạo kho chứa Git trong thư mục bạn đang làm việc:
154 $ git init
155 $ git add .
156 $ git commit -m "Lần commit khởi tạo"
158 sau đó nhân bản nó:
160 $ git clone . /some/new/directory
162 Bây giờ hãy chuyển đến thư mục mới đó và làm việc ở đây thay vì chỗ cũ, sử dụng Git để thỏa mãn tình yêu của mình. Đôi khi, bạn sẽ muốn đồng bộ hóa với những người khác nữa, trong trường hợp đó hãy chuyển tới thư mục nguyên gốc, đồng bộ hóa bằng cách sử dụng một hệ thống quản lý mã nguồn khác, và gõ:
164 $ git add .
165 $ git commit -m "Đồng bộ hóa với những người khác"
167 Sau đó chuyển tới thư mục mới và chạy:
169 $ git commit -a -m "Mô tả về các thay đổi của mình"
170 $ git pull
172 Thủ tục đem lại các thay đổi của bạn tới những người khác nữa trên hệ thống quản lý mã nguồn khác. Thư mục mới có chứa các tập tin mà bạn thay đổi. Chạy các lệnh mà hệ thống quản lý mã nguồn khác cần để tải chúng lên kho chứa trung tâm.
174 Subversion, có lẽ là hệ thống quản lý mã nguồn tập trung tốt nhất, được sử dụng bởi vô số các dự án. Lệnh *git svn* sẽ tự động hóa những việc đã nói ở trên dành cho Subversion, bạn cũng có thể làm như thế để http://google-opensource.blogspot.com/2008/05/export-git-project-to-google-code.html[xuất dự án Git thành Subversion].
176 === Mercurial ===
178 Mercurial là hệ thống tương tự như hệ thống quản lý mã nguồn có thể làm việc gần giống như Git. Với plugin `hg-git`, người sử dụng Mercurial có thể push và pull từ kho Git mà không mất mát gì.
180 Lấy plugin `hg-git` dành cho Git bằng cách:
182 $ git clone git://github.com/schacon/hg-git.git
184 hay là sử dụng Mercurial:
186 $ hg clone http://bitbucket.org/durin42/hg-git/
188 Thật buồn là tôi không biết rằng có một plugin tương tự dành cho Git. Vì vậy, tôi ủng hộ Git hơn Mercurial khi dùng cho kho chứa chính, dù là bạn thích Mercurial hơn. Với một dự án Mercurial, thường thường một người tình nguyện duy trì kho Git song song cho tương thích với người sử dụng Git, cũng phải cảm ơn plugin `hg-git`, một dự án Git tự động tiếp nhận người sử dụng Mercurial.
190 Mặc dù plugin có thể chuyển đổi Mercurial sang Git bằng cách push tới một kho rỗng, công việc này là dễ dàng với script `hg-fast-export.sh`, đã sẵn dùng từ:
192 $ git clone git://repo.or.cz/fast-export.git
194 Để chuyển đổi, trong một thư mục rỗng hãy chạy:
196 $ git init
197 $ hg-fast-export.sh -r /hg/repo
199 sau khi đặt script vào trong biến môi trường `$PATH`.
201 === Bazaar ===
203 Chúng tôi đề cập vắn tắt về Bazaar bởi vì nó là hệ thống quản lý mã nguồn phân tán
204 miễn phí và phổ biến nhất chỉ sau Git và Mercurial.
206 Bazaar có lợi thế vì phát triển sau, có tuổi tương đối trẻ; những người thiết kế ra nó có thể học hỏi được nhiều từ các sai lầm trong quá khứ, và tránh được vết xe đổ. Ngoài ra, các nhà phát triển còn lưu tâm đến khả năng chuyển đổi và tương tác với các hệ thống quản lý mã nguồn khác.
208 Plugin `bzr-git` giúp người dùng Bazaar làm việc với kho Git trong chừng mực nào đó. Chương trình chuyển đổi Bazaar thành Git, và có thể làm hơn thế nữa, trong khi `bzr-fast-export` thích hợp nhất cho việc chuyển đổi một lần duy nhất.
210 === Tại sao Tôi dùng Git? ===
212 Trước tiên, tôi chọn Git bởi tôi nghe nói nó làm được việc phi thường là có thể quản lý mã nguồn cho một thứ khó quản lý như hạt nhân của hệ điều hành *Linux*. Tôi chưa bao giờ nghĩ đến việc chuyển sang dùng một phần mềm quản lý mã nguồn khác. Git làm được những việc thật đáng ngưỡng mộ, và tôi chưa từng bao giờ gặp các vấn đề với sai sót của nó. Do tôi hoạt động chủ yếu trên Linux, phát hành trên các nền tảng khác không phải là điều mà tôi quan tâm.
214 Ngoài ra, tôi thích lập trình bằng ngôn ngữ C và bash scripts để thực thi như là ngôn ngữ kịch bản Python: ở đây có rất ít sự phụ thuộc, và tôi đam mê với những hệ thống thi hành nhanh chóng.
216 Tôi đã nghĩ về việc làm thế nào để Git có thể phát triển, xa hơn nữa là tự mình viết một công cụ tương tự như Git, nhưng đây không phải là bài tập có tính thực tế. Khi tôi hoàn thành dự án của mình, dù sao đi nữa tôi vẫn sẽ dùng Git, với lợi thế là có thể chuyển đổi từ hệ thống cũ sang một cách nhanh chóng.
218 Theo lẽ tự nhiên, những thứ cần thiết cho bạn và những thứ bạn mong muốn có lẽ khác nhau, và bạn có thể tốt hơn nếu mình làm việc với hệ thống khác. Dù sao đi nữa, bạn sẽ không bao giờ phải hối tiếc vì đã chọn Git.