Vì sao không nên commit thẳng lên nhánh main? Một pull request tốt cần có những gì?

Commit thẳng lên main nghĩa là thay đổi trở thành code chung ngay lập tức, trước khi có ai đọc và trước khi kiểm tra tự động (CI) chạy. Nếu main còn nối với việc deploy, một lỗi nhỏ sẽ lên thẳng production. Làm trên một nhánh riêng thì main luôn ở trạng thái chạy được, nhiều người làm song song không giẫm lên nhau, và mỗi thay đổi có một chỗ để thảo luận.

Với phần thứ hai, người phỏng vấn muốn nghe bạn nghĩ cho người review. Một pull request tốt thường có:

• Một mục đích duy nhất. Sửa một lỗi hoặc thêm một tính năng. PR trộn sửa lỗi với đổi tên hàng loạt và nâng thư viện thì rất khó review, và khó gỡ ra khi có sự cố.
• Commit chia theo ý nghĩa, tên rõ ràng. Ví dụ một commit cho bản sửa, một commit cho test. File tự sinh như package-lock.json nằm cùng commit với thay đổi sinh ra nó.
• Mô tả trả lời bốn câu: vấn đề là gì, đã đổi gì, kiểm tra bằng cách nào (lệnh cụ thể), và điều gì cố ý chưa làm.
• Đã tự review trước. Đọc lại diff của chính mình để bỏ console.log để quên, file cấu hình cá nhân, code thử nghiệm.
• Kích thước vừa phải. Vài chục tới vài trăm dòng có ý nghĩa. PR nghìn dòng thường chỉ nhận được một chữ "LGTM" mà không ai thật sự đọc.

Nên kể một ví dụ của chính bạn, chẳng hạn một lần đọc lại diff và bắt được dòng log in ra số điện thoại khách hàng trước khi mở PR.

Điểm cộng: nói rằng nhiều nhóm bật branch protection để chặn push thẳng lên main và bắt buộc CI xanh trước khi merge, và rằng PR nhỏ giúp tìm ra commit gây lỗi nhanh hơn.