Git中的Main和Master分支：什么是主分支及其用途

什么是Git中的Main / Master分支

Main分支（或Master — 取决于仓库设置）— 是在初始化任何Git仓库时创建的默认分支。它是项目的主分支，包含准备部署到生产的代码。

与进行日常新功能开发的develop不同，main是项目的展示窗口。main中的每个代码版本都经过了完整的周期：在feature分支中开发，在develop中集成，在release分支中准备发布，以及最终测试。只有在此之后，更改才会进入main。

关键原则：main必须始终保持稳定。如果在main中发现错误，这意味着需要立即进行hotfix，必须按计划外发布。因此，在专业项目中，main通过分支保护规则防止意外更改。

根据Git Book，main不是具有特殊属性的特殊分支，而是一个普通的提交引用，按照约定被视为主要分支。Git在系统级别不区分main和任何其他分支。

从master到main的迁移

历史上，Git中的默认分支被称为master。2020年6月，Black Lives Matter运动引起了人们对IT行业中master和slave术语的关注。GitHub宣布将默认分支迁移到main术语。

自2020年10月起，GitHub上的所有新仓库都使用main分支创建。GitLab和Bitbucket也实现了对main作为默认名称的支持。Git 2.28（2020年7月）添加了init.defaultBranch选项，用于配置默认分支名称。

从技术上讲，将现有分支从master重命名为main是一个简单的操作。主要挑战是更新CI/CD配置、文档和开发人员本地仓库中的所有引用。

要重命名现有仓库中的分支，请执行：

# 将master本地重命名为main
git branch -m master main

# 更新远程仓库
git push -u origin main

# 删除服务器上的旧master
git push origin --delete master

# 更新服务器上的HEAD
# （通过GitHub Web界面：Settings → Branches → Default branch）

main在Git Flow和GitHub Flow中的作用

Git Flow和GitHub Flow对main分支角色的定义不同。模型的选择取决于团队规模、发布频率和代码稳定性要求。

对于移动应用开发，标准是Git Flow，因为在App Store和Google Play中发布应用具有固定的发布周期。GitHub Flow更适合具有每天多次部署能力的Web项目。

GitHub Flow — 简化方法

在GitHub Flow中没有develop分支。所有feature分支都直接从main创建，完成后通过Pull Request合并回main。每次合并到main都会自动触发生产部署。这种模式需要高水平的测试自动化和团队纪律。

在GitHub Flow中没有develop分支。所有feature分支都直接从main创建，完成后通过Pull Request合并回main。每次合并到main都会自动触发生产部署。这种模式需要高水平的测试自动化和团队纪律。

保护main分支

分支保护对于main来说 — 在任何商业项目中都是强制设置。没有它，意外推送可能将未完成的代码发送到生产环境，或破坏对所有用户正常运行的应用程序。

• Require pull request — 禁止直接推送到main。所有更改通过PR进行审查。
• Require approvals — 合并到main至少需要2个批准（以防一个审查员出错）。
• Require status checks — 所有CI/CD检查必须在合并前成功。
• Require up-to-date — PR必须基于main的最新提交。
• Include administrators — 保护甚至适用于仓库所有者。
• Require signed commits — main中的所有提交必须使用GPG密钥签名。

配置所有六条规则 — 对于拥有10,000+用户群体的移动项目是标准。对于小型项目，前三条规则就足够了。

不同类型项目的保护级别比较

main的保护级别取决于项目的规模。初创公司可以满足于最低保护，而企业应用程序需要最大限制。

main中的发布和标签

标记（tagging）— 为main中的特定提交创建命名引用的做法。每个标签对应一个发布到生产环境的应用程序版本。这允许快速切换到任何先前的版本进行调试或修补。

移动应用开发中的标签命名标准 — SemVer（语义化版本控制）：v1.2.3，其中第一个数字是主版本（破坏性更改），第二个是小版本（新功能），第三个是补丁（修复）。

标签在release分支合并到main后创建。这个提交随后在CI/CD中构建、签名并发送到应用商店。如果在标签中发现错误，则从该标签创建hotfix分支。

# 创建带注释的发布标签
git tag -a v2.4.1 -m "Release version 2.4.1"

# 将标签发送到服务器
git push origin v2.4.1

# 查看仓库中的所有标签
git tag -l "v2.*"

# 从特定标签创建hotfix分支
git checkout -b hotfix/crash-fix v2.4.1

Git Flow分支层级

理解Git Flow中的分支层级 — 是正确组织协作开发的基础。每种分支类型都有自己的来源、目的和合并规则。

• Main（第1级） — 根分支，仅包含发布版本。在仓库初始化时创建。
• Develop（第2级） — 在项目开始时从main创建。包含所有功能的集成代码。
• Feature（第3级） — 从develop创建。个别功能的隔离开发。
• Release（第2级） — 从develop创建。准备特定发布版本。
• Hotfix（第2级） — 从main创建。紧急修复关键生产错误。

重要规则：feature永远不会直接合并到main。feature → develop → release → main — 正确的合并链。违反此规则将使整个Git Flow模型失去意义。

使用main的示例命令

考虑场景：团队完成了v2.5.0版本的发布准备。Release分支已经过检查并准备合并到main。合并后，创建标签并发布版本。

# 切换到main并更新
git checkout main
git pull origin main

# 合并已验证的release分支
git merge --no-ff release/2.5.0

# 创建发布标签
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# 将main和标签发送到服务器
git push origin main --tags

--no-ff（no fast-forward）标志保证创建合并提交，即使可以通过简单移动指针来完成合并。这保留了更改来自release分支的信息，从而简化了历史分析。

通过main进行hotfix操作

如果在生产环境中发现关键错误，流程与常规发布不同。Hotfix从main创建，修复后同时合并到main和develop。

如果在生产环境中发现关键错误，流程与常规发布不同。Hotfix从main创建，修复后同时合并到main和develop。

# 从main创建hotfix分支
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# 修复并提交
git add src/fix/
git commit -m "Fix crash on login screen"

# 将hotfix合并回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

# 同时将hotfix合并到develop
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# 删除hotfix分支
git branch -d hotfix/2.5.1-crash-fix