Giới Thiệu
Trong hơn một thập kỷ qua, tôi đã có cơ hội thử nghiệm với nhiều chiến lược và phong cách sử dụng Git khác nhau. Từ việc đặt tên nhánh cho đến mô tả yêu cầu kéo (pull request), tôi đã dành nhiều thời gian để suy nghĩ về cách tốt nhất để mô tả công việc của chúng tôi nhằm truyền đạt thông tin một cách rõ ràng và ngắn gọn nhất đến người khác. Có nhiều chiến lược và hướng dẫn phong cách để tận dụng tốt hệ sinh thái Git, nhưng không có giải pháp nào hoàn hảo cho mọi tình huống. Bài viết này sẽ phác thảo một số quy tắc và hướng dẫn mà tôi đã áp dụng vào cuộc sống hàng ngày với Git, những điều này đã hoạt động tốt cho đội ngũ của tôi.
Lưu ý: Đây là tài liệu đang phát triển và đã được điều chỉnh qua nhiều năm. Nó có thể không áp dụng cho bạn và tình huống của bạn, nhưng có thể có một số điểm hữu ích giúp cải thiện quy trình làm việc và hạnh phúc của nhà phát triển.
Nhánh (Branches)
99% thời gian, các thay đổi mã nguồn rơi vào một trong số ít loại. Khi tạo một nhánh mới, việc đặt tên một cách rõ ràng và có ý nghĩa có thể giúp các nhà phát triển khác biết ngay loại thay đổi nào đang được giới thiệu. Điều này cũng giúp đơn giản hóa việc tìm kiếm một nhánh bằng cách hoàn thành tab trên máy tính của bạn khi chuyển đổi giữa các nhánh.
Các Loại Nhánh
Các loại nhánh sau đây thích hợp cho hầu hết các trường hợp sử dụng. Chúng có thể được tinh chỉnh hoặc thay đổi tùy thuộc vào trường hợp cụ thể của bạn.
- feature - một tính năng mới
- fix - sửa lỗi, hotfix, lỗi chính tả, v.v.
- style - thay đổi về giao diện / trải nghiệm người dùng
- test - thêm hoặc tái cấu trúc các bài kiểm tra; không thay đổi mã sản xuất
- housekeeping - mọi thứ từ tái cấu trúc mã đến cập nhật tài liệu
- devops - cập nhật các tệp cấu hình, phiên bản phần mềm, v.v.
Định Dạng Nhánh
Định dạng nhánh được đề xuất sẽ giúp dễ dàng nhận biết loại công việc đã được thực hiện trong nhánh với một cái tên dễ đọc và rõ ràng. Độ dài tối đa của tên nhánh là 255 ký tự nhưng tôi cố gắng giữ độ dài không quá 50 ký tự để dễ đọc hơn.
type-name_of_branchLoại được phân tách khỏi tên nhánh bằng một dấu -, trong khi phần còn lại của tên được thực hiện theo định dạng snake case (các từ được phân tách bằng _).
Ngoài ra, nếu bạn đang sử dụng một ứng dụng theo dõi tác vụ / vấn đề như JIRA hoặc GitHub Projects, việc bao gồm số vấn đề / vé trong tên nhánh cũng sẽ tạo thêm tính khả thi và giúp tên nhánh dễ đọc hơn, ví dụ:
type/ticket#-name_of_branchVí dụ về tên nhánh:
feature-add_user_authentication
fix-about_page_infinite_redirect
// hoặc
feature/21-add_user_authentication
fix/42-about_page_infinite_redirectCam Kết (Commits)
Phát triển một định dạng có cấu trúc cho các thông điệp cam kết sẽ làm rõ mục đích của mỗi cam kết, dẫn đến một lịch sử git sạch hơn. Ngay lập tức, người ta có thể biết nếu một cam kết nhằm thêm một tính năng, sửa một lỗi hay chỉ để cải thiện chất lượng mã. Chúng ta nên cố gắng giữ công việc trong một nhánh nhỏ và có thể kiểm tra được, thường dẫn đến chỉ có một cam kết duy nhất cho mỗi nhánh, tuy nhiên, tốt hơn là có nhiều cam kết nhỏ trong một nhánh hơn là gộp tất cả các cam kết lại vào một trước khi hợp nhất. Điều này sẽ giúp dễ dàng hơn trong việc bisect các lỗi được giới thiệu.
Mẫu Thông Điệp Cam Kết:
Đây là một mẫu thông điệp cam kết mà tôi đã sử dụng trong một thời gian. Khi tôi cố gắng giữ cho các cam kết của mình cụ thể và riêng biệt, tôi định nghĩa dòng đầu tiên và để mọi thứ khác được chú thích. Tuy nhiên, nếu bạn đang đẩy một cam kết liên quan đến nhiều thay đổi, có thể tham chiếu đến một vấn đề hoặc mục tác vụ cụ thể, hoặc bao gồm các thay đổi có thể ảnh hưởng đến phát triển trong tương lai, thì nên làm rõ thông điệp cam kết với nhiều thông tin nhất có thể để giúp bạn (hoặc các thành viên trong đội) có một bức tranh rõ ràng về công việc đã được thực hiện chỉ bằng cách nhìn vào cam kết của bạn.
Chủ đề cam kết, như đã thấy dưới đây, có quy ước bắt đầu bằng loại công việc đang được cam kết (bug, feature, housekeeping, v.v.) tất cả đều ở dạng chữ thường, theo sau là một dấu chấm phẩy, một khoảng trắng và thông điệp cam kết, bắt đầu với chữ cái viết hoa, theo dạng mệnh lệnh, không có dấu chấm ở cuối.
type: [Ticket#](Tùy chọn) Tóm tắt thay đổi
# **--- Các Thay Đổi Đề Xuất ---**
#
#
# Vấn đề / Nhiệm vụ: [tên](url)
# --- KẾT THÚC CAM KẾT --- (thông tin chỉ, không cần bỏ chú thích)
# <type>: <subject> (Khoảng 50 ký tự)
# |<---- Sử Dụng Tối Đa 50 Ký Tự ---->|
# Giải thích lý do vì sao thay đổi này được thực hiện
# |<---- Cố Gắng Giới Hạn Mỗi Dòng Tối Đa 72 Ký Tự ---->|
# --------------------
# Loại có thể là
# feature (tính năng mới)
# fix (sửa lỗi)
# style (thay đổi giao diện / trải nghiệm người dùng)
# test (thêm hoặc tái cấu trúc các bài kiểm tra; không thay đổi mã sản xuất)
# housekeeping (tái cấu trúc mã hoặc thêm tài liệu)
# devops (thay đổi nền tảng / kiến trúc)
# --------------------
# Nhớ rằng
# - Sử dụng thái độ mệnh lệnh trong dòng chủ đề
# - Không kết thúc dòng chủ đề bằng dấu chấm
# - Tách chủ đề khỏi nội dung bằng một dòng trống
# - Sử dụng nội dung để giải thích cái gì và tại sao chứ không phải là cách
# --------------------Tất cả các dòng bắt đầu bằng # đều được chú thích và sẽ không hiển thị khi xem thông điệp cam kết, vì vậy nếu bạn định thêm thông tin trong tương lai vào thông điệp cam kết của mình, hãy chắc chắn bỏ chú thích các dòng cần thiết.
Bạn có thể thiết lập mẫu thông điệp cam kết mặc định của git với
git config --global commit.template ~/.gitmessageVí dụ về thông điệp cam kết:
feature: Thêm xác thực người dùng
fix: Vấn đề chuyển hướng vô hạn ở trang Giới thiệu
// hoặc
feature: [21] Thêm xác thực người dùng
fix: [42] Vấn đề chuyển hướng vô hạn ở trang Giới thiệuRất thường khi bắt đầu một phần công việc, tôi có thể không biết ngay lập tức thông điệp cam kết sẽ là gì vì nó thường phát triển khi công việc hoàn thành. Trong trường hợp này, tôi thường bắt đầu cam kết của mình bằng cách
wip: Không chắc vấn đề là gìvà sau đó, khi đã hoàn thành công việc và chuẩn bị nhánh cho việc xem xét, tôi sẽ đổi tên các thông điệp cam kết một cách phù hợp trong quá trình tái cấu trúc tương tác (git rebase -i).
Nhận Xét Kết Thúc
Đây không phải là tiêu chuẩn quy tắc git hoàn toàn mà bạn nên áp dụng và đó là điều đang liên tục phát triển và thay đổi khi tôi làm việc trên các dự án mới và khác nhau. Kinh nghiệm của mỗi người là khác nhau và phải được xử lý tương ứng, nhưng có thể có một số điểm hữu ích ở đây giúp bạn hướng dẫn quy trình git có cấu trúc và ngắn gọn hơn.
Để phát triển thêm các quy tắc, tôi cũng đã tạo ra các quy trình, quy trình làm việc và mẫu tiêu chuẩn khi nói đến các yêu cầu kéo (PR) của GitHub và các vấn đề ảnh hưởng đến việc đánh giá mã, kiểm tra QA và triển khai, nhưng đó là một câu chuyện cho một bài viết khác.
Tài Nguyên Thêm
1.) Nhiều cảm hứng cho các quy tắc này đã được lấy từ "Conventional Commits".
https://www.conventionalcommits.org/en/v1.0.0/#why-use-conventional-commits
https://marcodenisi.dev/en/blog/why-you-should-use-conventional-commits/
2.) Một bài viết kinh điển về cách tốt nhất để viết các thông điệp cam kết. Tôi đã thu thập nhiều lời khuyên về thông điệp cam kết trong bài viết này để bổ sung cho biến thể của tôi.
https://cbea.ms/git-commit/#imperative
3.) Một công cụ kiểm tra cam kết mà bạn có thể tích hợp vào quy trình làm việc của mình để thực thi một tiêu chuẩn về thông điệp cam kết. Có thể được cấu hình trong một hook GIT trước cam kết.
