31.10.2024 更新于：26.06.2026

Linux 虚拟服务器

11 4 min

Git 中的分支工作：开发者完整指南

Git 分支是现代软件开发中最强大的功能之一。它允许你在完全隔离的环境中开发新功能、修复错误和运行实验 — 而无需接触稳定的生产代码库。无论你是独立开发者还是分布式团队的一部分，掌握 Git 分支对于维护清晰、专业的工作流程至关重要。

本综合指南将引导你了解关于 Git 分支的所有内容：从理解核心概念到创建、切换、合并和管理分支，就像高级开发者一样。如果你在具有完全 root 访问权限的 VPS Hosting 环境中运行你的项目，这些工作流程可以无缝集成到你的日常开发流程中。

什么是 Git 分支？

Git 中的分支本质上是指向项目历史中特定提交的轻量级可移动指针。当你初始化一个仓库时，Git 会创建一个默认分支 — 通常称为 main 或 master — 它代表你的主要开发线。

当你创建一个新分支时，你实际上是在创建一条独立的开发线，它从代码库的当前状态分叉出来。在该分支上所做的更改不会影响任何其他分支，除非你明确地合并它们。这种隔离正是分支如此有价值的原因：你的 main 分支保持干净且可部署，而在进行中的工作则安全地存在于其他地方。

可以将分支想象为代码的平行宇宙。每一个都可以独立演进，你可以完全控制它们何时以及如何重新合并。

为什么 Git 分支对您的托管环境很重要

如果您在服务器上部署应用程序 — 无论是 VPS 托管计划还是专用服务器环境 — Git 分支变得更加关键。原因如下：

稳定性：您的生产分支 (main) 始终保持可部署状态。
团队协作：多个开发人员可以同时在独立分支上处理不同功能，而不会相互冲突。
安全实验：您可以在隔离分支上测试风险变更，如果出现问题，只需删除该分支即可。
CI/CD 集成：GitFlow 或基于主干的开发等分支策略与在您的服务器上运行的自动化部署管道完美配合。
回滚能力：如果合并引入了错误，您可以干净地恢复，而不会丢失其他工作。

在具有 NVMe SSD 存储和完全 root 访问权限的服务器上托管 Git 存储库意味着更快的克隆、获取和推送操作 — 这对于处理大型存储库或多个贡献者尤为重要。

第1步：检查现有分支

在创建任何新内容之前，最好先查看存储库中已存在的分支。使用以下命令：

git branch

这列出所有本地分支。当前活动分支用星号突出显示（*）。

要同时查看远程分支，请使用：

git branch -a

仅查看远程分支：

git branch -r

了解现有分支结构可以防止命名冲突，并帮助您在复杂项目中保持方向。

第 2 步：创建新分支

在 Git 中创建新分支有多种方法，具体取决于您的工作流程。

创建分支而不切换到它：

git branch branch_name

将 branch_name 替换为反映分支目的的有意义的名称。例如：

git branch feature/user-authentication

创建分支并立即切换到它（经典方法）：

git checkout -b branch_name

示例：

git checkout -b feature/user-authentication

使用现代 `switch` 命令创建并切换（Git 2.23+）：

git switch -c branch_name

示例：

git switch -c bugfix/login-redirect

引入了 git switch 命令，使分支操作更加直观，比过度使用的 git checkout 命令更清晰。两种方法都可行，但 git switch 是推荐的现代做法。

第 3 步：在分支之间切换

要在现有分支之间移动，您有两个选项：

经典方法：

git checkout branch_name

现代方法（推荐）：

git switch branch_name

示例 — 切换回主分支：

git switch main

重要：在切换分支之前，请确保您的工作目录是干净的。要么提交您的更改，要么使用 git stash 将其存储，否则 Git 可能会拒绝切换或将未提交的更改带入新的分支上下文。

git stash          # Save uncommitted changes temporarily
git switch main    # Switch branch
git stash pop      # Restore your stashed changes later

步骤 4：在分支上进行更改

一旦你在正确的分支上，你的开发工作流程就会正常进行。以下是标准周期：

1. 编辑或创建文件

使用你喜欢的编辑器或 IDE 进行更改。

2. 暂存你的更改

git add filename

或一次性暂存所有修改的文件：

git add .

3. 提交你的更改

git commit -m "Add user authentication module"

编写清晰、描述性的提交消息。好的提交消息解释了什么改变了以及为什么改变 — 而不仅仅是如何改变。当几个月后查看历史记录或为新团队成员提供培训时，这变得非常宝贵。

4. 将你的分支推送到远程仓库

如果你与团队协作或备份到远程服务器：

git push origin branch_name

示例：

git push origin feature/user-authentication

如果这是第一次推送此分支，你可能需要设置上游：

git push --set-upstream origin feature/user-authentication

第 5 步：合并分支

一旦您的功能或修复完成并经过测试，就该将其合并回目标分支了 — 通常是 main 或 develop。

