Vì sao những dự án tỷ đô vẫn dùng Email để nhận Code?
Nếu đã quen bấm nút “Create Pull Request” mượt mà trên GitHub, chắc chắn bạn sẽ thấy việc gửi code qua email chẳng khác nào quay lại… thời đồ đá. Thế nhưng, những “gã khổng lồ” như Linux Kernel (với hơn 10.000 patch mỗi bản release), Git, hay PostgreSQL vẫn kiên trì với mailing list suốt hàng thập kỷ qua.
Hồi mới tập tành đóng góp cho một module nhỏ trong Kernel, mình từng loay hoay mất cả buổi chỉ để cấu hình SMTP server. Tuy nhiên, khi đã quen tay, mình nhận ra cái hay của nó. Mọi thảo luận đều nằm gọn trong một luồng (thread) email cực nhẹ. Bạn không cần mở trình duyệt nặng nề. Quan trọng hơn, quy trình này buộc developer phải chau chuốt từng dòng commit message vì đó là thứ duy nhất giúp duy trì ngữ cảnh cho dự án sau 10-20 năm.
Cùng mình thiết lập git send-email từ con số không để sẵn sàng gửi bản vá đầu tiên nhé.
Quick Start: Gửi Patch đầu tiên trong 5 phút
Dành cho những ai đang vội, đây là lộ trình ngắn nhất để dùng Gmail làm “trạm trung chuyển” patch.
Bước 1: Cài đặt công cụ
Trên Ubuntu hoặc Debian, git send-email thường không đi kèm bộ cài Git mặc định mà nằm trong một package riêng.
sudo apt update
sudo apt install git-emailBước 2: Cấu hình SMTP (Ví dụ với Gmail)
Lưu ý: Bạn không thể dùng mật khẩu Gmail chính. Hãy truy cập tài khoản Google và tạo một App Password (Mật khẩu ứng dụng). Sau đó, nạp cấu hình vào Git:
git config --global sendemail.smtpserver smtp.gmail.com
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpuser [email protected]
# Dùng App Password vừa tạo ở đây
git config --global sendemail.smtppass your-app-passwordBước 3: Tạo Patch và Gửi
# Biến commit cuối cùng thành file .patch
git format-patch -1
# Gửi patch đến maintainer
git send-email [email protected] 0001-fix-something.patchQuy trình làm việc (Workflow) chuẩn chỉnh
Để trở thành một contributor chuyên nghiệp, chỉ biết gửi là chưa đủ. Bạn cần hiểu cách tổ chức một bộ patch (patch series) để maintainer không “ngó lơ” đóng góp của bạn.
1. Viết Commit Message “đắt giá”
Trong thế giới mailing list, commit message chính là tài liệu kỹ thuật. Mình thường dành nhiều thời gian để giải thích “tại sao” hơn là “cái gì”. Áp dụng quy tắc 50/72: Tiêu đề dưới 50 ký tự, nội dung chi tiết xuống dòng ở ký tự thứ 72.
subsystem: description of the change
Detailed explanation of why this change is necessary.
Context, bug report links, and performance impact.
Signed-off-by: Your Name <[email protected]>Bắt buộc: Đừng bao giờ quên dòng Signed-off-by. Đây là xác nhận pháp lý về bản quyền mã nguồn (DCO) mà Linux Kernel cực kỳ khắt khe.
2. Sử dụng git format-patch
Lệnh này chuyển đổi commit của bạn thành định dạng email chuẩn (RFC 2822). Nếu bạn có một chuỗi 5-10 commit, hãy dùng thêm flag --cover-letter. Nó tạo ra file 0000-cover-letter.patch để bạn viết tóm tắt tổng thể thay đổi, giúp người review nắm bắt nhanh mục tiêu của bạn.
3. Kiểm tra lại bằng –annotate
Đừng vội bấm gửi ngay. Mình luôn dùng flag --annotate khi chạy git send-email. Nó sẽ mở trình soạn thảo (Vim/Nano) cho phép bạn rà soát lại nội dung email, thêm bớt ghi chú bên dưới dòng --- mà không làm ảnh hưởng đến nội dung commit chính thức.
Nâng cao: Quản lý các phiên bản Patch (Revision)
Hiếm khi một patch được chấp nhận ngay lần đầu. Maintainer thường sẽ yêu cầu sửa lỗi hoặc tối ưu thêm. Lúc này, bạn cần gửi Version 2 (v2), Version 3 (v3)…
Gửi phiên bản mới
Thay vì sửa tên file thủ công, hãy để Git lo bằng flag -v:
git format-patch -v2 HEAD~1Tiêu đề email sẽ tự động đổi thành [PATCH v2] .... Điều này giúp các công cụ lọc mail của maintainer tự động nhóm các bản vá lại với nhau.
Sử dụng –in-reply-to
Để giữ cuộc hội thoại liền mạch, hãy gửi v2 dưới dạng reply của v1. Bạn chỉ cần copy Message-ID từ email cũ và chạy:
git send-email --in-reply-to="[email protected]" v2-0001-fix.patchKinh nghiệm “xương máu” và các lỗi sơ đẳng
Sau nhiều lần bị maintainer nhắc nhở, mình rút ra vài điểm cần lưu ý để tránh bị đánh giá là thiếu chuyên nghiệp:
Tuyệt đối không gửi patch bằng Web Mail
Nhiều bạn copy nội dung file patch rồi dán vào Gmail hay Outlook. Đây là sai lầm tai hại. Các trình duyệt thường tự động thay đổi khoảng trắng (tab thành space) hoặc tự ngắt dòng (word-wrap). Chỉ cần sai một dấu cách, patch sẽ bị hỏng và maintainer không thể dùng lệnh git am để áp dụng code của bạn được.
Chạy script kiểm tra lỗi tự động
Với Linux Kernel, họ cung cấp sẵn script checkpatch.pl. Trước khi gửi, hãy chạy lệnh sau:
./scripts/checkpatch.pl 0001-my-patch.patchNó sẽ bắt lỗi những thứ nhỏ nhặt nhất như dư khoảng trắng ở cuối dòng hay dùng thụt đầu dòng sai quy định (Kernel dùng Tab, không dùng Space).
Lời kết
Làm quen với git send-email có vẻ rắc rối ban đầu, nhưng đây là tấm vé thông hành để bạn bước chân vào thế giới System Programming chuyên nghiệp. Nó không chỉ là công cụ, mà còn rèn luyện tư duy kỷ luật và cách giao tiếp kỹ thuật chuẩn mực. Chúc các bạn có những patch đầu tiên được merge thành công vào các dự án core của thế giới!
