Lại bàn về cách commit code trong dự án

1950

Bài viết được sự cho phép của tác giả Tống Xuân Hoài

Hàng ngày chúng ta thường xuyên phải code và fix bug liên tục cùng với những thành viên khác trong team. Bỗng một ngày đẹp trời tester hô lên cái lỗi mà bạn đã sửa từ mấy tuần trước bỗng dưng quay trở lại. Bạn liền lên tiếng phân bua rõ ràng đã sửa rồi và phải chứng minh cho tester thấy. Bạn mở lịch sử commit lên và bùm… commit, fix bug, fix some bug… là những thứ đập vào mắt bạn. Không ai khác đó là chính là những message mà bạn commit!

Rồi giờ thì làm sao để tìm lại commit đó? Bạn tự dằn vặt tại sao lúc đó mình không commit rõ ràng hơn. Không sao cả, ai cũng có lúc mắc sai lầm và sai lầm là để sửa chữa nhưng quan trọng hơn là bạn phải nhận ra là bạn đã sai đã rồi để mình bày cách cho!

Hãy commit rõ ràng

Đúng thế trước tiên là hãy cố gắng đặt ra được những message thật rõ ràng và mang tính hành động hướng đến đối tượng.

Ví dụ:

  • Sửa lỗi lấy danh sách tỉnh/thành bị thiếu tên
  • Thêm tính năng cập nhật tỉnh/thành
  • Thêm mục Tài liệu tham khảo vào README.MD

Mình đang lấy ví dụ là Tiếng Việt, tùy vào từng quy tắc dự án của bạn có thể commit bằng Tiếng Anh nhưng cơ bản nội dung vẫn theo tinh thần như trên.

  Hãy commit code có tâm như Senior Developer

  Tôi vừa lỡ commit sai, làm sao để sửa lại ngay lập tức?

Hãy thêm prefix vào trước message

Đây là cách mà nhiều Dev đã và đang áp dụng trong nhiều dự án trên “mạng xã hội” Github. Dựa vào prefix để phân loại các loại commit thường thấy của bạn trong dự án, từ đó dễ dàng phân biệt và tìm kiếm hơn.

Chung quy là sẽ có một số prefix mà các Dev sẽ tự quy ước, nhưng không nhất thiết phải làm theo.

Một số hay dùng như:

  • feat: thêm một tính năng
  • fix: sửa một lỗi
  • refactor: tối ưu một tính năng nào đó đã có từ trước
  • style: những sửa đổi không làm thay đổi ý nghĩa của mã trước đó. Thường liên quan đến định dạng mã như thiếu dấu chấm phẩy (;), xóa khoảng trắng (space)…

Còn nhiều những prefix khác nữa, bạn có thể tham khảo ở bài viết này How to Write Better Git Commit Messages – A Step-By-Step Guide.

Ví dụ:

  • fix: Sửa lỗi lấy danh sách tỉnh/thành bị thiếu tên
  • feat: Thêm tính năng cập nhật tỉnh/thành
  • docs: Thêm mục Tài liệu tham khảo vào README.MD

Xem thêm Việc làm Developer hấp dẫn trên TopDev

Cố gắng tách biệt ý nghĩa của các commit

Mình biết có nhiều bạn (kể cả mình) sẽ hay gặp trường hợp trong khi đang thêm tính năng hay sửa một lỗi này bỗng nhiên phát hiện ra một lỗi khác và tiện tay sửa luôn. Rồi đến lúc commit thì chỉ viết message chung chung là “sửa một số lỗi”. Điều này rất là tiện tuy nhiên lại gây khó khăn trong truy vết, thế nên hãy cố gắng sửa chúng một cách lần lượt. Đừng sợ tốn commit mà hãy commit thật rõ ràng.

Hãy áp dụng Git Flow

Git flow là thuật ngữ để chỉ “quy ước” làm việc của team trong dự án. Ví dụ dự án phải có 3 nhánh là master để lưu lại code mới nhất, nhánh release để xác định tính năng sẵn sàng cho production và nhánh develop để phát triển tính năng cho release.

Ngoài ra Git Flow cũng quy định luồng phân chia và hợp nhất nhánh trong khi đang phát triển tính năng. Có một Git Flow rất nổi tiếng đó là Tóm tắt Git-Flow, các Dev có thể tham khảo.

Cuối cùng, hãy dùng tools có giao diện để quản lý.

Nếu bạn đã quen với giao diện dòng lệnh thì không sao nhưng với mình có nhiều lúc phải dùng những tools để quản lý Git. Mình thấy nó khá là tiện và cũng dễ dàng theo dõi Flow của dự án luôn.

Bây giờ hầu hết các trình viết code đều tích hợp hoặc có plugin giúp cho việc quản lý git bằng giao diện dễ dàng và tiện dụng, các Dev có thể tìm hiểu thêm tuỳ theo công cụ mà mình đang sử dụng.

Tóm lại là

Những chia sẻ bên trên của mình đều xuất phát từ kinh nghiệm trong công việc, việc áp dụng nó trong dự án của các Dev phải tuỳ thuộc vào Team Work và Flow của dự án. Nếu các Dev thấy chưa hợp lý hoặc có còn cách nào hay hơn thì hãy để lại bình luận cho mình và mọi người biết nhé!

Bài viết gốc được đăng tải tại 2coffee.dev

Có thể bạn quan tâm: