Series Git CLI Thực chiến #1: Kỷ nguyên "Code.zip" chấm dứt và Cỗ máy thời gian của Developer

Anh em đã bao giờ nhìn vào thư mục dự án của mình và thấy những file có tên kiểu này chưa:

• api-afc-v1.zip
• api-afc-v2-final.zip
• api-afc-v2-final-fix-loi-that-su.zip
• api-afc-sua-loi-cua-thang-A.zip

Đây là cách quản lý phiên bản "chạy bằng cơm" kinh điển. Hãy tưởng tượng anh em đang viết luồng xử lý giao dịch vé offline. Anh em sửa file transaction.go. Cùng lúc đó, một đồng nghiệp khác cũng mở file đó ra để tối ưu hóa truy vấn cơ sở dữ liệu. Đến cuối ngày, hai người copy code đè lên nhau. Bùm! Code của một người bay màu vĩnh viễn, hệ thống lỗi, sếp trừ lương.

Đó là lý do Git ra đời để cứu rỗi chúng ta.

1. Git thực chất là cái gì?

Nói một cách học thuật, Git là một Hệ thống Quản lý Phiên bản Phân tán (Distributed Version Control System).

Nói theo ngôn ngữ của một kỹ sư thực chiến: Git là một cỗ máy thời gian kết hợp với một vũ trụ đa chiều.

• Cỗ máy thời gian: Nó chụp ảnh (snapshot) lại toàn bộ thư mục code của anh em tại từng thời điểm. Nếu hôm nay code chạy ngon, ngày mai sửa xong lỗi luôn cả app, anh em chỉ cần gõ 1 lệnh là code quay ngược thời gian về đúng ngày hôm qua.
• Vũ trụ đa chiều (Branching): Anh em và đồng nghiệp có thể phân thân tạo ra các "nhánh" (branch) khác nhau. Anh em cứ thoải mái code tính năng A ở nhánh của mình, đồng nghiệp code tính năng B ở nhánh của họ mà không ai dẫm chân lên ai. Cuối cùng, Git sẽ có phép thuật dung hợp (merge) cả 2 nhánh đó lại thành một một cách hoàn hảo.

2. Bí ẩn 3 Trạng thái của Git (Bắt buộc phải hiểu)

Nhiều người học Git bằng cách học vẹt các câu lệnh add, commit, push nhưng không hiểu bên dưới nó chạy thế nào, dẫn đến việc bị conflict (xung đột) code là luống cuống không biết sửa.

Để làm chủ Git CLI, anh em bắt buộc phải hiểu bức tranh kiến trúc này. Git chia thư mục làm việc của anh em thành 3 khu vực riêng biệt:

1. Working Directory (Xưởng mộc): Đây là thư mục dự án anh em nhìn thấy trên máy tính. Anh em mở VS Code lên, gõ code, tạo file, xóa file... mọi thứ đều diễn ra ở Xưởng mộc này. Tuy nhiên, Git lúc này chỉ đứng nhìn chứ chưa hề lưu bất kỳ cái gì vào lịch sử cả.
2. Staging Area (Khu vực đóng gói): Giả sử anh em sửa 10 file, nhưng anh em chỉ muốn lưu lịch sử cho 3 file liên quan đến tính năng "Đăng nhập". Anh em sẽ dùng lệnh đẩy 3 file này từ Xưởng mộc vào Khu vực đóng gói. Nó giống như việc anh em chọn đồ nhét vào thùng carton, chuẩn bị dán băng keo.
3. Local Repository (Kho lưu trữ cục bộ): Sau khi đồ đã nhét đủ vào thùng, anh em dùng lệnh "niêm phong" thùng lại, dán nhãn ghi chú (VD: Đã hoàn thành tính năng Đăng nhập). Lúc này, cái thùng đó chính thức được đưa vào Kho lưu trữ. Nó trở thành một điểm lưu trong "cỗ máy thời gian" mà anh em có thể quay lại bất cứ lúc nào.

3. Tại sao kỹ sư giỏi luôn dùng Git CLI?

Dù các công cụ giao diện UI rất trực quan và đẹp mắt, tại sao khi phỏng vấn hoặc làm việc thực tế, dân Pro lại thích mở Terminal lên gõ lệnh cộc lốc?

1. Tốc độ: Thay vì phải rời tay khỏi bàn phím, cầm chuột click 3-4 phát qua các menu, anh em chỉ cần gõ git commit -am "fix bug" trong chưa tới 2 giây.
2. Sức mạnh tuyệt đối: UI chỉ cung cấp cho anh em những lệnh cơ bản. Khi gặp những ca khó như lỡ xóa nhầm một commit quan trọng, hoặc cần "bới rác" tìm lại một dòng code đã viết từ 6 tháng trước (git bisect, git reflog), chỉ có dòng lệnh mới cung cấp đủ tham số để anh em thi triển ma thuật.
3. Môi trường Server: Khi deploy một Microservice lên server Linux không có giao diện đồ họa, anh em không thể cài UI vào đó được. Giao tiếp qua SSH bằng CLI là con đường duy nhất.

Tóm lại bài 1

Hôm nay anh em đã hiểu được tại sao chúng ta phải dùng Git, và quan trọng nhất là "nằm lòng" 3 khu vực: Working Directory ➔ Staging Area ➔ Repository. Hiểu được sự luân chuyển giữa 3 khu vực này, anh em đã nắm được 50% sức mạnh của Git.

Ở Bài 2, chúng ta sẽ chính thức mở Terminal lên. Tôi sẽ hướng dẫn anh em cách khởi tạo kho chứa đầu tiên, cách đưa code qua lại giữa 3 khu vực này bằng những dòng lệnh CLI cơ bản nhưng sắc bén nhất. Chuẩn bị phím cơ đi nhé!