Skip to content
This repository
tree: a0c0402a44
Fetching contributors…

Cannot retrieve contributors at this time

file 231 lines (150 sloc) 12.684 kb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231
== Đa Người Dùng ==

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ó.
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*
và *clone* để giữ cùng một dự án nhưng ở những chỗ khác nhau.

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ừ
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
ở 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à
điều sống còn của một hệ thống quản lý mã nguồn.


=== Tôi Là Ai? ===

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*.
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.
Để chỉ định chúng một cách rõ ràng, hãy gõ:

  $ git config --global user.name "John Doe"
  $ git config --global user.email johndoe@example.com

Bỏ qua cờ global để đặt những thông tin này chỉ sử dụng cho kho chứa hiện tại.

=== Git Thông Qua SSH, HTTP ===

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ù
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.

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
thư mục chứa trang web của bạn:

 $ GIT_DIR=proj.git git init
 $ cd proj.git
 $ git --bare update-server-info
 $ cp hooks/post-update.sample hooks/post-update

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:

 $ chmod a+x hooks/post-update

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ỳ:

 $ git push web.server:/path/to/proj.git master

và mọi người có thể lấy dự án của bạn với lệnh:

 $ git clone http://web.server/proj.git

=== Git Thông Qua Mọi Thứ ===

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?
Bạn cần trong những trường hợp khẩn cấp? Chúng ta đã biết lệnh <<makinghistory, *git
fast-export* và *git fast-import* có thể chuyển đổi một kho chứa thành một tệp tin đơn
và ngược lại>>. Chúng ta có thể chuyển qua chuyển lại như vậy để truyền kho Git
đ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*.

Người gửi tạo một 'bundle':

 $ git bundle create somefile HEAD

sau đó gửi bundle, +somefile+, tới người cần bằng cách nào đó: thư điện tử,
ổ đĩ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,
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õ:

 $ git pull somefile

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
thước của nó, +somefile+ chứa các mục kho Git nguyên thủy.

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
kho chứa khác. Ví dụ, giả sử lần commit ``1b6d...'' là lần commit gần nhất
đã được chia sẻ giữa cả hai thành viên:

 $ git bundle create somefile HEAD ^1b6d

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
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,
thì hãy gõ:

 $ git tag -f lastbundle HEAD

và tạo một bản bundles mới với:

 $ git bundle create newbundle HEAD ^lastbundle

=== Vá: Sự Thịnh Hành Toàn Cầu ===

Miếng vá được trình bày ở dạng văn bản các thay đổi của bạn, nó dễ dàng được đọc hiểu bởi
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
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
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,
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.

Sử dụng lại ví dụ từ chương đầu tiên:

 $ git diff 1b6d > my.patch

đầ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,
gõ:

 $ git apply < my.patch

để áp dụng miếng vá.

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
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õ:

 $ git format-patch 1b6d

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:

 $ git format-patch 1b6d..HEAD^^

Ở 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:

 $ git am < email.txt

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ả.

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.

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
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
mà chẳng cần phải đọc hướng dẫn sử dụng!

=== Rất tiếc! Tôi đã chuyển đi ===

Sau khi nhân bản kho chứa, việc chạy lệnh *git push* hay *git pull* sẽ tự động
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ỗ
các tùy chọn config đã được tạo ra cùng với bản sao. Hãy xem thử:

 $ git config --list

Tùy chọn +remote.origin.url+ sẽ lưu giữ URL; ``origin'' là cái tên
được đặt cho kho nguồn. Với nhánh ``master'' theo như thường lệ, chúng ta có thể
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ả.

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:

 $ git config remote.origin.url git://new.url/proj.git

Tùy chọn +branch.master.merge+ chỉ ra nhánh remote mặc định trong
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
mã nguồn, như thế cho dù HEAD của kho nguồn về sau có
di chuyển đến một nhánh khác, lệnh pull sau này sẽ trung thành với
nhánh nguyên gốc.

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ó
được ghi trong tùy chọn +branch.master.remote+. Nếu chúng ta pull từ kho
chứa khác chúng ta phải chỉ đích xác tên nhánh mà chúng ta muốn:

 $ git pull git://example.com/other.git master

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ó
tham số.

=== Nhánh Trên Mạng ===

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
đượ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.
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
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.

Ta liệt kê các nhánh bằng lệnh:

 $ git branch -r

Bạn nhận được kết quả trông giống như thế này:

 origin/HEAD
 origin/master
 origin/experimental

Những nhánh tương ứng và HEAD của kho chứa remote, và bạn có thể sử dụng
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à
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
log để có được giá trị băm SHA1 thích hợp, nhưng dễ dàng hơn việc gõ:

 $ git diff origin/HEAD

Hay bạn có thể xem nhánh ``experimental'' đang làm gì:

 $ git log origin/experimental

=== Đa Máy chủ ===

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

 $ git remote add other git://example.com/some_repo.git
 $ git pull other some_branch

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
dễ dàng truy cập tất cả các nhánh của tất cả các kho chứa:

 $ git diff origin/experimental^ other/some_branch~5

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:

 $ git fetch # Lấy về từ nguyên gốc, theo mặc định.
 $ git fetch other # Lấy về từ lập trình viên thứ hai.

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,
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ờ
đang làm việc trên bản sao trên máy của mình.

Giờ ta xét đến phần hậu trường, lệnh pull đơn giản là *fetch* sau đó *merge*.
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;
việc làm này là một ngoại lệ đáng chú ý.

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
xác định, và những thứ khác nữa.

=== Sở Thích Riêng Của Tôi ===

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ể
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 đó
chỉ cần sử dụng chuột.

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,
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,
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.

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
tốt lên. Hãy đọc
http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[blog của Linus Torvalds].

Git thuận lợi trong việc tạo các miếng vá, cũng như là nó
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
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à
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.
Something went wrong with that request. Please try again.