Trả lời ngắn: Git không phải phần mềm bạn chọn dùng hay không — mọi công ty phần mềm đều dùng nó, nên đây là thứ phải học trước khi đi xin việc.
Khó khăn thật: không nằm ở việc nhớ lệnh mà ở việc hiểu mô hình hoạt động bên dưới.
Vì sao người mới thấy Git khó?
Phần lớn phần mềm có thể học bằng cách mò: bấm thử các nút, xem chuyện gì xảy ra, dần dần hiểu ra.
Công cụ này thì không. Các lệnh của nó thao tác trên một mô hình trừu tượng gồm ảnh chụp trạng thái, con trỏ và nhánh — và nếu bạn chưa hiểu mô hình đó thì mọi lệnh đều như phép thuật.
Hệ quả là người mới học thuộc lòng vài câu lệnh để làm việc hằng ngày, rồi hoảng loạn khi gặp tình huống ngoài kịch bản quen thuộc.
Cách học hiệu quả là ngược lại: dành hai giờ hiểu ba khái niệm cốt lõi trước, sau đó các lệnh trở nên hiển nhiên và bạn tự suy ra được cách xử lý tình huống lạ.
Git làm được gì?
| Việc | Mức độ | Ghi chú |
|---|---|---|
| Lưu lại toàn bộ lịch sử thay đổi mã nguồn | Tốt nhất | Quay về bất kỳ thời điểm nào trong quá khứ |
| Nhiều người làm chung mà không đè lên nhau | Tốt nhất | Lý do nó trở thành tiêu chuẩn ngành |
| Thử nghiệm trên nhánh riêng rồi bỏ nếu hỏng | Tốt nhất | Không ảnh hưởng mã đang chạy |
| Tìm ra thay đổi nào gây lỗi | Rất tốt | Có công cụ dò nhị phân qua lịch sử |
| Hoạt động hoàn toàn ngoại tuyến | Rất tốt | Toàn bộ lịch sử nằm trên máy bạn |
| Miễn phí, mã nguồn mở | Rất tốt | Không có phiên bản trả phí |
| Đường học với người mới | Kém | Khái niệm trừu tượng, thông báo lỗi khó hiểu |
| Xử lý tệp nhị phân lớn | Khá | Ảnh và video làm kho phình nhanh |
| Giao diện dòng lệnh | Khá | Cần công cụ đồ hoạ nếu bạn ngại gõ lệnh |
Ai nên học Git?
- Mọi người làm nghề lập trình — không có ngoại lệ, đây là yêu cầu tối thiểu.
- Người viết tài liệu kỹ thuật — nhiều nhóm quản lý tài liệu bằng cùng công cụ.
- Ai làm phân tích dữ liệu — để lưu lại phiên bản mã xử lý và mô hình.
- Người tự học lập trình muốn xin việc — nhà tuyển dụng mặc định bạn đã biết.
Chưa cần nếu bạn chỉ dùng máy cho công việc văn phòng — Google Drive đã có lịch sử phiên bản đủ dùng cho tài liệu.
Ba khái niệm cần hiểu trước khi học lệnh
Hiểu ba thứ này rồi thì phần lớn lệnh tự giải thích được.
| Khái niệm | Hiểu đơn giản là gì |
|---|---|
| Bản ghi thay đổi | Một ảnh chụp toàn bộ dự án tại một thời điểm |
| Nhánh | Một con trỏ chỉ vào một ảnh chụp cụ thể |
| Khu vực chuẩn bị | Chỗ bạn chọn ra những thay đổi nào sẽ vào ảnh chụp tiếp theo |
| Kho từ xa | Một bản sao của kho đặt trên máy chủ để cả nhóm đồng bộ |
| Gộp nhánh | Đưa các thay đổi từ nhánh này sang nhánh kia |
| Xung đột | Khi hai người sửa cùng một dòng và công cụ không tự quyết được |
Quy trình làm việc cơ bản hằng ngày
- Kéo về thay đổi mới nhất từ kho chung (2 phút) — Làm đầu mỗi buổi để tránh xung đột lớn.
- Tạo nhánh riêng cho việc bạn sắp làm (1 phút) — Không sửa thẳng trên nhánh chính.
- Viết mã và ghi lại thay đổi theo từng bước nhỏ (liên tục) — Mỗi bản ghi một việc.
- Viết mô tả rõ ràng cho từng bản ghi (mỗi lần) — Người đọc là bạn của sáu tháng sau.
- Đẩy nhánh lên kho chung và mở yêu cầu gộp (10 phút) — Để đồng nghiệp xem lại.
- Xoá nhánh sau khi đã gộp (1 phút) — Giữ danh sách nhánh gọn gàng.
Vì sao mô tả bản ghi thay đổi lại quan trọng?
Đây là thói quen phân biệt người làm việc chuyên nghiệp với người mới, và giá trị của nó chỉ lộ ra sau vài tháng.
Rất nhiều người ghi mô tả kiểu sửa lỗi, cập nhật, hoặc thậm chí chỉ một dấu chấm. Lúc viết thì bạn biết mình vừa làm gì nên thấy không cần ghi chi tiết.
Sáu tháng sau, khi có lỗi và bạn phải dò lại xem thay đổi nào gây ra nó, bạn nhìn vào một danh sách hai trăm dòng mô tả chung chung và không có manh mối nào.
Một mô tả tốt trả lời câu hỏi tại sao chứ không phải cái gì — vì phần cái gì đã nằm trong bản thân đoạn mã rồi. Ví dụ thay vì ghi sửa hàm tính giá, hãy ghi làm tròn giá theo đơn vị nghìn đồng để khớp với yêu cầu kế toán. Câu sau tiết kiệm cho ai đó nửa giờ điều tra.
Hạn chế cần biết
Đường học dốc với người mới
Khái niệm trừu tượng và thông báo lỗi không thân thiện.
Không hợp với tệp nhị phân lớn
Ảnh, video và tệp thiết kế làm kho phình rất nhanh.
Thao tác sửa lịch sử dễ gây rắc rối
Một số lệnh viết lại lịch sử có thể ảnh hưởng cả nhóm.
Cần công cụ đồ hoạ nếu ngại dòng lệnh
Bản gốc chỉ có giao diện dòng lệnh.
Không tự giải quyết được xung đột phức tạp
Vẫn cần người đọc và quyết định giữ phần nào.
Git so với các cách quản lý phiên bản khác
| Tiêu chí | Git | Chép thư mục thủ công | Lịch sử của dịch vụ đám mây |
|---|---|---|---|
| Nhiều người làm chung | Tốt nhất | Kém | Khá |
| Lưu lịch sử chi tiết | Tốt nhất | Kém | Tốt |
| Thử nghiệm không ảnh hưởng bản chính | Tốt nhất | Khá | Kém |
| Dễ với người mới | Kém | Tốt nhất | Rất tốt |
| Hợp với tệp nhị phân lớn | Khá | Tốt | Tốt nhất |
| Chi phí | Miễn phí | Miễn phí | Tuỳ gói |
Xem thêm đánh giá GitHub, đánh giá GitLab, đánh giá Visual Studio Code, hoặc duyệt nhóm công cụ lập trình.
Kết luận
Git là kỹ năng bắt buộc của nghề lập trình, và cũng là thứ hữu ích cho bất kỳ ai làm việc với tệp văn bản cần lưu lịch sử.
Cách học đúng là đầu tư hai giờ hiểu mô hình bên dưới trước khi học lệnh. Nếu bạn học thuộc lệnh mà chưa hiểu ảnh chụp và con trỏ là gì, bạn sẽ mắc kẹt ngay lần đầu gặp tình huống lạ.
Và hãy tập thói quen viết mô tả thay đổi cho tử tế ngay từ đầu. Đó là món quà bạn gửi cho chính mình của sáu tháng sau, khi phải quay lại tìm hiểu vì sao đoạn mã này lại được viết như vậy.
