Main và Master Branch trong Git: nó là gì và tại sao cần nhánh chính

Main / Master Branch trong Git là gì

Main Branch (hoặc Master — tùy thuộc vào cài đặt kho lưu trữ) là nhánh mặc định được tạo khi khởi tạo bất kỳ kho lưu trữ Git nào. Đây là nhánh chính của dự án và chứa mã sẵn sàng để triển khai vào sản xuất.

Không giống như develop, nơi công việc hàng ngày với các tính năng mới diễn ra sôi nổi, main là tủ trưng bày của dự án. Mỗi phiên bản mã trong main đã trải qua một chu trình đầy đủ: phát triển trong nhánh feature, tích hợp vào develop, chuẩn bị phát hành trong nhánh release và kiểm thử cuối cùng. Chỉ sau đó các thay đổi mới đến được main.

Nguyên tắc chính: main phải luôn ổn định. Nếu phát hiện lỗi trong main, điều đó có nghĩa là cần phát hành hotfix khẩn cấp ngoài lượt. Do đó, trong các dự án chuyên nghiệp, main được bảo vệ khỏi các thay đổi vô tình bằng các quy tắc bảo vệ nhánh.

Theo Git Book, main không phải là nhánh đặc biệt với các thuộc tính độc nhất, mà là một tham chiếu thông thường đến một commit được coi là chính theo quy ước. Git không phân biệt giữa main và bất kỳ nhánh nào khác ở cấp hệ thống.

Chuyển đổi từ master sang main

Trong lịch sử, nhánh mặc định trong Git được gọi là master. Vào tháng 6 năm 2020, phong trào Black Lives Matter đã thu hút sự chú ý đến các thuật ngữ master và slave trong ngành CNTT. GitHub đã công bố quá trình chuyển đổi sang thuật ngữ main cho nhánh mặc định.

Kể từ tháng 10 năm 2020, tất cả các kho lưu trữ mới trên GitHub được tạo với nhánh main. GitLab và Bitbucket cũng đã triển khai hỗ trợ main làm tên mặc định. Git 2.28 (tháng 7 năm 2020) đã thêm tùy chọn init.defaultBranch để cấu hình tên nhánh mặc định.

Về mặt kỹ thuật, việc đổi tên nhánh hiện có từ master sang main là một thao tác đơn giản. Thách thức chính là cập nhật tất cả các tham chiếu trong cấu hình CI/CD, tài liệu và kho lưu trữ cục bộ của các nhà phát triển.

Để đổi tên nhánh trong kho lưu trữ hiện có, hãy chạy:

# Đổi tên cục bộ master thành main
git branch -m master main

# Cập nhật kho lưu trữ từ xa
git push -u origin main

# Xóa master cũ trên máy chủ
git push origin --delete master

# Cập nhật HEAD trên máy chủ
# (qua giao diện web GitHub: Settings → Branches → Default branch)

Vai trò của main trong Git Flow và GitHub Flow

Git Flow và GitHub Flow định nghĩa vai trò của nhánh main khác nhau. Việc lựa chọn mô hình phụ thuộc vào quy mô nhóm, tần suất phát hành và yêu cầu về độ ổn định mã.

Đối với phát triển di động, Git Flow là tiêu chuẩn, vì việc xuất bản ứng dụng lên App Store và Google Play có chu kỳ phát hành cố định. GitHub Flow phù hợp hơn cho các dự án web có thể triển khai nhiều lần mỗi ngày.

GitHub Flow — phương pháp đơn giản hóa

Trong GitHub Flow, không có nhánh develop. Tất cả các nhánh feature được tạo trực tiếp từ main và sau khi hoàn thành được hợp nhất lại qua Pull Request. Mỗi lần hợp nhất vào main sẽ tự động kích hoạt triển khai vào sản xuất. Mô hình này đòi hỏi mức độ tự động hóa kiểm thử cao và kỷ luật nhóm.

Trong GitHub Flow, không có nhánh develop. Tất cả các nhánh feature được tạo trực tiếp từ main và sau khi hoàn thành được hợp nhất lại qua Pull Request. Mỗi lần hợp nhất vào main sẽ tự động kích hoạt triển khai vào sản xuất. Mô hình này đòi hỏi mức độ tự động hóa kiểm thử cao và kỷ luật nhóm.

Bảo vệ nhánh main

Bảo vệ nhánh cho main là cài đặt bắt buộc trong bất kỳ dự án thương mại nào. Nếu không có nó, một push vô tình có thể gửi mã chưa hoàn thiện vào sản xuất hoặc phá vỡ ứng dụng đang hoạt động cho tất cả người dùng.

• Require pull request — push trực tiếp vào main bị cấm. Mọi thay đổi qua PR có đánh giá.
• Require approvals — tối thiểu 2 phê duyệt để hợp nhất vào main (phòng trường hợp người đánh giá bỏ sót).
• Require status checks — tất cả kiểm tra CI/CD phải thành công trước khi hợp nhất.
• Require up-to-date — PR phải dựa trên commit main mới nhất.
• Include administrators — bảo vệ áp dụng ngay cả với chủ sở hữu kho lưu trữ.
• Require signed commits — tất cả commit trong main phải được ký bằng khóa GPG.

