Minor editing secrets.

[gitmagic/gitmagic.git] / vi / secrets.txt

== Các Bí Mật ==

Chúng ta mổ xẻ để hiểu được làm thế nào mà Git có thể thi hành kỳ diệu như vậy. Tôi sẽ không thể nói quá chi tiết được. Nếu bạn muốn có được sự mô tả chỉ tiết thì hãy đọc http://www.kernel.org/pub/software/scm/git/docs/user-manual.html[sổ tay].

=== Tính Ẩn ===

Git làm việc có vẻ kín đáo? Chỉ cần nói riêng về việc sử dụng lệnh commit và merge, bạn có thể làm việc mà không cần biết đến sự tồn tại của hệ thống quản lý mã nguồn. Cho đến khi bạn cần nó, và cho đến khi bạn vui sướng vì Git đã trông coi mã nguồn cho bạn trong suốt thời gian qua.

Các hệ thống quản lý mã nguồn khác ép buộc bạn luôn luôn phải tranh đấu với thói quan liêu. Quyền truy cập của các tệp tin có thể là chỉ cho phép đọc trừ phi bạn nói rõ với máy chủ trung tâm là các tệp tin nào bạn muốn chỉnh sửa. Tốc độ làm việc của phần lớn các lệnh sẽ tỷ lệ nghịch với số lượng người sử dụng. Mọi công việc sẽ đình trệ khi mạng máy tính hay máy chủ ngừng hoạt động.

Đối lập với hạn chế trên, Git đơn giản giữ lịch sử của dự án của bạn trong thư mục `.git` trong thư mục làm việc của bạn. Đây là bản sao lịch sử của riêng bạn, do vậy bạn có thể làm việc không cần mạng cho đến khi cần truyền thông với những người khác. Bạn có toàn quyền quyết định với các tệp tin của mình bởi vì Git có thể tạo lại trạng thái đã ghi lại từ `.git` bất kỳ lúc nào một cách dễ dàng.

=== Tính Toàn vẹn ===

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 toàn vẹn. Chính việc sử dụng hàm băm mã hóa đã làm ngăn ngừa sự sai hỏng dữ liệu do rủi ro hay ác ý.

Giá trị SHA1 có thể coi như là một số định danh 160-bit không trùng lắp cho mỗi chuỗi ký tự bạn dùng trong đời sống của mình. Trên thực tế nó còn làm được nhiều hơn thế: mọi chuỗi ký tự that any human will ever use over many lifetimes.

Bản thân giá trị SHA1 cũng là một chuỗi ký tự, chúng ta có thể băm chuỗi có chứa giá trị băm khác. This simple observation là cực kỳ hữu dụng: tra cứu 'hash chains'. Sau này chúng ta sẽ thấy làm cách nào Git sử dụng nó để mà đảm bảo tính toàn vẹn của dữ liệu.

Tóm lại, Git lưu giữ dữ liệu của bạn trong thư mục con `.git/objects`, thay vì sử dụng tên tệp tin như thông thường, bạn sẽ chỉ nhìn thấy ID của chúng. Bằng cách sử dụng ID để làm tên tệp tin, cũng tốt như là cách sử dụng lockfiles và timestamping, Git biến đổi bất kỳ hệ thống tệp tin thông thường bất kỳ nào thành một cơ sở dữ liệu hiệu quả và mạnh mẽ.

=== Thông Minh===

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 điều này một cách rõ ràng? Chắc chắn rồi, bạn có lẽ đã chạy lệnh *git mv*, nhưng   but that is exactly the same as a *git rm* theo sau bởi lệnh *git add*.

Git heuristically truy tìm renames and copies giữa các phiên bản liên tiếp. 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! Dẫu cho nó không thể it xử lý được mọi trường hợp, it does a decent job, và đặc tính này luôn luôn được phát triển. If it fails to work for you, try options enabling more expensive copy detection, và cất nhắc đến việc cập nhật.

=== Mục Lục ===

Với mọi tệp tin được theo dõi, 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'. Để xác định rõ một tệp tin có bị thay đổi hay không, Git so sánh nó ở thời điểm hiện tại với phần lưu giữ trong bộ nhớ. 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, nếu bạn chỉ chỉnh sửa
vài tệp tin, Git có thể cập nhật trạng thái của nó cực kỳ nhanh chóng.

We stated earlier that the index is a staging area. Why is a bunch of file
stats a staging area? Bởi vì lệnh add đặt các tệp tin vào trong cơ sở dữ liệu của Git
và cập nhật những stats này, trong lúc lệnh commit được thực hiện, mà không có tùy chọn, creates a
commit based only on these stats và các tệp tin đã sẵn có trong cơ sở dữ liệu.

