How Git Works bởi Julia Evans

Xin chào, chúng tôi là BFS(Byte Freaks Studio). 🎲

Hôm nay, tôi muốn giới thiệu đến các bạn một bài viết mà Julia Evans đã đăng trên blog cá nhân vào tháng 1 vừa qua. Đó chính là câu chuyện về việc trực tiếp chỉnh sửa tài liệu chính thức (documentation) của Git.

Khi sử dụng Git, chắc hẳn đã có ít nhất một lần bạn phải khựng lại trước những thuật ngữ như object, reference, hay index. Julia cũng đã gặp phải tình huống tương tự, và cuối cùng cô ấy đã cùng đồng nghiệp Marie bắt tay vào việc trực tiếp chỉnh sửa một vài trang hướng dẫn chính thức (man page) của Git.

Quá trình tinh chỉnh các trang git add, git checkout, git push, git pull bằng cách nhận phản hồi về "những điểm gây bối rối" từ 80 độc giả thử nghiệm, cùng với những khó khăn bất ngờ trong việc viết tài liệu mã nguồn mở mà họ đã nhận ra trong quá trình đó, là những nội dung mà bất kỳ người dùng Git nào cũng sẽ thấy thú vị khi đọc.

Bản dịch nằm ở bên dưới. Nếu bạn muốn xem bản gốc, bạn có thể kiểm tra trực tiếp tại đây.

Chúc bạn đọc vui vẻ. 🎲

Mô hình dữ liệu của Git (và một số cập nhật tài liệu)

Xin chào!

Mùa thu năm ngoái, tôi đã quyết định dành thời gian để cải thiện tài liệu hướng dẫn của Git. Thông thường, khi cảm thấy tài liệu còn thiếu sót, tôi thường giải quyết bằng cách viết bài trên blog hoặc làm zine riêng. Nhưng lần này, một ý nghĩ đã nảy ra trong đầu tôi.

"Liệu có thể làm cho chính tài liệu chính thức trở nên tốt hơn một chút không?"

Vì vậy, tôi đã cùng với đồng nghiệp Marie thực hiện một số cải tiến cho tài liệu Git.

Mô hình dữ liệu cho Git

Khi xem qua tài liệu Git, tôi nhận thấy Git sử dụng các thuật ngữ như object, reference, và index rất thường xuyên. Tuy nhiên, tôi phát hiện ra rằng đang thiếu các tài liệu giải thích chính xác những thuật ngữ này có nghĩa là gì và chúng có mối quan hệ như thế nào với các khái niệm cốt lõi như commit hay branch.

Vì vậy, chúng tôi đã soạn thảo tài liệu "Mô hình dữ liệu (Data Model)" mới.

Hiện tại bạn có thể đọc tại đây, và chúng tôi dự kiến nó sẽ được đưa vào trang web chính thức của Git sau bản phát hành tiếp theo.

LƯU Ý CỦA BFS: Hiện tại đã được cập nhật trên trang web chính thức của Git.

Lý do tôi đặc biệt hài lòng với công việc này là vì việc hiểu cách Git tổ chức dữ liệu commit và nhánh đã giúp ích rất nhiều cho tôi trong việc hiểu về Git suốt một thời gian dài. Vì vậy, tôi nghĩ rằng nhất định cần có một tài liệu giải thích mô hình dữ liệu của Git một cách ngắn gọn (khoảng 1.600 từ) nhưng chính xác.

Tuy nhiên, việc đảm bảo tính chính xác khó hơn tôi tưởng. Dù đã biết cấu trúc cơ bản nhưng tôi đã học được thêm nhiều chi tiết mới trong quá trình xem xét, và do đó phải chỉnh sửa nhiều phần. Ví dụ, phần giải thích về cách lưu trữ xung đột hợp nhất (merge conflict) trong vùng đệm (staging area) cũng đã được sửa đổi.

Cải thiện tài liệu bao gồm git push, git pull, v.v.

Ngoài ra, tôi cũng đã tiến hành cải thiện phần mở đầu của một vài trang hướng dẫn chính (man page) của Git.

