Login

Giải quyết merge conflict bình tĩnh và đúng cách

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Lần đầu thấy dòng chữ "CONFLICT (content): Merge conflict in..." nhiều người nghĩ mình đã làm hỏng cả dự án. Thực ra xung đột là chuyện hết sức bình thường khi nhiều người cùng sửa một đoạn code. Bài này giúp bạn hiểu nguyên nhân và xử lý từng bước một cách bình tĩnh.

Vì sao xảy ra xung đột?

Git tự động gộp được phần lớn thay đổi. Xung đột chỉ xuất hiện khi hai nhánh cùng sửa cùng một vùng dòng trong cùng một file, hoặc một bên sửa file trong khi bên kia xóa nó. Khi đó Git không đoán được phiên bản nào đúng và nhờ bạn quyết định.

Nhận diện dấu hiệu xung đột trong file

Sau khi chạy git merge và gặp xung đột, mở file bị báo lỗi, bạn sẽ thấy:

<<<<<<< HEADconst greeting = "Xin chào";=======const greeting = "Chào bạn";>>>>>>> feature/new-greeting
  • Phần giữa <<<<<<< HEAD và ======= là phiên bản ở nhánh hiện tại của bạn.
  • Phần giữa ======= và >>>>>>> là phiên bản từ nhánh đang được gộp vào.

Quy trình giải quyết từng bước

  1. Chạy git status để xem danh sách file đang có xung đột (mục "both modified").
  2. Mở từng file và quyết định giữ phiên bản nào: của bạn, của đối phương, hoặc kết hợp cả hai.
  3. Xóa các dòng đánh dấu <<<<<<<, =======, >>>>>>>. Kết quả cuối cùng phải là code hợp lệ.
  4. Chạy dự án và test để chắc code vẫn hoạt động.
  5. Đánh dấu đã giải quyết: git add ten-file.
  6. Hoàn tất: git commit (với merge) hoặc git rebase --continue (với rebase).

Nếu thấy rối và muốn bắt đầu lại, bạn có thể hủy quá trình bằng git merge --abort hoặc git rebase --abort. Mọi thứ trở về trạng thái trước khi gộp.

Công cụ hỗ trợ

Bạn không cần sửa bằng mắt trên văn bản thô. Các editor hiện đại như VS Code hiển thị nút "Accept Current Change", "Accept Incoming Change", "Accept Both Changes" ngay trên vùng xung đột, và có giao diện so sánh ba cột (merge editor). Ngoài ra bạn có thể dùng git mergetool để mở công cụ so sánh đã cấu hình.

Đừng chọn bừa: hiểu ý định của hai bên

Lỗi nguy hiểm nhất là nhấn "Accept" mà không đọc. Hãy tự hỏi:

  • Mỗi bên đang cố đạt điều gì? Đọc commit message hoặc hỏi người đã viết.
  • Hai thay đổi có bổ sung cho nhau hay mâu thuẫn nhau?
  • Sau khi gộp, logic còn nhất quán không (ví dụ một bên đổi tên hàm, bên kia gọi hàm cũ)?

Với các xung đột phức tạp, hãy nhắn đồng đội ngồi cùng giải quyết thay vì đoán. Năm phút trao đổi tốt hơn nhiều so với hai giờ sửa lỗi do gộp sai.

Cách giảm xung đột về lâu dài

  • Cập nhật thường xuyên: kéo thay đổi từ nhánh chính về nhánh của bạn mỗi ngày, xung đột nhỏ dễ xử lý hơn xung đột dồn lại.
  • Nhánh sống ngắn, commit nhỏ: ít dòng thay đổi thì ít khả năng đụng nhau.
  • Chia việc rõ ràng: tránh hai người cùng sửa một file lớn trong cùng thời điểm.
  • Dùng formatter chung: khác biệt về thụt lề và dấu ngoặc làm tăng xung đột vô ích.
  • Tránh đổi tên hoặc di chuyển file hàng loạt cùng lúc với người khác đang sửa nội dung.

Xung đột trong các file đặc biệt

Với file khóa phụ thuộc như package-lock.json hay composer.lock, đừng sửa tay. Cách thường dùng là giữ phiên bản của nhánh chính, rồi chạy lại lệnh cài đặt (npm install, composer install) để tạo lại file nhất quán. Với file sinh tự động khác, hãy chạy lại công cụ sinh thay vì chỉnh bằng tay.

Kết luận

Xung đột không phải lỗi của bạn mà là cơ chế bảo vệ để không ai vô tình ghi đè công sức của người khác. Hãy nhớ quy trình: xem trạng thái, đọc hiểu hai phiên bản, chọn hoặc kết hợp, test lại, add và commit. Thực hành vài lần trên repo thử, bạn sẽ không còn sợ nữa.

Để học làm việc nhóm với Git trong các dự án cụ thể, bạn có thể tìm khóa học phù hợp trên codebem.com.

author_photo
Nguyễn Đình Cường

0 comment