From 27a638d7e460c19d68874261bf188834bd12f2d7 Mon Sep 17 00:00:00 2001 From: Tran Ngoc Quan Date: Sun, 19 Dec 2010 15:19:06 +0700 Subject: [PATCH] Continue edit intro.txt drawback.txt grandmaster.txt --- vi/drawbacks.txt | 6 ++--- vi/grandmaster.txt | 66 +++++++++++++++++++++++++++--------------------------- vi/intro.txt | 24 ++++++++++---------- 3 files changed, 48 insertions(+), 48 deletions(-) diff --git a/vi/drawbacks.txt b/vi/drawbacks.txt index 8d528a6..fda1b19 100644 --- a/vi/drawbacks.txt +++ b/vi/drawbacks.txt @@ -33,11 +33,11 @@ Một số hệ thống quản lý mã nguồn bắt buộc bạn đánh dấu r 2. One can discover ai khác đang làm việc trên một tệp tin bằng cách hỏi máy chủ trung tâm ai đã đánh dấu là đang sửa. -Với một script thích hợp, you can achieve the same with Git. Điều này yêu cầu sự hợp tác từ người lập trình, người có thể chạy các script chuyên biệt khi biên soạn một tệp tin. +Với một script thích hợp, bạn có thể lưu giữ theo cách này với. Điều này yêu cầu sự hợp tác từ người lập trình, người có thể chạy các script chuyên biệt khi biên soạn một tệp tin. === Lịch sử Tệp tin === -Since Git records project-wide changes, việc cấu trúc lại lịch sử của một tệp tin đơn lẻ yêu cầu more work than in version control systems that track individual files. +Since Git records project-wide changes, việc cấu trúc lại lịch sử của một tệp tin đơn lẻ yêu cầu phải làm việc nhiều hơn các chương trình quản lý mã nguồn giữ dấu vết theo các tệp tin riêng lẻ. The penalty is typically slight, and well worth having as other operations có hiệu quả không ngờ. Ví dụ, `git checkout` nhanh hơn `cp -a`, and project-wide deltas compress better than collections of file-based deltas. @@ -79,7 +79,7 @@ Xét về mặt thi hành của Git, thay vì thiết kế của nó, điều h === Lần Commit Khởi tạo === -A stereotypical computer scientist đếm từ 0, thay vì 1. Thật không may, with respect to commits, git does not adhere to this convention. Many commands are unfriendly before the initial commit. Thêm nữa, some corner cases phải được đối đãi theo một cách đặc biệt, such as rebasing a branch with a different initial commit. +A stereotypical computer scientist đếm từ 0, thay vì 1. Thật không may, with respect to commits, git does not adhere to this convention. Rất nhiều lệnh bất lợi trước lần commit khởi tạo. Thêm nữa, some corner cases phải được đối đãi theo một cách đặc biệt, such as rebasing a branch with a different initial commit. Git would benefit from defining the zero commit: ngay khi kho chứa được tạo ra, HEAD được đặt cho một chuỗi ký tự bao gồm 20 byte rỗng. Lần commit đặc biệt này tương ứng với một cây (tree) rỗng, không có gốc, at some time predating all Git repositories. diff --git a/vi/grandmaster.txt b/vi/grandmaster.txt index 7050b4a..2ff023d 100644 --- a/vi/grandmaster.txt +++ b/vi/grandmaster.txt @@ -1,51 +1,51 @@ == Git Grandmastery == -By now, you should be able to navigate the *git help* pages and understand -almost everything. However, pinpointing the exact command required to solve a -given problem can be tedious. Perhaps I can save you some time: below are some -recipes I have needed in the past. +Bây giờ, bạn có thể thông qua lệnh *git help* để bật trang trợ giúp lên và có thể hiểu +gần như tất cả mọi thứ. Tuy nhiên, việc xác định chính xác lệnh yêu cầu xact command required to solve a +given problem can be tedious. Có lẽ tôi có thể giúp bạn tiết kiệm được thời gian: bên dưới là một vài +chiêu mà tôi đã từng sử dụng trong quá khứ. -=== Source Releases === +=== Phát hành Mã Nguồn === For my projects, Git tracks exactly the files I'd like to archive and release -to users. To create a tarball of the source code, I run: +to users. Để tạo gói tarball cho mã nguồn, Tôi chạy: $ git archive --format=tar --prefix=proj-1.2.3/ HEAD === Commit What Changed === -Telling Git when you've added, deleted and renamed files is troublesome for -certain projects. Instead, you can type: +Việc phải thông báo với Git khi bạn thêm, xóa hay đổi tên các tệp tin là việc rầy rà với +các dự án nào đó. Thay vào đó, bạn có thể gõ: $ git add . $ git add -u -Git will look at the files in the current directory and work out the details by -itself. Instead of the second add command, run `git commit -a` if you also -intend to commit at this time. See *git help ignore* for how to specify files -that should be ignored. +Git sẽ xem tất cả các tệp tin trong thư mục hiện tại and work out the details by +itself. Thay vì chạy lệnh add thứ hai, hãy chạy `git commit -a` nếu bạn cũng có +ý định commit vào lúc này. Xem *git help ignore* để biết làm cách nào để chỉ ra +các tệp tin bỏ qua. -You can perform the above in a single pass with: +Bạn có thể thi hành những điều trên chỉ cần một dòng lệnh: $ git ls-files -d -m -o -z | xargs -0 git update-index --add --remove -The *-z* and *-0* options prevent ill side-effects from filenames containing -strange characters. As this command adds ignored files, you may want to use the -`-x` or `-X` option. +Tùy chọn *-z* và *-0* prevent ill side-effects from filenames containing +strange characters. As this command adds ignored files, bạn có thể muốn sử dụng +tùy chọn `-x` hay `-X`. -=== My Commit Is Too Big! === +=== Lần commit này Nhiều Quá! === -Have you neglected to commit for too long? Been coding furiously and forgotten -about source control until now? Made a series of unrelated changes, because -that's your style? +Bạn quên việc commit quá lâu? Been coding furiously and forgotten +about source control until now? Made a series of unrelated changes, bởi vì +đây là phong cách của bạn? Đừng lo lắng. Chạy: $ git add -p -For each edit you made, Git will show you the hunk of code that was changed, -and ask if it should be part of the next commit. Answer with "y" or "n". You -have other options, such as postponing the decision; type "?" to learn more. +Với mỗi lần thay đổi mà bạn tạo ra, Git sẽ hiện cho bạn biết từng đoạn mã đã bị thay đổi, +và hỏi nó có phải là một bộ phận của lần commit tiếp theo. Trả lời là "y" hay "n". Bạn +có các sự lựa chọn khác, như là hoãn lại; gõ "?" để biết thêm chi tiết. Khi nào bạn thỏa mãn thì gõ @@ -77,9 +77,9 @@ commands that somehow change the index, such as *git add*. Usually we can ignore the index and pretend we are reading straight from and writing straight to the history. On this occasion, we want finer control, so we manipulate the index. We place a snapshot of some, but not all, of our changes into the index, and then permanently record this carefully rigged snapshot. -=== Don't Lose Your HEAD === +=== Đừng Quên HEAD của Mình === -The HEAD tag is like a cursor that normally points at the latest commit, advancing with each new commit. Some Git commands let you move it. For example: +Thẻ HEAD is like a cursor that normally points at the latest commit, advancing with each new commit. Some Git commands let you move it. For example: $ git reset HEAD~3 @@ -87,17 +87,17 @@ will move the HEAD three commits back. Thus all Git commands now act as if you h But how can you go back to the future? The past commits know nothing of the future. -If you have the SHA1 of the original HEAD then: +Nếu bạn có giá trị băm SHA1 của HEAD gốc thì: $ git reset 1b6d -But suppose you never took it down? Don't worry: for commands like these, Git saves the original HEAD as a tag called ORIG_HEAD, and you can return safe and sound with: +But suppose you never took it down? Đừng lo: for commands like these, Git ghi lại HEAD gốc với thẻ có tên làORIG_HEAD, và bạn có thể trở về ngon lành và an toàn với: $ git reset ORIG_HEAD === HEAD-hunting === -Perhaps ORIG_HEAD isn't enough. Perhaps you've just realized you made a monumental mistake and you need to go back to an ancient commit in a long-forgotten branch. +Có thể ORIG_HEAD là chưa đủ. Perhaps you've just realized you made a monumental mistake and you need to go back to an ancient commit in a long-forgotten branch. By default, Git keeps a commit for at least two weeks, even if you ordered Git to destroy the branch containing it. The trouble is finding the appropriate @@ -182,7 +182,7 @@ On the other hand, if you specify particular paths for checkout, then there are $ git reset --hard 1b6d -*Branch*: Deleting branches fails if this causes changes to be lost. To force a deletion, type: +*Branch*: Deleting branches fails if this causes changes to be lost. Để ép buộc việc xóa, hãy gõ: $ git branch -D dead_branch # instead of -d @@ -218,7 +218,7 @@ If only I had bought idiot insurance by using a _hook_ to alert me about these p Now Git aborts a commit if useless whitespace or unresolved merge conflicts are detected. -For this guide, I eventually added the following to the beginning of the +Với bản hướng dẫn này, I eventually added the following to the beginning of the *pre-commit* hook to guard against absent-mindedness: if git ls-files -o | grep '\.txt$'; then @@ -226,7 +226,7 @@ For this guide, I eventually added the following to the beginning of the exit 1 fi -Several git operations support hooks; see *git help hooks*. We activated the +Nhiều hoạt động của Git hỗ trợ hooks; hãy xem *git help hooks*. We activated the sample *post-update* hook earlier when discussing Git over HTTP. This runs -whenever the head moves. The sample post-update script updates files Git needs -for communication over Git-agnostic transports such as HTTP. +whenever the head moves. Đoạn script ví dụ post-update cập nhật các tệp tin Git cần +for communication over Git-agnostic transports giống như là HTTP. diff --git a/vi/intro.txt b/vi/intro.txt index 282c1f3..ea3214b 100644 --- a/vi/intro.txt +++ b/vi/intro.txt @@ -1,14 +1,14 @@ == Giới thiệu == -Tôi sử dụng cách suy diễn để giới thiệu quản lý mã nguồn. Xem tại http://en.wikipedia.org/wiki/Revision_control[the Wikipedia entry on revision control] để có được sự giải thích thỏa đáng. +Tôi sử dụng cách ví von để giới thiệu về quản lý mã nguồn. Xem tại http://en.wikipedia.org/wiki/Revision_control[the Wikipedia entry on revision control] để có được sự giải thích thỏa đáng. -=== Work is Play === +=== Làm việc là một Trò chơi === -I've played computer games almost all my life. In contrast, I only started using version control systems as an adult. Tôi tin rằng không chỉ có tôi như thế, and comparing the two may make these concepts easier to explain and understand. +I've played computer games almost all my life. 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ã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 tương đối nhiều, bạn sẽ muốn ghi lại thành quả công việc. Để 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 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. -Nhưng việc làm này sẽ ghi đè lên bản cũ. It's like those old school games which only had one save slot: sure you could save, but you could never go back to an older state. Which was a shame, because your previous save might have been right at an exceptionally fun part of the game that you'd like to revisit one day. Or worse still, your current save is in an unwinnable state, và 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ũ. It's like those old school games which only had one save slot: sure you could save, but you could never go back to an older state. Which was a shame, because 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. === Quản lý Mã nguồn === @@ -26,9 +26,9 @@ Bây giờ hãy tưởng tượng có một game rất khó. So difficult to fin Làm thế nào bạn có thể cài đặt một hệ thống mà chúng có thể lấy được at each other's saves một cách dễ dàng? Và tải lên cái mới hơn? -Ngày xưa, mọi dự án đều sử dụng hệ thống quản lý tập trung. Máy chủ ở đâu đó giữ tất cả các game đã được ghi lại. Không còn ai khác làm điều đó nữa. Every player kept at most a few saved games on their machine. When a player wanted to make progress, they'd download the latest save from the main server, play a while, save and upload back to the server for everyone else to use. +Ngày xưa, mọi dự án đều sử dụng hệ thống quản lý tập trung. Máy chủ ở đâu đó giữ tất cả các game đã được ghi lại. Không còn ai khác làm điều đó nữa. Mọi người giữ phần lớn các game được ghi lại trong máy của họ. When a player wanted to make progress, họ có thể tải về bản ghi lại cuối cùng đã lưu lại ở máy chủ, chơi một lúc, ghi lại và tải trở lại máy chủ để mọi người có thể sử dụng. -What if a player wanted to get an older saved game for some reason? Maybe the current saved game is in an unwinnable state because somebody forgot to pick up an object back in level three, and they want to find the latest saved game where the game can still be completed. Or maybe they want to compare two older saved games to see how much work a particular player did. +Điều gì xảy ra khi một người chơi, vì một lý do nào đó, muốn có được lần chơi cũ hơn? Có thể là lần chơi hiện tại không ổn định hay có sai sót bởi vì một người chơi nào đó quên không chỉnh lại trò chơi về mức 3, và họ muốn tìm lần chơi đã ghi lại cuối cùng mà họ vẫn chưa hoàn thành. Hay có thể là họ muốn so sánh sự khác nhau giữa các lần chơi để thấy được công việc đã làm của từng người chơi. There could be many reasons to want to see an older revision, but the outcome is the same. They have to ask the central server for that old saved game. The more saved games they want, the more they need to communicate. @@ -48,12 +48,12 @@ Roman numerals for calculations involving small numbers. Hơn thế nữa, dự án của bạn có thể lớn vượt ra ngoài mong đợi ban đầu. Việc sử dụng Git từ lúc khởi sự thì cũng giống như việc mang mang một bộ dao vạn năng chỉ để phục vụ cho việc mở nút chai. Đến một ngày nào đó bạn cấn đến một cái chìa vít bạn sẽ vui sướng vì mình không chỉ có mỗi cái mở nút chai. -=== Merge Conflicts === +=== Xung đột khi Trộn === -Với chủ đề này, our computer game analogy becomes too thinly stretched. Instead, let us again consider editing a document. +Với chủ đề này, sự ví von nó với một trò chơi trên máy tính hơi khó. Thay vì thế, để chủng tôi dùng hành động biên soạn một tài liệu để giải thích cho bạn. -Giả sử Alice chèn thêm một dòng vào đầu một tệp tin, và Bob nối một dòng vào cuối của bản sao của mình. Họ đều tải lên các thay đổi của mình. Most systems will automatically deduce a reasonable course of action: accept and merge their changes, so both Alice's and Bob's edits are applied. +Giả sử Alice chèn thêm một dòng vào đầu một tệp tin, và Bob nối một dòng vào cuối của bản sao của mình. Họ đều tải lên các thay đổi của mình. Phần lớn các hệ thống sẽ tự động luận ra hành động hợp lý: chấp nhận và trộn các sự thay đổi của họ, do đó cả hai sự chỉnh sửa của Alice và Bob đều được dùng. -Now suppose both Alice and Bob have made distinct edits to the same line. Then it is impossible to proceed without human intervention. The second person to upload is informed of a _merge conflict_, and must choose one edit over another, or revise the line entirely. +Bây giờ giả định cả Alice và Bob đã chỉnh sửa tạo ra sự khác biệt trên cùng 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 and must choose one edit over another, hay sửa lại toàn bộ dòng. -More complex situations can arise. Version control systems handle the simpler cases themselves, and leave the difficult cases for humans. Thông thường cách ứng sử của chúng có thể chỉnh sửa. +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ể chỉnh sửa. -- 2.11.4.GIT