Thành thạo Git cho Lập trình viên Fullstack: Từ Thao tác Hằng ngày đến Xử lý Xung đột Phức tạp

Git là một công cụ không thể thiếu đối với bất kỳ lập trình viên Fullstack nào. Không chỉ dừng lại ở việc gõ vài lệnh cơ bản như git add hay git commit, một lập trình viên Fullstack chuyên nghiệp cần phải nắm vững cách quản lý nhánh, xử lý các tình huống xung đột phức tạp giữa frontend và backend, cũng như duy trì một lịch sử dự án sạch sẽ.

1. Mô hình nhánh và Quy trình làm việc hiệu quả

Trong các dự án Fullstack, mã nguồn thường được chia thành nhiều phần như giao diện người dùng, dịch vụ API, cơ sở dữ liệu và các cấu hình triển khai. Việc sử dụng mô hình nhánh chuẩn giúp đội ngũ phát triển tránh được việc giẫm chân lên nhau.

Git Flow và GitHub Flow

Tùy thuộc vào quy mô dự án, bạn có thể áp dụng Git Flow hoặc GitHub Flow. Với GitHub Flow, mọi tính năng mới đều được phát triển trên một nhánh riêng biệt tách ra từ nhánh main (hoặc master). Sau khi hoàn thành và vượt qua các bài kiểm tra tự động, nhánh đó sẽ được trộn ngược lại vào main thông qua Pull Request.

git checkout -b feature/user-profile-api
git add .
git commit -m "feat(api): add user profile endpoint"
git push origin feature/user-profile-api

2. Xử lý Xung đột (Conflict) trong Môi trường Fullstack

Xung đột thường xảy ra khi lập trình viên frontend và backend cùng chỉnh sửa một file cấu hình chung (ví dụ: file Docker, file cấu hình môi trường hoặc file định nghĩa API chung). Khi Git không thể tự động trộn các thay đổi, nó sẽ yêu cầu bạn can thiệp thủ công.

Các bước xử lý conflict chuẩn

1. Cập nhật nhánh hiện tại với mã nguồn mới nhất từ remote: git pull origin main
2. Xác định các file bị xung đột bằng lệnh: git status
3. Mở các file đó trong trình soạn thảo mã nguồn và tìm các ký hiệu <<<<<<<, =======, và >>>>>>>.
4. Chỉnh sửa lại nội dung để giữ lại logic chính xác của cả hai phía.
5. Đánh dấu đã giải quyết: git add <ten-file>
6. Hoàn tất quá trình trộn: git commit

3. Best Practice khi sử dụng Git

Để duy trì một dự án bền vững và dễ bảo trì, bạn nên tuân thủ các nguyên tắc sau:

• Commit nhỏ gọn và có ý nghĩa: Mỗi commit chỉ nên giải quyết một vấn đề duy nhất. Sử dụng quy ước đặt tên commit (Conventional Commits) như feat, fix, refactor, docs.
• Kiểm tra trước khi đẩy code: Luôn chạy các bài kiểm tra (tests) và kiểm tra định dạng mã nguồn (linter) trước khi tạo Pull Request.
• Tránh dùng ép buộc trên nhánh chung: Không sử dụng git push -f trên các nhánh chính như main hoặc staging để tránh làm mất mã nguồn của đồng đội.

4. Các lỗi thường gặp và Cách khắc phục

Quên đưa file vào commit trước đó

Nếu bạn vừa commit nhưng phát hiện ra mình quên sửa một lỗi nhỏ, bạn không cần phải tạo một commit mới mà có thể cập nhật trực tiếp vào commit cũ:

git add .                        
git commit --amend --no-edit

Muốn hủy bỏ các thay đổi chưa commit

Khi bạn thử nghiệm một đoạn code và muốn đưa file về trạng thái ban đầu của lần commit gần nhất:

git restore <ten-file>

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

Khi nào nên dùng Merge, khi nào nên dùng Rebase?

Sử dụng git merge khi bạn muốn giữ lại lịch sử phát triển chính xác của từng nhánh, phù hợp với các nhánh công cộng. Sử dụng git rebase để làm phẳng lịch sử commit trên nhánh cá nhân trước khi tạo Pull Request, giúp người review dễ dàng theo dõi từng bước thay đổi của bạn.

Làm thế nào để khôi phục một commit đã bị xóa nhầm?

Bạn có thể sử dụng lệnh git reflog để xem lại toàn bộ lịch sử các thao tác trên kho lưu trữ cục bộ, sau đó tìm mã hash của trạng thái trước khi xóa và dùng git reset --hard <ma-hash> để khôi phục.