From fcbea90cb39d27c655b048587c400713397c379b Mon Sep 17 00:00:00 2001 From: Tran Ngoc Quan Date: Sat, 25 Dec 2010 14:58:22 +0700 Subject: [PATCH] Edit multiplayer.txt and secrets.txt --- vi/multiplayer.txt | 62 +++++++++++++++++++++--------------------- vi/secrets.txt | 80 +++++++++++++++++++++++++++--------------------------- 2 files changed, 71 insertions(+), 71 deletions(-) diff --git a/vi/multiplayer.txt b/vi/multiplayer.txt index 808cc29..65b8c5d 100644 --- a/vi/multiplayer.txt +++ b/vi/multiplayer.txt @@ -48,7 +48,7 @@ và mọi người có thể lấy dự án của bạn với lệnh: === 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ủ hay là mạng? +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? Need to improvise during an emergency? We've seen <>. We could shuttle such files back and forth to transport git @@ -59,13 +59,13 @@ 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à *xxd* printout and an OCR scanner, reading bits over the phone, -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 bằng cách gõ: +ổ đĩ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 -The receiver can even do this from an empty repository. Despite its -size, +somefile+ contains the entire original git repository. +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 bundling only changes the other repository lacks. Ví dụ, giả sử lần commit ``1b6d...'' là lần commit gần nhất @@ -83,15 +83,15 @@ và tạo một bản bundles mới với: $ git bundle create newbundle HEAD ^lastbundle -=== Vá: The Global Currency === +=== 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 universal appeal. 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 mã nguồn nào. As long -as your audience can read their email, they can see your edits. Tương tự thế, về phía mình, +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 mã nguồn nào. Chừng nào +độc giả của bạn có thể đọc được thư điện tử của họ, họ 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 trên mạng. -Recall from the first chapter: +Sử dụng lại ví dụ từ chương đầu tiên: $ git diff 1b6d > my.patch @@ -103,15 +103,15 @@ gõ: để áp dụng miếng vá. In more formal settings, when author names and perhaps signatures should be -recorded, generate the corresponding patches past a certain point by typing: +recorded, generate the corresponding patches past tại một thời điểm chính xác trong quá khứ bằng cách gõ: $ git format-patch 1b6d -The resulting files can be given to *git-send-email*, hay có thể gửi thủ công. Bạn cũng có thể chỉ định rõ một vùng commit: +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 đó gõ: +Ở 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 @@ -120,8 +120,8 @@ Lệnh này sẽ áp dụng cho miếng vá nhận được, đồng thời tạ Với một chương trình đọc thư điện tử, bạn có thể sử dụng con chuột để to see the email in its raw original form trước khi ghi miếng vá thành một tệp tin. There are slight differences for mbox-based email clients, nhưng nếu bạn sử dụng một trong -số chúng, you're probably the sort of person who can figure them out easily -without reading tutorials! +số chúng, you're probably the sort of person who 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 === @@ -139,13 +139,13 @@ Nếu kho chứa nguyên bản đã chuyển chỗ, chúng ta có thể cập nh $ git config remote.origin.url git://new.url/proj.git -The +branch.master.merge+ option specifies the default remote branch in -a *git pull*. Trong suốt quá trình During the initial clone, nó được đặt cho nhánh hiện hành của kho chứa +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, so even if the HEAD of the source repository subsequently moves to a different branch, a later pull will faithfully follow the original branch. -This option only applies to the repository we first cloned from, which is +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ừ, which is recorded in the option +branch.master.remote+. Nếu chúng ta pull từ kho chứa khác chúng ta phải chỉ đích xác nhánh mà chúng ta muốn: @@ -158,8 +158,8 @@ tham số. 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 giấu chúng đi: bạn phải hỏi mới có thể biết chính xác. -This prevents branches in the remote repository from interfering with -your branches, và cũng làm cho Git dễ dàng hơn với người mới dùng. +This prevents branches in the từ kho chứa remote từ phiền phức với +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: @@ -171,10 +171,10 @@ Bạn nhận được kết quả trông giống như thế này: origin/master origin/experimental -These represent branches and the HEAD of the remote repository, and can be used -trong các lệnh Git thông thường. Ví dụ như là, suppose you have made many commits, and -wish to compare against the last fetched version. You could search through the -logs for the appropriate SHA1 hash, but it's much easier to type: +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 @@ -185,7 +185,7 @@ Hay bạn có thể xem nhánh ``experimental'' đang làm gì: === Multiple Remotes === 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 -keep tabs on both. 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: +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 @@ -201,12 +201,12 @@ Nhưng chúng ta chỉ muốn so sánh sự khác nhau giữ chúng nhưng khôn $ 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, -we can refer to any branch of any repository in a Git command because we now -possess a local copy. +we can refer to 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. Recall that behind the scenes, 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 this situation is a notable exception. +việc làm này this situation is 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. @@ -217,9 +217,9 @@ Với dự án của mình, tôi thích những người cộng tác tạo các 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), I run Git commands to navigate và xem xét các thay đổi, -which ideally are well-organized and well-described. 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 nữa. Khi đã hài lòng, tôi push tới kho chứa chính. +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 it. 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 diff --git a/vi/secrets.txt b/vi/secrets.txt index d813567..ffeb367 100644 --- a/vi/secrets.txt +++ b/vi/secrets.txt @@ -1,4 +1,4 @@ -== Secrets Revealed == +== Các Bí Mật == We take a peek under the hood and explain how Git performs its miracles. I will skimp over details. For in-depth descriptions refer to http://www.kernel.org/pub/software/scm/git/docs/user-manual.html[the user manual]. @@ -8,27 +8,27 @@ How can Git be so unobtrusive? Aside from occasional commits and merges, you can Other version control systems force you to constantly struggle with red tape and bureaucracy. Permissions of files may be read-only unless you explicitly tell a central server which files you intend to edit. The most basic commands may slow to a crawl as the number of users increases. Work grinds to a halt when the network or the central server goes down. -In contrast, Git simply keeps the history of your project in the `.git` directory in your working directory. This is your own copy of the history, so you can stay offline until you want to communicate with others. You have total control over the fate of your files because Git can easily recreate a saved state from `.git` at any time. +In contrast, Git simply keeps the history of your project in the `.git` directory in your working directory. This is your own copy of the history, so you can stay offline until you want to communicate with others. You have total control over the fate of your files because Git can easily recreate a saved state from `.git` bất kỳ lúc nào. -=== Integrity === +=== Tính Toàn vẹn === -Most people associate cryptography with keeping information secret, but another equally important goal is keeping information safe. Proper use of cryptographic hash functions can prevent accidental or malicious data corruption. +Phần lớn mọi người sử dụng phương pháp mã hóa để giữ cho thông tin của mình không bị nhòm ngó, nhưng có thứ quan trọng không kém đó là giữ cho thông tin của mình được an toàn. Proper use of cryptographic hash functions có thể ngăn ngừa accidental or malicious data corruption. -A SHA1 hash can be thought of as a unique 160-bit ID number for every string of bytes you'll encounter in your life. Actually more than that: every string of bytes that any human will ever use over many lifetimes. +A SHA1 hash can be thought of as a là một số định danh 160-bit không trùng lắp cho mỗi chuỗi ký tự you'll encounter in your life. Actually more than that: every string of bytes that any human will ever use over many lifetimes. As a SHA1 hash is itself a string of bytes, we can hash strings of bytes containing other hashes. This simple observation is surprisingly useful: look up 'hash chains'. We'll later see how Git uses it to efficiently guarantee data integrity. Briefly, Git keeps your data in the `.git/objects` subdirectory, where instead of normal filenames, you'll find only IDs. By using IDs as filenames, as well as a few lockfiles and timestamping tricks, Git transforms any humble filesystem into an efficient and robust database. -=== Intelligence === +=== Thông Mính=== -How does Git know you renamed a file, even though you never mentioned the fact explicitly? Sure, you may have run *git mv*, but that is exactly the same as a *git rm* followed by a *git add*. +Làm thể nào mà Git biết bạn đã đổi tên một tệp tin, dù là bạn chẳng bao giờ đề cập đến thực tế này the fact explicitly? Chắc chắn rồi, you may have run *git mv*, but that is exactly the same as a *git rm* followed by a *git add*. -Git heuristically ferrets out renames and copies between successive versions. In fact, it can detect chunks of code being moved or copied around between files! Though it cannot cover all cases, it does a decent job, and this feature is always improving. If it fails to work for you, try options enabling more expensive copy detection, and consider upgrading. +Git heuristically ferrets out renames and copies between successive versions. Trên thực tế, nó có thể tìm ra từng đoạn mã nguồn đã bị di chuyển hay sao chép giữa các tệp tin! Though it cannot cover all cases, it does a decent job, and this feature is always improving. If it fails to work for you, try options enabling more expensive copy detection, and consider upgrading. === Indexing === -For every tracked file, Git records information such as its size, creation time and last modification time in a file known as the 'index'. To determine whether a file has changed, Git compares its current stats with those cached in the index. If they match, then Git can skip reading the file again. +For every tracked file, Git ghi lại các thông tin như là kích thước, thời gian tạo và lần cuối sửa đổi trong một tệp tin được biết đến là một mục lục 'index'. To determine whether a file has changed, Git compares its current stats with those cached in the index. Nếu chúng giống nhau, thế thì Git có thể bỏ qua việc đọc tệp tin đó lại lần nữa. Since stat calls are considerably faster than file reads, if you only edit a few files, Git can update its state in almost no time. @@ -40,7 +40,7 @@ commit based only on these stats and the files already in the database. === Git's Origins === -This http://lkml.org/lkml/2005/4/6/121[Linux Kernel Mailing List post] describes the chain of events that led to Git. The entire thread is a fascinating archaeological site for Git historians. +http://lkml.org/lkml/2005/4/6/121[Linux Kernel Mailing List post] này describes the chain of events that led to Git. The entire thread is a fascinating archaeological site for Git historians. === The Object Database === @@ -50,36 +50,36 @@ the index, branch names, tags, configuration options, logs, the current location of the head commit, and so on. The object database is elementary yet elegant, and the source of Git's power. -Each file within `.git/objects` is an 'object'. There are 3 kinds of objects -that concern us: 'blob' objects, 'tree' objects, and 'commit' objects. +Mỗi tệp tin trong `.git/objects` là một 'đối tượng'. Ở đây có 3 loại đối tượng +that concern us: đối tượng 'blob', đối tượng 'tree', và đối tượng 'commit'. === Blobs === -First, a magic trick. Pick a filename, any filename. In an empty directory: +First, a magic trick. Pick a filename, any filename. Trong một thư mục rỗng: $ echo sweet > YOUR_FILENAME $ git init $ git add . $ find .git/objects -type f -You'll see +.git/objects/aa/823728ea7d592acc69b36875a482cdf3fd5c8d+. +Bạn sẽ thấy +.git/objects/aa/823728ea7d592acc69b36875a482cdf3fd5c8d+. -How do I know this without knowing the filename? It's because the -SHA1 hash of: +How do I know this without knowing the filename? Đó là bởi vì đó là giá trị +băm SHA1 của: "blob" SP "6" NUL "sweet" LF -is aa823728ea7d592acc69b36875a482cdf3fd5c8d, -where SP is a space, NUL is a zero byte and LF is a linefeed. You can verify -this by typing: +là aa823728ea7d592acc69b36875a482cdf3fd5c8d, +với SP là khoảng trắng, NUL là byte có giá trị bằng 0 và LF ký tự xuống dòng. Bạn có thể xác minh lại +bằng lệnh sau: $ printf "blob 6\000sweet\n" | sha1sum -Git is 'content-addressable': files are not stored according to their filename, -but rather by the hash of the data they contain, in a file we call a 'blob +Git is 'content-addressable': tệp tin không được lưu trữ như theo tên của chúng, +but rather by the hash of the data they contain, trong tệp tin chúng ta gọi là một in a file we call a 'blob object'. We can think of the hash as a unique ID for a file's contents, so -in a sense we are addressing files by their content. The initial `blob 6` is -merely a header consisting of the object type and its length in bytes; it +in a sense we are addressing files by their content. Phần khởi đầu `blob 6` đơn thuần +chỉ là phần đầu của một merely a header consisting of the object type and its length in bytes; it simplifies internal bookkeeping. Thus I could easily predict what you would see. The file's name is irrelevant: @@ -91,7 +91,7 @@ the same no matter how many you add. Git only stores the data once. By the way, the files within +.git/objects+ are compressed with zlib so you should not stare at them directly. Filter them through -http://www.zlib.net/zpipe.c[zpipe -d], or type: +http://www.zlib.net/zpipe.c[zpipe -d], hay gõ: $ git cat-file -p aa823728ea7d592acc69b36875a482cdf3fd5c8d @@ -99,7 +99,7 @@ which pretty-prints the given object. === Trees === -But where are the filenames? They must be stored somewhere at some stage. +Nhưng mà tên tệp tin ở đâu? Chúng phải được lưu giữ ở đâu đó chứ. Git gets around to the filenames during a commit: $ git commit # Type some message. @@ -111,8 +111,8 @@ You should now see 3 objects. This time I cannot tell you what the 2 new files a $ find .git/objects -type f Now you should see the file -+.git/objects/05/b217bb859794d08bb9e4f7f04cbda4b207fbe9+, because this is the -SHA1 hash of its contents: ++.git/objects/05/b217bb859794d08bb9e4f7f04cbda4b207fbe9+, bởi vì đây là giá trị băm +SHA1 của nội dung của nó: "tree" SP "32" NUL "100644 rose" NUL 0xaa823728ea7d592acc69b36875a482cdf3fd5c8d @@ -120,7 +120,7 @@ Check this file does indeed contain the above by typing: $ echo 05b217bb859794d08bb9e4f7f04cbda4b207fbe9 | git cat-file --batch -With zpipe, it's easy to verify the hash: +Với lệnh zpipe, ta có thể dễ dàng xác thực một giá trị băm: $ zpipe -d < .git/objects/05/b217bb859794d08bb9e4f7f04cbda4b207fbe9 | sha1sum @@ -150,7 +150,7 @@ though usually it's safe to remove +refs/original+ by hand. === Commits === -We've explained 2 of the 3 objects. The third is a 'commit' object. Its +Chúng tôi đã giảng giải cho bạn 2 trong số 3 đối tượng (object). Cái thứ 3 chính là 'commit'. Its contents depend on the commit message as well as the date and time it was created. To match what we have here, we'll have to tweak it a little: @@ -175,18 +175,18 @@ which is the SHA1 hash of its contents: LF "Shakespeare" LF -As before, you can run zpipe or cat-file to see for yourself. +Như ở phần trước, bạn có thể chạy lệnh zpipe hay cat-file để tự mình trông thấy. -This is the first commit, so there are no parent commits, but later commits -will always contain at least one line identifying a parent commit. +Đây là lần commit đầu tiên, do vậy lần commit này không có cha, nhưng những lần commit sau +sẽ luôn luôn chứa it nhất là một dòng chỉ định commit cha. === Indistinguishable From Magic === Git's secrets seem too simple. It looks like you could mix together a few shell scripts and add a dash of C code to cook it up in a matter of hours: a melange of basic filesystem operations and SHA1 hashing, garnished with lock files and fsyncs for robustness. In fact, this accurately describes the earliest versions of Git. Nonetheless, apart from ingenious packing tricks to save space, and ingenious indexing tricks to save time, we now know how Git deftly changes a filesystem into a database perfect for version control. -For example, if any file within the object database is corrupted by a disk -error, then its hash will no longer match, alerting us to the problem. By -hashing hashes of other objects, we maintain integrity at all levels. Commits +Ví dụ, nếu một tệp tin bất kỳ nào đó trong if any file within the object database is corrupted by a disk +error, then its hash will no longer match, điều này sẽ mang lại rắc rối cho chúng ta. By +hashing hashes of other objects, chúng ta có thể duy trì tính liêm chính ở tất cả các mức. Commits are atomic, that is, a commit can never only partially record changes: we can only compute the hash of a commit and store it in the database after we already have stored all relevant trees, blobs and parent commits. The object @@ -206,9 +206,9 @@ as well as the commit where it was first corrupted. In short, so long as the 20 bytes representing the last commit are safe, it's impossible to tamper with a Git repository. -What about Git's famous features? Branching? Merging? Tags? -Mere details. The current head is kept in the file +.git/HEAD+, +Đặc tính nào của Git là trứ danh nhất? Nhánh? Trộn? Hay Tags? +Mere details. The current head được giữ trong tệp tin +.git/HEAD+, which contains a hash of a commit object. The hash gets updated during a commit -as well as many other commands. Branches are almost the same: they are files in -+.git/refs/heads+. Tags too: they live in +.git/refs/tags+ but they -are updated by a different set of commands. +as well as many other commands. Branches are almost the same: chúng là các tệp tin trong thư mục ++.git/refs/heads+. Tags cũng thế: chúng ở tại +.git/refs/tags+ nhưng chúng +được cập nhật bởi các lệnh khác nhau. -- 2.11.4.GIT