Khi tác tử AI làm hỏng mã, việc đầu tiên là dừng phiên và khoanh thiệt hại: hỏng ở thư mục làm việc, trên nhánh riêng, đã gộp vào nhánh chính, hay đã lên môi trường thật. Mỗi mức có cách hoàn tác khác nhau, và git giữ lại nhiều hơn bạn nghĩ: phần lớn những gì đã ghi nhận đều cứu được, kể cả sau lệnh đặt lại mạnh tay.
Bài này đi từ mức nhẹ đến mức nặng, kèm lệnh git cụ thể, rồi tới phần quan trọng không kém: họp rút kinh nghiệm thế nào để sự cố biến thành một dòng trong quy ước nhóm thay vì một người bị trách. Phần thiết lập nhánh riêng và điểm lưu để phòng trước có bài riêng trong danh mục này.
Năm phút đầu: dừng và khoanh thiệt hại
Đừng bắt đầu bằng việc yêu cầu tác tử "sửa lại cho đúng". Một tác tử vừa làm hỏng thường tiếp tục đi theo hướng đã sai. Trình tự an toàn:
- Dừng phiên tác tử. Nếu nó đang chạy lệnh, ngắt lệnh.
- Chạy git status và git log --oneline -10 để biết đang ở nhánh nào, có thay đổi chưa ghi nhận không, những lần ghi nhận gần nhất là gì.
- Trước khi làm gì khác, tạo một nhánh đánh dấu trạng thái hiện tại: git branch hien-truong. Nhánh này giữ nguyên mọi thứ đã ghi nhận để xem lại sau, dù bạn hoàn tác thế nào.
- Nếu còn thay đổi chưa ghi nhận mà bạn muốn xem lại, cất chúng: git stash push -u -m "phien tac tu loi". Tuỳ chọn -u đưa cả tệp mới chưa theo dõi vào.
- Xác định thay đổi đã rời máy chưa: đã đẩy lên kho từ xa, đã gộp, đã triển khai. Câu trả lời quyết định bạn được dùng cách hoàn tác nào.
Nhánh hien-truong là thói quen rẻ nhất mà nhiều người bỏ. Khi đang hoảng, người ta hay chạy liên tiếp vài lệnh đặt lại và mất dấu trạng thái lỗi, sau đó không còn gì để rút kinh nghiệm. Một lệnh tạo nhánh mất ba giây và giữ lại toàn bộ hiện trường.
Chọn cách hoàn tác theo mức thiệt hại
Nguyên tắc chung: chưa chia sẻ cho ai thì được viết lại lịch sử; đã chia sẻ thì chỉ thêm lần ghi nhận đảo ngược, không viết lại.
| Mức thiệt hại | Cách hoàn tác | Lưu ý |
|---|---|---|
| Chỉ thay đổi chưa ghi nhận trong thư mục | git restore kèm tên tệp, hoặc cất bằng stash rồi bỏ | Tệp mới chưa theo dõi phải xoá riêng, xem trước bằng git clean -n |
| Đã ghi nhận trên nhánh riêng, chưa đẩy | git reset --hard về lần ghi nhận tốt cuối cùng | Đã có nhánh hien-truong giữ lại bản lỗi |
| Đã đẩy nhánh riêng, chưa ai khác dùng | Đặt lại như trên rồi đẩy kèm tuỳ chọn ghi đè an toàn | Báo nhóm nếu có ai có thể đã kéo nhánh về |
| Đã gộp vào nhánh chính | git revert -m 1 kèm mã băm lần gộp | Tạo lần ghi nhận đảo ngược, đi qua yêu cầu gộp như bình thường |
| Đã lên môi trường thật | Theo quy trình hoàn tác triển khai của nhóm trước, sửa mã sau | Ưu tiên đưa hệ thống về trạng thái chạy được, rồi mới tìm nguyên nhân |
Tuỳ chọn ghi đè an toàn khi đẩy là --force-with-lease: nó chỉ ghi đè nếu nhánh trên kho từ xa vẫn đúng như lần cuối bạn thấy, nên không vô tình xoá việc người khác vừa đẩy lên. Với nhánh chính, không bao giờ ghi đè; luôn dùng lần ghi nhận đảo ngược.
Cứu lại thứ tưởng đã mất bằng reflog
Tình huống hay gặp: bạn hoặc tác tử chạy lệnh đặt lại mạnh tay, hoặc xoá nhánh, rồi nhận ra trong đó có vài lần ghi nhận đáng giữ. Git ghi lại mọi lần con trỏ HEAD di chuyển trong nhật ký tham chiếu, xem bằng git reflog. Mỗi dòng là một trạng thái HEAD từng ở, kèm mã băm và hành động: chuyển nhánh, ghi nhận, đặt lại.
Tìm dòng ngay trước lệnh đặt lại, lấy mã băm, rồi tạo nhánh từ đó: git branch cuu-lai kèm mã băm. Toàn bộ lần ghi nhận tưởng đã mất nằm nguyên trên nhánh mới. Nhật ký tham chiếu là cục bộ, chỉ có trên máy đã chạy lệnh, và các mục cũ được dọn sau một thời gian theo cấu hình mặc định, nên cứu càng sớm càng chắc.
Giới hạn cần biết: reflog chỉ cứu được những gì đã từng được ghi nhận. Thay đổi chưa bao giờ ghi nhận mà bị lệnh đặt lại mạnh tay hay lệnh khôi phục tệp ghi đè thì git không giữ. Nếu thay đổi đã từng được đưa vào vùng chuẩn bị ghi nhận, vẫn còn cơ may tìm lại nội dung tệp bằng git fsck --lost-found, nhưng không còn tên tệp, phải tự nhận diện. Đây là lý do mạnh nhất để yêu cầu tác tử ghi nhận thường xuyên trên nhánh riêng: mỗi lần ghi nhận là một điểm git cứu được.
Khi tác tử xoá tệp git không theo dõi
Đây là tình huống khó nhất vì git không giúp được gì: tệp cấu hình cục bộ, tệp biến môi trường, thư mục dữ liệu thử, ghi chú cá nhân để trong thư mục dự án mà không ghi nhận. Lệnh xoá trên dòng lệnh thường không đưa tệp vào thùng rác của hệ điều hành, nên tệp không nằm chờ ở đó như khi bạn xoá bằng trình quản lý tệp.
Có vài chỗ còn cơ may tìm lại. Nhiều trình soạn thảo giữ lịch sử cục bộ của tệp từng mở, tách khỏi git; kiểm tính năng lịch sử cục bộ hoặc dòng thời gian của tệp trong trình soạn thảo bạn dùng. Phần mềm sao lưu của máy, nếu có, có thể có bản gần đây. Với tệp biến môi trường, đồng nghiệp hoặc nơi lưu bí mật của nhóm thường có bản gốc. Nếu không còn đâu, bạn dựng lại từ đầu, và nếu tệp chứa khoá, đây là lúc tạo khoá mới thay vì đi tìm khoá cũ.
Cách phòng tốt hơn mọi cách cứu: giữ trong kho một bản mẫu của mọi tệp cấu hình cục bộ, với giá trị giả, để dựng lại trong vài phút; để dữ liệu thử có thể sinh lại bằng một lệnh; và đặt lệnh xoá vào nhóm lệnh tác tử phải hỏi trước. Ba việc này làm một lần, dùng mãi.
Những kiểu hỏng hay gặp ở tác tử và dấu hiệu sớm
Xoá tệp nó cho là thừa. Thường là tệp cấu hình cục bộ, tệp dữ liệu mẫu, hoặc mã chỉ được gọi qua cấu hình mà tác tử không lần ra. Dấu hiệu: diff có tệp bị xoá mà phiếu việc không nhắc. Nếu tệp đó không được git theo dõi, mất là mất hẳn.
Sửa lan sang vùng không liên quan. Tác tử sửa một lỗi, thấy cảnh báo ở tệp bên cạnh, sửa luôn, rồi sửa tiếp kiểm thử cho khớp. Dấu hiệu: số tệp thay đổi tăng vọt giữa phiên.
Chạy lệnh tác động ra ngoài. Chạy tệp chuyển đổi dữ liệu trên cơ sở dữ liệu dùng chung, gọi dịch vụ thật trong lúc thử. Loại này git không hoàn tác được; phải phòng bằng quyền và điểm dừng.
Đổi môi trường. Cài, gỡ hoặc nâng gói ở cấp hệ thống hay môi trường chung, làm dự án khác trên cùng máy hỏng theo. Dấu hiệu: nhật ký phiên có lệnh cài đặt không nằm trong phiếu.
Viết lại lịch sử. Gộp nhiều lần ghi nhận, đặt lại gốc nhánh, đẩy kèm ghi đè. Trên nhánh riêng thì phiền, trên nhánh chung thì nghiêm trọng. Chặn bằng cài đặt quyền và bảo vệ nhánh.
Họp rút kinh nghiệm không đổ lỗi
Sau khi hệ thống ổn định, dành ba mươi phút rút kinh nghiệm, kể cả với sự cố nhỏ. Mục tiêu không phải tìm ai sai, mà tìm vì sao quy trình để lỗi đi xa đến vậy. "Tác tử làm hỏng" không phải nguyên nhân gốc, cũng như "lập trình viên bất cẩn" chưa bao giờ là nguyên nhân gốc. Câu hỏi đúng là: vì sao tác tử có quyền làm việc đó, vì sao không ai thấy trước khi gộp, vì sao kiểm thử không bắt được.
Cách làm đơn giản: viết dòng thời gian sự việc từ nhánh hien-truong, nhật ký phiên và lịch sử triển khai; xác định những điểm lẽ ra có thể chặn được; mỗi điểm chọn một hành động cụ thể có người nhận và hạn. Hành động tốt thường là thay đổi cấu hình hoặc kiểm tra tự động, không phải lời nhắc "lần sau cẩn thận hơn".
Ví dụ giả định: tác tử xoá một tệp cấu hình không được git theo dõi khi dọn thư mục, máy chủ thử nghiệm không khởi động được nửa ngày. Hành động rút ra: thêm tệp cấu hình mẫu vào kho, đưa lệnh xoá vào danh sách lệnh cần hỏi trong cài đặt quyền, thêm vào tệp hướng dẫn dự án rằng không xoá tệp ngoài phạm vi phiếu. Không ai bị trách, và lỗi này khó lặp lại.
Phòng trước: danh sách kiểm sau mỗi sự cố
Mỗi sự cố là dịp rà lại hàng rào. Danh sách dưới đây nên đi qua sau mỗi lần tác tử gây hỏng, dù nhỏ:
- Tác tử có đang làm trên nhánh riêng, trong thư mục sạch không, hay ai đó đã cho chạy thẳng trên nhánh chính.
- Cài đặt quyền có chặn lệnh xoá, lệnh đẩy, lệnh viết lại lịch sử, lệnh cài đặt gói không.
- Nhánh chính có được bảo vệ, bắt buộc rà và kiểm tra tự động trước khi gộp không.
- Tệp cấu hình cục bộ quan trọng có bản mẫu trong kho để dựng lại nhanh không.
- Khoá truy cập trong môi trường của tác tử có phải khoá của môi trường thử, quyền hẹp, không phải khoá thật.
- Quy trình hoàn tác triển khai của nhóm có được thử gần đây không, hay chỉ tồn tại trên giấy.
Mục cuối hay bị quên nhất. Nhiều nhóm có quy trình hoàn tác nhưng chưa từng chạy thử, và chỉ phát hiện nó không chạy đúng vào ngày cần nó nhất. Thử hoàn tác một bản triển khai trên môi trường thử nghiệm mỗi quý một lần là đủ để quy trình còn sống.
Câu hỏi thường gặp
Có nên nhờ chính tác tử đã làm hỏng sửa lại không?
Chỉ sau khi bạn đã hiểu nó hỏng ở đâu và đã đưa mã về trạng thái tốt. Khi đó mở phiên mới, giao phiếu việc mới nêu rõ cách làm trước đã sai thế nào. Để tác tử tự sửa tiếp trong cùng phiên lỗi thường dẫn tới chuỗi sửa vòng vòng.
Lệnh revert và lệnh reset khác nhau thế nào?
Reset dời nhánh về một lần ghi nhận cũ, các lần ghi nhận sau biến khỏi nhánh, tức là viết lại lịch sử. Revert tạo lần ghi nhận mới mang thay đổi ngược lại, lịch sử giữ nguyên. Trên nhánh đã chia sẻ, luôn dùng revert.
Thay đổi trong cơ sở dữ liệu do tác tử chạy có hoàn tác bằng git được không?
Không. Git chỉ quản mã. Dữ liệu phải khôi phục từ bản sao lưu hoặc bằng tệp chuyển đổi đảo ngược nếu có. Vì vậy tác tử không nên có quyền chạy lệnh ghi lên cơ sở dữ liệu dùng chung.
Reflog giữ lại bao lâu?
Theo cấu hình mặc định của git, mục còn liên quan tới nhánh được giữ khoảng ba tháng, mục không còn liên quan khoảng một tháng, nhưng có thể khác tuỳ cấu hình máy. Đừng trông vào đó lâu dài; cứu ngay khi phát hiện.
Có cần báo cả nhóm khi tác tử làm hỏng nhánh riêng của mình?
Không bắt buộc nếu hỏng chưa rời máy bạn. Nhưng nếu bài học có ích, như một lệnh nguy hiểm cần thêm vào danh sách chặn, nên chia sẻ trong buổi nhìn lại. Sự cố nhỏ được chia sẻ giúp tránh sự cố lớn.
Họp rút kinh nghiệm có cần biên bản không?
Nên có một ghi chép ngắn: dòng thời gian, nguyên nhân, hành động, người nhận, hạn. Lưu chung chỗ với quy ước nhóm. Lần sau gặp sự cố tương tự, đọc lại ghi chép cũ giúp xử lý nhanh hơn nhiều.