Một bài viết được gắn thẻ "workflow"

Workflow​

Lịch sử git thiếu nhất quán​

Hầu hết developer chúng ta đều biết đến git - nếu chưa biết thì phải tìm hiểu và sử dụng ngay - một công cụ quá tuyệt vời để quản lý source code. Và giống như việc đặt tên biến trong code, commit messages cũng là một thứ gì đó thực sự gây đau đầu.

Trong một team, có anh em sẽ chỉ đặt một message ngắn ngủn cho xong, một số cẩn thận sẽ viết rõ những thay đổi trong đó và chèn thêm cả JIRA ticket number. Như thế sẽ tạo ra sự thiếu nhất quán trong lịch sử commit vốn đã rất phức tạp. Điều này khiến mình nghĩ đến việc chuẩn hóa commit trong project hiện tại.

Lựa chọn công cụ​

Để có một commit có đầy đủ ý nghĩa với: loại commit (feature, fix bug, refactor...), JIRA ticket number, description. Sau thời gian ngâm cứu trên mạng thì mình đã tìm ra Commitizen và quyết định sử dụng nó để áp chuẩn cho việc commit.

Commitizen là công cụ dạng command line (dòng lệnh) hỗ trợ tự động format commit messages bằng cách hỏi bạn một vài câu hỏi, bạn nhập câu trả lời và commitizen sẽ tạo commit theo chuẩn dựa trên các thông tin được nhập. Bạn có thể cài đặt commitizen global với:

npm install commitizen -g

Không thích cài global thì có thể cài vào dev dependencies của package.json cũng ok:

npm install commitizen --save-dev

Giờ thì thay vì commit bằng lệnh:

git commit

Ta dùng:

git cz

Cấu hình commitizen​

Để bắt đầu làm việc với commitizen, chúng ta cần cài đặt thêm một vài cấu hình có sẵn trong package.json gọi là adapter. Những adapter này sẽ định nghĩa những câu hỏi khi commit. Bạn có thể chọn một adapter từ đây.

Trong bài viết này mình chọn cz-conventional-changelog để bắt đầu, bạn cũng nên cài nó vào dev dependencies.

npm install cz-conventional-changelog --save-dev

Tiếp tục cấu hình adapter với lệnh sau:

commitizen init cz-conventional-changelog --save-dev

cz-conventional-changelog sẽ ép commit message theo chuẩn như sau:

type(scope): JIRA-Ticket - Short description

Sau khi gõ lệnh "git cz", dòng lệnh sẽ đưa ra những câu hỏi về: type, scope, short description, long description, breaking changes - vui lòng đọc kỹ các câu hỏi trước khi chọn hoặc trả lời, việc này khá dễ dàng và sẽ rất nhanh quen thôi.

Cấu hình validate commit message​

Adapter cz-conventional-changelog không yêu cầu nhập JIRA ticket number nên chúng ta cần kiểm tra dòng đầu của commit message để chắc chắn nó có chưa JIRA ticket number. Ta có thể làm điều này với Husky và validate-commit-message. Để bắt đầu thì cũng cài 2 tool này dạng dev dependencies:

npm install husky --save-dev
npm install validate-commit-msg --save-dev

Husky là một tool cho phép ta có thể chạy kèm lệnh bất kỳ với git hooks, còn validate-commit-message thì sử dụng regex kiểm tra string. Để cấu hình 2 tool này thì chúng ta cần thêm thủ công đoạn config sau vào bên dưới "config" trong package.json:

"validate-commit-msg": {
  "types": [
    "feat",
    "fix",
    "docs",
    "style",
    "refactor",
    "perf",
    "test",
    "chore",
    "revert"
  ],
  "warnOnFail": false,
  "maxSubjectLength": 72,
  "subjectPattern": "^[A-Z]+-[0-9]+ - .*",
  "subjectPatternErrorMsg": "Subject must be in format 'CMS-123 - Commit message'",
  "helpMessage": ""
}

Commit theo chuẩn không chỉ cho đẹp​

Ngoài cải thiện tính dễ dễ hiểu của commit messages. Việc commit theo chuẩn chung như trên còn có rất nhiều lợi ích khác:

• Quan trọng nhất phải kể đến đó là có thể đánh version phần mềm dựa trên commit (theo https://semver.org/)
• Trigger thay đổi trên các tool dự án (JIRA)
• CICD support
• ...

Tận hưởng kết quả​

Done rồi, commitizen đã sẵn sàng để bảo vệ sự trong sáng và nhất quán trong lịch sử git của bạn. Bài viết dựa trên kinh nghiệm cá nhân và có sự tham khảo + dịch lại từ: https://dev.bleacherreport.com/how-we-use-commitizen-to-clean-up-commit-messages-a16790dcd2fd.

Bạn có bao giờ tự hỏi​

1. Git còn gì ngoài git commit, git push và git pull? Thỉnh thoảng dùng thêm git merge, còn gì nữa không?
2. git merge và git rebase khác gì nhau, nên dùng cái nào?
3. Ở vị trí team leader bạn sẽ vận hành git ra sao để kết hợp với process của team (agile) và giải quyết các conflict trong quá trình code?
4. Lịch sử git có giá trị như thế nào? Hay bạn chẳng bao giờ để ý đến nó?

Nếu bạn là 1 git command line master thì mọi thứ đều có thể được giải quyết dưới local bằng dòng lệnh. Nhưng khi làm việc trong một nhóm đông thành viên, làm thế nào để xử lý các vấn đề conflict code, release ra sao, thêm feature mới như thế nào, hotfix ra làm sao một cách trơn tru và hiệu quả, giảm thiểu tối đa các bước thủ công, tiến dần đến một git workflow tự động hoàn toàn (devops).

Luôn luôn tạo ra linear history​

Git Workflow được giới thiệu sau đây luôn giữ một tư duy cực kỳ nhất quán về git history luôn luôn là linear history (có thể hiểu là history trên một đường thẳng). Nhìn trong hình đủ thấy linear history dễ hiểu hơn rất nhiều so với non-linear history, đủ dễ để nhìn vào graph là có thể thấy được thứ tự của các commit và sự khác nhau giữa các version được release.

Tham khảo​

1. http://www.bitsnbites.eu/a-tidy-linear-git-history/

git merge và git rebase đúng lúc đúng chỗ​

Nguyên tắc tiên quyết​

1. Để update code mới nhất, không merge trên local, hãy dùng rebase
2. merge tự động bằng merge (pull) request (cần cấu hình để khi merge sẽ sinh ra một empty commit nhằm đánh dấu vị trí merge)

Một ví dụ thực tế về linear history​