Commit — khái niệm, quy tắc định dạng và làm việc với Git

Commit trong Git là gì

Commit trong Git là một đối tượng lưu trữ trạng thái của các tệp dự án tại một thời điểm cụ thể. Mỗi commit chứa một ảnh chụp nhanh của tất cả các tệp được theo dõi, một tham chiếu đến commit cha và siêu dữ liệu. Không giống như các hệ thống quản lý phiên bản khác, Git sử dụng bộ nhớ định địa chỉ nội dung — mỗi đối tượng được xác định bằng hash SHA-1 của nội dung của nó.

Khi một nhà phát triển commit các thay đổi, Git tạo ra một đối tượng commit lưu trữ: đối tượng tree (cấu trúc tệp), hash của commit cha, tác giả, người commit, ngày tháng và thông điệp. Đối tượng này là bất biến — sau khi được tạo, một commit không thể được sửa đổi mà không thay đổi hash của nó. Tính bất biến này đảm bảo tính toàn vẹn của lịch sử dự án.

# Tổ chức thay đổi và commit
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# Xem chi tiết commit
git log --oneline -3
git show HEAD

# Tổ chức tất cả thay đổi và commit trong một bước
git commit -a -m "Update dependencies to latest versions"

Các commit tạo thành một đồ thị có hướng không chu trình (DAG), trong đó mỗi commit mới tham chiếu đến commit trước đó. Điều này cho phép điều hướng qua lịch sử, hoàn tác các thay đổi và phân tích sự tiến hóa của cơ sở mã. Hiểu cấu trúc của DAG Git là nền tảng để làm việc nâng cao với commit.

Cách commit thay đổi đúng cách

Quy trình commit trong Git bao gồm hai giai đoạn: thêm thay đổi vào khu vực tổ chức (index) và tạo commit. Khu vực tổ chức cho phép nhà phát triển chọn những thay đổi cụ thể sẽ được đưa vào commit, ngay cả khi nhiều tệp đã được sửa đổi trong thư mục làm việc.

Quy tắc nguyên tử là nguyên tắc chính của một commit tốt. Mỗi commit nên chứa một thay đổi logic. Nếu một nhà phát triển sửa lỗi và tái cấu trúc mã — đây nên là hai commit riêng biệt. Các commit nguyên tử giúp đơn giản hóa việc đánh giá mã, hoàn tác thay đổi và phân tích lịch sử.

Trước khi commit, cần kiểm tra: liệu trong mã có còn đầu ra gỡ lỗi, các khối bị chú thích hoặc các thay đổi ngẫu nhiên hay không. Để làm điều này, sử dụng lệnh git diff --cached, hiển thị chính xác những gì sẽ được đưa vào commit. Kiểm tra bổ sung với git status hiển thị danh sách các tệp trong khu vực tổ chức.

• Kiểm tra thay đổi — git diff --cached hiển thị nội dung sẽ vào commit
• Kiểm tra chất lượng — mã phải vượt qua linter và bài kiểm tra trước khi commit
• Viết thông điệp — mô tả rõ ràng mục đích của thay đổi
• Kiểm tra tệp đã tổ chức — git status xác nhận danh sách tệp

Quy tắc viết thông điệp commit

Thông điệp commit là tài liệu về thay đổi dành cho các nhà phát triển tương lai. Một thông điệp tốt trả lời các câu hỏi: điều gì đã được thay đổi và tại sao. Quy ước Conventional Commits (nhóm Angular, 2016) đã trở thành tiêu chuẩn cho nhiều dự án và định nghĩa định dạng: loại(phạm vi): mô tả.

Một thông điệp commit tốt bao gồm tiêu đề (tối đa 50 ký tự) và phần thân (tùy chọn, tối đa 72 ký tự mỗi dòng). Tiêu đề được viết ở dạng mệnh lệnh: “Add” không phải “Added” hay “Adds”. Capitalization và dấu chấm ở cuối tiêu đề không được sử dụng — đây là quy ước quốc tế của Git.

Thông điệp tồi: “fix things” hoặc “update” — không mang thông tin. Trong một tháng, nhà phát triển sẽ không thể hiểu điều gì đã được thay đổi và tại sao. Thông điệp tốt: “fix(payment): handle timeout in stripe callback” — ngay lập tức rõ ràng điều gì và ở đâu đã được sửa.

Những lỗi thường gặp khi commit

Các nhà phát triển, đặc biệt là người mới bắt đầu, thường mắc những lỗi điển hình khi commit. Phổ biến nhất là commit quá lớn, chứa hàng chục thay đổi hỗn hợp. Commit như vậy không thể hoàn tác một phần và việc đánh giá mã trở nên khó khăn.

Lỗi phổ biến thứ hai là thông điệp commit kém. Các thông điệp như “fix”, “update”, “changes” hoặc “wip” không cung cấp ngữ cảnh cho các nhà phát triển tương lai. Sau sáu tháng, sẽ không ai nhớ điều gì đã được sửa. Quy tắc rất đơn giản: hãy tưởng tượng một năm sau bạn đang xem lịch sử và cố gắng tìm một thay đổi cụ thể.

Lỗi thứ ba là commit mã chưa được biên dịch hoặc không hoạt động. Sau một commit, mã ít nhất phải biên dịch được. Không làm hỏng bản dựng là yêu cầu cơ bản cho bất kỳ commit nào vào nhánh chung. Để làm điều này, bản dựng và các bài kiểm tra được chạy trước khi commit.

Lỗi thứ tư là commit dữ liệu bí mật. Khóa API, mật khẩu và mã token không được xuất hiện trong lịch sử Git. Nếu bí mật đã được commit, không chỉ cần xóa nó trong một commit mới mà còn phải xóa khỏi toàn bộ lịch sử qua git filter-branch hoặc BFG Repo-Cleaner.

Kỹ thuật nâng cao khi làm việc với commit

Git cung cấp các công cụ để quản lý lịch sử commit. Một trong những công cụ hữu ích nhất là git commit --amend, cho phép bổ sung commit cuối cùng với các thay đổi mới hoặc sửa thông điệp. Điều này thuận tiện nếu nhà phát triển quên bao gồm một tệp hoặc gõ sai trong thông điệp.

# Sửa thông điệp commit cuối cùng
git commit --amend -m "fix(auth): correct token validation logic"

# Thêm tệp bị quên vào commit cuối cùng
git add missed-file.txt
git commit --amend --no-edit

# Rebase tương tác cho 3 commit cuối
git rebase -i HEAD~3

Rebase tương tác là một công cụ mạnh mẽ để viết lại lịch sử. Nó cho phép kết hợp các commit (squash), thay đổi thông điệp (reword), sắp xếp lại (reorder) và xóa commit (drop). Tuy nhiên, rebase thay đổi lịch sử, vì vậy nó chỉ được sử dụng trên các commit cục bộ chưa được đẩy lên kho lưu trữ từ xa.

Có hai cách tiếp cận để hoàn tác commit. git revert tạo một commit mới hoàn tác các thay đổi của commit trước — phương pháp an toàn bảo toàn lịch sử. git reset xóa commit khỏi lịch sử — nguy hiểm nếu commit đã được đẩy. Trong phát triển nhóm, chỉ sử dụng git revert để hoàn tác các commit đã xuất bản.