Lúc đầu, tôi chỉ đơn giản nghĩ rằng "hãy thử sửa theo hướng mà mình cho là tốt hơn", nhưng tôi đã sớm nhận ra rằng có một vấn đề.

"Cho dù tôi có nói rằng lời giải thích của mình tốt hơn, liệu các Git maintainer có lý do gì để tin vào điều đó không?"

Khi làm việc với tài liệu mã nguồn mở, tôi thường xuyên bắt gặp tình huống như thế này.

"Giải thích như thế này không phải sẽ rõ ràng hơn sao?"

"Không, giải thích như thế kia mới tốt hơn chứ?"

Tuy nhiên, tôi nghĩ rằng việc các chuyên gia phần mềm tranh luận với nhau về việc "cách giải thích nào dễ hiểu hơn" không mấy hiệu quả. Bởi vì những người đã sử dụng một công cụ cụ thể trong thời gian dài thường khó có thể đánh giá được những người mới bắt đầu gặp khó khăn ở điểm nào.

Vì vậy, chúng tôi muốn tìm kiếm một phương pháp dựa trên cơ sở thực tế hơn một chút.

Tìm lỗi thông qua người đọc thử

Chúng tôi đã tuyển tình nguyện viên từ Mastodon để nhờ họ đọc các tài liệu hiện có và cho biết điều gì gây nhầm lẫn hoặc những câu hỏi nào nảy sinh.

Khoảng 80 độc giả thử nghiệm đã để lại ý kiến, và tôi đã học được rất nhiều điều trong quá trình đó.

Phản hồi mà mọi người để lại rất đa dạng.

• Thuật ngữ khó hiểu

  • pathspec là gì vậy??

  • reference có nghĩa là gì? mean?

  • Thuật ngữ upstream có ý nghĩa đặc biệt gì trong Git không? have a special meaning in Git?

• Ý kiến cho rằng một câu cụ thể nào đó khó hiểu

• Đề xuất nội dung muốn được thêm vào

  • "Tôi luôn làm công việc này nên tôi hy vọng nó sẽ được bao gồm ở đây."

• Chỉ ra sự mâu thuẫn giữa các tài liệu

  • Ở một nơi thì X có vẻ như là giá trị mặc định, nhưng ở nơi khác thì Y lại có vẻ như là giá trị mặc định.

Điều thú vị là hầu hết những người đọc thử nghiệm đều là những người đã sử dụng Git ít nhất từ 5 đến 10 năm trở lên.

Điều này thực ra lại rất tốt. Bởi vì nếu ngay cả những người đã sử dụng Git trong một thời gian dài cũng cảm thấy khó hiểu một câu văn hay thuật ngữ nào đó, thì đó chính là bằng chứng mạnh mẽ cho thấy tài liệu cần phải được sửa đổi để trở nên rõ ràng hơn.

Phương thức này, tức là

"Nếu người dùng thực tế đọc tài liệu hiện có và chỉ ra các vấn đề, chúng tôi sẽ sửa chữa những vấn đề đó"

Tôi cảm thấy cách tiếp cận này, tức là "sửa đổi vấn đề khi người dùng thực tế đọc tài liệu hiện có và chỉ ra những điểm bất cập", đã mang lại hiệu quả rất cao và tôi dự định sẽ thử áp dụng lại trong các dự án khác trong tương lai.

Bạn đã chỉnh sửa những trang hướng dẫn (manual page) nào?

Chúng tôi đã chỉnh sửa bốn trang hướng dẫn sau đây.

• git add (trước, sau)

• git checkout (trước, sau)

• git push (trước, sau)

• git pull (trước, sau)

Đặc biệt là các thao tác git push và git pull đã mang lại sự thú vị nhất.

Ngoài việc cải thiện phần mở đầu, tôi cũng đã viết mới các nội dung sau.

• upstream branchPhần giải thích về khái niệm nhánh thượng nguồn là gì(

  Trước đây, thực tế là nó đã không được giải thích một cách rõ ràng.)

• push refspec Sắp xếp lại phần giải thích vềexplanation cleanup

