Git và quản lý phiên bản trong phát triển di động: khái niệm, lệnh cơ bản và cách hoạt động

Quản lý phiên bản và Git: là gì?

Git là hệ thống quản lý phiên bản phân tán (VCS) được tạo bởi Linus Torvalds vào năm 2005 để phát triển nhân Linux. Không giống như các hệ thống tập trung (SVN, CVS), Git lưu trữ một bản sao đầy đủ lịch sử dự án trên mỗi máy tính của nhà phát triển. Điều này có nghĩa là bạn có thể thực hiện commit, xem lịch sử và tạo nhánh ngay cả khi không có kết nối Internet.

Git hoạt động với ảnh chụp nhanh (snapshots) — mỗi commit lưu trạng thái của tất cả tệp dự án tại thời điểm lưu. Nếu tệp không thay đổi, Git tạo tham chiếu đến phiên bản trước, tiết kiệm dung lượng. Theo phân tích GitHub (2025), kho lưu trữ trung bình chứa 1.200 commit và 15 nhánh.

Tại IT Sectr, chúng tôi đã sử dụng Git từ năm 2017 trong tất cả các dự án. Kinh nghiệm của chúng tôi cho thấy cấu hình Git đúng cách từ ngày đầu tiên giúp tiết kiệm cho nhóm tới 30% thời gian hợp nhất và giải quyết xung đột. Git đã trở thành tiêu chuẩn thực tế — nó được hỗ trợ bởi tất cả các IDE hiện đại (Android Studio, Xcode, VS Code) và hệ thống CI/CD.

# Thiết lập Git cơ bản
git config --global user.name "Tên của bạn"
git config --global user.email "email@cua.ban"

# Tạo kho lưu trữ mới
git init my-project
cd my-project

# Thêm tệp và commit
git add README.md
git commit -m "Initial commit"

# Làm việc với kho lưu trữ từ xa
git remote add origin https://github.com/user/my-project.git
git push -u origin main

Mã trên cho thấy trình tự cơ bản: khởi tạo kho lưu trữ, commit đầu tiên và xuất bản lên máy chủ từ xa. Lệnh git init tạo một thư mục .git ẩn để lưu trữ toàn bộ lịch sử dự án. Mỗi git commit tạo một điểm khôi phục mà bạn có thể quay lại bất kỳ lúc nào.

Khái niệm cơ bản: Repository, Branch, Commit

Hiểu ba khái niệm cơ bản — Repository, Branch và Commit — là cần thiết để làm việc với bất kỳ hệ thống quản lý phiên bản nào. Kho lưu trữ là một vùng chứa cho toàn bộ dự án. Commit là trạng thái đã lưu của các tệp. Branch là một dòng phát triển riêng biệt.

Repository (kho lưu trữ) có thể là cục bộ (trên máy tính của bạn) hoặc từ xa (trên máy chủ GitHub, GitLab). Mỗi nhà phát triển sao chép kho lưu trữ từ xa vào máy của họ và làm việc với bản sao cục bộ. Các thay đổi được đồng bộ hóa qua push (gửi) và pull (lấy). Trong quản lý phiên bản phân tán, mỗi nhà phát triển lưu trữ một bản sao đầy đủ lịch sử.

Branch (nhánh) là một con trỏ trỏ đến một trong các commit. Các nhánh cho phép phát triển song song: một nhà phát triển làm việc trên tính năng mới (feature branch), người khác sửa lỗi (hotfix branch), người thứ ba chuẩn bị phát hành (release branch). Theo GitLab Flow (2025), dự án trung bình có 3–5 nhánh hoạt động đồng thời.

Commit là một đơn vị thay đổi. Mỗi commit chứa một hàm băm duy nhất (SHA-1), thông điệp, tác giả và dấu thời gian. Thực hành tốt là thực hiện các commit nhỏ có ý nghĩa với thông điệp mô tả — điều này giúp đơn giản hóa việc đánh giá mã và khôi phục thay đổi. Quản lý phiên bản qua commit cung cấp cho bạn lịch sử dự án đầy đủ.

