3,918 lượt đọc

Tại sao Git lại phức tạp như vậy

từ tác giả Marcin Wosinek6m2022/11/16

dài quá đọc không nổi

Git được viết bởi Linus Torvalds để quản lý cơ sở mã Linux. Nó được thực hiện với những mục tiêu khác nhau: những mục tiêu quan trọng hơn và thách thức hơn. Git ưu tiên người dùng cũ và thói quen của họ hơn là sự đơn giản dành cho người dùng mới hơn. Giao diện Git phức tạp hơn mức cần thiết vì nó tôn trọng thói quen cũ của người dùng. Git được bảo mật khỏi các cuộc tấn công trung gian: hầu như không có cách nào can thiệp vào bên trong kho lưu trữ mà Git không nhận thấy có gì đó không ổn.

featured image - Tại sao Git lại phức tạp như vậy

Khi bạn học lập trình, mọi người thường khuyên bạn nên học Git. Về lý thuyết, điều đó nghe có vẻ dễ dàng: một chương trình theo dõi các thay đổi đối với mã của bạn giúp bạn khôi phục các phiên bản mã trước đó khi bạn cần. Bên cạnh đó, nó là một công cụ được sử dụng ở hầu hết mọi nơi trong ngành. Trong thực tế… Ít nhất thì Git có thể gây nhầm lẫn.

Tại sao nó phải theo cách này?

Giao diện dòng lệnh—CLI

Hầu hết người dùng máy tính hàng ngày không quen với sự sang trọng của giao diện dựa trên văn bản. Tôi gọi nó là sang trọng, bởi vì như tôi đã viết trước đây , nó có một số lợi thế lớn—mặc dù có thể mất một thời gian để làm quen với trải nghiệm người dùng. Vì vậy, nếu các hiệp hội của bạn khớp với những hiệp hội trong danh sách:

cat —một con vật có lông,
cd —cách mọi người thường nghe nhạc và
grep —một số từ tượng thanh,

thì rất có thể trải nghiệm đầu tiên của bạn với Git sẽ gặp thêm khó khăn khi học những điều cơ bản về dòng lệnh. Thứ mà Windows 95 và những thứ cùng loại với nó đã lấy đi của bạn.

Mục tiêu thiết kế của Git

Git không bao giờ có nghĩa là đơn giản. Nó được thực hiện với những mục tiêu khác nhau: những mục tiêu quan trọng hơn và thách thức hơn.

Lưu trữ an toàn dữ liệu đã lưu

Git có nghĩa là luôn trả lại cho bạn dữ liệu chính xác như dữ liệu đã được lưu HOẶC cho bạn biết kho lưu trữ bị hỏng. Và nó thực hiện một công việc tuyệt vời với nó—bạn có thể chắc chắn rằng trạng thái mà bạn nhận được khi kiểm tra một cam kết chính xác như ý nghĩa của tác giả. Tất nhiên, điều này giả định rằng họ biết những gì họ đang làm.

Làm thế nào để Git đạt được bảo mật dữ liệu tốt như vậy? Nó làm như vậy theo cách thông minh để lưu trữ mọi thứ — các xác nhận, thư mục và tệp. Mỗi đối tượng được xác định bằng hàm băm mật mã của nội dung của nó—một số được tạo dựa trên nội dung của đối tượng, số này sẽ thay đổi nếu bất kỳ thứ gì bên trong tệp bị thay đổi. Vì các tham chiếu giữa các đối tượng cũng được băm, nên hầu như không có cách nào can thiệp vào bên trong kho lưu trữ mà Git không nhận thấy có gì đó không ổn. Và ngay cả trong những trường hợp đó, mã có ý nghĩa sẽ được thay thế bằng văn bản dài vô nghĩa.

Làm việc trên các mạng không an toàn với những người tham gia không đáng tin cậy

Bởi vì mọi thứ được xác định bằng hàm băm mật mã, Git không cần phải tin tưởng nhiều vào mạng để giữ nguyên dữ liệu. Git được bảo mật khỏi các cuộc tấn công trung gian: không có cách nào ai đó có thể đưa mã có ý nghĩa vào giữa hai nút của Git. Tất nhiên, nếu ai đó có thể đọc các cam kết mà họ không cố ý, thì đây cũng là một vấn đề, nhưng với hậu quả ít nguy hiểm hơn so với những kẻ tấn công đưa mã vào cơ sở mã.

Đối với một lớp bảo mật bổ sung, Git cung cấp các cam kết đăng ký—một phương tiện bổ sung để đảm bảo cam kết được tác giả bởi người được coi là tác giả của nó.

Duy trì khả năng tương thích ngược

Giao diện Git phức tạp hơn mức cần thiết vì nó tôn trọng thói quen cũ của người dùng. Tôi đã học Git vào năm 2011 và cho đến tuần trước tôi đã không nhận thấy có một git switch mới được khuyến nghị để thay đổi nhánh. Cách tôi thường làm ( git checkout + nhiều cờ khác nhau) vẫn hoạt động tốt. Git ưu tiên người dùng cũ và thói quen của họ hơn là sự đơn giản dành cho người dùng mới hơn—điều này đưa chúng ta đến điểm tiếp theo.

Trải nghiệm người dùng cho siêu người dùng

Git là một công cụ được tạo ra dành cho những siêu người dùng. Nó được viết bởi Linus Torvalds để quản lý cơ sở mã Linux—không phải nhiệm vụ của người mới bắt đầu. Người dùng chính của Git phát triển hệ điều hành, có nhiều thập kỷ kinh nghiệm về lập trình và sống bên trong dòng lệnh. Tất cả các ứng dụng bên cạnh đó là ngẫu nhiên và không phải là mối quan tâm chính đối với những người phát triển Git.