Khi thực hiện công việc này, tôi lại một lần nữa nhận ra việc duy trì tài liệu mã nguồn mở khó khăn đến nhường nào.

"Câu văn không chỉ cần phải rõ ràng mà đồng thời còn phải chính xác với sự thật."

Đôi khi cũng cần có sự thỏa hiệp. Ví dụ, hãy cùng xem câu văn sau đây.

git push có thể thất bại nếu bạn chưa thiết lập upstream cho nhánh hiện tại, tùy thuộc vào giá trị mà push.default được thiết lập.
("현재 브랜치의 upstream이 설정되지 않았다면, push.default 설정에 따라 git push가 실패할 수 있다.")

Lời giải thích này hơi mơ hồ. Tuy nhiên, để giải thích đầy đủ ý nghĩa chính xác của cụm từ "tùy thuộc vào cài đặt" thì sẽ phức tạp hơn rất nhiều, và chỉ riêng việc đó thôi cũng đã có thể trở thành một dự án lớn rồi.

Về quá trình đóng góp cho Git

Tôi cũng đã mất khá nhiều thời gian để hiểu được quy trình phát triển của Git.

Tôi không định giải thích tất cả ở đây. Bởi vì chỉ riêng việc đó thôi cũng có thể trở thành một bài viết riêng biệt rồi.

Thay vào đó, tôi sẽ để lại một vài ghi chú ngắn.

• Git có một máy chủ Discord, và có một kênh "my first contribution" dành cho những người lần đầu đóng góp.

  • Tôi đã nhận được sự giúp đỡ cần thiết để bắt đầu, và mọi người đều rất thân thiện.

• Tôi đã thực hiện tất cả các đóng góp thông qua GitGitGadget.

  • Tôi có thể sử dụng quy trình làm việc quen thuộc là GitHub Pull Request,

  • GitGitGadget đã giúp chuyển đổi chúng sang định dạng bản vá email (email patch) mà các nhà phát triển Git thường sử dụng.

  • Nhờ vậy, tôi không cần phải học cách gửi bản vá qua email theo cách mới.

• Khi trả lời các đánh giá, tôi đã sử dụng trình duyệt email thông thường mà mình hay dùng (giao diện web của Fastmail).

  • Tôi đã ngắt dòng văn bản ở mức 80 ký tự để phù hợp với quy ước của mailing list.

  
  

• 
  

Ngoài ra, kho lưu trữ danh sách gửi thư của lore.kernel.org hơi khó điều hướng. Vì vậy, tôi đã tự tạo một trình xem danh sách gửi thư Git đơn giản để giúp việc đọc các luồng thảo luận dài trở nên dễ dàng hơn.

Trong quá trình đóng góp và đánh giá, tôi đã nhận được sự giúp đỡ từ rất nhiều người. Tôi xin gửi lời cảm ơn đến Emily Shaffer, Johannes Schindelin (tác giả của GitGitGadget), Patrick Steinhardt, Ben Knoble, Junio Hamano và nhiều người khác nữa.

BFS

Điểm đáng chú ý nhất trong bài viết này là Julia đã không sửa đổi tài liệu chỉ dựa trên sự tự tin rằng "mình có thể giải thích tốt hơn". Thay vào đó, cô ấy đã thu thập phản ứng của những người dùng thực tế trước, và xác định hướng chỉnh sửa dựa trên dữ liệu đó. Việc lắng nghe tiếng nói của những người thực sự đang cảm thấy bối rối sẽ đáng tin cậy hơn nhiều so với việc hai chuyên gia tranh luận rằng "cách diễn đạt này rõ ràng hơn".

Nếu bạn vẫn luôn cảm thấy có điều gì đó chưa rõ ràng về các thuật ngữ Git dù vẫn sử dụng chúng hàng ngày, bài viết này có lẽ sẽ phần nào cho bạn thấy câu trả lời.

Trong thời gian tới, tôi dự định sẽ chọn lọc và dịch lại từng bài viết liên quan đến Git mà Julia đã đăng tải trên blog cá nhân của mình để giới thiệu đến các bạn. Có những bài viết nói về những bất tiện nhỏ mà chúng ta thường gặp khi sử dụng Git, cũng có những bài viết giúp chúng ta nhìn nhận lại những hiểu lầm về các khái niệm tưởng chừng như đã quen thuộc.

