Sao chép một tệp 200 MB và nó bay. Chạy git status trong cùng thư mục đó và thời gian chờ đủ lâu để bạn chuyển sang việc khác. Hai quan sát này không mâu thuẫn, vì truyền khối đo thông lượng còn Git đo xem nó đặt được bao nhiêu câu hỏi nhỏ với hệ thống tệp mỗi giây, và một cây từ xa được gắn sẽ biến mỗi câu hỏi thành một lượt đi về. Chỉnh VPN sẽ không sửa được khối lượng công việc có hình dạng sai.

Vì sao status là thước đo sai

Git phải biết về nhiều tệp: tệp nào bị sửa, tệp nào chưa được theo dõi và liệu dữ liệu chỉ mục đã lưu đệm còn khớp với những gì trên đĩa hay không. Qua SSHFS, mỗi quan sát đó có thể là một thao tác mạng. Đơn vị công việc ở đây là số tệp, không phải megabyte.

Đó là lý do lần status đầu sau khi clone chậm, và cũng là lý do những lần sau có thể chậm hơn nữa trong một cây đầy đầu ra biên dịch. Việc quét các tệp chưa theo dõi đi qua những thư mục mà bạn có thể không quan tâm, và mỗi bước là một yêu cầu nữa qua đường truyền. Trên đường 40 ms, một cây vài nghìn mục trở thành vài nghìn lượt đi về. Không cần bắt gói tin để xác nhận phép cộng đó.

Thước đo tải xuống nói rằng đường truyền tốt; nó không nói gì về việc nghìn lần đọc nhỏ có xong trong chiều nay hay không.

Chuyển cây làm việc, không phải các nút chỉnh

Một bản clone cục bộ đặt cây làm việc, chỉ mục và các thao tác Git trên cùng một máy. Pull trở thành một bước mạng nhìn thấy được thay vì mọi lần kiểm tra tệp đều như vậy.

Điều này phù hợp mỗi khi lập trình viên có thể giữ mã nguồn cần thiết ở máy cục bộ, mà phần lớn thời gian là vậy. Nó cũng làm sắc nét ranh giới giữa commit và triển khai, vì sửa một tệp cục bộ không còn vô tình thay đổi một dịch vụ từ xa đang chạy; thay đổi phải được push và triển khai như mọi thứ khác. Cái giá là mã tồn tại ở hai nơi, nên hãy quyết định bản sao nào là chuẩn và bản vá nóng trên máy chủ quay lại kho như thế nào. Cuộc trò chuyện đó rẻ hơn một lệnh status mà không ai muốn chạy.

Nếu không gian làm việc phải ở xa, hãy chạy Git tại đó

Đôi khi không thể chuyển không gian làm việc: bản dựng cần môi trường đó, dữ liệu quá lớn hoặc chính sách giữ mã nguồn trên máy chủ. Khi đó hãy chạy Git và các công cụ phát triển liên quan ngay cạnh các tệp, qua một shell từ xa được phê duyệt hoặc môi trường phát triển từ xa. Trình soạn thảo có thể ở lại laptop trong khi phần backend của nó làm việc bên cạnh cây làm việc.

Các thao tác đắt đỏ khi đó diễn ra cục bộ trên máy chủ từ xa, và mạng chỉ chuyên chở lưu lượng của trình soạn thảo thay vì hàng nghìn lệnh gọi stat. Đây là cách sửa giống hệt một bản clone cục bộ, được diễn đạt như một lựa chọn triển khai chứ không phải di trú.

Đồng bộ là quy trình có chủ sở hữu, không phải bộ đệm

Một không gian làm việc được đồng bộ có thể giảm các lần đọc từ xa lặp lại, nhưng nó không phải bộ đệm trong suốt. Nó cần một chủ sở hữu cho mỗi thay đổi, một quy tắc cho xung đột và một thỏa thuận về các tệp được tạo ra mà cả hai bên đều cho là của mình. Không có những quy tắc đó, cách sắp xếp tạo ra bất đồng thay vì tiện lợi.

Một bộ đồng bộ hai chiều không có chúng tạo ra vấn đề khác với vấn đề nó đã giải, thường là một lần hợp nhất mà không ai có thể quy cho ai. Tránh chạy hai tiến trình Git trên một cây làm việc dùng chung trừ khi bạn hiểu chúng phối hợp thế nào.

Sau đó hãy tinh chỉnh, và giữ SSH hợp lý

Khi cách sắp xếp đúng, hai thiết lập thay đổi số tệp mà Git phải hỏi: status.showUntrackedFiles và bộ đệm tệp chưa theo dõi phía sau core.untrackedCache. Không cái nào thay đổi chi phí của mỗi câu hỏi trên 40 ms; chúng chỉ thay đổi số câu hỏi. Chỉ vặn một nút khi các lượt đi về đã là cục bộ.

Hãy đo thời gian của lệnh làm bạn khó chịu thay vì suy luận từ một thước đo sao chép một tệp lớn, và để yên mã hóa SSH được hỗ trợ. Một mật mã lỗi thời không rút ngắn lượt đi về; nó thêm một vấn đề thứ hai sống lâu hơn vấn đề đầu. Tài liệu tham chiếu git status đáng đọc một lần, vì lệnh này làm nhiều việc hơn hẳn cái tên của nó.

Bài viết liên quan