Phương pháp sử dụng git mà tôi luôn tin tưởng

Vậy thì "đủ" luôn là một từ khoá phù hợp khi xây dựng một git strategy. Đây là chiến lược mà tôi đã tin tưởng và sử dụng trong nhiều năm.

Phương pháp sử dụng git mà tôi luôn tin tưởng

Xây dựng chiến lược git cho dự án giống như một loại nghệ thuật: quá cứng nhắc thì members khó follow, làm chậm tốc độ development. Nếu quá lỏng lẻo thì correction cost sẽ rất lớn thậm chí còn có thể mang tới những thảm hoạ bất ngờ. Vậy thì "đủ" luôn là một từ khoá phù hợp khi xây dựng một git strategy. Đây là chiến lược mà tôi đã tin tưởng và sử dụng trong nhiều năm.

1. Quy Tắc Cơ Bản

  • Luôn sử dụng git pull trước khi bắt đầu viết code.
  • Không đẩy các tập tin lớn lên repository.
  • Không đẩy dữ liệu nhạy cảm của production lên repository. (Secret manager sẽ được tôi đề cập ở một bài viết khác)

2. Tuân Theo Chiến Lược Phân Nhánh

Sử dụng mô hình phân nhánh có cấu trúc giúp ngăn ngừa xung đột và giữ cho quá trình phát triển được tổ chức. Quy trình làm việc theo nhánh tính năng được khuyến nghị:

  • Nhánh main (hoặc master) – Code ổn định sẵn sàng cho sản xuất.
  • Nhánh develop – Những thay đổi mới nhất đang được kiểm tra trước khi phát hành.
  • Nhánh tính năng — Được sử dụng cho các tính năng mới, đặt tên phù hợp (ví dụ: feature/nlp-model).
  • Nhánh sửa lỗi — Được sử dụng để sửa các lỗi khẩn cấp (ví dụ: bugfix/memory-leak).
Diagram illustrating a Git branching model, showing main and develop branches, multiple feature branches, a bugfix branch, and merge requests, along with notes about tagging a release and handling conflicts.

Để tạo và chuyển sang nhánh tính năng:

git checkout -b feature/image-classification

Sau khi thực hiện các thay đổi, đẩy nhánh lên:

git push origin feature/image-classification

Khi tính năng hoàn thành, hợp nhất nó vào nhánh develop:

git checkout develop  
git merge feature/image-classification  
git push origin develop

3. Viết Thông Điệp Commit Có Ý Nghĩa

Tránh các thông điệp chung chung như "Cập nhật code". Thay vào đó, hãy viết thông điệp commit rõ ràng và mô tả:

git commit -m "Triển khai mô hình phân tích cảm xúc dựa trên TensorFlow"

Một thông điệp commit tốt nên:

  • ✔️ Mô tả những gì đã thay đổi
  • ✔️ Giải thích lý do thay đổi (nếu cần thiết)
  • ✔️ Sử dụng thì mệnh lệnh (ví dụ: "Sửa vấn đề về độ chính xác trong mô hình OCR")

4. Commit Các Thay Đổi Nhỏ, Hợp Lý

Commit thường xuyên và giữ cho các thay đổi nhỏ giúp dễ dàng theo dõi tiến trình và hoàn tác các vấn đề. Thay vì một commit lớn, hãy chia nhỏ:

✅ Tốt:

git commit -m "Thêm tiền xử lý dữ liệu cho bộ dữ liệu MNIST"
git commit -m "Triển khai kiến trúc CNN cho nhận dạng chữ số"
git commit -m "Thêm các chỉ số đánh giá và dừng sớm"

❌ Tệ:

git commit -m "Cập nhật mô hình AI"

5. Pull Trước Khi Push

Trước khi đẩy các thay đổi của bạn, luôn kéo các thay đổi mới nhất từ repository từ xa để tránh xung đột merge:

git pull origin develop

Nếu xảy ra xung đột, Git sẽ đánh dấu chúng, và bạn phải giải quyết chúng thủ công trước khi commit phiên bản cuối cùng.

Tips: Khi Conflict khó xảy ra

Khi bạn không thể giải quyết xung đột sau khi pull, hãy làm theo các bước sau:

  1. Tạo một nhánh mới từ nhánh tính năng hiện tại của bạn
  2. Đẩy nhánh mới này và tạo pull request trở lại nhánh tính năng ban đầu
  3. Xem xét xung đột cùng với đội

Ví dụ:

  1. Bạn đang làm việc trên nhánh feature/object-detection
  2. Bạn pull và cố gắng giải quyết xung đột, nhưng một số xung đột quá phức tạp
  3. Tạo nhánh mới: git checkout -b feature/object-detection-conflict
  4. Đẩy nhánh này: git push origin feature/object-detection-conflict
  5. Tạo pull request: feature/object-detection-conflictfeature/object-detection
  6. Xem xét và merge cùng với đội

6. Sử Dụng Git Tags cho Các Phiên Bản

Đánh dấu giúp theo dõi các phiên bản ổn định và đơn giản hóa việc quay lại phiên bản cũ. Bạn có thể đánh dấu một phiên bản như sau:

git tag -a v1.0.0 -m "Phiên bản mô hình ổn định đầu tiên với độ chính xác 85%"
git push origin v1.0.0

Sau này, bạn có thể kiểm tra một phiên bản cụ thể nếu cần:

git checkout tags/v1.0.0

7. Sử Dụng Pull Requests và Code Reviews

Thay vì merge trực tiếp vào nhánh main hoặc develop, hãy sử dụng pull requests (PRs) trên các nền tảng như GitHub hoặc GitLab. Điều này cho phép:

  • ✔️ Đánh giá code trước khi merge
  • ✔️ Kiểm tra tự động trước khi triển khai
  • ✔️ Một lịch sử về ai đã thay đổi những gì và tại sao

8. Các Công Cụ Được Khuyến Nghị

Việc git merge/rebase trong một số tình huống là một công việc đau đớn và phức tạp. Khi này, mặc dù đã sử dụng qua github desktop, VScode, Cursor (công cụ code chính của tôi hiện tại ❤️)… Nhưng tôi vẫn tin tưởng nhất là bộ công cụ quản lý git của JetBrains.

  • IntelliJ IDEA
  • PyCharm

JetBrains có một bộ công cụ git rất rất mạnh mẽ cho việc resolve conflict (local, online), checkout, rollback, merge, rebase ... tất cả có giao diện rõ ràng và tránh gây nhầm lẫn.

Bạn nên thành thạo một loại công cụ để tránh sai sót trong quá trình quản lý git và resolve git conflict. Các công cụ của JetBrains cung cấp giao diện trực quan và mạnh mẽ cho việc xử lý conflict, cho phép:

  • So sánh code theo từng dòng
  • Chấp nhận thay đổi từ bên này hoặc bên kia một cách dễ dàng
  • Xem xét lịch sử thay đổi ngay trong giao diện
  • Tự động phát hiện và gợi ý giải quyết conflict