Đây là những bài viết giúp bạn hiểu sâu hơn khi xem cùng với 《How Git Works》, tôi dự định sẽ giải thích từng nội dung một nên hãy cùng mong chờ nhé. 🎲

- BFS 🎲

" Xin chào!

Tôi rất vui mừng khi bản dịch tiếng Hàn của cuốn 《How Git Works》 được xuất bản. Mặc dù tôi không thể đọc được tiếng Hàn, nhưng nhìn vào thiết kế và độ hoàn thiện của bản dịch, tôi cảm thấy nó đã được tạo ra một cách thực sự đẹp mắt.

Hy vọng cuốn tạp chí nhỏ (Zine) này sẽ giúp bạn hiểu và sử dụng Git một cách tự tin hơn.

Chúc bạn đọc vui vẻ! "

— Julia Evans

Xin chào. Chúng tôi là BFS (Byte Freaks Studio). 🎲
Sau khi đọc lời chào của Julia, có lẽ bạn sẽ nảy sinh một thắc mắc.

Tại sao Julia lại quyết định tạo ra bản tin (Zine) này?

Git là một công cụ mà vô số nhà phát triển trên toàn thế giới sử dụng hàng ngày, nhưng đồng thời cũng là công cụ khiến nhiều người cảm thấy khó khăn nhất. Julia cũng đã chú ý đến điểm đó, và nỗi trăn trở ấy cuối cùng đã dẫn đến sự ra đời của tác phẩm mang tên 《How Git Works》.

Bài viết dưới đây là bài đăng trên blog do chính Julia viết vào thời điểm xuất bản cuốn 《How Git Works》. Tôi xin giới thiệu bài viết này bằng tiếng Hàn vì nghĩ rằng nó sẽ giúp bạn hiểu sâu hơn về việc cuốn Zine này đã bắt đầu từ vấn đề gì và tác giả muốn truyền tải điều gì.

Chúc bạn đọc vui vẻ. 🎲

Xin chào!

Có vẻ như trong vài tháng qua tôi đã liên tục nói về Git trên blog này. Cuối cùng thì tập san (Zine) về Git cũng đã hoàn thành! Nó đã được xuất bản vào thứ Sáu tuần trước.

Cuốn tạp chí (Zine) này dành cho ai?

Cuốn zine này được viết dành cho những người đã sử dụng Git trong nhiều năm nhưng vẫn cảm thấy sợ nó. Tôi luôn nghĩ rằng: thật tệ khi phải sợ hãi một công cụ mà mình sử dụng hàng ngày trong công việc! Tôi muốn mọi người có thể sử dụng Git một cách tự tin.

Mục tiêu của bản tin (zine) này là:

• Giải thích rằng các khái niệm của Git vốn có thể gây cảm giác đáng sợ lúc đầu (ví dụ như "trạng thái detached HEAD") thực ra khá đơn giản nếu bạn hiểu được điều gì đang thực sự diễn ra.

• Chỉ ra những phần cần đặc biệt cẩn thận trong Git. Ví dụ, stash là một trong những tính năng dễ làm mất nội dung công việc nhất, và một khi xảy ra vấn đề thì việc khôi phục cũng cực kỳ phiền phức. Vì vậy, tôi thường không sử dụng stash nhiều.

• Đính chính những hiểu lầm phổ biến về các khái niệm cốt lõi của Git như commit, branch và merge

Rốt cuộc thì Git có điều gì mà lại gây bối rối đến thế?

Việc viết cuốn zine này thực sự khó khăn hơn tôi tưởng. Khi bắt đầu viết, tôi đã sử dụng Git khá tự tin trong suốt 10 năm rồi. Vì vậy, tôi hầu như không còn nhớ cảm giác khi còn phải vật lộn với Git là như thế nào nữa.

