Vấn đề: Khi đống commit trở thành “mớ bòng bong”
Cầm trịch một team dev 5-10 người, không ít lần mình rơi vào cảnh “mù thông tin” dù code vẫn push lên ầm ầm. Dự án vẫn chạy, nhưng khi cần nhìn lại tổng thể để biết ai đang tập trung vào module nào, hay file nào đang bị thay đổi quá nhiều (code churn) gây mất ổn định, mình lại lúng túng.
Dùng git log thuần túy giống như đọc một cuốn tiểu thuyết không có mục lục. Bạn thấy mọi chi tiết để debug, nhưng để tổng hợp báo cáo hay đánh giá tiến độ thì đúng là một cực hình. Mình không thể ngồi đếm từng dòng để biết tuần này ông A làm bao nhiêu task, hay ông B có đang “spam” commit vô nghĩa hay không.
Nguyên nhân: Git log mặc định không dành cho việc thống kê
Về bản chất, git log là một cuốn nhật ký ghi chép mọi biến động theo thời gian. Nó cực giỏi trong việc truy vết, nhưng lại rất tệ khi cần tổng hợp số liệu vì những lý do sau:
- Nhiễu thông tin: Các commit nhỏ lẻ kiểu “fix typo” hay “update readme” nằm xen kẽ với các tính năng quan trọng, làm loãng dữ liệu.
- Thiếu định lượng: Bạn không thể biết khối lượng công việc thực tế (số dòng code thêm/xóa) nếu không soi kỹ từng commit.
- Khó phân loại: Việc lọc ra đóng góp của từng thành viên trong một khoảng thời gian cụ thể mà vẫn giữ được sự gọn gàng là điều gần như không thể với lệnh log cơ bản.
Giải pháp: Từ lệnh có sẵn đến công cụ chuyên sâu
Để giải quyết bài toán này, mình thường áp dụng 3 cấp độ tiếp cận tùy theo nhu cầu cần số liệu nhanh hay phân tích sâu.
1. Git shortlog: Công cụ “mì ăn liền” cực mạnh
Đây là lệnh built-in sẵn có trong Git. Thay vì liệt kê chi tiết, nó nhóm các commit theo tác giả. Mình thường dùng lệnh này nhất trong các buổi họp sync nhanh cuối tuần.
# Thống kê số lượng commit của mỗi người, sắp xếp từ nhiều đến ít
git shortlog -sn
# Xem chi tiết tiêu đề commit của từng người trong 14 ngày qua
git shortlog --since="14 days ago"Điểm cộng: Chạy ngay không cần cài đặt, tốc độ phản hồi tính bằng milisecond.
Hạn chế: Chỉ dừng lại ở việc đếm số lượng commit, chưa cho thấy độ phức tạp của công việc.
2. Git log –stat: Soi kỹ khối lượng công việc
Muốn biết ai đó thực sự “cày cuốc” hay chỉ đang dạo chơi, mình dùng --stat. Lệnh này bóc tách số file bị thay đổi và chi tiết số dòng thêm/xóa của từng người.
# Thống kê thay đổi của một dev cụ thể từ đầu năm 2024
git log --author="Hoang Nguyen" --since="2024-01-01" --stat3. Công cụ bên thứ ba: git-quick-stats và git-effort
Khi dự án bước vào giai đoạn bảo trì phức tạp, mình cần biết file nào đang là “điểm nóng” (thay đổi quá thường xuyên). Lúc này, các lệnh mặc định bắt đầu bộc lộ hạn chế về mặt trực quan.
Hướng dẫn triển khai thực tế
Cách 1: Lập báo cáo nhanh cho Sprint Review
Để chuẩn bị cho buổi Sprint Review, mình thường chạy lệnh dưới đây để có cái nhìn tổng quát về đóng góp của cả team:
git shortlog -sn --all --no-merges-s: Chỉ hiển thị tổng số.-n: Sắp xếp giảm dần để biết ai đang “nhiệt” nhất.--all: Quét trên mọi branch, không bỏ sót code đang nằm ở nhánh feature.--no-merges: Loại bỏ commit merge. Điều này cực quan trọng vì merge commit thường không chứa code mới, nếu tính vào sẽ làm sai lệch con số thực tế.
Kinh nghiệm thực tế: Có lần mình thấy một bạn dev có tới 300 commit trong khi người khác chỉ 50. Kiểm tra bằng git shortlog -e, mình phát hiện bạn ấy dùng 2 email khác nhau (cá nhân và công ty). Mình đã dùng file .mailmap để gộp danh tính, giúp báo cáo chuẩn xác hơn.
Cách 2: Tìm “ổ bug” với Git Effort
Trong mọi dự án luôn tồn tại những file code “nhạy cảm”, hễ chạm vào là lỗi. Mình gọi đó là Hot Files. Để nhận diện chúng, mình dùng git-effort thuộc bộ tool git-extras.
# Cài đặt nhanh trên Ubuntu
sudo apt install git-extras
# Tìm xem file nào được chỉnh sửa nhiều nhất
git effort --activeLệnh này hiển thị số ngày làm việc và tổng số commit tác động vào file. Nếu file auth_service.py có 150 commit trong 3 tháng, đó rõ ràng là ứng viên hàng đầu cần được Refactor ngay lập tức.
Cách 3: Dashboard trực quan với git-quick-stats
Nếu bạn thích cảm giác chuyên nghiệp với menu tương tác ngay trên terminal, git-quick-stats là lựa chọn số 1.
# Sau khi cài đặt, khởi chạy bằng lệnh
git-quick-statsMục Contribution stats by author sẽ cho bạn thấy biểu đồ đóng góp theo tháng. Nhìn vào đây, mình dễ dàng nhận ra giai đoạn nào team bị quá tải hoặc năng suất sụt giảm để điều chỉnh khối lượng công việc kịp thời.
So sánh các phương pháp
| Tiêu chí | Git Shortlog | Git Log –stat | Git-quick-stats |
|---|---|---|---|
| Độ tiện dụng | Rất cao (Sẵn có) | Trung bình | Cần cài đặt |
| Độ chi tiết | Thấp (Chỉ đếm) | Khá (Dòng code) | Rất sâu (Biểu đồ) |
| Phù hợp cho | Báo cáo nhanh | Kiểm tra task | Phân tích hệ thống |
Lời kết: Đừng để con số đánh lừa bạn
Sau nhiều năm quản lý, mình rút ra một bài học xương máu: Số lượng commit hay số dòng code không bao giờ tỷ lệ thuận với trình độ.
Một Senior Dev có thể chỉ push đúng 1 commit với 10 dòng code nhưng xử lý triệt để lỗi logic nghiêm trọng. Trong khi đó, một Junior có thể loay hoay cả tuần với 50 commit nhỏ lẻ mà vẫn chưa xong việc. Hãy dùng các công cụ này như một chiếc la bàn để định hướng, chứ đừng biến chúng thành thước đo KPI duy nhất.
Thói quen của mình là kết hợp git shortlog với việc review code. Nếu thấy ai đó có quá nhiều commit rác kiểu “update”, mình sẽ hướng dẫn họ dùng git commit --amend hoặc squash commit để giữ lịch sử dự án luôn sạch đẹp và chuyên nghiệp.
