vi/drawbacks.txt

   1 == Phụ lục A: Hạn chế của Git ==
   2
   3 Git bộc lộ một số nhược điểm mà tôi đã gặp qua. Một số có thể xử lý thủ công một cách dễ dàng bằng các script và hook, một số yêu cầu phải tổ chức lại hay xác lập lại dự án, một số ít rắc rối còn lại, chỉ còn cách là ngồi đợi. Hay tốt hơn cả là bắt tay vào và giúp đỡ!
   4
   5 === Điểm yếu SHA1 ===
   6
   7 Thời gian trôi đi, những nhà mật mã đã phát hiện ra ngày càng nhiều điểm yếu của thuật toán SHA1. Already,
   8 finding hash collisions is feasible for well-funded organizations. Trong khoảng
   9 vài năm, có lẽ những chiếc PC thông thường cũng đủ sức để âm thầm
  10 làm hư hỏng một kho Git.
  11
  12 Hy vọng là Git sẽ chuyển sang sử dụng hàm băm tốt hơn trước khi tìm ra cách phá mã SHA1.
  13
  14 === Microsoft Windows ===
  15
  16 Sử dụng Git trên hệ điều hành Microsoft Windows có vẻ hơi cồng kềnh một chút:
  17
  18 - http://cygwin.com/[Cygwin], mô phỏng Linux dành cho Windows, có chứa  http://cygwin.com/packages/git/[Git đã chuyển đổi để chạy trên Windows].
  19
  20 - http://code.google.com/p/msysgit/[Git chạy trên MSys] là một thay thế với các hỗ trợ tối thiểu nhất, bởi vì chỉ cần một ít lệnh để thực hiện một số việc mà thôi.
  21
  22 === Các Tệp tin Không liên quan ===
  23
  24 Nếu dự án của bạn rất lớn và chứa rất nhiều tệp tin không có liên quan mà luôn luôn bị thay đổi, Git có thể chịu thiệt thòi hơn các hệ thống khác bởi vì các tệp tin riêng lẻ không được giữ dấu viết. Git giữ các dấu vết thay đổi cho toàn bộ dự án, điều này thường là có lợi.
  25
  26 Giải pháp là chia nhỏ dự án của bạn ra, mỗi một phần bao gồm các tệp tin liên quan đến nhau. Hãy sử dụng *git submodule* nếu bạn vẫn muốn giữ mọi thứ trong một kho chung.
  27
  28 === Ai sửa và Sửa gì? ===
  29
  30 Một số hệ thống quản lý mã nguồn bắt buộc bạn đánh dấu rõ ràng vào tệp tin theo một cách nào đó trước khi biên soạn. While this is especially annoying when this involves talking to a máy chủ trung tâm, việc làm này có hai lợi ích:
  31
  32   1. Diffs thì nhanh bởi vì nó chỉ kểm tra các tệp tin đã đánh dấu.
  33
  34   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.
  35
  36 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.
  37
  38 === Lịch sử Tệp tin  ===
  39
  40 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ẻ.
  41
  42 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.
  43
  44 === Khởi tạo Bản sao ===
  45
  46 Việc tạo một bản sao có vẻ hơi xa xỉ hơn là checking out trong các hệ thống quản lý mã nguồn khác khi phần mềm có lịch sử phát triển lâu dài.
  47
  48 Cái giá phải trả ban đầu là cần nhiều thời gian để lấy về, nhưng nếu làm như thế, các tác vụ cần làm trong tương lai sẽ nhanh chóng và không cần có mạng. Tuy nhiên, trong một số hoàn cảnh, cách làm thích đáng hơn là tạo một bản sao không đầy đủ tất cả với tùy chọn `--depth`. Điều này giúp ta làm nhanh hơn, nhưng bản sao nhận được sẽ thiếu đi một số chức năng do đó bạn sẽ không thể thực thi được một số lệnh.
  49
  50 === Các Dự Án Hay Thay Đổi ===
  51
  52 Git was written to be fast with respect to the size of the changes. Con người chỉ tạo ra sự thay đổi rất nhỏ giữa các phiên bản. Một lời nhận xét có sửa lỗi ở đây, có đặc tính mới ở đây, sửa lỗi chú thích, v.v... Nhưng nếu các tệp tin của bạn căn bản khác nhau  different in successive revisions, thì trong mỗi lần commit, phần ghi lịch sử toàn bộ dự án của bạn tất yếu sẽ tăng kích cỡ.
  53
  54 Không có  bất kỳ một hệ thống quản lý mã nguồn nào có thể làm được điều này, but standard Git users will suffer more since normally histories are cloned.
  55
  56 The reasons why the changes are so great should be examined. Định dạng các tệp tin có thể bị thay đổi. Các thay đổi nhỏ should only cause minor changes phần lớn tại một số ít tệp tin.
  57
  58 Or perhaps a database or backup/archival solution is what is actually being sought, không phải là hệ thống quản lý mã nguồn. Ví dụ, quản lý mã nguồn không thích hợp cho việc quản lý ảnh được chụp một cách định kỳ từ webcam.
  59
  60 If the files really must be constantly morphing and they really must be versioned, a possibility is to use Git in a centralized fashion. One can create shallow clones, which checks out little or no history of the project. Dĩ nhiên, nhiều công cụ dành cho Git sẽ không thể hoạt động được, và sự sửa chữa phải được chuyển lên như là các miếng vá. This is probably fine as it's unclear why anyone would want the history of wildly unstable files.
  61
  62 Một ví dụ khác là dự án phụ thuộc vào firmware, cái này có dạng thức là tệp tin nhị phân có kích thước rất lớn. Người sử dụng không quan tâm tới lịch sử của firmware, and updates compress poorly, vì vậy quản lý firmware có lẽ là không cần thiết vì nó làm phình to kích thước kho chứa.
  63
  64 Trong trường hợp này, mã nguồn có thể lưu giữ trong kho Git, và tệp tin nhị phân được giữ ở nơi khác. Để cho công việc trở nên dễ dàng hơn, một người có thể phân phối một script mà nó sử dụng Git để clone mã nguồn, và dùng lệnh rsync hay Git shallow clone cho firmware.
  65
  66 === Bộ Đếm ===
  67
  68 Một số hệ quản trị mã nguồn tập trung duy trì một số nguyên dương tự động tăng lên khi có lần commit mới được chấp nhận. Git quy các thay đổi này bởi giá trị băm của chúng, điều này là tốt trong phần lớn hoàn cảnh.
  69
  70 Nhưng một số người thích có nó ở dạng số nguyên. May mắn thay, rất dễ dàng để viết các script như thế với mỗi lần cập nhật, kho Git trung tâm Git gia một số nguyên, có thể là trong một thẻ (tag), và kết hợp nó với giá trị băm của lần commit cuối.
  71
  72 Mỗi bản sao có thể có một bộ đếm riêng, nhưng điều này chẳng ích lợi gì, chỉ có kho chứa trung tâm và bộ đếm của nó là có ý nghĩa với mọi người.
  73
  74 === Các thư mục Rỗng ===
  75
  76 Các thư mục rỗng không được theo dõi. Tạo ra các tệp tin giả để thử trục trặc này.
  77
  78 Xét về mặt thi hành của Git, thay vì thiết kế của nó, điều hạn chế này này là đáng trách. Với một chút may mắn, một khi Git gains more traction, thêm nhiều người đòi hỏi tính năng này và nó sẽ được thực hiện.
  79
  80 === Lần Commit Khởi tạo ===
  81
  82 A stereotypical computer scientist đếm từ 0, thay vì 1. Thật không may, with respect to commits, git không tôn trọng quy ước này. 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, như là việc rebasing a một nhánh với lần commit khởi tạo khác.
  83
  84 Git có thể có được lợi ích từ việc định nghĩa lần commit zero: 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.
  85
  86 Sau đó chạy lệnh git log, ví dụ thế, thì Git nên báo cho người dùng biết chưa có lần commit nào, thay vì phát ra một lỗi nghiêm trọng. Điều tương tự xảy ra với các công cụ khác.
  87
  88 Tất cả các bản commit đầu tiên hoàn toàn là con cháu của bản 0 (zero).
  89
  90 Tuy nhiên, ở đây có một số vấn đề xảy ra trong một số trường hợp đặc biệt. Nếu nhiều nhánh với các lần khởi tạo commit khác nhau được trộn với nhau, then rebasing the result đòi hỏi thực chất có sự can thiệp bằng tay.
  91
  92 === Giao diện Lập lờ ===
  93
  94 Để commit A và B, nghĩa của biểu thức "A..B" và "A...B" tùy thuộc vào
  95 việc lệnh mong đó là hai điểm mút hay là một vùng. Xem *git help diff*
  96 và *git help rev-parse*.