Nhưng nhờ có Marie và sự giúp đỡ của rất nhiều người đã chia sẻ về Git trên Mastodon, cuối cùng tôi đã nhận ra một thực tế rằng có rất nhiều phần trong Git không hề trực quan, gây hiểu lầm hoặc đơn giản là cực kỳ khó hiểu.

Ví dụ như những điều này.

• Các thuật ngữ gây nhầm lẫn (như các biểu đạt "fast-forward", "reference", "remote-tracking branch")

• Các thông báo gây hiểu lầm (ví dụ: thông báo Your branch is up to date with 'origin/main' không nhất thiết có nghĩa là nó thực sự đã được đồng bộ hóa với nhánh main của kho lưu trữ từ xa)

• Kết quả đầu ra không cung cấp đủ thông tin (ví dụ: ngay cả bây giờ, khi nhìn vào xung đột hợp nhất (merge conflict), vẫn có những lúc tôi không thể nắm bắt ngay lập tức đoạn mã nào đến từ nhánh nào)

• Thiếu hướng dẫn về tình huống các nhánh bị phân tách (diverged) (ví dụ: khi bạn chạy git pull mà nhánh local và nhánh remote đang bị phân tách, Git không giải thích rõ ràng cho lắm về việc nên xử lý tình huống này như thế nào)

• Các hành vi không nhất quán (ví dụ: reflog hầu như luôn hoạt động theo cách chỉ thêm bản ghi, nhưng stash là một ngoại lệ. Khi thực hiện git stash drop, các mục hiện có sẽ thực sự bị xóa)

Càng nghe nhiều câu chuyện về việc mọi người cảm thấy bối rối như thế nào về Git, tôi càng thấy rõ ràng rằng Git là một công cụ không dễ để hiểu được logic nội tại của nó chỉ bằng cách dùng thử.

Những điểm kỳ lạ của Git cuối cùng rồi cũng sẽ trở nên quen thuộc

Đọc đến đây, có lẽ bạn sẽ cảm thấy Git giống như một công cụ tồi tệ. Thậm chí bạn có thể tự hỏi: "Rốt cuộc thì ai lại đi dùng cái thứ này chứ?"

Nhưng trải nghiệm của tôi thì hơi khác một chút. Sau khi hiểu được ý nghĩa thực sự của những thông báo lỗi kỳ lạ mà Git đưa ra, hầu hết các tình huống đều trở nên khá bình thường.

Ví dụ, giả sử bạn gặp phải lỗi như sau.

failed to push some refs to 'github.com/wizard-zines-site'

Khi đó tôi sẽ nghĩ: "À, chắc là có ai đó đã đẩy các thay đổi lên nhánh main sau lần cuối mình git pull rồi". Và tôi sẽ chạy git pull --rebase để lấy các thay đổi về rồi tiếp tục công việc đang làm. Thông thường việc này chỉ mất khoảng 10 giây là xong.

Hoặc bạn cũng có thể thấy cảnh báo như sau:

Bạn đang ở trạng thái 'detached HEAD'

Trong những trường hợp như vậy, bạn chỉ cần chạy lệnh git checkout mybranch trước khi tiếp tục viết mã. Đó không phải là vấn đề gì lớn.

Đối với tôi, cũng như đối với nhiều người hay thảo luận về Git, những cách diễn đạt kỳ lạ đặc trưng của Git đã trở nên quá quen thuộc đến mức đôi khi chúng tôi quên mất tại sao ai đó lại cảm thấy nó khó hiểu đến vậy.

Cấu trúc bên trong của Git nên được khai thác sâu đến mức nào?

Một trong những điều tôi băn khoăn nhất khi viết cuốn Zine này là nên giải thích nội dung bên trong thư mục .git đến mức độ nào.

Cuối cùng, chúng tôi đã quyết định bao gồm một trang về cấu trúc bên trong của Git ("Khám phá thư mục .git"), nhưng nhìn chung, chúng tôi tập trung nhiều hơn vào các hoạt động thực tế mà bạn thấy khi sử dụng Git và lý do tại sao đôi khi Git lại có những hành vi ngoài dự đoán.

Có hai lý do cho việc đó.