Sự đánh đổi đơn giản

Khi bạn thiết kế hệ thống, không có gì là miễn phí—sự đơn giản bao gồm cả người dùng.

Che giấu sự phức tạp

Khi bạn đang giải quyết một vấn đề phức tạp vốn có, bạn làm cho các giải pháp trở nên dễ dàng bằng cách trừu tượng hóa sự phức tạp. Nó đã biến mất? Không, nó chỉ bị ẩn khỏi người dùng. Ví dụ: trong trường hợp kết nối internet, tôi và hầu hết hiểu chất lượng kết nối chỉ là số lượng thanh tại 📶:

ít hơn là xấu
nhiều hơn là tốt

Điều này là đủ để sử dụng internet, nhưng nó gây khó hiểu và khó khắc phục mọi sự cố kết nối.

Git tập trung vào việc phơi bày tất cả sự phức tạp đi kèm với việc thay đổi tệp song song và đồng bộ hóa theo cách không đồng bộ. Ở phía đối diện, bạn có quyền truy cập trực tiếp vào ổ đĩa được chia sẻ. Thật dễ dàng để sử dụng, nhưng điều gì sẽ xảy ra khi hai người cố gắng chỉnh sửa cùng một tệp cùng một lúc? Một người may mắn sẽ giữ được những thay đổi của họ, còn người kia sẽ mất tất cả. Đó không phải là một quy trình làm việc tốt, đặc biệt nếu những thay đổi bị mất đáng giá hàng giờ lao động đắt đỏ. Vì Git cho người dùng thấy tất cả các vấn đề có thể xuất hiện trong tình huống này, nên Git có thể giải quyết xung đột trong các tệp theo cách thông minh—điều này trong một số trường hợp yêu cầu người dùng thực hiện thủ công.

Dễ dàng so với an toàn

Một phần khác của Git khiến người dùng bối rối là các ID cam kết rất dài, cũng như không thể ghi nhớ các con số. Ngay cả ở dạng viết tắt, thân thiện với người dùng, chúng trông giống như 0828ae1 . Và ID đầy đủ là 0828ae10b20500fbc777cc40aa88feefd123ea5e . Thay vào đó, chúng ta có thể chỉ có số theo thứ tự hay chỉ sử dụng tên chi nhánh? Vấn đề là các ID xác nhận là các hàm băm đảm bảo tính toàn vẹn của dữ liệu—chúng đảm bảo rằng xác nhận X trên máy của tôi giống với xác nhận X trên điều khiển từ xa hoặc trên máy của bạn. Và sự không phù hợp giữa chúng có thể xuất hiện vì những lý do khác nhau:

cố ý—rebase, sửa đổi, xóa hoặc bất kỳ hoạt động nào khác làm thay đổi lịch sử
không cố ý—một lỗi hoặc một cuộc tấn công vào cơ sở mã

Đơn giản hóa giao diện và ẩn biểu mẫu ID cam kết, người dùng sẽ loại bỏ khả năng người dùng hiểu điều gì đang xảy ra trên cơ sở mã mà họ đang chạy trên máy của mình. Và bởi vì mã theo định nghĩa được chạy trên máy, bất kỳ khai thác bảo mật nào cũng sẽ cực kỳ nguy hiểm.

Đây có phải là cách tiếp cận đúng?

Khi tôi học Git, nó vẫn còn là một điều mới lạ—tôi học nó vào năm 2011 và Git được tạo ra vào năm 2005 (lần xác nhận đầu tiên là từ Thứ Năm ngày 7 tháng 4 15:13:13 2005 -0700 ). Vào thời điểm đó, tôi đang sử dụng SVN tại nơi làm việc và Mercurial thường được coi là giải pháp thay thế Git thân thiện với người dùng hơn. Gần đây bạn đã nghe những cái tên đó chưa? Git thống trị gần như hoàn toàn thị trường kiểm soát phiên bản. Nó đã trở nên phổ biến với sự phát triển của GitHub, nhưng ngay cả khi nó khó đối với người mới bắt đầu thì nó vẫn là một công cụ rất hiệu quả và nó sẽ tồn tại ở đây.

Làm gì khi là một lập trình viên mới bắt đầu?

Lời khuyên của tôi là học nó càng sớm càng tốt. Rất khó có khả năng Git sẽ sớm trở nên đơn giản hơn. Hoặc bao giờ hết. Các hệ thống kiểm soát phiên bản nói chung giúp tiết kiệm rất nhiều vấn đề đau đầu trong khi bạn lập trình. Tôi không thể tưởng tượng được việc làm việc với mã hiệu quả nếu bạn gặp khó khăn trong việc di chuyển giữa các phiên bản cơ sở mã của mình. Học tốt Git sẽ giúp bạn tập trung vào các thử thách viết mã thay vì vật lộn với các tệp bị mất hoặc khắc phục cái gọi là “các vấn đề về Git”—mà hầu như mọi người luôn tự làm hỏng kho lưu trữ của mình.

Bên cạnh đó, việc học Git đã trở thành một nghi thức đối với các nhà phát triển mới. Là một nhà phát triển, bạn phải sử dụng nó và Git sẽ khiến cuộc sống của bạn trở nên khốn khổ nếu bạn cố sử dụng nó mà không hiểu rõ về nó. Lựa chọn thông minh là tìm hiểu nó theo các điều kiện của bạn chứ không đợi cho đến khi phản hồi của người đánh giá hoặc các vấn đề về mã buộc bạn phải tìm hiểu nó trong khi xử lý các trách nhiệm khác cùng một lúc.