Thành thạo Git cho lập trình viên Backend: Từ quản lý mã nguồn đến xử lý xung đột

Trong phát triển phần mềm hiện đại, đặc biệt là ở mảng Backend, Git không chỉ là công cụ lưu trữ lịch sử mã nguồn mà còn là xương sống của quy trình CI/CD và cộng tác nhóm. Một Backend Developer giỏi không chỉ biết các lệnh cơ bản như git add hay git commit, mà còn phải nắm vững cách quản lý lịch sử commit, giải quyết tranh chấp (conflict) trong các hệ thống phân tán lớn và áp dụng chiến lược nhánh hiệu quả.

Chiến lược nhánh (Branching Strategy) cho Backend

Đối với các dự án Backend có tính phức tạp cao và nhiều môi trường triển khai (Development, Staging, Production), việc áp dụng một chiến lược nhánh chuẩn mực là bắt buộc để tránh làm gián đoạn hệ thống.

Git Flow và Trunk-Based Development

Git Flow là mô hình truyền thống sử dụng các nhánh dài hạn như main, develop kết hợp với các nhánh ngắn hạn feature, release và hotfix. Mô hình này phù hợp với các sản phẩm có chu kỳ phát hành (release cycle) định kỳ.

Ngược lại, Trunk-Based Development đang trở thành xu hướng chủ đạo trong các hệ thống microservices và CI/CD hiện đại. Tất cả lập trình viên gộp mã thường xuyên (vài lần một ngày) vào một nhánh chính duy nhất (main), sử dụng Feature Flag để ẩn các tính năng chưa hoàn thiện.

Xử lý xung đột (Merge Conflict) phức tạp trong Backend

Xung đột mã nguồn thường xảy ra khi hai lập trình viên cùng chỉnh sửa một tệp tin (ví dụ: file cấu hình kết nối database application.yml hoặc migration của cơ sở dữ liệu) ở cùng một dòng.

Quy trình xử lý xung đột chuyên nghiệp

1. Xác định chính xác tệp tin bị xung đột bằng lệnh git status.
2. Mở tệp tin và tìm các ký hiệu phân cách <<<<<<<, =======, và >>>>>>>.
3. Thảo luận với đồng nghiệp hoặc kiểm tra lịch sử git log -S để hiểu ngữ cảnh của cả hai đoạn mã.
4. Tiến hành chỉnh sửa thủ công để giữ lại logic chính xác, sau đó chạy lại toàn bộ kiểm thử (unit test, integration test).

Ví dụ cấu hình bị xung đột khi cấu hình kết nối PostgreSQL:

<<<<<<< HEAD
spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/db_v1
=======
spring:
  datasource:
    url: jdbc:postgresql://postgres-master:5432/db_v2
>>>>>>> feature/upgrade-db

Quản lý lịch sử commit với Git Rebase và Interactive Rebase

Một lịch sử commit sạch sẽ giúp việc truy vết lỗi (debugging) bằng git bisect trở nên khả thi và chính xác. Thay vì tạo ra quá nhiều commit rác chứa thông điệp như "fix typo" hay "test", hãy sử dụng git rebase -i để gộp (squash) các commit trước khi tạo Pull Request.

git checkout feature/payment-gateway
git rebase -i main

Trong cửa sổ chỉnh sửa hiện ra, bạn có thể thay đổi từ pick thành squash hoặc fixup đối với các commit phụ nhằm tạo ra một chuỗi lịch sử logic, dễ đọc.

Lỗi thường gặp và cách khắc phục

Dưới đây là các tình huống kỹ sư Backend thường gặp phải trong công việc hàng ngày:

• Commit nhầm vào nhánh main: Sử dụng git reset --soft HEAD^ để hoàn tác commit nhưng vẫn giữ nguyên thay đổi trong workspace, sau đó chuyển sang nhánh mới.
• Cần lưu tạm thay đổi mà không muốn commit: Sử dụng git stash push -m "WIP: refactor auth module" và khôi phục bằng git stash pop.
• Xóa nhầm nhánh chưa gộp: Khôi phục thông qua bộ đệm cục bộ bằng lệnh git reflog để tìm mã hash commit gần nhất, sau đó tạo lại nhánh từ mã hash đó.

Checklist kiểm tra trước khi tạo Pull Request

Trước khi yêu cầu team review mã nguồn cho một tính năng Backend, hãy đảm bảo các tiêu chí sau:

• Đã đồng bộ mã mới nhất từ nhánh đích bằng git pull --rebase.
• Đã xóa bỏ các đoạn mã debug, log thông tin nhạy cảm (JWT secret, DB password).
• Lịch sử commit đã được tinh chỉnh gọn gàng, thông điệp rõ ràng theo chuẩn Conventional Commits.
• Tất cả các bài kiểm tra tự động (CI pipeline) đều chạy thành công.

Câu hỏi thường gặp (FAQ)

Khi nào nên dùng Merge thay vì Rebase?

Nên dùng git merge khi làm việc với các nhánh công khai (như main, develop) để giữ nguyên dấu vết lịch sử cộng tác của nhóm. Nên dùng git rebase cho các nhánh tính năng cá nhân trước khi đưa lên review để tạo lịch sử tuyến tính, sạch sẽ.

Làm sao để cấu hình Git an toàn khi làm việc với nhiều tài khoản GitHub/GitLab?

Sử dụng tính năng IncludeIf trong file cấu hình toàn cục ~/.gitconfig để tự động áp dụng SSH key và email tương ứng dựa trên thư mục dự án (ví dụ: thư mục công việc và thư mục cá nhân).