Một là vì đã có sẵn rất nhiều tài liệu tuyệt vời giải thích về cấu trúc bên trong của Git.

Và lý do còn lại là vì tôi cảm thấy rằng, ngay cả khi đã đọc những tài liệu đó, việc hiểu được chúng liên kết như thế nào với những hiện tượng thực tế hiển thị trên giao diện người dùng của Git cũng không hề dễ dàng như tưởng tượng.

Ví dụ, bạn có thể dễ dàng tìm thấy các tài liệu giải thích về kho lưu trữ từ xa (remote) của Git. Một số tài liệu giải thích như sau:

Remote-tracking branches [...] nhắc bạn về vị trí của các nhánh trong kho lưu trữ từ xa vào lần cuối cùng bạn kết nối với chúng.

Tuy nhiên, ngay cả khi đã đọc lời giải thích này, thông báo sau đây hiển thị trong git status vẫn có thể khiến bạn bối rối:

Your branch is up to date with 'origin/main'

Điều đó không có nghĩa là bạn có thể mặc nhiên hiểu rằng nó hoàn toàn được đồng bộ hóa với nhánh main của kho lưu trữ từ xa.

Vì vậy, trong cuốn zine này, thay vì giải thích cấu trúc bên trong của Git trước, tôi muốn tập trung vào những thao tác mà các bạn thực sự gặp phải khi sử dụng Git, đồng thời giải thích các nguyên lý hoạt động bên trong của Git đằng sau những thao tác đó.

Thật ra tôi rất thích Git

Trong bài viết này, tôi đã đưa ra khá nhiều lời phê bình về Git. Tuy nhiên, tôi chỉ viết Zine về những công nghệ mà mình thực sự yêu thích. Git cũng không ngoại lệ.

Có rất nhiều lý do khiến tôi yêu thích Git.

• Nó rất nhanh!

• Khả năng tương thích ngược rất tuyệt vời. Những kiến thức về Git mà tôi đã học từ 10 năm trước đến nay vẫn còn giá trị gần như nguyên vẹn.

• Có rất nhiều dịch vụ lưu trữ Git tuyệt vời mà bạn có thể sử dụng miễn phí. (GitHub! GitLab! Và còn rất nhiều dịch vụ khác nữa!) Nhờ đó, tôi có thể sao lưu mã nguồn của mình một cách dễ dàng.

• Quy trình làm việc đơn giản thực sự rất đơn giản. Khi thực hiện dự án một mình, hầu hết mọi thứ đều hoạt động rất tốt ngay cả khi bạn chỉ lặp lại git commit -am 'whatever' và git push.

• Hầu hết các tệp nội bộ của Git đều là các tệp văn bản khá đơn giản. (Hoặc có các phiên bản có thể xem được dưới dạng văn bản.) Vì vậy, nó mang lại cảm giác rằng bạn luôn có thể hiểu được những gì đang diễn ra bên trong nếu cần thiết.

Hy vọng cuốn tạp chí (Zine) này sẽ giúp ích được phần nào trong việc khiến các bạn cũng trở nên yêu thích Git.

Những người đã giúp đỡ tạo nên tập san (Zine) này

Tôi không tự mình tạo ra những cuốn Zine này!

Tôi đã dành 8 tháng làm việc cùng Marie Claire LeBlanc Flanagan vào mỗi sáng để cùng suy nghĩ cách giải thích Git một cách rõ ràng hơn. Vladimir Kašiković đã thiết kế bìa, và Gersande La Flèche đảm nhận việc hiệu đính. James Coglan, tác giả của cuốn 《Building Git》, đã thực hiện việc kiểm tra kỹ thuật, và quản lý vận hành Lee đã giúp đỡ không chỉ việc chép lại văn bản mà còn vô số việc khác nữa. Đối tác của tôi, Kamal, như mọi khi, đã đọc bản thảo đầu tiên và chỉ ra những phần còn gượng gạo, và tôi cũng đã có rất nhiều cuộc trò chuyện thú vị về Git với Marco Rogers.

