Git rerere: Ghi nhớ cách giải quyết conflict khi merge và rebase

Một nhánh tính năng tồn tại lâu có thể gặp lại cùng đoạn conflict mỗi lần tích hợp thay đổi. Git rerere ghi nhớ cách bạn từng giải quyết xung đột và thử áp dụng lại khi gặp tình huống tương ứng. Giá trị của nó là giảm thao tác lặp, trong khi việc kiểm tra logic vẫn thuộc về người phát triển.

1. Bật theo repository và giữ bước review

Trong repository muốn sử dụng, chạy:

git config --local rerere.enabled true
git config --local rerere.autoupdate false
git config --show-origin --get rerere.enabled
git config --show-origin --get rerere.autoupdate

Phạm vi local giúp thử nghiệm trên một dự án. Đặt autoupdate thành false để phần giải quyết được áp dụng vào working tree nhưng không tự stage. Kiểm tra nguồn cấu hình cũng giúp phát hiện giá trị kế thừa từ thiết lập global của máy.

2. Ví dụ: hai nhánh cùng đổi timeout

Giả sử file settings.txt ban đầu chứa timeout=10. Nhánh main đổi thành 20, nhánh topic đổi thành 30. Khi merge topic vào main, cùng một dòng bị thay đổi nên Git có thể tạo conflict như sau:

<<<<<<< HEAD
timeout=20
=======
timeout=30
>>>>>>> topic

Trong bài tập, quyết định nghiệp vụ là 25. Đây là một lựa chọn giả định để minh họa; không có quy tắc lấy trung bình hai giá trị khi xử lý conflict thật. Mở file bằng editor, thay toàn bộ đoạn conflict bằng timeout=25, rồi lưu lại.

git rerere diff
git diff -- settings.txt
git diff --check
git rerere
git add -- settings.txt
git diff --cached -- settings.txt
git commit -m "Resolve timeout conflict"

Lệnh rerere sau khi sửa giúp ghi nhận kết quả; Git cũng tích hợp việc gọi rerere trong luồng merge/commit. Chạy test liên quan trước khi commit. Bài tập chỉ có một file; dự án thật cần xử lý hết các path xung đột.

3. Khi gặp lại conflict tương ứng

Để thử mà không viết lại lịch sử, tạo một nhánh thử trỏ vào commit main trước lần merge đầu tiên, rồi merge cùng topic vào nhánh đó trong cùng repository. Rerere có thể điền lại timeout=25. Điều này đã được kiểm tra trong repository thử nghiệm riêng khi biên soạn bài.

Với autoupdate=false, file có thể không còn dấu conflict nhưng status vẫn báo UU settings.txt. Working tree và index là hai trạng thái khác nhau: Git đã điền nội dung gợi ý, còn bạn chưa đánh dấu path được giải quyết.

git status --short
git rerere remaining
git diff -- settings.txt
git diff --check
# Chạy test và đọc nội dung file trước khi stage
git add -- settings.txt
git diff --cached -- settings.txt

Chỉ sau khi review mới hoàn thành merge bằng commit. Nếu đang rebase, dùng git rebase --continue theo trạng thái Git hướng dẫn. Không thay quy trình rebase bằng một merge commit tùy ý.

4. Ba lệnh kiểm tra phục vụ ba câu hỏi

Kết hợp chúng với git status và diff thông thường. Không có danh sách remaining không đồng nghĩa toàn bộ thay đổi đã được stage, test hoặc đúng nghiệp vụ.

5. Kết quả cũ không còn phù hợp thì làm gì?

Nếu yêu cầu mới cần timeout bằng 40, hãy sửa nội dung thành kết quả đúng rồi kiểm tra lại. Để bỏ bản ghi rerere gắn với conflict hiện tại của file, dùng lệnh có phạm vi cụ thể:

git rerere forget -- settings.txt

Lệnh này dành cho conflict hiện tại, không phải thao tác hoàn tác commit. Nếu xuất hiện no remembered resolution, dừng quy trình ghi lại cache: chưa có bằng chứng bản ghi mong muốn đã được quên. Kiểm tra trạng thái conflict và phiên bản Git trong bản sao thử nghiệm; không xóa cả cache để xử lý một file. Để hoàn thành lần tích hợp hiện tại, vẫn có thể sửa file thủ công, chạy test rồi stage kết quả đúng. Chỉ thử ghi lại resolution khi đã xác định được trạng thái rerere phù hợp. Đọc lại file sau mỗi bước; forget không tự khôi phục nội dung theo ý muốn.

Nếu muốn dừng phiên tích hợp, xem git status rồi chọn đúng git merge --abort hoặc git rebase --abort. Lưu riêng phần chỉnh sửa muốn giữ trước đó. Tốt nhất bắt đầu merge với working tree sạch, vì abort không phải cơ chế sao lưu công việc đang dang dở.

6. Review phần tự áp dụng như code mới

Một resolution khớp về văn bản vẫn có thể sai về ý nghĩa. Ví dụ cả hai nhánh cùng thay timeout nhưng một nhánh đã đổi đơn vị từ giây sang mili giây; ghép dòng thành công không chứng minh ứng dụng hoạt động đúng.

• Đọc context xung quanh, kể cả thay đổi ở file gọi hàm hoặc cấu hình khác.
• Chạy test cho hành vi từng bị conflict, không chỉ lint.
• Đọc diff đã stage để biết chính xác nội dung sẽ commit.
• Ghi lý do lựa chọn nếu quyết định ảnh hưởng API, dữ liệu hoặc cấu hình vận hành.

git diff --check hữu ích để phát hiện vấn đề whitespace và dấu conflict được đưa vào diff. Nó không thay thế compiler, test hoặc code review. Một số conflict như submodule cũng cần xử lý theo bản chất riêng.

7. Áp dụng trong nhóm

Thử trước trên một repository và đo số lần phải giải quyết lại cùng đoạn code. Nếu xung đột chủ yếu đến từ file sinh tự động, hãy xem lại cách sinh file và chiến lược tích hợp. Rerere giúp thao tác nhanh hơn, nhưng không sửa nguyên nhân tổ chức code khiến nhánh liên tục va chạm.

Đừng coi cache resolution trên máy cá nhân là kiến thức duy nhất của nhóm. Đặt lý do nghiệp vụ trong commit hoặc review, để người khác hiểu quyết định kể cả khi họ không có bản ghi rerere. Điểm dừng phù hợp là: nội dung đã được kiểm tra, test đạt, index đúng và phiên merge/rebase đã hoàn tất.

Tài liệu tham khảo

git rerere, git config, git merge, git diff và git add.