Lời nói đầu

Có lẽ ai trong chúng ta khi trở thành một developer cũng đã làm quen với Git và trong đó commit code là việc không thể thiếu. Khi thực hiện commit có yêu cầu nhập giải thích commit (commit message). Vì commit message là bắt buộc nên nếu để trống mà thực hiện thì commit sẽ thất bại. Vấn đề phát sinh ở đây là khi một cái gì là bắt buộc thì sẽ có cách để lách nó, và từ đây những commit message “gọi là cho có” dần hình thành và phát triển.

Các phong cách thường thấy

Khoan hay nói về chất lượng source code, về coding convention…, thứ đầu tiên mà những reviewers nhìn thấy tất nhiên là những commit message và đó là vấn đề chúng ta sẽ bàn luận trong topic này. Thật lòng mà nói không có định nghĩa hoặc quy chuẩn nào cho việc nên viết commit message như thế nào, bản thân người viết cũng không thể phản biện được chắc chắn là cách viết nào đúng cách viết nào sai tuy nhiên để giúp tracking các vấn đề, dễ tìm kiếm, dễ hiểu là điều có thể.

Phong cách nhất quán

• Thường là sử dụng 1 số các common commit message dạng như: Fix bug, Save, Refactor code, Commit…
• Đa phần là sử dụng những common commit message ở trên cho đa số các trường hợp khi muốn commit code.
• Ưu điểm:
  • Nhanh, ít tốn thời gian
  • Phù hợp trong các tính huống khẩn cấp (Dự án cháy, lụt…)
• Nhược điểm: (Có lẽ ai cũng nhận thấy)
  • Đọc commit message mà không phán đoán được commit đấy sinh ra với mục đích gì.
  • Không nắm được các thay đổi trong code.
  • Không theo 1 quy tắc nào nên việc tìm kiếm nhanh gần như bất khả thi.

Phong cách có tiêu chuẩn chung

Thường thì mỗi dự án đều đặt ra một tiêu chuẩn chung cho các commit message trong dự án của mình, mục đích dễ nhận thấy là:

• Mọi người trong cùng 1 dự án cũng như người mới có thể hình dung được bao quát được nội dung code thay đổi làm công việc chính là gì, tiện cho việc review đánh giá cũng như tìm kiếm.
• Lưu giữ đầy đủ thông tin có thể tìm kiếm và kiểm chứng được các thay đổi.

Ví dụ:

Dòng thứ 1: Tóm tắt nội dung thay đổi trong commit
Dòng thứ 2: Dòng trống
Dòng thứ 3 trở đi: Lý do đã thay đổi

• Một số dự án lại thêm thông tin của Task vào commit message để giúp việc tìm kiếm dễ dàng hơn.

• Ưu điểm:
  • Phần nào đó loại bỏ được các vấn đề của Phong cách nhất quán
• Nhược điểm:
  • Nội dung chỉ con người hiểu được, mỗi khi thực hiện release sẽ cần duyệt lại tất cả các commit để xây dựng CHANGELOG
  • Sẽ có vấn đề nảy sinh khi thực hiện tự động hoá

Conventional Commits

A specification for adding human and machine readable meaning to commit messages Tạm dịch: Những tiêu chuẩn, bộ quy tắc giúp con người cũng như máy có thể hiểu được nội dung của những commit messages Nguồn: https://www.conventionalcommits.org/en/v1.0.0/

Nguồn: angrynerds.co

Conventional Commits là một phần quan trọng để giúp chúng ta tự động hoá phần lớn các bước trong việc phát triển phần mềm, nói một cách chi tiết hơn là việc linh động CHANGELOG

CHANGELOG nói chung là nơi chúng ta sẽ lưu giữ tất cả các thay đổi được thực hiện trong một giao đoạn của ứng dụng hoặc hệ thống, chẳng hạn như sửa lỗi, tính năng mới, v.v.

Thực hiện xây dựng CHANGELOG một cách chỉnh chu và minh bạch sẽ giúp ích rất nhiều trong quá trình phát triển, giúp tiết kiệm thời gian tìm kiếm, ghi nhớ. Đơn giản nhất là khi khách hàng hỏi “Phiên bản mới có gì thay đổi?” hoặc “Tính năng này sẽ có trên phiên bản nào?” thì chúng ta sẽ có cơ sở để trả lời một cách nhanh chóng. Việc CHANGELOG thường sẽ chỉ do người quản lý sản phẩm thực hiện và việc này cần sự chính xác cũng nhưng thời gian để xác nhận các thông tin, sai sót cũng có thể xảy ra. Do đó Conventional Commits được sử dụng để tự động hoá, giải phóng sức lao động.

Một số các ưu điểm

• Cho phép mọi người trong dự án dễ dàng kiểm tra lịch sử dự án thông qua các nội dung commit đồng thời hiểu bản chất của những thay đổi của source code
• Dễ dàng phân loại các commit.
• Giúp mọi người trong dự án có thói quen phân nhỏ các commit theo mục đích hơn là tập trung tất cả và một commit chung.
• Tự động tạo ra file CHANGELOGs.

Cấu trúc chung

Cấu trúc chung của một commit message theo conventional có dạng:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Trong đó

