How Git Works bởi Julia Evans

" 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 🎲