Feature Branch

Feature Branch (nhánh tính năng) là một nhánh tạm thời được tạo từ develop hoặc main để phát triển một tác vụ cụ thể. Sau khi hoàn thành công việc, nhánh được hợp nhất lại qua Pull Request và bị xóa. Thực hành này cho phép cô lập các thay đổi mà không ảnh hưởng đến sự ổn định của cơ sở mã chính.

Quy trình làm việc điển hình: tạo nhánh feature/add-login → thực hiện vài commit → tạo Pull Request → trải qua Đánh giá mã → hợp nhất vào develop. Tại IT Sectr, chúng tôi sử dụng chính xác cách tiếp cận này: mỗi tác vụ Jira tương ứng với một nhánh tính năng riêng biệt. Điều này giúp đơn giản hóa việc theo dõi thay đổi và khôi phục nếu cần.

Rebase vs Merge

Merge tạo một commit hợp nhất kết hợp hai nhánh. Nó bảo toàn lịch sử đầy đủ, bao gồm cả các dòng phát triển song song. Rebase viết lại lịch sử: nó lấy các commit từ một nhánh và "áp dụng lại" chúng lên trên nhánh khác, tạo ra lịch sử tuyến tính.

Merge phù hợp hơn cho các nhánh công khai và nhóm lớn nơi thứ tự thời gian quan trọng. Rebase thuận tiện cho các nhánh tính năng cá nhân trước khi tạo PR — nó làm cho lịch sử sạch hơn và dễ hiểu hơn. Tuy nhiên, không bao giờ áp dụng rebase cho các nhánh mà người khác đang làm việc, vì nó viết lại lịch sử.

# Tạo và chuyển sang nhánh tính năng
git checkout -b feature/add-login main

# Làm việc trong nhánh
git add login-screen/
git commit -m "Add login screen layout"

# Rebase lên main mới nhất trước PR
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push lên kho lưu trữ từ xa
git push origin feature/add-login

Ví dụ này cho thấy quy trình làm việc điển hình: tạo nhánh tính năng từ main, vài commit và rebase để có lịch sử tuyến tính sạch trước khi gửi đánh giá. Cách tiếp cận này giảm thiểu xung đột hợp nhất.

Git Flow vs Trunk-Based Development

Git Flow và Trunk-Based Development là hai chiến lược quản lý phiên bản chính xác định cách nhóm tổ chức công việc với Git. Lựa chọn phụ thuộc vào quy mô nhóm, tần suất phát hành và yêu cầu ổn định.

