vi/intro.txt

   1 == Giới thiệu ==
   2
   3 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.
   4
   5 === Làm việc là một Trò chơi ===
   6
   7 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.
   8
   9 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.
  10
  11 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.
  12
  13 === Quản lý Mã nguồn ===
  14
  15 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. Computer games improved on this long ago, many of them providing multiple automatically timestamped save slots.
  16
  17 Let's make the problem slightly tougher. Say you have a bunch of files that go together, như mã nguồn cho một dự án chẳng hạn, hay các tệp tin cho một website. Bây giờ bạn muốn giữ một phiên bản cũ bạn phải lưu giữ toàn bộ thư mục. Giữ nhiều phiên bản như thế bằng cách thủ công thật bất tiện, và nhanh chóng trở nên xa hoa.
  18
  19 Với một số games, ghi lại một game really does consist of a directory full of files. These games hide this detail from the player and present a convenient interface to manage different versions of this directory.
  20
  21 Hệ thống quản lý mã nguồn không có sự khác biệt nào. They all have nice interfaces to manage a directory of stuff. You can save the state of the directory every so often, and you can load any one of the saved states later on. Unlike most computer games, they're usually smart about conserving space. Typically, only a few files change between version to version, and not by much. Storing the differences instead of entire new copies saves room.
  22
  23 === Hệ Phân tán ===
  24
  25 Bây giờ hãy tưởng tượng có một game rất khó. So difficult to finish that many experienced gamers all over the world decide to team up and share their saved games to try to beat it. Speedruns are real-life examples: players specializing in different levels of the same game collaborate to produce amazing results.
  26
  27 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?
  28
  29 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.
  30
  31 Đ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.
  32
  33 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.
  34
  35 The new generation of version control systems, of which Git is a member, are known as distributed systems, and can be thought of as a generalization of centralized systems. When players download from the main server they get every saved game, not just the latest one. It's as if they're mirroring the central server.
  36
  37 Việc khởi tạo bản sao có vẻ hơi xa hoa, đặc biệt là nếu nó có lịch sử phát triển lâu dài, nhưng cũng chỉ là việc kéo dài thời gian để chạy. Một lợi ích trực tiếp là khi các tài liệu cũ cần đến, việc liên lạc với máy chủ trung tâm là không cần thiết.
  38
  39 === Mê tín Vớ vẩn ===
  40
  41 Một quan niêm phổ biến là hệ thống phân tán không thích hợp với dự án yêu cầu một kho chứa trung tâm chính thức. Nothing could be further from the truth. Chụp ảnh ai đó không có nghĩa là lấy mất đi linh hồn họ. Cũng thế, nhân bản kho chính cũng không làm giảm đi sự quan trọng của nó.
  42
  43 A good first approximation is that anything a centralized version control system can do, a well-designed distributed system can do better. Network resources are simply costlier than local resources. While we shall later see there are drawbacks to a distributed approach, one is less likely to make erroneous comparisons with this rule of thumb.
  44
  45 Một dự án nhỏ có thể chỉ cần một phần nhỏ các đặc tính được đưa ra bởi một
  46 hệ thống như thế, but using systems that scale poorly for tiny projects is like using
  47 Roman numerals for calculations involving small numbers.
  48
  49 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.
  50
  51 === Xung đột khi Trộn ===
  52
  53 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.
  54
  55 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.
  56
  57 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.
  58
  59 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.