=== Git's Origins ===

http://lkml.org/lkml/2005/4/6/121[Linux Kernel Mailing List post] này miêu tả chain of events that led to Git. Toàn bộ tuyến này is a fascinating archaeological địa chỉ dành cho các sử gia Git.

=== Đối tượng Cơ Sở Dữ Liệu ===

Mỗi một phiên bản của dữ liệu của bạn được giữ trong 'object database', mà nó nằm trong
thư mục con `.git/objects`; the other residents of `.git/` hold lesser data:
mục lục, tên các nhánh, các thẻ tag, các tùy chọn cấu hình, nhật ký, vị trí
hiện tại của location of the head commit, và những thứ tương tự như thế. The object database is elementary yet
elegant, và cội nguồn sức mạnh của Git.

Mỗi tệp tin trong `.git/objects` là một 'đối tượng'. Ở đây có 3 loại đối tượng
liên quan đến chúng ta: đối tượng 'blob', đối tượng cây 'tree', và đối tượng 'commit'.

=== Blobs ===

Đầu tiên, hãy tạo một tệp tin bất kỳ. Đặt cho nó một cái tên, tên gì cũng được. Trong một thư mục rỗng:

 $ echo sweet > YOUR_FILENAME
 $ git init
 $ git add .
 $ find .git/objects -type f

Bạn sẽ thấy +.git/objects/aa/823728ea7d592acc69b36875a482cdf3fd5c8d+.

Làm sao mà tôi biết được tệp tin khi không thấy tên của nó? Đó là bởi vì đó là giá trị
băm SHA1 của:

 "blob" SP "6" NUL "sweet" LF

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 sử dụng cách 'lấy nội dung để làm tên cho tệp tin': 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 'đối tượng
blob'. Chúng ta có thể nghĩ giá trị băm như là một định danh duy nhất cho nội dung của tệp tin, do vậy
ta có tên tệp tin được định danh bởi nội dung của nó. Phần khởi đầu `blob 6` đơn thuần
chỉ là phần đầu bao gồm kiểu đối tượng và độ dài của nó tính bằng byte; việc làm này
làm đơn giản hóa việc vận hành bên trong Git.

Đến đây tôi có thể dễ dàng đoán được bạn nghĩ gì. Tên của tệp tin là không thích hợp:
only the data inside is used to construct the blob object.

You may be wondering what happens to identical files. Hãy thử thêm một bản sao
một tệp tin nào đó của bạn, với bất kỳ một cái tên nào cũng được. Nội dung của +.git/objects+ stay
the same no matter how many you add. Git chỉ lưu giữ dữ liệu một lần duy nhất.

Nhưng dẫu sao, các tệp tin nằm trong +.git/objects+ đã bị nén lại theo chuẩn zlib do vậy bạn
không thể xem chúng một cách trực tiếp được. Đọc chúng thông qua
http://www.zlib.net/zpipe.c[zpipe -d], hay gõ:

 $ git cat-file -p aa823728ea7d592acc69b36875a482cdf3fd5c8d

lệnh này trình bày đối tượng được cho ở dạng dễ đọc trên màn hình.

=== Trees ===

Nhưng mà tên tệp tin ở đâu? Chúng phải được lưu giữ ở đâu đó chứ.
Git lấy tên tệp tin trong quá trình commit:

 $ git commit  # Type some message.
 $ find .git/objects -type f

Bạn sẽ thấy 3 đối tượng. Ở thời điểm này tôi không thể nói hai tệp tin mới này là cái gì, as it partly depends on the filename you picked. We'll proceed assuming you chose ``rose''. If you didn't, you can rewrite history to make it look like you did:

 $ git filter-branch --tree-filter 'mv YOUR_FILENAME rose'
 $ find .git/objects -type f

Bây giờ bạn có lẽ nhìn thấy tệp tin
+.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

Xác thực tệp tin này chứa thông tin như trên bằng cách gõ:

 $ echo 05b217bb859794d08bb9e4f7f04cbda4b207fbe9 | git cat-file --batch

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

Hash verification is trickier via cat-file because its output contains more
than the raw uncompressed object file.

