移动开发中的 Git 与版本控制：概念、基本命令及工作原理

版本控制和 Git：是什么？

Git 是一个分布式版本控制系统 (VCS)，由 Linus Torvalds 于 2005 年为 Linux 内核开发而创建。与集中式系统（SVN、CVS）不同，Git 在每个开发者的计算机上存储项目历史的完整副本。这意味着即使没有互联网连接，您也可以进行提交、浏览历史和创建分支。

Git 使用快照（snapshot）工作 — 每个提交保存保存时所有项目文件的状态。如果文件没有更改，Git 会创建一个对先前版本的引用，从而节省空间。根据 GitHub 分析（2025），平均仓库包含 1200 次提交和 15 个分支。

在 IT Sectr，我们从 2017 年开始在所有项目中使用 Git。我们的经验表明，从第一天起正确配置 Git 可以为团队节省多达 30% 的合并和冲突解决时间。Git 已成为事实标准 — 所有现代 IDE（Android Studio、Xcode、VS Code）和 CI/CD 系统都支持它。

# Git 基本配置
git config --global user.name "您的姓名"
git config --global user.email "your@email.com"

# 创建新仓库
git init my-project
cd my-project

# 添加文件并提交
git add README.md
git commit -m "Initial commit"

# 使用远程仓库
git remote add origin https://github.com/user/my-project.git
git push -u origin main

上面的代码展示了基本流程：初始化仓库、第一次提交和发布到远程服务器。git init 命令创建一个隐藏的 .git 文件夹，用于存储整个项目历史。每个 git commit 创建一个恢复点，您可以随时返回。

基本概念：Repository、Branch、Commit

理解三个基本概念 — 仓库（Repository）、分支（Branch）和提交（Commit） — 对于使用任何版本控制系统都至关重要。仓库是整个项目的容器。提交是文件的已保存状态。分支是独立的开发线。

仓库可以是本地（在您的计算机上）或远程（在 GitHub、GitLab 服务器上）。每个开发者将远程仓库克隆到自己的机器上并使用本地副本工作。更改通过 push（发送）和 pull（拉取）同步。在分布式版本控制中，每个开发者存储历史的完整副本。

分支（Branch）是指向某个提交的指针。分支允许并行开发：一个开发者开发新功能（feature branch），另一个修复错误（hotfix branch），第三个准备发布（release branch）。根据 GitLab Flow（2025），平均项目同时有 3-5 个活跃分支。

提交（Commit）是更改的单位。每个提交包含唯一的哈希（SHA-1）、消息、作者和时间戳。好的做法是进行有描述性消息的小型有意义提交 — 这简化了代码审查和更改回滚。通过提交进行版本控制为您提供完整的项目历史。

Feature Branch（功能分支）

功能分支（Feature Branch）是从 develop 或 main 创建的临时分支，用于开发特定任务。工作完成后，分支通过 Pull Request 合并回去并删除。这种做法允许隔离更改，而不影响主代码库的稳定性。

典型工作流：创建分支 feature/add-login → 进行多次提交 → 创建 Pull Request → 通过代码审查 → 合并到 develop。在 IT Sectr，我们正是使用这种方法：每个 Jira 任务对应一个独立的功能分支。这简化了更改跟踪和必要时回滚。

Rebase 与 Merge

Merge 创建一个合并提交，将两个分支结合在一起。它保留完整的历史，包括并行开发线。Rebase 重写历史：它从一个分支获取提交并将它们"重新应用"到另一个分支之上，创建线性历史。

Merge 更适合公共分支和大型团队，因为时间顺序很重要。Rebase 在创建 PR 之前对个人功能分支很方便 — 它使历史更清晰、更易懂。但是，rebase 绝不应应用于其他开发者正在工作的分支，因为它会重写历史。

# 创建并切换到功能分支
git checkout -b feature/add-login main

# 在分支中工作
git add login-screen/
git commit -m "Add login screen layout"

