Thành thạo Git cho lập trình viên Mobile: Chiến lược Branching, Git LFS và Xử lý Conflict hiệu quả

Quản lý mã nguồn trong phát triển ứng dụng di động đòi hỏi những quy chuẩn khắt khe hơn so với phát triển web thông thường. Sự khác biệt này đến từ việc ứng dụng Mobile phải tương tác trực tiếp với phần cứng, phụ thuộc vào các công cụ đóng gói nhị phân (binary files) như .apk, .aab, .ipa, và việc phát hành phiên bản phải tuân theo chu kỳ xét duyệt nghiêm ngặt của Apple App Store và Google Play Store. Bài viết này đúc kết các best practice về Git giúp đội ngũ lập trình Mobile tối ưu hóa quy trình làm việc.

1. Chiến lược Branching tối ưu cho Mobile: Gitflow mở rộng

Các dự án mobile thường phải duy trì song song nhiều phiên bản trên production (ví dụ: vá lỗi khẩn cấp cho bản v1.2 trong khi bản v1.3 đang được thử nghiệm). Do đó, chiến lược Gitflow tiêu chuẩn được tinh chỉnh để phù hợp hơn với đặc thù phát triển mobile:

• main (hoặc master): Luôn chứa mã nguồn sạch, khớp chính xác với phiên bản đang phát hành trên Store.
• develop: Nhánh tích hợp chính cho chu kỳ tính năng tiếp theo.
• release/x.y.z: Nhánh chuẩn bị phát hành. Đây là nơi thực hiện QA testing, fix bug nhỏ và tối ưu hóa trước khi đưa lên store. Tuyệt đối không thêm tính năng mới ở nhánh này.
• hotfix/x.y.z+1: Nhánh rẽ từ main để vá lỗi nghiêm trọng trên production.

Quy tắc đặt tên nhánh

Sử dụng tiền tố rõ ràng kết hợp với mã ticket từ Jira hoặc Trello giúp tự động hóa CI/CD:

• feature/MOB-123-payment-gateway
• bugfix/MOB-145-crash-on-launch
• hotfix/MOB-150-fix-login-loop

2. Quản lý tài nguyên lớn và mã nguồn nhị phân với Git LFS

Một thách thức lớn trong lập trình mobile là dung lượng của các tệp tài nguyên như hình ảnh độ phân giải cao, tệp âm thanh, video hướng dẫn, hoặc các mô hình AI/ML nhúng. Đưa trực tiếp các tệp này vào Git lịch sử sẽ làm tăng vọt dung lượng repository, khiến thời gian clone và checkout kéo dài đáng kể.

Git LFS (Large File Storage) giải quyết vấn đề này bằng cách thay thế các tệp nặng bằng các con trỏ văn bản nhỏ trong Git, trong khi dữ liệu thực tế được lưu trữ trên một server từ xa riêng biệt.

Cấu hình Git LFS thực tế:

# Cài đặt Git LFS trên máy tính
git lfs install

# Theo dõi các định dạng tệp nhị phân phổ biến trong mobile
git lfs track "*.png"
git lfs track "*.jpg"
git lfs track "*.apk"
git lfs track "*.ipa"
git lfs track "*.framework"
git lfs track "*.aab"

# Đảm bảo tệp .gitattributes được commit
git add .gitattributes
git commit -m "chore: configure git lfs for mobile binaries"

3. Xử lý Conflict thực tế trong dự án Android và iOS

Conflict trong lập trình mobile thường xảy ra ở các tệp cấu hình dự án, nơi mà Git thông thường rất khó tự động gộp (merge).

Trường hợp 1: Conflict trong tệp Package Manager (Package.swift, Podfile.lock, build.gradle)

Khi hai lập trình viên cùng thêm thư viện mới, tệp lock file sẽ bị conflict. Best practice là không cố gắng giải quyết thủ công từng dòng code trong các tệp này. Thay vào đó:

1. Chấp nhận một phiên bản tạm thời hoặc hủy bỏ merge (git merge --abort).
2. Cập nhật lại file cấu hình gốc (ví dụ: Podfile hoặc build.gradle).
3. Chạy lệnh đồng bộ hóa để công cụ quản lý phụ thuộc tự sinh lại tệp lock file chuẩn xác:

# Đối với iOS CocoaPods
pod install

# Đối với Android Gradle
./gradlew clean build

Trường hợp 2: Conflict trong tệp Project File (project.pbxproj của Xcode)

Tệp project.pbxproj nổi tiếng là "nỗi ác mộng" của iOS developer khi xảy ra conflict vì cấu trúc JSON phức tạp và các UUID được sinh tự động. Để hạn chế:

• Hạn chế tối đa việc nhiều người thêm/xóa file resource hoặc thay đổi build setting cùng một thời điểm.
• Sử dụng các công cụ hỗ trợ như XcodeGen hoặc Tuist để tự động sinh tệp project.pbxproj từ file cấu hình YAML/Swift, loại bỏ hoàn toàn khả năng conflict ở tệp này.

4. Best Practice khi viết Commit Message cho Mobile

Commit message rõ ràng giúp đội ngũ QA và Product Manager dễ dàng tra cứu tính năng hoặc lỗi nào đã được đưa vào bản build nội bộ (Internal Test/TestFlight).

Sử dụng chuẩn Conventional Commits:

feat(auth): integrate biometrics login using LocalAuthentication

- Add FaceID and TouchID fallback mechanism
- Update Info.plist with NSCameraUsageDescription

JIRA: MOB-204

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

Checklist trước khi tạo Pull Request (PR)

• Đã rebase code mới nhất từ nhánh develop để giải quyết conflict tại máy cá nhân.
• Đã chạy Unit Test và UI Test cục bộ không có lỗi.
• Đã loại bỏ hoàn toàn các tệp nhật ký debug, tệp build tạm thời (ví dụ: thư mục DerivedData trên Xcode hay build/ trên Android).
• Đã kiểm tra dung lượng ứng dụng không tăng bất thường do tài nguyên mới.

FAQ

Q: Có nên dùng git merge hay git rebase khi cập nhật code từ develop?
A: Nên sử dụng git pull --rebase để giữ cho lịch sử commit phẳng (linear history), giúp việc đọc lịch sử thay đổi của ứng dụng dễ dàng hơn và thuận tiện khi cần thực hiện git bisect để tìm bug.

Q: Làm sao để khôi phục khi vô tình commit tệp keystore hoặc chứng chỉ (certificate) lên git?
A: Bạn cần ngay lập tức thay thế chứng chỉ đó trên hệ thống (revoke). Sau đó sử dụng công cụ như git-filter-repo để xóa hoàn toàn tệp đó khỏi lịch sử git trước khi push lên remote repository.