• Các thành phần type, description là bắt buộc cần có trong commit message, optional là tùy chọn, có hoặc không có cũng được.
• type: từ khóa để phân loại các commit là feature, fix bug, refactor…
• scope: cũng được dùng để phân loại commit, nhưng khác với type nó giúp trả lời câu hỏi: commit này refactor|fix cái gì? được đặt trong cặp ngoặc đơn ngay sau type. VD: feat(authentication):, fix(homescreen):…
• description: mô tả một cách ngắn gọn về nôi dung commit.
• body: là mô tả dài và chi tiết hơn, cần thiết khi description chưa thể nói rõ hết được.
• footer: một số thông tin mở rộng như số ID của pull request, issue.. được quy định theo conventional.

Ví dụ

feat: add hat wobble
^--^  ^------------^
|     |
|     +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.

Một số type phổ biến và thường dùng

• feat: Những thay đổi cho tính năng mới.
• fix: Những thay đổi liên quan đến sửa lỗi trong ứng dụng, hệ thống.
• docs: Những thay đổi liên quan đến sửa đổi document trong repo.
• style: Những thay đổi không làm thay đổi ý nghĩa của code như căn hàng, xuồng dòng ở cuối file…
• refactor: Tối ưu source code, có thể liên quan logic…Ví dụ như xoá code thừa, tối giản code, đổi tên biến …
• perf: Thay đổi giúp tăng hiệu năng.
• test: Thêm hoặc sửa các testcase trong hệ thống.
• build: Thay đổi liên quan đến hệ thống hoặc các thư viên bên ngoài (Ảnh hưởng đến tiến trình build)
• ci: Thay đổi liên quan đến cấu hình CI…
• chore: Những sửa đổi nhỏ nhặt không liên quan tới code.
• BREAKING CHANGE: Nhưng commit mới footer là BREAKING CHANGE thể hiện những thay đổi gây ảnh hướng lớn đến source code ví dụ thay đổi kiểu dữ liệu, cách lấy dữ liệu… => Qua đó cảnh báo mọi người để tránh phát sinh các vấn đề.

Ví dụ từ: yargs

Các thông tin chi tiết hơn mọi người có thể đọc trực tiếp từ nguồn Conventional Commits để có thể hiểu rõ hơn.

Làm thế nào để ứng dụng vào dự án?

Đến đây chắc mọi người đã có được một cái nhìn tổng quan về Conventional Commits, vậy chúng ta sẽ sử dụng trong các dự án thực tế như thế nào, nhìn tưởng dễ nhưng cũng cần rèn luyện một thói quen cho mỗi thành viên trong team phát triển. Thú thực ở dự án hiện tại người viết cũng chưa áp dụng Conventional Commits vào nên mỗi khi release phiên bản phải phải ra kha khá effort để tổng hợp và chuẩn bị CHANGELOGS.

Dự án VitaDairy

Hiện tại dự án VitaDairy đơn thuần là đang commit với nội dung ngắn gọn để mô tả nội dung cho những thay đổi trong source code. Về cơ bản thì cũng đủ thông tin, các thành viên trong dự án có thể hiểu được nột dung thay đổi tuy nhiên khi người viết tổng hợp CHANGELOGS cho giai đoạn release thì vấn đề xảy ra, thực sự khó để tổng hợp từ danh sách những thay đổi như trong hình bên dưới.

Thay đổi

• Thử áp dụng Conventional Commits cho các commit mới để chuẩn bị cho phiên bản mới

  

• Để generate CHANGELOGS cho dự án, team sẽ sử dụng 1 plugin của fastlane có tên là semantic_release

  Tham khảo thêm tại: Semantic Release for Fastlane @ Medium - By Jiri Otahal

• Mô tả method của FastFile

  

• Kết quả:

  

• Và CHANGELOGS chúng ta thu được.

  

• Từ đây về cơ bản chúng ta có thể tự động hoá được bước xử lý CHANGELOGS, đưa ra được những output rõ ràng và dễ hiểu hơn.

Các công cụ bổ trợ

Dưới đây là một số công cụ có thể giúp ích mọi người khi làm việc với Conventional Commits

CLI Tool

Commitizen là công cụ giúp mọi người có thể commit code sử dụng command đồng thời tích hợp sẵn Conventional Commits, rất thích hợp với những anh em thường sử dụng command để commit code.

Linter

commitlint là công cụ giúp mọi người cũng như team đảm bảo ràng các commit là đúng chuẩn, tránh những commit sai gây ảnh hưởng đến process của dự án cũng nhưng ảnh hưởng đến team. Đây cũng là một cách để mọi người rèn dần thói quen khi làm việc với Conventional Commits.

VS Code Extension

Nếu bạn thường sử dụng VS Code thì đây là một extention hữu ích

Tổng kết

Theo quan điểm cá nhân, việc áp dụng Conventional Commits không chắc sẽ tốt và hợp lý cho tất cả các dự án, tuy nhiên với những dựng án cần release nhiều cũng nhưng đông người tham gian thì việc áp dụng Conventional Commits sẽ giúp tối ưng khá tốt luồng làm việc, tự động hoá tối đa cũng như góp phần và việc xây dựng DEVOPS trong các dự án. Cảm ơn mọi người và hẹn gặp lại mọi người vào kì tới nhé ^^.

Tham khảo

• Conventional Commits v1.0.0
• Conventional Commits Cheatsheet
  •