# 在 PR 前 Rebase 到最新 main
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push 到远程仓库
git push origin feature/add-login

此示例展示了典型的工作流：从 main 创建功能分支、多次提交和 rebase，以便在发送审查之前获得清晰的线性历史。这种方法可以最大限度地减少合并冲突。

Git Flow 与 Trunk-Based Development

Git Flow 和 Trunk-Based Development 是两种主要的版本控制策略，决定了团队如何组织与 Git 的工作。选择取决于团队规模、发布频率和稳定性要求。

Git Flow 是一个严格的模型，具有多个永久分支：main（发布代码）、develop（当前开发）、feature/*（新功能）、release/*（发布准备）和 hotfix/*（紧急修复）。此模型适用于具有清晰发布周期的项目（例如，版本 1.0、2.0 的移动应用程序）。

Trunk-Based Development 是一种具有单个主分支（trunk/main）的方法，所有开发者每天多次合并更改。功能标志用于隐藏未完成的功能。这种方法在 Web 开发和初创企业中很受欢迎，因为交付速度很重要。

Git Flow

Git Flow 由 Vincent Driessen 于 2010 年提出，至今仍是最流行的模型之一。其主要优点是按生命周期阶段严格分离代码。main 分支仅包含发布代码，develop 包含当前开发，功能分支将新功能相互隔离。

Hotfix 分支从 main 创建用于紧急修复，合并后合并回 main 和 develop。Release 分支在团队准备好发布时从 develop 创建。只添加错误修复和元数据（版本、构建）。发布后，release 分支合并到 main 和 develop。根据 JetBrains 调查（2024），37% 的团队使用 Git Flow。此版本控制模型仍然是具有固定发布的项目的标准。

# Git Flow 示例：开始发布工作
git checkout -b release/1.2.0 develop

# 在 release 分支中修复错误
git commit -m "Fix login button crash"

# 完成发布 — 合并到 main 和 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

# 删除 release 分支
git branch -d release/1.2.0

代码说明了 release 分支的创建、稳定和合并到主分支。--no-ff 标志保证了合并提交，保留了更改来自 release 分支的信息。

Pull Request 和代码审查

Pull Request (PR) 是开发者从自己的分支向主分支提议更改的机制。PR 是团队工作中版本控制的关键元素 — 它不仅仅是合并代码的方式，而是讨论、审查和质量检查的过程。在 GitLab 中，类似的机制称为 Merge Request (MR)，但本质相同：通知团队更改并获得批准。

好的 PR 应该很小（最多 300 行代码），专注于单个任务，并包含已完成工作和原因的描述。根据 Google 研究（2025），超过 400 行的 PR 审查时间延长一倍，检测错误的概率降低 30%。代码审查（Code Review）是合并前由其他开发者检查代码。

在 IT Sectr，我们对每个 PR 进行强制性的代码审查。这不仅提高了代码质量，还有助于在团队内部分享知识。代码审查检查：代码是否遵循架构原则、是否有错误、是否有足够的测试、变量是否命名正确。所有评论都在 PR 中讨论，直到合并。

平台：GitHub、GitLab、Bitbucket

Git 是一种协议，但协作需要一个版本控制平台，提供 Web 界面、访问管理、CI/CD 和审查工具。三个平台主导市场：GitHub、GitLab 和 Bitbucket。

GitHub 是最大的平台，拥有超过 5600 万开发者。归 Microsoft 所有，提供 Actions (CI/CD)、Pages（托管）、Discussions 和 Copilot。免费计划包括最多 3 人团队的无限私有仓库。GitHub 在开源社区中很受欢迎。

GitLab 是一个完整的 DevOps 平台，具有集成的 CI/CD、容器注册表和基础设施管理。与 GitHub 不同，GitLab 可以安装在您自己的服务器上（Self-Managed）。Atlassian 的 Bitbucket 与 Jira 和 Confluence 紧密集成，使其成为已使用 Atlassian 生态系统的团队的选择。