Cấu hình tất cả sáu quy tắc là tiêu chuẩn cho các dự án di động với 10.000+ người dùng. Đối với các dự án nhỏ, ba quy tắc đầu tiên là đủ.

So sánh mức độ bảo vệ cho các loại dự án khác nhau

Mức độ bảo vệ của main phụ thuộc vào quy mô dự án. Một startup có thể tồn tại với bảo vệ tối thiểu, trong khi ứng dụng doanh nghiệp yêu cầu các hạn chế tối đa.

Phát hành và thẻ trong main

Gắn thẻ là thực hành tạo các tham chiếu có tên đến các commit cụ thể trong main. Mỗi thẻ tương ứng với một phiên bản ứng dụng được phát hành vào sản xuất. Điều này cho phép chuyển nhanh đến bất kỳ bản phát hành nào trước đó để gỡ lỗi hoặc vá lỗi.

Tiêu chuẩn đặt tên thẻ trong phát triển di động là SemVer (Phiên bản ngữ nghĩa): v1.2.3, trong đó số đầu tiên là phiên bản chính (thay đổi phá vỡ), số thứ hai là phiên bản phụ (tính năng mới) và số thứ ba là bản vá (sửa lỗi).

Một thẻ được tạo sau khi hợp nhất nhánh release vào main. Commit này sau đó được xây dựng trong CI/CD, ký và gửi đến cửa hàng ứng dụng. Nếu phát hiện lỗi trong thẻ, một nhánh hotfix được tạo từ thẻ đó.

# Tạo thẻ phát hành có chú thích
git tag -a v2.4.1 -m "Release version 2.4.1"

# Gửi thẻ lên máy chủ
git push origin v2.4.1

# Xem tất cả thẻ trong kho lưu trữ
git tag -l "v2.*"

# Tạo nhánh hotfix từ một thẻ cụ thể
git checkout -b hotfix/crash-fix v2.4.1

Hệ thống phân cấp nhánh Git Flow

Hiểu hệ thống phân cấp nhánh trong Git Flow là nền tảng để tổ chức phát triển cộng tác đúng cách. Mỗi loại nhánh có nguồn gốc, mục đích và quy tắc hợp nhất riêng.

• Main (Cấp 1) — nhánh gốc, chỉ chứa phiên bản phát hành. Được tạo khi khởi tạo kho lưu trữ.
• Develop (Cấp 2) — được tạo từ main khi bắt đầu dự án. Chứa mã tích hợp của tất cả các tính năng.
• Feature (Cấp 3) — được tạo từ develop. Phát triển riêng biệt các tính năng riêng lẻ.
• Release (Cấp 2) — được tạo từ develop. Chuẩn bị một bản phát hành cụ thể để ra mắt.
• Hotfix (Cấp 2) — được tạo từ main. Sửa lỗi khẩn cấp các lỗi sản xuất nghiêm trọng.

Quy tắc quan trọng: feature không bao giờ được hợp nhất trực tiếp vào main. feature → develop → release → main là chuỗi hợp nhất chính xác. Vi phạm quy tắc này làm mất đi ý nghĩa của toàn bộ mô hình Git Flow.

Ví dụ lệnh làm việc với main

Xem xét một tình huống: nhóm đã hoàn tất chuẩn bị phát hành v2.5.0. Nhánh release đã được đánh giá và sẵn sàng hợp nhất vào main. Sau khi hợp nhất, một thẻ được tạo và bản phát hành được công bố.

# Chuyển sang main và cập nhật
git checkout main
git pull origin main

# Hợp nhất nhánh release đã xác minh
git merge --no-ff release/2.5.0

# Tạo thẻ phát hành
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# Gửi main và thẻ lên máy chủ
git push origin main --tags

Cờ --no-ff (không fast-forward) đảm bảo tạo commit hợp nhất, ngay cả khi việc hợp nhất có thể được thực hiện bằng cách chỉ di chuyển con trỏ. Điều này bảo tồn thông tin rằng các thay đổi đến từ nhánh release, giúp phân tích lịch sử dễ dàng hơn.

Làm việc với hotfix qua main

Nếu phát hiện lỗi nghiêm trọng trong sản xuất, quy trình sẽ khác với bản phát hành thông thường. Một hotfix được tạo từ main và sau khi sửa lỗi, nó được hợp nhất vào cả main và develop.

Nếu phát hiện lỗi nghiêm trọng trong sản xuất, quy trình sẽ khác với bản phát hành thông thường. Một hotfix được tạo từ main và sau khi sửa lỗi, nó được hợp nhất vào cả main và develop.

# Tạo nhánh hotfix từ main
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# Sửa lỗi và commit
git add src/fix/
git commit -m "Fix crash on login screen"

# Hợp nhất hotfix trở lại main
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# Hợp nhất hotfix vào develop
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# Xóa nhánh hotfix
git branch -d hotfix/2.5.1-crash-fix