CodeReady
Quay lại kiến thức

Ban biên tập CodeReady

Git chuyên sâu cho Frontend Developer: Quy trình làm việc và xử lý sự cố thực tế

Hướng dẫn toàn diện về Git dành cho lập trình viên Frontend, tập trung vào chiến lược nhánh, giải quyết xung đột, tối ưu lịch sử commit và các tình huống thực chiến tại dự án doanh nghiệp.

Trong phát triển phần mềm hiện đại, Git không đơn thuần là công cụ lưu trữ mã nguồn mà là xương sống của quy trình CI/CD và cộng tác nhóm. Đối với lập trình viên Frontend, việc nắm vững Git giúp quản lý các tính năng giao diện phức tạp, xử lý hiệu quả việc đồng bộ tài nguyên tĩnh và phối hợp nhịp nhàng với đội ngũ Backend, Tester cũng như Product Owner. Bài viết này đúc kết các kỹ thuật Git nâng cao và best practice dành riêng cho kỹ sư Frontend.

1. Chiến lược nhánh Git (Git Branching Strategy) trong dự án Frontend

Các dự án Frontend thường có tốc độ phát triển nhanh, nhiều tính năng chạy song song và yêu cầu phát hành bản vá (hotfix) liên tục. Việc lựa chọn chiến lược nhánh phù hợp giúp giảm thiểu tối đa xung đột mã nguồn.

Git Flow vs. GitHub Flow

Trong khi Git Flow phù hợp với các sản phẩm có chu kỳ phát hành rõ ràng thông qua các nhánh develop, release và master/main, thì GitHub Flow lại được ưa chuộng hơn trong các đội ngũ Agile/Scrum phát triển sản phẩm SaaS nhờ sự tinh gọn. Với GitHub Flow, nhánh main luôn ở trạng thái sẵn sàng deploy, mọi tính năng mới đều được phát triển trên nhánh riêng (feature branch) và đưa vào main thông qua Pull Request.

Quy tắc đặt tên nhánh (Branch Naming Convention)

Sự thống nhất trong cách đặt tên nhánh giúp hệ thống tự động hóa (CI/CD) nhận diện môi trường và tác vụ dễ dàng hơn:

  • feature/FE-123-user-profile
  • bugfix/FE-456-fix-modal-z-index
  • hotfix/FE-789-patch-login-crash

2. Kỹ thuật quản lý lịch sử commit sạch

Lịch sử commit lộn xộn với các thông điệp như "fix bug", "update CSS", "tôi buồn ngủ quá" sẽ gây khó khăn lớn khi cần tra cứu nguyên nhân lỗi (git blame) hoặc khi cần rollback.

Interactive Rebase (git rebase -i)

Trước khi tạo Pull Request, bạn nên gom (squash) các commit nhỏ lẻ thành một commit hoàn chỉnh mang tính logic cao. Ví dụ, để gom 3 commit gần nhất:

git rebase -i HEAD~3

Trong trình soạn thảo hiện ra, thay thế pick bằng squash (hoặc s) cho các commit phía dưới để gộp chúng vào commit đầu tiên.

Quy chuẩn Conventional Commits

Sử dụng cấu trúc thông điệp commit chuẩn giúp tự động hóa việc sinh changelog và định hình phiên bản:

feat(auth): add google login button to login modal
fix(cart): resolve double-click issue on checkout button
refactor(header): migrate navigation to CSS Grid

3. Xử lý xung đột (Merge Conflict) trong dự án Frontend

Xung đột thường xảy ra ở các tệp cấu hình (như package.json, webpack.config.js) hoặc các component được nhiều lập trình viên cùng chỉnh sửa.

Quy trình xử lý xung đột tệp package.json

Khi đồng nghiệp thêm một thư viện mới và bạn cũng vậy, package.json và package-lock.json (hoặc yarn.lock) sẽ bị xung đột. Cách xử lý an toàn nhất:

  1. Giữ lại các thay đổi cần thiết của cả hai phía trong package.json.
  2. Xóa tệp khóa phiên bản (package-lock.json hoặc yarn.lock).
  3. Chạy lại lệnh cài đặt gói phụ thuộc để hệ thống tự động tái tạo tệp khóa chính xác: npm install hoặc yarn.
  4. Thêm và commit lại các tệp cấu hình.

4. Các cạm bẫy thường gặp và cách khắc phục

Dưới đây là một số tình huống khẩn cấp mà lập trình viên Frontend thường đối mặt trong quá trình làm việc hàng ngày.

Lỡ commit nhầm tệp mã nguồn nhạy cảm hoặc tệp build

Nếu bạn lỡ commit tệp .env chứa khóa API hoặc thư mục dist/ lên nhánh local nhưng chưa push:

git reset --soft HEAD^

Lệnh này sẽ hủy commit nhưng giữ lại toàn bộ thay đổi trong không gian làm việc. Sau đó, hãy cập nhật tệp .gitignore để bỏ qua các tệp này.

Khôi phục một tệp duy nhất về trạng thái trên nhánh chính

Khi bạn thử nghiệm giao diện và làm hỏng một component, thay vì hoàn tác toàn bộ dự án, bạn có thể khôi phục riêng tệp đó:

git checkout origin/main -- src/components/Button.tsx

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

  • Đã đồng bộ mã nguồn mới nhất từ nhánh chính về nhánh hiện tại (git pull origin main hoặc git rebase origin/main).
  • Đã chạy kiểm tra định dạng và quy chuẩn mã nguồn (npm run lint, npm run format).
  • Đã kiểm tra kỹ không còn các đoạn mã thử nghiệm (console.log thừa, đoạn code comment tạm thời).
  • Thông điệp commit rõ ràng, tuân thủ quy chuẩn của dự án.

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

Tôi nên dùng git merge hay git rebase khi cập nhật nhánh tính năng?

Git rebase giúp lịch sử commit phẳng, tuyến tính và dễ theo dõi hơn khi review code. Tuy nhiên, nếu nhánh tính năng của bạn đang được chia sẻ với nhiều lập trình viên khác, hãy dùng git merge để tránh làm xáo trộn lịch sử của đồng nghiệp.

Làm sao để hủy bỏ hoàn toàn các thay đổi chưa commit?

Nếu bạn muốn xóa sạch mọi thay đổi chưa lưu và đưa thư mục làm việc về đúng trạng thái của commit gần nhất, hãy dùng: git reset --hard HEAD. Hãy cẩn trọng vì lệnh này không thể hoàn tác.

Ôn tiếp theo chủ đề này

Chuyển sang câu hỏi hoặc case study để luyện cách trả lời.

Xem câu hỏi