Cuối cùng, tôi cũng muốn gửi lời cảm ơn đến tất cả các độc giả bản thử nghiệm (beta reader). Lần này đã có tới 66 độc giả tham gia, đây là con số lớn nhất từ trước đến nay! Họ đã để lại hàng trăm ý kiến về những điều gây nhầm lẫn, những gì họ đã học được, và cả những câu đùa nào của tôi là thú vị.

Thật không dễ dàng gì khi nghe rằng những trang mà tôi nghĩ mình đã giải thích rõ ràng thực ra lại gây bối rối vô cùng. Tuy nhiên, nhờ phát hiện và chỉnh sửa được những vấn đề đó trước khi xuất bản chính thức, cuốn zine này đã có thể trở thành một thành phẩm tốt hơn nhiều.

Xin cảm ơn

Như mọi khi, tôi xin chân thành cảm ơn tất cả những người đã mua zine của tôi trong suốt thời gian qua. Nhờ sự ủng hộ không ngừng nghỉ của các bạn mà tôi mới có thể đi được đến tận đây.

Và xin cảm ơn hơn 1.000 người đã mua bản zine này chỉ trong vòng 3 ngày kể từ khi xuất bản!!!

Nhờ đó, cuốn zine này đã lập kỷ lục là cuốn zine bán chạy nhất trong một ngày trong lịch sử của Wizard Zines. Điều này thật sự đáng kinh ngạc và tôi vô cùng cảm động.

BFS(Byte Freaks Studio)

Bạn đã đọc xong bài viết của Julia chưa?

Điểm ấn tượng nhất trong bài viết này là Julia đã không dừng lại ở việc chỉ trích những bất tiện của Git. Git rất khó. Đôi khi nó kỳ lạ, một số thông báo thì khó hiểu, và một số thao tác thì không hề trực quan. Tuy nhiên, Julia đã đặt ra câu hỏi: "Tại sao Git lại như vậy?". Và cô ấy đã cố gắng phân tích cũng như giải thích từng bước lý do tại sao Git lại khó hiểu đến thế.

Một điểm ấn tượng khác nữa là góc nhìn về tài liệu học tập Git.

Trên thị trường hiện nay đã có rất nhiều tài liệu tuyệt vời giải thích về cấu trúc bên trong của Git. Tuy nhiên, ngay cả sau khi đọc những tài liệu đó, khi thực sự sử dụng Git trên terminal, vẫn thường xuyên xuất hiện những câu hỏi như "Vậy tại sao bây giờ Git lại hành động như thế này?".

Có một khoảng cách lớn hơn tưởng tượng giữa nguyên lý nội bộ của Git và giao diện người dùng mà người dùng thực tế đối mặt. Có lẽ nhiều người đã từng có trải nghiệm tương tự. Đó là cảm giác sau khi đọc xong một phần của cuốn sách dày về Git, bạn tưởng chừng như đã hiểu hết, nhưng rồi lại bối rối khi gặp phải thông báo lỗi trong quá trình làm việc thực tế.

Chúng tôi đánh giá cao việc Julia đã chỉ ra chính xác khoảng cách đó. Trên hết, câu nói này đã tạo được sự đồng cảm đặc biệt.

Bạn đang ở trạng thái 'detached HEAD'

Nếu là một nhà phát triển, chắc hẳn đã có ít nhất một lần bạn phải khựng lại khi nhìn thấy thông báo này.

"Cái này có nghĩa là gì?" "Bây giờ mình phải làm gì đây?" "Nếu chạm vào sai chỗ thì liệu có làm hỏng cái gì không nhỉ?"

Tôi cũng đã từng có những trăn trở tương tự như các bạn. Vì vậy, tôi cảm thấy cuốn sách này không hẳn là một cuốn sách giải thích mọi thứ về Git, mà gần giống như một cuốn sách giúp bạn hiểu tại sao Git lại hoạt động như vậy.

Và khi sự thấu hiểu đó dần tích lũy, Git sẽ trở thành một công cụ bớt xa lạ và bớt đáng sợ hơn. Tôi hy vọng rằng thông qua 《How Git Works》, các bạn cũng sẽ hiểu Git hơn một chút và bớt lo sợ về nó hơn.

— BFS 🎲