Merge conflict không đáng sợ: xử lý bình tĩnh từng bước

Bạn gõ git pull, và terminal trả về một dòng chữ đỏ quen thuộc:CONFLICT (content): Merge conflict in src/app.js

Tim đập nhanh hơn một nhịp. Bạn mở file, thấy những ký hiệu lạ <<<<<<<, =======, >>>>>>> chen ngang vào logic code của mình.

Đừng hoảng. Merge conflict không phải là lỗi, cũng không phải bùa phép gì ghê gớm. Đơn giản là Git đang đứng hình vì không dám tự ý quyết định thay bạn. Hiểu đúng bản chất và quy trình xử lý, việc giải quyết conflict sẽ chỉ tốn của bạn chưa đầy một phút.

1. Bản chất của Merge Conflict là gì?

Git là một công cụ gộp code cực kỳ thông minh. Nếu bạn sửa hàm A còn đồng nghiệp sửa hàm B, Git tự động ghép lại mượt mà.

Conflict chỉ xảy ra khi cùng một vùng code bị hai nhánh thay đổi theo hai cách khác nhau. Lúc này, Git không thể đoán được ý đồ kinh doanh hay logic nào là đúng. Nó dừng lại và nhường quyền quyết định cho bạn — người hiểu code nhất ở thời điểm đó.

2. Giải mã cấu trúc Conflict trong file

Khi mở file bị xung đột, bạn sẽ thấy cấu trúc dạng như sau:

JavaScript

function tinhPhiShip(donHang) {
<<<<<<< HEAD
  return donHang.tongTien > 500000 ? 0 : 30000;
=======
  return donHang.tongTien > 300000 ? 0 : 25000;
>>>>>>> tinh-nang/khuyen-mai
}

• Phần giữa <<<<<<< HEAD và =======: Code ở nhánh hiện tại bạn đang đứng (local branch).

• Phần giữa ======= và >>>>>>> [tên-nhánh]: Code từ nhánh đang được gộp vào (remote hoặc nhánh feature khác).

Nhiệm vụ của bạn: Giữ lại logic đúng, kết hợp hoặc viết lại, và bắt buộc phải xóa sạch 3 dòng ký hiệu <<<<<<<, =======, >>>>>>>.

3. Quy trình 5 bước xử lý chuẩn chỉnh

Bước 1: Khoanh vùng phạm vi

Chạy lệnh kiểm tra xem còn file nào khác dính đạn không:

Bash

git status

Các file bị xung đột sẽ nằm trong mục Unmerged paths. Hãy xử lý tuần tự từng file một, tuyệt đối đừng mở hàng loạt gây rối mắt.

Bước 2: Hiểu rõ ngữ cảnh trước khi quyết định

Đây là bước dễ "bóp dái" nhất. Đừng bao giờ chọn đại Accept Current Change hay Accept Incoming Change nếu chưa đọc kỹ.

• Trong ví dụ trên, một bên nâng ngưỡng miễn ship, một bên hạ ngưỡng và đổi mức phí mới cho chiến dịch marketing.

• Hãy check git log, git blame, hoặc ping thẳng đồng nghiệp qua Slack/Telegram nếu thấy logic không rõ ràng. Một câu hỏi 5 giây rẻ hơn rất nhiều so với một cú deploy lỗi lên Production.

Bước 3: Resolve & Clean

Sửa trực tiếp bằng tay hoặc tận dụng tính năng 3-Way Merge cực mạnh trên VS Code / WebStorm để so sánh trực quan giữa Local, Incoming và Result. Sau khi chốt phiên bản cuối cùng, xóa sạch các dòng phân cách của Git.

Bước 4: Chạy thử (Sanity Check)

Code hết ký hiệu conflict không có nghĩa là code chạy đúng. Hãy chạy lại test suite, build app hoặc test nhanh tính năng vừa sửa. Đừng chủ quan push ngay lập tức.

Bước 5: Hoàn tất quá trình

Đánh dấu file đã được giải quyết và tiếp tục tiến trình:

Bash

git add src/app.js
git commit            # Nếu đang ở giữa quá trình merge
git rebase --continue # Nếu đang ở giữa quá trình rebase

4. Góc nhìn thực chiến: Khi mọi thứ quá rối

Nếu bạn loay hoay sửa một lúc rồi nhận ra mình làm nát bét logic, đừng cố vá víu thêm. Git luôn có nút "Ctrl+Z" cấp độ hệ thống để đưa bạn về vạch xuất phát:

Bash

git merge --abort
git rebase --abort

Nhớ rằng luôn có đường lui giúp tâm lý lập trình viên vững vàng hơn rất nhiều khi xử lý các đợt rebase nhánh lớn.

5. Những "bẫy" thường gặp

• Conflict trong file lock (package-lock.json, pnpm-lock.yaml): Đừng bao giờ ngồi sửa bằng tay file này. Hãy chọn đại một phía (ours hoặc theirs), sau đó chạy lại lệnh cài đặt (ví dụ: pnpm install hoặc npm install) để package manager tự tính toán và cập nhật lại file lock cho khớp với package.json.

• Bẫy ours và theirs khi Rebase: Hãy cực kỳ cẩn thận vì ý nghĩa của từ này bị đảo ngược so với lúc Merge. Trong rebase, ours là nhánh đích bạn đang đè lên, còn theirs mới là commit của chính bạn. Đọc kỹ nội dung thay vì chỉ nhìn tên gọi!

6. Mẹo phòng bệnh hơn chữa bệnh

Bạn không thể triệt tiêu hoàn toàn conflict trong một team đông người, nhưng hoàn toàn có thể giảm thiểu 80% bằng kỷ luật nhóm:

• Rebase thường xuyên: Thường xuyên kéo code từ nhánh main/develop về nhánh tính năng của bạn, đừng để tách nhánh cả tuần mới merge.

• Giữ PR/MR ngắn gọn: PR càng nhỏ, diện tích chồng lấn code càng thấp.

• Đồng bộ công cụ: Cùng dùng một cấu hình Prettier/ESLint trong team để tránh các conflict vô nghĩa chỉ vì khoảng trắng hay dấu phẩy cuối dòng (trailing comma).

• Giao tiếp chủ động: Nếu biết mình sắp sửa một core service lớn mà nhiều người cùng chung tay, hãy hú lên một tiếng trên kênh chat chung của team.

Lời kết: Merge conflict không phải là dấu hiệu bạn viết code kém, mà là minh chứng cho thấy dự án đang sống và có nhiều lập trình viên cùng đóng góp. Giữ cái đầu lạnh, hiểu rõ ý đồ code của đồng nghiệp, và luôn nhớ lệnh --abort là cứu cánh an toàn nhất cho bạn!