From cb0579e99c3c7b6c6c3aec39d113b009717e5208 Mon Sep 17 00:00:00 2001 From: Tran Ngoc Quan Date: Wed, 16 Feb 2011 09:05:02 +0700 Subject: [PATCH] Complete edit basic, clone, intro, preface --- README | 7 ++++-- vi/basic.txt | 20 ++++++++--------- vi/branch.txt | 68 +++++++++++++++++++++++++++++----------------------------- vi/clone.txt | 24 ++++++++++----------- vi/intro.txt | 16 +++++++------- vi/preface.txt | 8 +++---- 6 files changed, 73 insertions(+), 70 deletions(-) diff --git a/README b/README index ea4b32b..dca3d21 100644 --- a/README +++ b/README @@ -1,2 +1,5 @@ -This project translate gitMagic ebook to Vietnamese -Author: Tran Ngoc Quan +This project translate gitMagic ebook into Vietnamese. +Transalted by: Trần Ngọc Quân. + +Special thanks: + -Clytie Siddall diff --git a/vi/basic.txt b/vi/basic.txt index bfa4241..2a19625 100644 --- a/vi/basic.txt +++ b/vi/basic.txt @@ -11,7 +11,7 @@ trong thư mục hiện hành chứa các mã nguồn hay văn bản mà bạn m $ git init $ git add . - $ git commit -m "My first backup" + $ git commit -m "Bản sao lưu đầu tiên" Bây giờ nếu như các sửa đổi của bạn không như mong đợi, hãy phục hồi lại bản cũ (bản cuối cùng bạn commit): @@ -19,7 +19,7 @@ Bây giờ nếu như các sửa đổi của bạn không như mong đợi, hã Lưu lại state lần nữa: - $ git commit -a -m "Another backup" + $ git commit -a -m "Bản sao lưu khác" === Thêm, Xóa, Đổi tên === @@ -71,7 +71,7 @@ Một lúc nào đó bạn lại muốn nhảy tới một bản cũ hơn. Trong $ git checkout 82f5 -Nó giúp bạn quay lại đúng thời điểm đó, trong khi vẫn giữ lại những lần commit mới hơn. Tuy nhiên, giống như cỗ máy thời gian trong các bộ phim khoa học viễn tưởng, nếu bây giờ bạn sửa sau đó commit, bạn sẽ ở trong một thực tại khác, bởi vì hành động của bạn bây giờ đã khác với chúng trong lần đầu tiên ở tại đây. +Nó giúp bạn quay lại đúng thời điểm đó, trong khi vẫn giữ lại những lần commit mới hơn. Tuy nhiên, giống như cỗ máy thời gian trong các bộ phim khoa học viễn tưởng, nếu bây giờ bạn sửa sau đó commit, bạn sẽ ở trong một thực tại khác, bởi vì hành động của bạn bây giờ đã khác với lúc chúng trong lần đầu tiên ở tại đây. Có cách thực tế hơn là sử dụng 'branch', và <>. Bây giờ, chỉ cần nhớ là @@ -99,7 +99,7 @@ Bạn không thích việc cắt dán ư? Hãy sử dụng: $ git checkout :/"My first b" để nhảy tới lần commit mà phần chú thích của nó bắt đầu với chuỗi bạn đã cho. -Bạn cũng có thể yêu cầu state thứ 5 kể từ cuối: +Bạn cũng có thể yêu cầu state thứ 5 kể từ lần cuối: $ git checkout master~5 @@ -126,7 +126,7 @@ Lấy về một bản sao của một dự án quản lý bằng Git bằng cá $ git clone git://server/path/to/files -Ví dụ, để lấy tất cả các tệp tin mà tôi đã dùng để tạo ra cho trang mạng này là: +Ví dụ, để lấy tất cả các tệp tin mà tôi đã dùng để tạo ra cho trang này là: $ git clone git://git.or.cz/gitmagic.git @@ -134,7 +134,7 @@ Chúng ta sẽ có nhiều điều để nói về lệnh *clone* sớm thôi. === Thử Nghiệm === -Nếu bạn đã tải về một bản sao của một dự án sử dụng *git clone*, bạn có thể nâng cấp lên phiên bản cuối cùng với lệnh: +Nếu bạn đã tải về một bản sao của một dự án bằng lệnh *git clone*, bạn có thể lấy về phiên bản cuối cùng với lệnh: $ git pull @@ -146,7 +146,7 @@ Thực hiện điều này với Git, trong thư mục làm việc của Git: $ git init $ git add . - $ git commit -m "First release" + $ git commit -m "Bản phát hành đầu tiên" Sau đó nói với những người cùng sử dụng hãy chạy: @@ -158,7 +158,7 @@ Sau đó nói với những người cùng sử dụng hãy chạy: Kể từ lúc này, bất cứ khi nào mã nguồn của bạn đã có thể sử dụng được, chỉ việc thực hiện: - $ git commit -a -m "Next release" + $ git commit -a -m "Bản phát hành tiếp" và những người sử dụng có thể cập nhật dữ liệu của họ bằng cách chuyển tới thư mục làm việc tương ứng và gõ: @@ -185,7 +185,7 @@ Try also: $ git whatchanged --since="2 weeks ago" -Thường thường, tôi duyệt lịch sử bằng http://sourceforge.net/projects/qgit[qgit] để thay thế cách ở trên, bởi vì nó có giao diện đồ họa bóng bẩy, hay http://jonas.nitro.dk/tig/[tig], có giao diện dòng lệnh làm việc rất tốt với các máy có kết nối chậm. Một lựa chọn khác là cài đặt máy chủ web, chạy lệnh *git instaweb* và sử dụng bất kỳ trình duyệt web nào. +Thường thường, tôi duyệt lịch sử bằng http://sourceforge.net/projects/qgit[qgit] để thay thế cách ở trên, bởi vì nó có giao diện đồ họa bóng bẩy, hay http://jonas.nitro.dk/tig/[tig], có giao diện dòng lệnh làm việc rất tốt với các máy có kết nối mạng chậm. Một lựa chọn khác là cài đặt máy chủ web, chạy lệnh *git instaweb* và sử dụng bất kỳ trình duyệt web nào. === Bài Tập=== @@ -205,4 +205,4 @@ Coi A, B, C, D là 4 lần commit thành công, nơi mà B giống A ngoại tr $ git revert B -Lựa chọn nào là tốt nhất? Cách nào bạn thích nhất. Thật dễ dàng để có được thứ mà bạn muốn với Git, và thường là có nhiều cách để thực hiện được một thứ bạn muốn. +Lựa chọn nào là tốt nhất? Cách nào bạn thích nhất. Thật dễ dàng để có được thứ mà bạn muốn với Git, và thường là có nhiều hơn một cách để thực hiện được một thứ bạn muốn. diff --git a/vi/branch.txt b/vi/branch.txt index c3706cc..2bb9a7b 100644 --- a/vi/branch.txt +++ b/vi/branch.txt @@ -70,7 +70,7 @@ Mặt khác, sau khi 'check out' một trạng thái cũ, Git tự động đặ === Sửa Nhanh === -Bạn đang phân vân giữa ngã ba đường khi bạn phải xác định là xóa tất cả mọi thứ hoặc là are told to drop everything and fix a newly discovered lỗi trong lần commit `1b6d...`: +Bạn đang phân vân giữa ngã ba đường khi bạn phải xác định là xóa tất cả mọi thứ hoặc là sửa chữa các lỗi mới phát hiện ra trong lần commit `1b6d...`: $ git commit -a $ git checkout -b fixes 1b6d @@ -80,8 +80,8 @@ Một khi bạn đã sửa lỗi: $ git commit -a -m "Sửa lỗi" $ git checkout master -và phục hồi lại công việc theo phận sự của mình. Bạn thậm chí có thể 'merge' in the freshly -baked bugfix: +và phục hồi lại công việc theo phận sự của mình. Bạn thậm chí có thể trộn với lần commit đã sửa để +sửa lỗi: $ git merge fixes @@ -93,22 +93,22 @@ không hay biết nó hoạt động như thế nào. Chúng ta đã sử dụng việc trộn từ lâu rồi. Lệnh *pull* trên thực tế đã 'fetch' các lần commit và sau đó trộn chúng vào trong nhánh hiện hành của bạn. Nếu trên máy của mình bạn không có -thay đổi gì cả, thế thì việc trộn sẽ là một 'fast forward', a degenerate case akin to fetching +thay đổi gì cả, thế thì việc trộn sẽ là một 'fast forward', trường hợp này cũng na ná như việc lấy về phiên bản cuối cùng trong hệ thống quản lý mã nguồn tập trung. Nhưng nếu bạn đã có thay đổi trên máy của mình, Git sẽ tự động trộn, và báo cáo cho bạn nếu có xung đột xảy ra. -Thông thường, một lần commit có một 'commit cha', tạm gọi thế, the previous -commit. Merging branches together produces a commit with at least two parents. +Thông thường, mỗi lần commit có một 'commit cha', tạm gọi thế, chính là lần +commit trước. Việc trộn các nhánh với nhau phát sinh ra một lần commit với ít nhất hai 'cha'. Điều này đặt ra câu hỏi: lần commit mà `HEAD~10` thực sự ám chỉ đến là lần nào? Một lần commit có thể có nhiều cha, thế thì chúng ta phải theo cái nào? -It turns out this notation chooses the first parent every time. Đây là +Nó sẽ gọi ra 'cha' đầu tiên. Đây là desirable bởi vì nhánh hiện hành trở thành cha đầu tiên trong suốt quá trình trộn; một cách thường xuyên, bạn chỉ liên quan đến những thay đổi mình tạo ra trong nhánh hiện hành , as opposed to changes merged in từ các nhánh khác. -Bạn có thể quy một cha nào đó với một dấu mũ. Ví dụ, để hiển thị -logs từ cha thứ hai: +Bạn hãy quy một cha nào đó với một dấu mũ. Ví dụ, để hiển thị +nhật ký tính từ 'cha' thứ hai: $ git log HEAD^2 @@ -134,21 +134,21 @@ mã nguồn của bạn phải được xem xét lại trước khi chấp nhậ thứ nhất đã được chấp thuận trước khi bắt đầu phần thứ hai. Nhờ có việc tạo nhánh và trộn dễ dàng và cũng chẳng mất mát gì, chúng ta có thể phá vỡ quy tắc và làm việc trên -Part II trước khi Part I chính thức sẵn sàng. Gải sử bạn đã commit Part I +Part II trước khi Part I chính thức sẵn sàng. Giả sử bạn đã commit Part I và gửi nó đi để xem xét. Giả sử bạn đang ở nhánh `master`. Thế thì hãy phân nhánh ra: $ git checkout -b part2 -Tiếp đến, làm việc trên Part II, commit những thay đổi của bạn your changes along the way. To err is human, -and often you'll want to go back và sửa lỗi nào đó trong Part I. -Nếu may mắn, or very good, bạn có thể bỏ qua những dòng này. +Tiếp đến, làm việc trên Part II, commit những thay đổi của bạn bao nhiêu tùy thích. Lỗi là ở con người, +và bạn sẽ phải thường xuyên quay trở lại để sửa lỗi nào đó trong Part I. +Nếu may mắn, hay trong trường hợp tốt, bạn có thể bỏ qua những dòng này. - $ git checkout master # Go back to Part I. + $ git checkout master # Quay trở lại Part I. $ fix_problem - $ git commit -a # Commit the fixes. - $ git checkout part2 # Go back to Part II. - $ git merge master # Merge in those fixes. + $ git commit -a # Commit sau khi sửa lỗi. + $ git checkout part2 # Quay trở lại Part II. + $ git merge master # Trộn các thay đổi. Cuối cùng, Part I được chấp thuận: @@ -166,16 +166,16 @@ một nhánh từ trước đây 7 lần commit. Thế thì gõ: $ git branch -m master part2 # Đổi tên nhánh "master" thành "part2". $ git checkout HEAD~7 -b master # Tạo nhánh "master" mới 7 lần commit ngược từ trước. -Nhánh `master` bây giờ chỉ chứa Part I, và nhánh `part2` trở thành contains -phần ngừng lại. We are in the latter branch; we created `master` without switching to -it, because we want to continue work on `part2`. This is unusual. Until now, -we've been switching to branches immediately after creation, as in: +Nhánh `master` bây giờ chỉ chứa Part I, và nhánh `part2` trở thành nhánh +chứa. Chúng ta đang ở nhánh sau; chúng ta đã tạo nhánh `master` mà không chuyển đến +nó, bởi vì chúng ta muốn tiếp tục làm việc trên `part2`. Điều này hơi bất thường. Cho đến lúc này, +Chúng ta chuyển đến các nhánh ngay sau khi chúng được tạo ra, như là trong: $ git checkout HEAD~7 -b master # Tạo một nhánh và chuyển tới nó. === Cải Tổ Lại Sự Pha Trộn === -Có lẽ bạn thích làm việc trên mọi khía cạnh của một dự án trên cùng một nhánh. You want to keep works-in-progress to yourself and và muốn những người khác chỉ thấy được các lần commit của bạn không họ have been neatly organized. Hãy chuẩn bị một cặp nhánh: +Có lẽ bạn thích làm việc trên mọi khía cạnh của một dự án trên cùng một nhánh. Bạn muốn giữ riêng các thay đổi mình đang làm cho riêng mình và muốn những người khác chỉ thấy được các lần commit của bạn sau khi đã được tổ chức lại. Hãy chuẩn bị một cặp nhánh: $ git branch -b sanitized # Tạo một nhánh dùng cho việc dọn. $ git checkout -b medley # Tạo và chuyển nhánh thành nơi làm việc. @@ -185,7 +185,7 @@ Tiếp theo, làm việc gì đó: sửa lỗi, thêm các đặc tính kỹ thu $ git checkout sanitized $ git cherry-pick medley^^ -áp dụng applies the grandparent of the head commit of the nhánh ``medley'' to nhánh ``sanitized''. Với lệnh thích hợp là cherry-picks bạn có thể cấu trúc một nhánh mà nó chỉ chứa mã nguồn không thay đổi, và những lần commit có liên quan sẽ được nhóm lại với nhau. +áp dụng nhánh ông-bà của lần commit head của nhánh ``medley'' thành nhánh ``sanitized''. Với lệnh thích hợp là cherry-picks bạn có thể cấu trúc một nhánh mà nó chỉ chứa mã nguồn không thay đổi, và những lần commit có liên quan sẽ được nhóm lại với nhau. === Quản Lý Các Nhánh === @@ -199,17 +199,17 @@ nhánh ``master'' mà không động chạm gì đến nó và tạo các nhánh Các tùy chọn *-d* and *-m* cho phép bạn xóa hay di chuyển (đổi tên) các nhánh. Xem thêm *git help branch*. -Nhánh ``master'' thông thường rất hữu dụng. Những người khác có thể cho rằng +Nhánh ``master'' thông thường rất hữu dụng. Những người khác sẽ nghĩ rằng kho chứa của bạn có nhánh với tên này, và nhánh đó chứa phiên bản chính thức của dự án của bạn. Mặc dù bạn có thể đổi tên hay xóa bỏ nhánh ``master'', nhưng bạn nên tôn trọng thỏa thuận ngầm này. === Nhánh Tạm === -Một lát sau bạn có lẽ nhận thức được rằng you are creating short-lived branches -frequently vì các lý do như: mọi nhánh khác đơn thuần phục vụ cho -việc ghi lại trạng thái hiện tại so you can briefly hop back to an older state to -fix a high-priority bug hay thứ gì đó. +Một lát sau bạn có lẽ nhận thức được rằng mình cần có các nhánh tạm thời +vì các lý do như: mọi nhánh khác đơn thuần phục vụ cho +việc ghi lại trạng thái hiện tại do vậy bạn có thể nhảy trở lại các trạng thái cũ hơn để mà +sửa chữa các lỗi nghiêm trọng hay thứ gì đó. Điều này cũng tương tự như việc chuyển kênh trên TV một cách tạm thời để thấy chương trình khác đang chiếu cái gì. Nhưng thay vì chỉ cần nhấn vài cái nút, bạn phải tạo, check out, @@ -220,18 +220,18 @@ chẳng thua kém gì chiếc điều khiển từ xa của một chiếc TV: Lệnh này ghi lại trạng thái hiện hành vào một vị trí tạm thời (một 'stash') và phục hồi lại trạng thái trước đó. Thư mục bạn đang làm việc xuất hiện chính xác -như trước khi bạn chỉnh sửa, và bạn có thể sửa lỗi, pull in upstream changes, và +như trước khi bạn chỉnh sửa, và bạn có thể sửa lỗi, pull về các thay đổi ngược dòng, và cứ như thế. Khi bạn muốn qua trở lại trạng thái đã được tạm giấu đi đó, hãy gõ: - $ git stash apply # Bạn có thể phải giải quyết các xung đột có thể xảy ra. + $ git stash apply # Bạn có thể sẽ phải giải quyết các xung đột có thể nảy sinh. Bạn có thể có nhiều trạng thái được tạm giấu đi, và vận dụng chúng theo nhiều cách khác nhau. Xem -*git help stash*. As you may have guessed, Git duy trì các nhánh ở behind the scenes to perform this magic trick. +*git help stash*. Bạn cũng có thể đoán được, Git duy trì các nhánh ở hậu trường để thực hiện việc này. === Làm Theo Cách Của Mình === -You might wonder if branches are worth the bother. Cuối cùng, clones are almost -as fast, và bạn có thể hoán chuyển giữa chúng với lệnh *cd* thay vì sử dụng +Bạn có thể thấy là các nhánh phiền hà quá. Cuối cùng, clones hầu như là +lệnh nhanh nhất, và bạn có thể hoán chuyển giữa chúng với lệnh *cd* thay vì sử dụng lệnh riêng của Git. Ta thử xét đến các trình duyệt web. Tại sao việc hỗ trợ mở nhiều tab thì cũng tốt như mở trên nhiều cửa sổ khác nhau? @@ -240,6 +240,6 @@ chỉ giữ một cửa sổ trình duyệt được mở, và sử dụng các có lẽ lại khăng khăng cực đoan cho rằng: mở trên nhiều cửa sổ khác nhau và chẳng cần tab nữa. Một nhóm khác lại thích cả hai một lúc. -Việc tạo nhánh thì cũng giống như các tab cho thư mục làm việc của bạn, việc nhân bản thì giống như việc mở một cửa sổ duyệt mới. Những việc này nhanh chóng và nội bộ, thế thì sao lại không +Việc tạo nhánh thì cũng giống như các tab cho thư mục làm việc của bạn, còn việc nhân bản thì lại giống như việc mở một cửa sổ duyệt mới. Những việc này nhanh chóng và nội bộ, thế thì sao lại không thử nghiệm để tìm thấy cách thực hiện thích hợp nhất cho mình? Git giúp bạn làm việc chính xác như bạn muốn. diff --git a/vi/clone.txt b/vi/clone.txt index bb37b07..b63ccec 100644 --- a/vi/clone.txt +++ b/vi/clone.txt @@ -6,7 +6,7 @@ Với Git và các hệ thống quản lý mã nguồn phân tán, clone là tá === Đồng bộ hóa Các Máy tính === -Tôi có thể tạo gói tarball hay sử dụng lệnh *rsync* để sao lưu (backup) và đồng bộ hóa dữ liệu. Nhưng thỉnh thoảng, tôi biên tập trên laptop 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 với nhau. +Tôi có thể tạo gói tarball hay sử dụng lệnh *rsync* để sao lưu (backup) và đồng bộ hóa dữ liệu. Nhưng thỉnh thoảng, tôi biên tập trên laptop 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. 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: @@ -40,13 +40,13 @@ Khởi động dịch vụ Git daemon nếu cần: $ git daemon --detach # nó có thể đã hoạt động rồi Để 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 -và khởi tạo kho Git. Cách thường thấy là điền vào form trên trang web. +và khởi tạo kho Git. Cách thường thấy nhất là điền vào form trên trang web. 'Push' dự án của bạn lên máy chủ trung tâm bằng lệnh: $ git push git://central.server/path/to/proj.git HEAD -Để check out mã nguồn, các nhà phát triển phần mềm chỉ cần gõ: +Để lấy về mã nguồn, các nhà phát triển phần mềm chỉ cần gõ: $ git clone git://central.server/path/to/proj.git @@ -76,7 +76,7 @@ Kho bare (kho trần) được đặt tên như vậy vì nó không chứa thư Kho bare có vai trò hoạt động giống như máy chủ trung tâm trong các hệ thống 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 clone 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ó -đặ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 nhưng phổ biến dữ liệu. Sự phát triển +đặ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ự phát triển 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 thư mục làm việc. @@ -89,14 +89,14 @@ quen thuộc? Trước hết, việc pull gặp lỗi trên kho trần: thay và 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 máy chủ trung tâm, việc pull lên nó hơi cồng kềnh. Chúng ta phải đăng nhập vào máy chủ trước, và cung cấp cho lệnh pull địa chỉ mạng -của máy chúng ta đang pull từ đó. Firewalls có thể gây trở ngại, và điều gì xảy ra khi chúng ta không +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 có khả năng truy cập shell máy chủ trong chỗ đầu tiên đó? 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. Tóm lại, khi bạn học Git, chỉ push khi đích là kho bare; nếu không thì dùng pull. -=== Rẽ nhánh Dự án === +=== Rẽ Nhánh Dự Án === 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: @@ -108,13 +108,13 @@ Từ bây giờ trở đi, bạn có thể trộn các sự thay đổi từ d $ git pull -=== Backup Không giới hạn === +=== Sao Lưu Không Giới Hạn === -Want numerous tamper-proof geographically diverse redundant archives? 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. Not just of the current state, but of mục lịch sử trong dự án của mình. 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. +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. Không chỉ mỗi trạng thái hiện hành mà cả các mục lịch sử trong dự án của mình. 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. 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. -The truly paranoid should luôn luôn ghi ra 20-byte giá trị băm SHA1 cuối 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ó. +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ó. === Làm nhiều việc cùng lúc === @@ -125,7 +125,7 @@ Bạn muốn làm nhiều việc cùng một lúc trên một dự án. Thế th Nhờ có http://en.wikipedia.org/wiki/Hard_link[liên kết cứng], việc nhân bản nội bộ 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. -You can now work on two independent features simultaneously. Ví dụ như, bạn +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 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 và pull các thay đỏi từ một bản sao khác: @@ -169,7 +169,7 @@ hay là sử dụng Mercurial: $ hg clone http://bitbucket.org/durin42/hg-git/ -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ì parallel Git repository 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. +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. 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ừ: @@ -193,7 +193,7 @@ Plugin `bzr-git` giúp người dùng Bazaar làm việc với kho Git trong ch === Tại sao Tôi sử dụng Git === -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ư nhân (kernel) của hệ điều hành Linux. Tôi chưa bao giờ nghĩ đến việc chuyển sang cái 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. +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ư kernel của hệ điều hành Linux. Tôi chưa bao giờ nghĩ đến việc chuyển sang cái 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. 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à Python script: ở đâ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. diff --git a/vi/intro.txt b/vi/intro.txt index 3557b26..14e10d9 100644 --- a/vi/intro.txt +++ b/vi/intro.txt @@ -1,16 +1,16 @@ == Giới thiệu == -Tôi sử dụng cách ví von để giới thiệu về hệ thống quản lý mã nguồn. Xem tại http://en.wikipedia.org/wiki/Revision_control[bài viết về quản lý mã nguôn trên Wikipedia] để có được sự giải thích thỏa đáng. +Tôi sử dụng cách ví von để giới thiệu về hệ thống quản lý mã nguồn. Xem http://en.wikipedia.org/wiki/Revision_control[bài viết về quản lý mã nguồn trên Wikipedia] để có được sự giải thích thỏa đáng. -=== Làm việc là một Trò chơi === +=== 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 có 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 game. 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. +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. Which was a shame, bởi vì your previous save might have been right at an exceptionally fun part of the game that you'd like to revisit one day. Tệ hơn nữa, 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. +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, 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. -=== Quản lý Mã nguồn === +=== Quản Lý Mã Nguồn === Khi biên soạn, bạn có thể chọn 'Save As...' để tạo tệp tin vớ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 này từ rất lâu rồi, rất nhiều trong số chúng cung cấp khả năng ghi lại tự động theo thời gian. @@ -18,7 +18,7 @@ Chúng ta sẽ giải quyết một vấn đề hơi hóc búa một chút nhé! Đối với một số trò chơi, ghi lại một trò chơi thực tế bao gồm toàn bộ thư mục. Những trò chơi này che giấu những chi tiết từ phía người chơi và phơi bày ra một giao diện thích hợp để quản lý các phiên bản của thư mục này. -Hệ thống quản lý mã nguồn không có sự khác biệt nào. 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. Chỉ lưu giữ những cái có thay đổi thay vì toàn bộ tất cả. +Hệ thống quản lý mã nguồn không có sự khác biệt nào. 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 === @@ -40,7 +40,7 @@ Việc khởi tạo bản sao như thế có vẻ hơi xa hoa, đặc biệt là 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. Chân lý tồn tại một cách khách quan mà không phụ thuộc vào nhận thức của con người. 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ó. -A good first approximation is that anything a một hệ thống quản lý mã nguồn tập trung có thể làm, một hệ thống phân tán được thiết kế tốt có thể làm nhiều hơn thế. 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, one is less likely to make erroneous comparisons with quy tắc ngón tay cái này. +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 này thường đúng: hệ thống phân tán là hữu hiệu 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 @@ -56,4 +56,4 @@ Giả sử Alice chèn thêm một dòng vào đầu một tệp tin, và Bob n Bây giờ giả sử cả Alice và Bob cùng sửa một dòng. Thế thì điều 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ễ cho chúng, và để lại những tình huống khó khăn cho chúng ta. Thông thường cách ứng xử của chúng có thể điều chỉnh được. +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. Thông thường cách ứng xử của chúng có thể điều chỉnh được. diff --git a/vi/preface.txt b/vi/preface.txt index d33db13..5c2705a 100644 --- a/vi/preface.txt +++ b/vi/preface.txt @@ -22,8 +22,8 @@ Thay vì đi sâu vào chi tiết, chúng tôi đưa ra phác thảo cách làm .Các định dạng khác - - link:book.html[Single webpage]: HTML đơn giản, không định dạng bằng CSS. - - link:book.pdf[PDF file]: thuận tiện cho việc in ấn. + - link:book.html[Trang web đơn]: định dạng HTML đơn giản, không định dạng bằng CSS. + - link:book.pdf[Định dạng PDF]: thuận tiện cho việc in ấn. - http://packages.debian.org/gitmagic[gói dành cho Debian], http:://packages.ubuntu.com/gitmagic[gói dành cho Ubuntu]: cài tự động tại địa chỉ này. Làm thủ công tại http://csdcf.stanford.edu/status/[khi bạn không có kết nối mạng]. - http://www.amazon.com/Git-Magic-Ben-Lynn/dp/1451523343/[Sách giấy [Amazon.com]]: 64 trang, 15.24cm x 22.86cm, đen trắng. Rất tiện sử dụng vì chẳng cần đến điện. @@ -35,7 +35,7 @@ François Marier đã bảo trì gói Debian do Daniel Baumann khởi xướng. JunJie, Meng, JiangWei, Rodrigo Toledo, Leonardo Siqueira Rodrigues, -Benjamin Bellee, Armin Stebich, và Trần Ngọc Quân đã dịch bản hướng dẫn này. +Benjamin Bellee, Armin Stebich và Trần Ngọc Quân đã dịch bản hướng dẫn này. Tôi cũng gửi lời cảm ơn tới sự giúp đỡ và sự tán dương của các bạn. Tôi muốn trích dẫn lời các bạn ra ở đây, nhưng làm như thế có vẻ hơi lố bịch. @@ -52,7 +52,7 @@ Trân thành cảm ơn các địa chỉ đã lưu giữ bản hướng dẫn n === Giấy phép sử dụng === -Hướng dẫn này được phát hành dựa trên giấy phép http://www.gnu.org/licenses/gpl-3.0.html[the GNU General Public License version 3]. Đương nhiên, mã nguồn được lưu giữ trong kho Git, +Hướng dẫn này được phát hành dựa trên giấy phép http://www.gnu.org/licenses/gpl-3.0.html[the GNU General Public License version 3]. Đương nhiên, nội dung của cuốn sách được lưu giữ trong kho Git, và bạn có thể dễ dàng có được nó bằng cách gõ: $ git clone git://repo.or.cz/gitmagic.git # Tạo thư mục "gitmagic". -- 2.11.4.GIT