Git Flow là mô hình nghiêm ngặt với nhiều nhánh cố định: main (mã phát hành), develop (phát triển hiện tại), feature/* (tính năng mới), release/* (chuẩn bị phát hành) và hotfix/* (sửa lỗi khẩn cấp). Mô hình này phù hợp với các dự án có chu kỳ phát hành rõ ràng (ví dụ: ứng dụng di động với phiên bản 1.0, 2.0).

Trunk-Based Development là cách tiếp cận với một nhánh chính duy nhất (trunk/main) nơi tất cả nhà phát triển hợp nhất thay đổi nhiều lần trong ngày. Cờ tính năng được sử dụng để ẩn các tính năng chưa hoàn thành. Cách tiếp cận này phổ biến trong phát triển web và khởi nghiệp nơi tốc độ giao hàng quan trọng.

Git Flow

Git Flow, được đề xuất bởi Vincent Driessen vào năm 2010, vẫn là một trong những mô hình phổ biến nhất. Ưu điểm chính của nó là sự phân tách mã nghiêm ngặt theo các giai đoạn vòng đời. Nhánh main chỉ chứa mã phát hành, develop chứa phát triển hiện tại và các nhánh tính năng cô lập các tính năng mới với nhau.

Các nhánh hotfix được tạo từ main để sửa lỗi khẩn cấp và sau khi hợp nhất được hợp nhất lại vào cả main và develop. Các nhánh release được tạo từ develop khi nhóm sẵn sàng phát hành. Chỉ có sửa lỗi và siêu dữ liệu (phiên bản, bản dựng) được thêm vào chúng. Sau khi phát hành, nhánh release được hợp nhất vào main và develop. Theo khảo sát của JetBrains (2024), 37% nhóm sử dụng Git Flow. Mô hình quản lý phiên bản này vẫn là tiêu chuẩn cho các dự án có phát hành cố định.

# Ví dụ Git Flow: bắt đầu công việc phát hành
git checkout -b release/1.2.0 develop

# Sửa lỗi trong nhánh release
git commit -m "Fix login button crash"

# Hoàn thành phát hành — hợp nhất vào main và develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# Xóa nhánh release
git branch -d release/1.2.0

Mã minh họa việc tạo nhánh release, ổn định nó và hợp nhất vào các nhánh chính. Cờ --no-ff đảm bảo một commit hợp nhất, bảo toàn thông tin rằng các thay đổi đến từ nhánh release.

Pull Request và Đánh giá mã

Pull Request (PR) là cơ chế mà nhà phát triển đề xuất thay đổi từ nhánh của họ vào nhánh chính. PR là yếu tố chính của quản lý phiên bản trong công việc nhóm — nó không chỉ là cách hợp nhất mã, mà là quá trình thảo luận, đánh giá và kiểm tra chất lượng. Trong GitLab, cơ chế tương tự được gọi là Merge Request (MR), nhưng bản chất giống nhau: thông báo cho nhóm về các thay đổi và nhận được phê duyệt.

Một PR tốt nên nhỏ (tới 300 dòng mã), tập trung vào một tác vụ duy nhất và chứa mô tả về những gì đã làm và tại sao. Theo nghiên cứu của Google (2025), PR trên 400 dòng mất gấp đôi thời gian để đánh giá và xác suất phát hiện lỗi giảm 30%. Đánh giá mã (Code Review) là việc kiểm tra mã bởi một nhà phát triển khác trước khi hợp nhất.

Tại IT Sectr, chúng tôi thực hành Đánh giá mã bắt buộc cho mọi PR. Điều này không chỉ cải thiện chất lượng mã mà còn giúp lan truyền kiến thức trong nhóm. Đánh giá mã kiểm tra: mã có tuân thủ nguyên tắc kiến trúc không, có lỗi không, có đủ bài kiểm tra không, biến có được đặt tên đúng không. Tất cả nhận xét được thảo luận trong PR cho đến khi hợp nhất.

Nền tảng: GitHub, GitLab, Bitbucket

Git là một giao thức, nhưng để cộng tác cần một nền tảng quản lý phiên bản cung cấp giao diện web, quản lý truy cập, CI/CD và công cụ đánh giá. Ba nền tảng thống trị thị trường: GitHub, GitLab và Bitbucket.

GitHub là nền tảng lớn nhất với hơn 56 triệu nhà phát triển. Thuộc sở hữu của Microsoft, cung cấp Actions (CI/CD), Pages (lưu trữ), Discussions và Copilot. Gói miễn phí bao gồm kho lưu trữ riêng tư không giới hạn cho nhóm tới 3 người. GitHub phổ biến trong cộng đồng mã nguồn mở.

GitLab là nền tảng DevOps hoàn chỉnh với CI/CD tích hợp, registry vùng chứa và quản lý cơ sở hạ tầng. Không giống GitHub, GitLab có thể được cài đặt trên máy chủ của riêng bạn (Self-Managed). Bitbucket của Atlassian được tích hợp chặt chẽ với Jira và Confluence, khiến nó trở thành lựa chọn cho các nhóm đã sử dụng hệ sinh thái Atlassian.