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!
Đú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ụ:
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.
Đâ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ư:
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ụ:
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.
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.
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.
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é!
Xin chào, tôi tên là Hoài - một anh Dev kể chuyện bằng cách viết ✍️ và làm sản phẩm 🚀. Với nhiều năm kinh nghiệm lập trình, tôi đã đóng góp một phần công sức cho nhiều sản phẩm mang lại giá trị cho người dùng tại nơi đang làm việc, cũng như cho chính bản thân. Sở thích của tôi là đọc, viết, nghiên cứu... Tôi tạo ra trang Blog này với sứ mệnh mang đến những bài viết chất lượng cho độc giả của 2coffee.dev.Hãy theo dõi tôi qua các kênh LinkedIn, Facebook, Instagram, Telegram.
Bình luận (2)