Công cụ của chuyên gia và xử lý sự cố

Cho đến giờ, chúng ta đã xem xét kịch bản lý tưởng: bạn viết mã, tạo các commit, tạo Pull Request. Nhưng trong thực tế thường có điều gì đó không như ý: bạn có thể mắc lỗi trong mã, tạo commit với thông điệp sai hoặc đơn giản nhận ra rằng mình đi sai hướng. Trong bài giảng này, chúng ta sẽ tìm hiểu cách giải quyết những vấn đề phổ biến nhất.

1. Rollback — hoàn tác các thay đổi trước khi commit

Kịch bản: bạn đã sửa một tệp, nhưng nhận ra rằng tất cả các chỉnh sửa đều không đúng và muốn nhanh chóng đưa tệp về trạng thái mà nó có sau lần commit cuối cùng.

Hãy dùng chức năng Rollback:

1. Mở thẻ Commit.
2. Tìm trong danh sách tệp đã sửa mà bạn muốn “rollback”.
3. Nhấp chuột phải vào nó và chọn Rollback.

IDE sẽ cảnh báo rằng các thay đổi sẽ bị mất. Hãy xác nhận, và tệp sẽ ngay lập tức quay về phiên bản cuối cùng đã lưu trong Git. Đây là cách đơn giản và an toàn nhất để hủy các thay đổi cục bộ.

2. Reset — xóa các commit cục bộ

Kịch bản: bạn đã tạo một hoặc vài commit, nhưng chưa thực hiện push. Bạn nhận ra các commit này là sai và muốn xóa hoàn toàn chúng, như thể chúng chưa từng tồn tại.

Hãy dùng chức năng Reset:

1. Mở thẻ Git -> Log để xem lịch sử commit.
2. Tìm commit “tốt” cuối cùng mà bạn muốn quay về (commit nằm trước các commit lỗi).
3. Nhấp chuột phải vào nó và chọn Reset Current Branch to Here....

Trong cửa sổ mở ra, bạn sẽ được chọn chế độ reset. Cấp độ khắt khe nhất — Hard.

Cảnh báo! Chế độ Hard sẽ xóa vĩnh viễn mọi commit sau commit đã chọn, cũng như tất cả các thay đổi trong mã có trong những commit đó. Hãy sử dụng nó với sự thận trọng cao và chỉ cho các commit mà chưa ai thấy (những commit chưa được gửi lên GitHub).

3. Làm gì sau khi Push?

Kịch bản: bạn đã thực hiện push, và chỉ sau đó mới nhận ra có lỗi trong đó.

Ngay khi commit lên máy chủ từ xa, nó trở thành một phần của lịch sử chung của dự án. Cố gắng viết lại lịch sử này có thể tạo ra vấn đề rất lớn cho đồng nghiệp của bạn. Hãy tưởng tượng họ đã tải các thay đổi của bạn và bắt đầu làm việc dựa trên chúng.

Giải pháp đúng đắn và an toàn:

Chỉ cần tạo một commit mới để sửa lỗi và gửi nó đi. Đây là thực hành hoàn toàn bình thường. Như vậy, lịch sử vẫn trung thực và dễ hiểu đối với tất cả mọi người.

4. Nhìn về quá khứ: làm việc nâng cao với log

Chúng ta đã quen với thẻ Git -> Log, nhưng đây không chỉ là danh sách commit mà còn là một công cụ điều tra mạnh mẽ.

• Hash của commit (Commit Hash): bạn hẳn đã thấy trong log một chuỗi chữ và số, ví dụ a1b2c3d. Hash này là duy nhất, cho phép tham chiếu chính xác tới bất kỳ điểm nào trong lịch sử dự án. Bạn hiếm khi phải dùng nó thủ công, nhưng điều quan trọng là biết rằng đây chính là định danh duy nhất cho mỗi “snapshot” của mã nguồn bạn.
• Bạn có thể lọc lịch sử theo nhánh, tác giả, ngày tháng hoặc thậm chí theo từ khóa trong thông điệp commit. Điều này giúp nhanh chóng tìm ra ai và khi nào đã làm việc trên một phần chức năng cụ thể.
• Muốn tìm commit nơi một dòng mã cụ thể được thêm vào hoặc bị xóa? Trong cửa sổ Log có ô tìm kiếm, ô này không chỉ tìm theo thông điệp mà còn theo nội dung của chính các thay đổi.
• Nhấp chuột phải vào vùng lề của trình chỉnh sửa mã và chọn Annotate with Git Blame. IDE sẽ hiển thị trước mỗi dòng ai và trong commit nào đã sửa nó lần cuối. Điều này cực kỳ hữu ích để hiểu vì sao mã được viết như vậy.

5. Khu vực nguy hiểm: Force Push

Vậy là chúng ta đã khẳng định rằng việc thay đổi các commit đã gửi đi là một ý tưởng tồi. Nhưng nếu bạn đã thay đổi lịch sử cục bộ của mình (ví dụ bằng Reset) và giờ nó lệch so với lịch sử trên máy chủ thì sao? Khi cố gắng thực hiện push thông thường, Git sẽ báo lỗi để bảo vệ lịch sử chung khỏi bị ghi đè.

Trong những trường hợp như vậy, có một tùy chọn — force push (gửi bắt buộc). Lệnh này nói với máy chủ: “Hãy quên tất cả những gì bạn có. Phiên bản lịch sử cục bộ của tôi là phiên bản đúng duy nhất. Hãy thay lịch sử của bạn bằng lịch sử của tôi.”

CẢNH BÁO! Trong 99% trường hợp, sử dụng force push trong các dự án làm việc nhóm là một thảm họa. Nó có thể xóa vĩnh viễn những commit mà đồng nghiệp của bạn đã tải về và đang làm việc dựa trên chúng. Điều này chẳng khác nào xé các trang khỏi cuốn sách thư viện chung và dán trang của bạn vào.

Khi tuyệt đối KHÔNG được dùng force push:

• Trên bất kỳ nhánh chung nào: main, develop, master. Không bao giờ.
• Trên bất kỳ nhánh nào mà có người khác ngoài bạn đang làm việc.

Kịch bản hợp lệ duy nhất:

Bạn làm việc trên nhánh feature cá nhân của mình mà chưa ai thấy hoặc sử dụng. Bạn đã tạo vài commit “bẩn”, gửi chúng lên máy chủ, rồi quyết định “chải chuốt” lại bằng Reset. Trong trường hợp này, bạn có thể thực hiện force push để cập nhật nhánh của mình trên máy chủ trước khi tạo Pull Request.

Trong IDE, tùy chọn này thường được ẩn phía sau nút Push. Các nhà phát triển IDE đã cố tình làm như vậy để bạn không bấm nhầm.

Nếu bạn không chắc chắn 100% về những gì mình đang làm — đừng bao giờ dùng force push. An toàn hơn là tạo một commit mới với các bản sửa lỗi.

6. Cập nhật dự án

Luôn nhấn Update Project trên nhánh main trước khi bắt đầu làm một nhiệm vụ mới. Điều này sẽ giúp bạn tránh được rất nhiều xung đột merge về sau và đảm bảo bạn bắt đầu làm việc với phiên bản mã mới nhất.

1

Khảo sát/đố vui

, cấp độ , bài học

Không có sẵn

Làm quen với Git và GitHub

Kiểm soát phiên bản: làm việc với Git và GitHub

Mở