分步合并流程：

1. 切换到目标分支：

git switch main

2. 从远程拉取最新更改（在团队环境中很重要）：

git pull origin main

3. 合并您的功能分支：

git merge feature/user-authentication

如果合并是干净的（没有冲突），Git 将根据分支历史自动创建合并提交或执行快进合并。

快进合并与合并提交

快进合并：当目标分支未从功能分支分叉时发生。Git 只是将指针向前移动。不会创建合并提交。
三向合并：当两个分支都已分叉时发生。Git 创建一个新的合并提交，将两个历史联系在一起。

要始终创建合并提交（对于在项目日志中保留分支历史很有用）：

git merge --no-ff feature/user-authentication

第 6 步：解决合并冲突

当文件中的相同行在两个分支上被以不同方式修改时，就会发生合并冲突。Git 无法自动确定要保留哪个版本，因此它会要求您手动解决冲突。

识别冲突

发生冲突时，Git 将输出类似以下内容：

CONFLICT (content): Merge conflict in src/auth.js
Automatic merge failed; fix conflicts and then commit the result.

冲突在文件中的样子

<<<<<<< HEAD
const loginUrl = '/api/v2/login';
=======
const loginUrl = '/api/v1/login';
>>>>>>> feature/user-authentication

<<<<<<< HEAD 和 ======= 之间的所有内容都是来自您当前分支的版本。
======= 和 >>>>>>> feature/user-authentication 之间的所有内容都是传入的版本。

解决冲突

在编辑器中打开有冲突的文件。
决定保留哪个版本 — 或编写一个结合两者的新版本。
删除所有冲突标记（<<<<<<<、=======、>>>>>>>）。
保存文件。

解决后完成合并

git add src/auth.js
git commit -m "Resolve merge conflict in auth module"

使用合并工具

对于复杂的冲突，可视化合并工具非常有用：

git mergetool

流行的工具包括 VS Code 的内置 diff 编辑器、vimdiff、meld 和 kdiff3。

第 7 步：删除分支

一旦分支已被合并且不再需要，删除它以保持您的存储库整洁和易于导航。

删除本地分支（安全 — 仅在已合并时有效）：

git branch -d branch_name

示例：

git branch -d feature/user-authentication

强制删除分支（即使未合并）：

git branch -D branch_name

谨慎使用 -D — 它会永久丢弃该分支上的任何未合并工作。

删除远程分支：

git push origin --delete branch_name

示例：

git push origin --delete feature/user-authentication

定期清理过时分支可以保持您的存储库井然有序，并防止团队环境中的混淆。

步骤 8：查看分支历史和结构

要获得整个分支和提交历史的可视化概览，请使用：

git log --oneline --graph --decorate --all

这会生成一个紧凑的 ASCII 艺术图，显示：

所有分支中的所有提交
每个分支指针当前所在的位置
合并点和分歧点
标签和 HEAD 位置

示例输出：

* a3f9c12 (HEAD -> main, origin/main) Merge branch 'feature/user-authentication'
|
| * 7b2e441 Add password hashing utility
| * 3d1a908 Create login endpoint
|/
* 9c4f017 Initial project setup

要获得特定分支的更详细视图：

git log branch_name --oneline

要比较两个分支并查看一个分支中存在但另一个分支中不存在的提交：

git log main..feature/user-authentication --oneline

第 9 步：高级分支技术

使用 Rebase 而不是 Merge

Rebase 是 Merge 的替代方案，它重写提交历史以生成更清洁的线性时间线：

git rebase main

这会将你的功能分支提交重新应用到最新的 main 之上，消除合并提交。结果是更清洁的历史记录 — 但永远不要对已推送到共享远程的分支进行 Rebase，因为它会重写历史记录并给协作者造成问题。

Cherry-picking 特定提交

如果你只需要另一个分支中的一个特定提交，而不是合并整个分支：

git cherry-pick commit_hash

这对于直接从开发分支将关键错误修复应用到生产环境而不合并未完成的功能很有用。

跟踪远程分支

要设置跟踪远程分支的本地分支：

git checkout --track origin/branch_name

或使用现代语法：

git switch --track origin/branch_name

Git 分支策略用于生产环境

如果您在Dedicated Servers或 VPS 环境中管理实时应用程序，采用正式的分支策略可以大大提高部署可靠性。

GitFlow

一个结构化的工作流，具有用于功能、发布和修复的专用分支：

