Quy tắc đơn giản nhất để làm việc an toàn với tác tử AI là: không bao giờ để nó sửa trực tiếp trên nhánh chính. Mỗi việc một nhánh git riêng, tạo từ trạng thái sạch, ghi nhận (commit) từng bước nhỏ, rồi bạn quyết gộp hay bỏ cả nhánh. Làm vậy thì tệ nhất bạn chỉ mất một nhánh, không mất một buổi gỡ rối.
Bài này đi từng bước với các lệnh git chuẩn, chạy được trên git từ bản 2.23 trở lên (bản có lệnh git switch và git restore). Nếu máy bạn dùng bản cũ hơn, lệnh git checkout làm được việc tương đương. Phần chạy nhiều tác tử cùng lúc bằng nhiều thư mục làm việc có bài riêng trong danh mục này.
Vì sao nhánh riêng quan trọng hơn khi người sửa là tác tử
Khi bạn tự sửa mã, mỗi thay đổi đi qua đầu bạn trước khi vào tệp. Tác tử thì có thể sửa hai mươi tệp trong vài phút, chạy lệnh định dạng lại cả thư mục, xoá tệp mà nó cho là thừa. Không phải vì nó phá, mà vì nó tối ưu cho việc hoàn thành yêu cầu. Nếu tất cả xảy ra trên nhánh chính, thay đổi của nó trộn lẫn với việc dở dang của bạn, và việc tách ra trở nên rất khó.
Nhánh riêng cho bạn ba thứ. Thứ nhất là ranh giới: mọi thay đổi của phiên tác tử nằm gọn một chỗ, so được với nhánh chính bằng một lệnh. Thứ hai là quyền phủ quyết rẻ: không ưng thì xoá nhánh, nhánh chính không hề bị đụng. Thứ ba là lịch sử: nếu tác tử ghi nhận từng bước nhỏ, bạn đọc được nó đã đi những bước nào, bước nào đi lạc, và có thể giữ năm bước đầu bỏ hai bước sau.
Điều kiện tiên quyết là thư mục làm việc phải sạch trước khi tạo nhánh. Nếu bạn đang có thay đổi chưa ghi nhận, hoặc ghi nhận chúng, hoặc cất tạm bằng git stash. Đừng giao việc cho tác tử khi thư mục còn thay đổi dở của bạn, vì đến cuối phiên bạn sẽ không phân biệt được dòng nào của ai.
Tạo nhánh và giao việc: các lệnh theo thứ tự
Ví dụ giả định: nhánh chính tên main, việc cần làm là sửa lỗi tính phí vận chuyển.
- Kiểm trạng thái: git status. Kết quả phải báo không có gì cần ghi nhận. Nếu có, xử lý trước.
- Cập nhật nhánh chính: git switch main rồi git pull, để nhánh mới bắt đầu từ bản mới nhất của nhóm.
- Tạo nhánh cho việc: git switch -c ai/sua-phi-van-chuyen. Tiền tố "ai/" giúp cả nhóm nhìn danh sách nhánh là biết nhánh nào do tác tử làm.
- Ghi trong phiếu giao việc: làm trên nhánh hiện tại, không tạo nhánh khác, không chuyển nhánh, không đẩy lên kho từ xa.
- Yêu cầu tác tử ghi nhận sau mỗi bước có kiểm thử qua, mỗi lần ghi nhận một ý, lời mô tả nói rõ đã đổi gì.
- Khi phiên kết thúc, xem lịch sử nhánh: git log --oneline main..HEAD liệt kê đúng những lần ghi nhận có trên nhánh này mà nhánh chính chưa có.
Chuyện có cho tác tử tự chạy lệnh git hay không tuỳ cài đặt quyền của công cụ. Cách an toàn lúc mới dùng là cho phép các lệnh chỉ đọc và lệnh ghi nhận cục bộ, còn lệnh đẩy lên kho từ xa, lệnh xoá nhánh, lệnh viết lại lịch sử thì để bạn tự gõ.
Commit nhỏ: vì sao và nhỏ đến mức nào
Mỗi lần ghi nhận nên hoàn tác được một mình. Nếu bước ba sai mà bước bốn, năm không phụ thuộc vào nó, bạn hoàn tác riêng bước ba bằng git revert và giữ phần còn lại. Ghi nhận to gộp cả năm bước thì chỉ có thể giữ hết hoặc bỏ hết.
Tách việc định dạng khỏi việc sửa logic. Tác tử hay tiện tay chạy trình định dạng lên cả tệp. Nếu phần đổi khoảng trắng và phần đổi logic nằm chung một lần ghi nhận, diff dài hàng trăm dòng và chỗ đổi thật bị chôn vùi. Yêu cầu ghi nhận định dạng riêng, hoặc cấm định dạng ngoài những dòng đã sửa.
Lời mô tả viết cho người đọc sáu tháng sau. Không phải "sửa lỗi" mà là "tính phí vận chuyển theo cân nặng làm tròn lên thay vì làm tròn xuống". Tác tử viết lời mô tả khá tốt nếu được yêu cầu nói rõ lý do, không chỉ liệt kê tệp.
Ghi nhận cả khi kiểm thử đang đỏ có chủ đích. Trong cách làm viết kiểm thử trước, bước đầu là một kiểm thử thất bại. Ghi nhận nó riêng với lời mô tả nói rõ là cố ý, để người đọc lịch sử không tưởng nhánh bị hỏng giữa chừng.
Đánh dấu phần do tác tử viết nếu nhóm có quy ước. Một số nhóm thêm dòng chú thích ở cuối lời mô tả để ghi công cụ đã tham gia. Đây là quy ước của nhóm, không phải yêu cầu của git; điều quan trọng là thống nhất và làm đều.
Điểm lưu và đường lui khi tác tử đi lạc giữa phiên
Nhánh riêng cộng với ghi nhận nhỏ cho bạn nhiều đường lui. Bảng dưới gom các tình huống hay gặp và lệnh phù hợp. Lệnh có chữ "hard" xoá thay đổi chưa ghi nhận, nên luôn chạy git status trước để biết mình sắp bỏ gì.
| Tình huống | Lệnh gợi ý | Ghi chú |
|---|---|---|
| Tác tử đang sửa dở, muốn bỏ thay đổi trong một tệp | git restore [tệp] | Trả tệp về lần ghi nhận gần nhất; thay đổi chưa ghi nhận trong tệp đó mất hẳn |
| Muốn đặt điểm lưu trước một bước rủi ro | git tag diem-luu-1 | Nhãn cục bộ, quay lại bằng tên thay vì nhớ mã băm |
| Hai lần ghi nhận cuối đi sai hướng, nhánh chưa chia sẻ cho ai | git reset --hard HEAD~2 | Chỉ dùng trên nhánh riêng chưa đẩy lên kho từ xa |
| Một lần ghi nhận ở giữa sai, phần sau vẫn đúng | git revert [mã băm] | Tạo lần ghi nhận mới đảo ngược, không viết lại lịch sử |
| Bỏ cả phiên làm việc của tác tử | git switch main rồi git branch -D ai/sua-phi-van-chuyen | Nhánh chính không bị ảnh hưởng gì |
Nhãn điểm lưu là thói quen ít người dùng mà rất đáng. Trước khi cho tác tử làm phần khó, như đổi cấu trúc một mô-đun, bạn gắn một nhãn. Sau đó dù nó ghi nhận bao nhiêu lần, lệnh git diff diem-luu-1 vẫn cho bạn thấy toàn bộ những gì đã đổi từ mốc đó.
So nhánh của tác tử với nhánh chính trước khi gộp
Khi tác tử báo xong, đừng vội gộp. Bắt đầu bằng cái nhìn tổng: git diff --stat main...HEAD (ba dấu chấm) cho biết những tệp nào đổi trên nhánh này kể từ chỗ nó tách khỏi nhánh chính, mỗi tệp thêm bớt bao nhiêu dòng. Ba dấu chấm quan trọng: nó so với điểm rẽ nhánh, nên những thay đổi đồng nghiệp đã gộp vào nhánh chính trong lúc đó không lẫn vào kết quả.
Nhìn danh sách, bạn đánh giá được ngay vài điều. Có tệp nào nằm ngoài phạm vi phiếu việc không. Có tệp nào bị xoá không. Tệp kiểm thử có bị sửa nhiều hơn tệp mã không, vì đó có thể là dấu hiệu tác tử đổi kỳ vọng cho khớp với mã. Tệp khoá phiên bản thư viện có đổi không, vì nghĩa là có thư viện được thêm hoặc nâng.
Sau đó mới đọc chi tiết từng tệp, bắt đầu từ tệp quan trọng nhất chứ không theo thứ tự chữ cái. Nếu nhánh dài và nhóm muốn lịch sử gọn, bạn có thể gộp kiểu nén nhiều lần ghi nhận thành một khi đưa vào nhánh chính, tính năng có sẵn trên hầu hết nền tảng lưu kho. Khi đó các lần ghi nhận nhỏ vẫn còn trên nhánh để tra cứu nếu nhóm giữ nhánh lại.
Những sai lầm hay gặp khi cho tác tử dùng git
Các lỗi dưới đây đều xảy ra trong thực tế với nhóm mới dùng tác tử, và đều tránh được bằng một dòng trong tệp hướng dẫn dự án hoặc cài đặt quyền.
- Để tác tử tự đẩy lên kho từ xa ngay trong phiên: mất cơ hội xem lại trước khi người khác thấy, và lỡ có khoá bí mật trong mã thì khoá đã rời máy bạn.
- Cho phép lệnh viết lại lịch sử trên nhánh đã chia sẻ: đồng nghiệp đã kéo nhánh về sẽ gặp xung đột khó hiểu.
- Không kiểm tệp mới tác tử tạo ra: lệnh git status mới liệt kê tệp chưa theo dõi, còn git diff thì không. Tệp nháp, tệp nhật ký, tệp chứa dữ liệu thử có thể lọt vào lần ghi nhận nếu tác tử dùng lệnh thêm tất cả.
- Quên tệp bỏ qua: nếu thư mục môi trường, tệp biến môi trường, thư mục bộ nhớ đệm chưa có trong tệp bỏ qua của git, tác tử có thể ghi nhận cả chúng.
- Để nhánh của tác tử sống hàng tuần: nhánh chính đi xa, xung đột chồng chất, và bản sửa tác tử làm dựa trên mã đã cũ. Nhánh của tác tử nên sống tính bằng giờ hoặc vài ngày.
Một biện pháp rẻ là yêu cầu tác tử thêm tệp bằng tên cụ thể thay vì thêm tất cả, và xem lại danh sách tệp chưa theo dõi trước mỗi lần ghi nhận. Nếu kho có công cụ quét khoá bí mật chạy trước khi ghi nhận, càng tốt.
Dọn dẹp sau khi gộp hoặc bỏ nhánh
Nhóm dùng tác tử đều đặn sẽ thấy danh sách nhánh phình rất nhanh: mỗi ngày vài nhánh ai/, nhánh gộp rồi, nhánh bỏ dở, nhánh thử nghiệm. Sau vài tuần, không ai còn nhớ nhánh nào đang chờ duyệt, nhánh nào đã chết. Dọn dẹp định kỳ tốn vài phút mà giữ cho kho dễ đọc.
Lệnh git branch --merged main liệt kê các nhánh cục bộ đã nằm trọn trong nhánh chính, xoá an toàn bằng git branch -d (chữ d thường, git từ chối nếu nhánh chưa gộp). Với nhánh bỏ dở, trước khi xoá bằng chữ D hoa, đọc lại lời mô tả các lần ghi nhận xem có bước nào đáng giữ không; nếu có, nhặt riêng lần ghi nhận đó sang nhánh khác bằng git cherry-pick kèm mã băm.
Một thói quen nhỏ khác: trước khi xoá nhánh của một phiên đi lạc, chép phần tóm tắt cuối phiên của tác tử vào ghi chú của thẻ công việc, kèm một câu vì sao bỏ. Lần sau có người giao lại việc tương tự, họ biết hướng đó đã thử và vì sao không thành. Nhánh thì xoá được, bài học thì nên giữ lại.
Câu hỏi thường gặp
Có cần tạo nhánh riêng khi chỉ nhờ tác tử sửa một dòng?
Không bắt buộc, nhưng chi phí tạo nhánh gần bằng không còn lợi ích thì lớn: tác tử hay sửa nhiều hơn bạn nghĩ. Nhiều nhóm đặt luật đơn giản là mọi phiên tác tử đều mở nhánh, để khỏi phải cân nhắc từng lần.
Nên đặt tên nhánh cho tác tử thế nào?
Dùng một tiền tố chung như ai/ rồi đến mô tả ngắn không dấu, ví dụ ai/sua-phi-van-chuyen. Nếu nhóm gắn mã thẻ công việc vào tên nhánh thì giữ quy ước đó, chỉ thêm tiền tố để phân biệt nhánh do người làm và do tác tử làm.
Tác tử đã lỡ sửa trên nhánh chính chưa ghi nhận thì xử lý sao?
Tạo nhánh mới ngay tại chỗ bằng git switch -c kèm tên nhánh; thay đổi chưa ghi nhận sẽ đi theo sang nhánh mới, nhánh chính vẫn sạch. Sau đó ghi nhận trên nhánh mới và xem lại như bình thường.
Gộp kiểu nén hay gộp giữ nguyên lịch sử thì tốt hơn?
Tuỳ quy ước nhóm. Nén giúp nhánh chính gọn, mỗi việc một dòng lịch sử. Giữ nguyên giúp tra từng bước tác tử đã đi. Điều quan trọng là cả nhóm dùng một cách thống nhất và lời mô tả khi gộp nói rõ việc đã làm.
Có nên cho tác tử tự giải quyết xung đột khi gộp?
Được, nhưng xem kỹ. Tác tử giải xung đột khá nhanh ở chỗ thay đổi rõ ràng, nhưng với chỗ cả hai bên đều sửa logic, nó có thể chọn bỏ thay đổi của đồng nghiệp. Sau khi giải, chạy lại toàn bộ kiểm thử và đọc riêng các khối từng bị xung đột.
Nhãn điểm lưu có bị đẩy lên kho từ xa không?
Mặc định lệnh đẩy không mang theo nhãn, trừ khi bạn chỉ định. Vì vậy nhãn điểm lưu thường chỉ nằm trên máy bạn. Xong việc có thể xoá bằng git tag -d kèm tên nhãn để danh sách nhãn khỏi rối.