Tệp tin này là một đối tượng cây 'tree': một danh sách các hàng bao gồm kiểu tệp tin,
tên tệp tin, và giá trị băm. Trong ví dụ của chúng ta, kiểu tệp tin là 100644, điều này
có nghĩa `rose` là tệp tin bình thường, và giá trị băm là một đối tượng blob mà nó chứa
nội dung của `rose'. Dạng tệp tin khác có thể là tệp tin thi hành, symlinks hay
các thư mục. Trong trường hợp cuối, giá trị băm sẽ chỉ đến đối tượng cây 'tree'.

Nếu bạn đã chạy lệnh filter-branch, you'll have old objects you no longer need. Mặc dù
chúng sẽ bị loại bỏ một cách tự động một khi thời hạn chấm dứt đã đến, chúng ta sẽ
xóa chúng ngay bây giờ theo cách dưới đây:

 $ rm -r .git/refs/original
 $ git reflog expire --expire=now --all
 $ git prune

Với các dự án thật bạn nên tránh việc sử dụng lệnh như trên, làm như thế bạn
đã phá hủy dữ liệu sao lưu dự phòng. Nếu bạn muốn làm sạch kho chứa, cách hay nhất là tạo
một bản sao mới. Cũng thế, hãy cẩn thận khi thao tác trực tiếp với thư mục +.git+: điều gì xảy ra nếu một lệnh
Git khác cũng đang thực thi cùng lúc, hay là mất điện đột ngột?
Đại khái, refs có thể được xóa bằng lệnh *git update-ref -d*,
though usually it's safe to remove +refs/original+ bằng tay.

=== Commits ===

Chúng tôi đã giảng giải cho bạn 2 trong số 3 đối tượng của Git. Cái thứ 3 chính là 'commit'. Nội dung
của nó buộc chặt vào phần chú thích của lần commit cũng như thời gian, ngày tháng chúng được
tạo ra. To match what we have here, we'll have to tweak it a little:

 $ git commit --amend -m Shakespeare  # Thay đổi phần chú thích.
 $ git filter-branch --env-filter 'export
     GIT_AUTHOR_DATE="Fri 13 Feb 2009 15:31:30 -0800"
     GIT_AUTHOR_NAME="Alice"
     GIT_AUTHOR_EMAIL="alice@example.com"
     GIT_COMMITTER_DATE="Fri, 13 Feb 2009 15:31:30 -0800"
     GIT_COMMITTER_NAME="Bob"
     GIT_COMMITTER_EMAIL="bob@example.com"'  # Rig timestamps and authors.
 $ find .git/objects -type f

Bạn có thể thấy
+.git/objects/49/993fe130c4b3bf24857a15d7969c396b7bc187+
là giá trị băm SHA1 của nội dung của nó:

 "commit 158" NUL
 "tree 05b217bb859794d08bb9e4f7f04cbda4b207fbe9" LF
 "author Alice <alice@example.com> 1234567890 -0800" LF
 "committer Bob <bob@example.com> 1234567890 -0800" LF
 LF
 "Shakespeare" LF

Như ở phần trước, bạn có thể chạy lệnh zpipe hay cat-file để tự mình trông thấy.

Đâ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 ===

Bí mật của Git dường như có vẻ đơn giản. Nó giống như bạn có thể trộn lẫn cùng nhau một ít kịch bản (shell scripts) và một ít code C mà đun trong vài giờ: a melange of basic filesystem operations and SHA1 hashing, garnished with lock files and fsyncs for robustness. Trên thực tế, this accurately describes the earliest versions of Git. Tuy nhiên, 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 việc quản lý mã nguồn.

Ví dụ, nếu một tệp tin bất kỳ nào đó trong đối tượng cơ sở dữ liệu bị sai hỏng bởi lỗi do ổ đĩa,
thế thì giá trị băm tương ứng của nó sẽ không đúng nữa, điều này sẽ mang lại rắc rối cho chúng ta. Bằng
việc băm giá trị băm của đối tượng khác, chúng ta có thể duy trì tính toàn vẹn ở tất cả các mức. Commit
are atomic, thật vậy đấy, 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
database is immune to unexpected interruptions such as power outages.

We defeat even the most devious adversaries. Suppose somebody attempts to
stealthily modify the contents of a file in an ancient version of a project. To
keep the object database looking healthy, they must also change the hash of the
corresponding blob object since it's now a different string of bytes. This
means they'll have to change the hash of any tree object referencing the file,
and in turn change the hash of all commit objects involving such a tree, in
addition to the hashes of all the descendants of these commits. This implies the
hash of the official head differs to that of the bad repository. By
following the trail of mismatching hashes we can pinpoint the mutilated file,
as well as the commit where it was first corrupted.

Nói ngắn gọn, dùng 20 byte để đại diện cho lần commit cuối là an toàn,
nod không thể giả mạo với kho chứa Git.

Đặc tính nào của Git là trứ danh nhất? Nhánh? Trộn? Hay Tags?
Chỉ là chi tiết. Head hiện hành được giữ trong tệp tin +.git/HEAD+,
mà nó có chứa giá trị băm của một đối tượng commit. Giá trị băm được cập nhật trong quá trình commit
cũng như là một số lệnh khác. Nhánh đại thể cũng tương tự: 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.