Spanish translation of secrets.txt by Oscar Uribe.
[gitmagic.git] / vi / multiplayer.txt
blob8082a314cdfe9ceeb2212521a75e7e6203c3fa25
1 == Đa Người Dùng ==
3 Lúc đầu tôi sử dụng Git cho dự án riêng của mình mà tôi cũng là người duy nhất phát triển nó.
4 Trong số những lệnh liên quan đến bản chất phân tán của Git, tôi chỉ cần lệnh *pull*
5 và *clone* để giữ cùng một dự án nhưng ở những chỗ khác nhau.
7 Sau đó tôi muốn mã nguồn của mình được phổ biến trên mạng bằng việc sử dụng Git, và bao gồm cả những thay đổi từ
8 những người đóng góp. Tôi đã phải học cách làm thế nào để quản lý các dự án có nhiều người phát triển phần mềm
9 ở khắp nơi trên toàn thế giới. May mắn thay, đây là sở trường của Git, và người ta có thể nói đây là
10 điều sống còn của một hệ thống quản lý mã nguồn.
12 === Tôi Là Ai? ===
14 Mỗi lần commit sẽ lưu giữ tên và địa chỉ thư điện tử, điều này có thể nhìn thấy bằng lệnh *git log*.
15 Theo mặc định, Git sử dụng các trường để lưu giữ các cài đặt trong hệ thống của mình.
16 Để cài đặt các thông tin cá nhân của mình vào, hãy gõ:
18   $ git config --global user.name "John Doe"
19   $ git config --global user.email johndoe@example.com
21 Bỏ qua cờ global để đặt những thông tin này chỉ sử dụng cho kho chứa hiện tại.
23 === Git Thông Qua SSH, HTTP ===
25 Giả sử bạn có thể truy cập vào một máy chủ web qua SSH, nhưng Git lại chưa được cài đặt ở đây. Mặc dù
26 không hiệu quả như giao thức nguyên bản của nó, nhưng Git vẫn có thể truyền thông thông qua HTTP.
28 Tải về, dịch và cài Git bằng tài khoản của bạn, và tạo kho chứa tại
29 thư mục chứa trang web của bạn:
31  $ GIT_DIR=proj.git git init
32  $ cd proj.git
33  $ git --bare update-server-info
34  $ cp hooks/post-update.sample hooks/post-update
36 Với các phiên bản Git cũ, lệnh copy không thực hiện được và bạn phải chạy:
38  $ chmod a+x hooks/post-update
40 Từ giờ bạn có thể xuất bản mới nhất của mình thông qua SSH từ một bản sao bất kỳ:
42  $ git push máy.chủ.web:/đường/dẫn/đến/proj.git master
44 và mọi người có thể lấy dự án của bạn với lệnh:
46  $ git clone http://máy.chủ.web/proj.git
48 === Git Thông Qua Mọi Thứ ===
50 Bạn muốn đồng bộ hóa kho chứa nhưng lại không có máy chủ và cũng không có mạng?
51 Bạn cần trong những trường hợp khẩn cấp? Chúng ta đã biết lệnh <<makinghistory, *git
52 fast-export* và *git fast-import* có thể chuyển đổi một kho chứa thành một tệp tin đơn
53 và ngược lại>>. Chúng ta có thể chuyển qua chuyển lại như vậy để truyền kho Git
54 đi thông qua bất kỳ phương tiện nào, nhưng có một công cụ hiệu quả hơn đó chính là *git bundle*.
56 Người gửi tạo một 'bundle':
58  $ git bundle create somefile HEAD
60 sau đó gửi bundle, +somefile+, tới người cần bằng cách nào đó: thư điện tử,
61 ổ đĩa USB, và bản in *xxd* và một bộ quét nhận dạng chữ OCR, đọc các bit thông qua điện thoại,
62 tín hiệu khói, v.v.. Người nhận khôi phục lại các lần commit từ bundle nhận được bằng cách gõ:
64  $ git pull somefile
66 Bộ nhận thậm chí có thể làm được việc này từ một kho chứa rỗng. Mặc dù kích
67 thước của nó, +somefile+ chứa các mục kho Git nguyên thủy.
69 Trong các dự án lớn hơn, việc triệt tiêu lãng phí bằng cách chỉ bundle những thay đổi còn thiếu
70 kho chứa khác. Ví dụ, giả sử lần commit ``1b6d...'' là lần commit gần nhất
71 đã được chia sẻ giữa cả hai thành viên:
73  $ git bundle create somefile HEAD ^1b6d
75 Nếu phải làm việc này thường xuyên, một khó khăn là bạn không thể nhớ được chính xác lần commit tương ứng với lần gửi cuối. Trang
76 trợ giúp sẽ gợi ý cho bạn cách sử dụng các thẻ (tag) để giải quyết vấn đề này. Ấy là, sau khi bạn gửi một bundle,
77 thì hãy gõ:
79  $ git tag -f lastbundle HEAD
81 và tạo một bản bundles mới với:
83  $ git bundle create newbundle HEAD ^lastbundle
85 === Vá: Sự Thịnh Hành Toàn Cầu ===
87 Miếng vá được trình bày ở dạng văn bản để thể hiện các thay đổi của bạn, nó dễ dàng được đọc hiểu bởi
88 con người cũng như là máy tính. Điều này mang lại cho chúng sức lôi cuốn toàn cầu. Bạn có thể gửi miếng vá qua
89 thư điện tử cho những nhà phát triển phần mềm khác mà chẳng cần lo họ đang sử dụng hệ thống quản lý mã nguồn nào. Chừng nào
90 mà độc giả của bạn có thể đọc được thư điện tử của mình thì họ còn có thể thấy được phần chỉnh sửa của bạn. Tương tự thế, về phía mình,
91 những thứ bạn cần là có một địa chỉ thư điện tử: ở đây chẳng cần cài đặt kho chứa Git nào trên mạng.
93 Sử dụng lại ví dụ từ chương đầu tiên:
95  $ git diff 1b6d > my.patch
97 đầu ra là một miếng vá mà bạn có thể dán vào một thư điện tử để trao đổi với người khác. Ở kho Git,
98 gõ:
100  $ git apply < my.patch
102 để áp dụng miếng vá.
104 Còn một hình thức định dạng khác nữa, tên và có lẽ cả chữ ký của tác giả cũng được
105 ghi lại, tạo miếng vá tương ứng với một thời điểm chính xác trong quá khứ bằng cách gõ:
107  $ git format-patch 1b6d
109 Tệp tin lưu kết quả có thể chuyển cho lệnh *git-send-email*, hay có thể làm thủ công. Bạn cũng có thể chỉ định rõ một vùng commit:
111  $ git format-patch 1b6d..HEAD^^
113 Ở phía người nhận cuối, ghi lại thư điện tử thành tệp tin, sau đó chạy lệnh:
115  $ git am < email.txt
117 Lệnh này sẽ áp dụng cho miếng vá nhận được, đồng thời tạo ra một lần commit, bao gồm các thông tin như là tác giả.
119 Với một chương trình đọc thư điện tử, bạn có thể sử dụng con chuột để chuyển định dạng thư về dạng văn bản thuần  trước khi ghi miếng vá thành một tệp tin.
121 Có một số khác biệt nhỏ giữa các trình đọc đọc thư điện tử, nhưng nếu bạn sử dụng một trong
122 số chúng, bạn hầu như chắc chắn là người mà có thể cấu hình chúng một cách dễ dàng
123 mà chẳng cần phải đọc hướng dẫn sử dụng!
125 === Rất tiếc! Tôi đã chuyển đi ===
127 Sau khi nhân bản kho chứa, việc chạy lệnh *git push* hay *git pull* sẽ tự động
128 push tới hay pull từ URL gốc. Git đã làm điều này như thế nào? Bí mật nằm ở chỗ
129 các tùy chọn config đã được tạo ra cùng với bản sao. Hãy xem thử:
131  $ git config --list
133 Tùy chọn +remote.origin.url+ sẽ lưu giữ URL; ``origin'' là cái tên
134 được đặt cho kho nguồn. Với nhánh ``master'' theo như thường lệ, chúng ta có thể
135 thay đổi hay xóa các tên này nhưng chẳng có lý do gì để phải làm như thế cả.
137 Nếu kho chứa nguyên bản đã chuyển chỗ, chúng ta có thể cập nhật URL thông qua:
139  $ git config remote.origin.url git://url.mới/proj.git
141 Tùy chọn +branch.master.merge+ chỉ ra nhánh remote mặc định trong
142 lệnh *git pull*. Trong suốt quá trình nhân bản, nó được đặt cho nhánh hiện hành của kho chứa
143 mã nguồn, như thế cho dù HEAD của kho nguồn về sau có
144 di chuyển đến một nhánh khác, lệnh pull sau này sẽ trung thành với
145 nhánh nguyên gốc.
147 Tùy chọn này chỉ áp dụng cho kho chứa chúng ta lần đầu tiên nhân bản từ, nó
148 được ghi trong tùy chọn +branch.master.remote+. Nếu chúng ta pull từ kho
149 chứa khác chúng ta phải chỉ đích xác tên nhánh mà chúng ta muốn:
151  $ git pull git://example.com/other.git master
153 Phần phía trên giải thích tại sao một số lệnh push và pull ví dụ của chúng ta lại không có
154 tham số.
156 === Nhánh Trên Mạng ===
158 Khi bạn nhân bản một kho chứa, bạn cũng đồng thời nhân bản tất cả các nhánh của nó. Bạn sẽ không nhận
159 được cảnh báo này bởi vì Git không thông báo cho bạn: bạn phải hỏi mới có thể biết chính xác.
160 Việc làm này giúp ngăn ngừa phiền phức do nhánh mạng gây ra cho
161 các nhánh của bạn, và cũng làm cho Git dễ dàng hơn với người mới dùng.
163 Ta liệt kê các nhánh bằng lệnh:
165  $ git branch -r
167 Bạn nhận được kết quả trông giống như thế này:
169  origin/HEAD
170  origin/master
171  origin/experimental
173 Những nhánh tương ứng và HEAD của kho chứa remote, và bạn có thể sử dụng
174 trong các lệnh Git thông thường. Ví dụ như là, giả sử bạn làm nhiều lần commit, và
175 muốn so sánh chúng với bản đã fetch cuối cùng. Bạn cũng có thể tìm kiếm trong tệp tin
176 log để có được giá trị băm SHA1 thích hợp, nhưng dễ dàng hơn việc gõ:
178  $ git diff origin/HEAD
180 Hay bạn có thể xem nhánh ``experimental'' đang làm gì:
182  $ git log origin/experimental
184 === Đa Máy chủ ===
186 Giả sử hai người cùng phát triển trên một sự án của chúng ta, và họ muốn
187 giữ lại sự khác biệt trên cả hai. Chúng ta theo dõi hơn một kho chứa tại một thời điểm với lệnh:
189  $ git remote add other git://example.com/some_repo.git
190  $ git pull other some_branch
192 Bây giờ chúng ta có thể trộn với nhánh của kho chứa thứ hai, và chúng ta
193 dễ dàng truy cập tất cả các nhánh của tất cả các kho chứa:
195  $ git diff origin/experimental^ other/some_branch~5
197 Nhưng chúng ta chỉ muốn so sánh sự khác nhau giữ chúng nhưng không áp dụng các thay đổi này với chúng ta? Nói cách khác, chúng ta khảo sát các nhánh của họ nhưng không thay đổi những gì đang có trong thư mục làm việc của mình. Thế thì thay vì pull, ta dùng lệnh:
199  $ git fetch        # Lấy về từ nguyên gốc, theo mặc định.
200  $ git fetch other  # Lấy về từ lập trình viên thứ hai.
202 Lệnh này chỉ mang về phần lịch sử. Mặc dù thư mục làm việc vẫn còn nguyên chưa bị động đến,
203 chúng ta có thể xét bất kỳ nhánh nào của bất kỳ kho chứa nào trong một lệnh Git bởi vì chúng ta bây giờ
204 đang làm việc trên bản sao trên máy của mình.
206 Giờ ta xét đến phần hậu trường, lệnh pull đơn giản là *fetch* sau đó *merge*.
207 Thông thường chúng ta *pull* bởi vì chúng ta muốn trộn với lần commit cuối cùng sau khi fetch;
208 việc làm này là một ngoại lệ đáng chú ý.
210 Xem *git help remote* để biết cách làm thế nào để gỡ bỏ kho chứa trên mạng, bỏ qua các nhánh
211 xác định, và những thứ khác nữa.
213 === Sở Thích Riêng Của Tôi ===
215 Với dự án của mình, tôi thích những người cộng tác tạo các kho chứa ở nơi mà tôi có thể
216 pull. Một số dịch vụ Git cho phép bạn đặt nhánh riêng của mình từ một dự án trên đó
217 chỉ cần sử dụng chuột.
219 Sau khi tôi fetch một cây (tree), tôi chạy lệnh Git để di chuyển và xem xét các thay đổi,
220 với ý tưởng là để tổ chức và mô tả tốt hơn. Tôi trộn với các thay đổi của chính mình,
221 và có thể sẽ sửa thêm chút ít. Sau khi đã hài lòng, tôi push nó lên kho chứa chính.
223 Mặc dù tôi ít nhận được sự cộng tác, nhưng tôi tin rằng việc này sẽ thay đổi theo chiều hướng
224 tốt lên. Hãy đọc
225 http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[blog của Linus Torvalds].
227 Git thuận lợi trong việc tạo các miếng vá, cũng như là nó
228 tiết kiệm công sức cho chúng ta trong việc chuyển đổi chúng thành những lần commit dành cho Git. Hơn thế nữa, Git lưu giữ các thông tin rất chi tiết
229 như là ghi lại tên và địa chỉ thư điện tử của tác giả, cũng như là ngày tháng và
230 thời gian, và nó cũng đòi hỏi tác giả phải mô tả về những thay đổi mà họ đã tạo ra.