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

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

Những mẩu tin ngắn hàng ngày dành cho bạn
  • Ngủ dậy cái, sáng ra thấy mọi người đang xôn xao về mô hình Reasoning R1 của nhà Deepseek.

    Chà, nó có gì mà hót vậy? Có nhiều đấy chứ! Đầu tiên là nguồn mở, sau đó là hiệu năng quảng cáo ngang ngửa o1 của OpenAI, thứ ba là có nhiều tuỳ chọn tham số từ 1.5B đến 70B tha hồ lựa chọn hoặc nghiên cứu.

    » Xem thêm
  • Lên luôn cho nóng 🔥🔥🔥

    Một hướng dẫn cực hay và chi tiết về jj - Jujutsu - như mình đã chi sẻ trước đó jujutsu-tutorial

    » Xem thêm
  • Mỗi khi làm một trang web mới, thứ đầu tiên khiến bạn đau đầu nhất là gì? Với tôi chắc là bố cục. Trong bố cục có một thứ ảnh hưởng rất sâu sắc đó chính là font chữ. Thật vậy, một trang web trở nên sang trọng hơn phụ thuộc rất nhiều vào font chữ. Việc kết hợp nhiều font lại với nhau, đặt đúng chỗ, thuận mắt với người dùng sẽ mang lại ấn tượng rất sâu sắc.

    Ấy thế chọn font chưa bao giờ là dễ, mình mới tìm thấy trang uifonts.app giúp mọi người nhanh chóng kiểm tra xem font chữ này có hợp với ý tưởng website mới của mình hay không 😇

    » Xem thêm

Vấn đề

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 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

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ổng kết

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é!

Cao cấp
Hello

Bí mật ngăn xếp của Blog

Là một lập trình viên, bạn có tò mò về bí mật công nghệ hay những khoản nợ kỹ thuật về trang blog này? Tất cả bí mật sẽ được bật mí ngay bài viết dưới đây. Còn chờ đợi gì nữa, hãy bấm vào ngay!

Là một lập trình viên, bạn có tò mò về bí mật công nghệ hay những khoản nợ kỹ thuật về trang blog này? Tất cả bí mật sẽ được bật mí ngay bài viết dưới đây. Còn chờ đợi gì nữa, hãy bấm vào ngay!

Xem tất cả

Đăng ký nhận thông báo bài viết mới

hoặc
* Bản tin tổng hợp được gửi mỗi 1-2 tuần, huỷ bất cứ lúc nào.

Bình luận (2)

Nội dung bình luận...
Avatar
Trần Cường2 năm trước
Thực sự mình không để ý đến cái này, mình chỉ commit theo lý do tại sao
Trả lời
Avatar
Linh Trần2 năm trước
Giờ mình mới biết có commit theo
Trả lời
Bấm hoặc cuộn mạnh để sang bài mới