main — 仅生产就绪代码
develop — 已完成功能的集成分支
feature/* — 单个功能分支
release/* — 发布准备分支
hotfix/* — 紧急生产修复

基于主干的开发

一种更简单、高速度的方法，所有开发人员频繁提交到 main（”主干”），使用短期功能分支或功能标志来管理未完成的工作。受具有强大 CI/CD 管道的团队青睐。

GitHub Flow

一个轻量级变体：从 main 分支出来，打开拉取请求，审查，合并。对于较小的团队或具有持续部署的项目来说简单有效。

Git 分支管理最佳实践

遵循这些约定将使您的存储库保持整洁、团队保持一致、部署可预测：

1. 使用描述性、结构化的分支名称

采用一致的命名约定，一目了然地传达目的：

类型	示例
功能	`feature/user-authentication`
错误修复	`bugfix/login-redirect-loop`
热修复	`hotfix/payment-gateway-crash`
发布	`release/v2.4.0`
实验	`experiment/graphql-migration`

2. 保持分支生命周期短

分支在未合并的情况下存在的时间越长，与 main 的分歧就越大，痛苦的合并冲突风险就越高。目标是在几天内合并功能分支，而不是几周。

3. 经常早期提交

小的、频繁的提交更容易审查、恢复和理解。避免捆绑数十个不相关更改的大型”包罗万象”提交。

4. 合并前始终拉取

在合并功能分支之前，从 main 拉取最新更改以最小化冲突：

git pull origin main

5. 编写有意义的提交消息

遵循常规提交格式以保持一致性：

feat: add OAuth2 login support
fix: resolve null pointer in user profile loader
docs: update API authentication guide
refactor: simplify database connection pooling

6. 保护您的主分支

在托管 Git 平台（GitHub、GitLab、Gitea）上，配置分支保护规则以要求拉取请求审查才能合并到 main。这可以防止意外直接推送到生产环境。

7. 使用 CI/CD 自动化

将您的 Git 工作流与 CI/CD 管道集成，在每次分支推送时自动运行测试。只有通过所有测试的分支才应该有资格合并。这与正确配置的服务器环境完美配合——如果您托管自己的 Git 服务器或 CI 运行器，带有 root 访问权限的 VPS 托管计划可以让您完全控制管道配置。

在您的服务器上设置私有 Git 存储库

如果您更喜欢自托管 Git 存储库而不是依赖第三方平台，您可以直接在服务器上设置一个裸 Git 存储库。

在服务器上初始化一个裸存储库：

mkdir -p /srv/git/myproject.git
cd /srv/git/myproject.git
git init --bare

从您的本地机器克隆它：

git clone user@yourserver.com:/srv/git/myproject.git

像任何远程一样将分支推送到它：

git push origin feature/new-dashboard

自托管您的 Git 存储库可以让您获得完整的隐私、第三方平台不会施加的存储限制，以及对访问权限的完全控制。将其与 SSL 证书配对以加密开发人员和服务器之间的流量，并考虑设置 SSH 密钥身份验证以实现安全的无密码访问。

对于需要功能完整的 Git 托管界面的团队，可以在您的 VPS 上安装 Gitea 或 GitLab CE 等工具，不到一小时即可完成，为您提供拉取请求、问题跟踪和 CI/CD 管道——全部自托管在您控制的基础设施上。

快速参考：基本 Git 分支命令

任务	命令
列出本地分支	`git branch`
列出所有分支（包括远程）	`git branch -a`
创建新分支	`git branch branch_name`
创建并切换到新分支	`git switch -c branch_name`
切换到现有分支	`git switch branch_name`
将分支合并到当前分支	`git merge branch_name`
使用显式合并提交进行合并	`git merge --no-ff branch_name`
变基到另一个分支	`git rebase main`
删除已合并的本地分支	`git branch -d branch_name`
强制删除本地分支	`git branch -D branch_name`
删除远程分支	`git push origin --delete branch_name`
查看图形化分支历史	`git log --oneline --graph --decorate --all`
暂存未提交的更改	`git stash`
应用暂存的更改	`git stash pop`
精选特定提交	`git cherry-pick commit_hash`

结论

Git 分支不仅仅是一个技术特性 — 它是一种专业纪律，将有组织、可扩展的开发与混乱、脆弱的代码库区分开来。通过掌握本指南中涵盖的命令和策略，您将能够自信地管理复杂项目、与团队成员有效协作，并可预测地进行部署。

需要牢记的关键原则：

隔离工作在专用分支中，始终保护您的 main 分支。
描述性命名分支，使每个协作者都能立即理解其目的。
频繁合并以最小化分歧并降低冲突复杂性。
清理已合并的分支，保持您的存储库易于导航。
自动化测试和部署，通过与您的分支工作流绑定的 CI/CD 管道。

无论您是在构建个人项目还是管理工程师团队，正确的托管基础设施都会产生真实的差异。快速 NVMe 存储加速 Git 操作，root 访问权限让您能够完全按需配置环境，可靠的正常运行时间确保您的存储库始终可访问。探索为开发人员设计的 VPS 托管计划，或升级到专用服务器以满足高需求的团队环境。如果您还在管理与存储库一起的 Web 应用程序，共享 Web 托管为较小的项目提供了经济高效的选择。

您的 Git 工作流仅与支持它的基础设施一样强大 — 确保两者都经久耐用。

所有托管服务节省