Tại sao lịch sử Git của bạn lại trở nên lộn xộn?
Bạn đã bao giờ chạy lệnh git shortlog -sn để thống kê đóng góp và nhận về một kết quả dở khóc dở cười chưa? Một đồng nghiệp tên “Nguyễn Văn A” nhưng lại xuất hiện tận 4 lần. Khi thì là nguyenvana, lúc lại là A Nguyen, [email protected], hay tệ nhất là [email protected].
Tình trạng này cực kỳ phổ biến trong các dự án lâu năm. Trong một repo mình từng quản lý, dù chỉ có 12 thành viên nhưng danh sách tác giả lên tới 50 người. Nguyên nhân thường do anh em quên cấu hình git config hoặc dùng máy cá nhân để fix bug gấp. Hệ quả là dữ liệu thống kê sai lệch, việc truy vết (traceability) trở thành một cơn ác mộng.
Nhiều người sẽ nghĩ ngay đến git filter-branch hoặc BFG để sửa lịch sử. Đừng làm thế! Mình từng mất trắng một buổi chiều vì force push nhầm sau khi rewrite history. Có một giải pháp an toàn hơn, không làm thay đổi mã hash commit, đó chính là .mailmap.
.mailmap – “Bộ lọc” thông minh cho Git
Về cơ bản, .mailmap hoạt động như một lớp ánh xạ (mapping). Nó không sửa dữ liệu gốc trong database của Git. Thay vào đó, khi bạn chạy git log hay git blame, Git sẽ nhìn vào file này để hiển thị tên và email theo đúng quy tắc bạn đặt ra.
Hãy tưởng tượng nó như một cuốn danh bạ thông minh. Dù người gọi có dùng số máy bàn, số cá nhân hay số công ty, điện thoại vẫn hiển thị đúng một cái tên duy nhất. Mọi thứ trở nên ngăn nắp mà không cần động chạm đến cấu trúc commit cũ.
Hướng dẫn cấu hình .mailmap chi tiết
1. Khởi tạo
Bạn chỉ cần tạo một file text đơn giản tên là .mailmap tại thư mục gốc của dự án:
touch .mailmap2. Các cú pháp thường dùng
Cú pháp của file này rất linh hoạt. Dưới đây là 3 kịch bản mình hay áp dụng nhất:
Gộp nhiều email về một tên chuẩn:
Dùng khi một người dùng nhiều email khác nhau nhưng tên hiển thị giống nhau.
Proper Name <[email protected]> <[email protected]>
Proper Name <[email protected]> <[email protected]>Sửa cả tên và email bị sai:
Map chính xác một cặp định danh cũ sang định danh mới.
Proper Name <[email protected]> Commit Name <[email protected]>Chỉ chuẩn hóa tên cho một email:
Hữu ích khi email đã đúng nhưng tên hiển thị lại là nickname hoặc tên máy tính.
Proper Name <[email protected]>3. Ví dụ thực tế từ dự án
Giả sử ông bạn “Trần Văn Tú” đang làm loạn log với 3 kiểu định danh khác nhau. Mình sẽ viết vào file .mailmap như sau:
Tran Van Tu <[email protected]> <[email protected]>
Tran Van Tu <[email protected]> Tu Tran <[email protected]>
Tran Van Tu <[email protected]> tu.tran <[email protected]>Lưu file lại và thử chạy git shortlog -sn. Bạn sẽ thấy điều kỳ diệu: 3 dòng riêng biệt trước đó đã gộp lại thành một dòng duy nhất với tên “Tran Van Tu”.
Tận dụng tối đa sức mạnh của .mailmap
Sức mạnh thực sự của .mailmap nằm ở lệnh git blame. Khi cần tìm người chịu trách nhiệm cho một dòng code từ 3 năm trước, bạn sẽ thấy ngay tên thật thay vì một email lạ hoắc đã ngừng hoạt động.
Từ phiên bản Git 2.9.0, hầu hết các lệnh đều tự động nhận diện file này nếu nó nằm ở root. Tuy nhiên, để chắc chắn hoặc khi dùng các công cụ cũ, bạn có thể thêm flag:
git log --use-mailmapKinh nghiệm cá nhân của mình là hãy commit file .mailmap này lên repo. Khi đó, tất cả đồng nghiệp trong team đều sẽ được thừa hưởng một lịch sử dự án sạch sẽ. Việc làm báo cáo đóng góp hàng tháng nhờ đó mà tiết kiệm được ít nhất 30-45 phút ngồi cộng tay.
Vài lưu ý nhỏ để tránh lỗi
- Thứ tự: Git đọc file từ trên xuống. Quy tắc nào khớp trước sẽ được ưu tiên.
- Độ chính xác: Git phân biệt chữ hoa chữ thường (Case sensitive) với email. Bạn nên copy trực tiếp email từ log ra để tránh sai sót.
- Cú pháp: Luôn có khoảng trắng giữa tên và dấu ngoặc nhọn
< >. Thiếu khoảng trắng này, Git sẽ lờ file của bạn đi.
Lời kết
Dọn dẹp Git không nhất thiết phải dùng đến những kỹ thuật “đao to búa lớn”. Chỉ với một file text nhỏ, bạn đã thể hiện được sự chuyên nghiệp và tinh tế trong cách quản lý mã nguồn. Hãy thử tạo .mailmap ngay hôm nay, đồng nghiệp chắc chắn sẽ thầm cảm ơn bạn vì sự ngăn nắp này!
