企业官网建设流程全解析

入行那年我还在用最原始的方式提交代码，所有改动全挤在 master 分支上，线上出问题时直接回滚，然后加班到凌晨去追那几行到底是谁写坏的。直到有一次误把半成品 merge 到了线上版本，被部门前辈叫过去对着屏幕讲了一遍分支管理，我才知道自己过去一年都在用最危险的方式写代码。那套 Git 分支管理的方法论，我后来换了两家公司，从小团队到几十人的技术部，一直沿用到现在，只是在此基础上做了些场景化的扩展。

这篇东西不是教科书式的科普，而是结合我自己踩过的坑、看别人踩过的坑，整理出来的一套真正能落地的 Git 分支管理方案。内容包括：为什么必须要做分支隔离、最稳的 master/dev/feature/hotfix 四类分支怎么配合、Windows 环境下从安装到配置的完整步骤、以及我这些年最常遇到的分支混乱场景和对应解法。无论你是刚入行的新人，还是被分支搞得焦头烂额的团队负责人，都能从这里找到可以直接抄作业的做法。

1. 内容整体设计与思路拆解

1.1 分支管理要解决的核心问题是什么

很多人刚接触 Git 时觉得分支不过是个“代码副本”，想开就开，想删就删，没什么技术含量。但真正进入团队协作、尤其是进入需要持续发布的生产环境后，分支管理本质上是在解决三个问题：隔离风险、并行协作、版本追溯。

隔离风险是第一位。没有分支隔离的团队，所有人挤在同一个分支上提交，集成问题会频繁爆发。你今天下午提交了一个半成品函数，同事下班前拉代码，整个系统跑不起来了，这种互相“投毒”的经历我见过太多。有了独立分支后，每个人的半成品代码都留在自己的空间里，不影响别人，也不会污染稳定版本。

并行协作是第二层需求。业务需求永远是一波接一波的，A 组在做订单模块重构，B 组在修支付超时的 Bug，C 组可能还在做新活动的页面开发。如果没有分支把他们隔开，代码合并时的冲突会让你怀疑人生。分支就像车间里的独立工位，每个人在自己的工位上作业，最后把成品交给组装线就好。

版本追溯则体现在线上出问题时。没有分支管理的项目，出问题后你根本不知道当前线上跑的是哪一版代码，最近改了什么，是哪次提交引入的故障。有了清晰的分支命名和合并记录，每一行代码都能追溯到具体的需求、具体的提交人和具体的提交时间，这个能力在生产事故处理中是救命稻草。

1.2 为什么我推荐“重策略、轻工具”的路线

现在的 Git 图形化工具做得已经非常成熟，SourceTree、Tower、GitKraken 甚至 IDE 自带的 Git 面板，可视化程度都很高。但我在实际带团队时发现一个现象：工具用得很溜的人，分支策略往往一团糟。原因是大部分人只把图形界面当作“点击操作面板”，并没有在脑子里建立起分支流动的模型。

我自己的做法是，先把策略定清楚，再去想用什么工具。策略解决的是“代码怎么流动、谁有权合到哪里”的问题，工具只是执行策略的手段。用命令行还是图形界面，这点反而不重要。你如果理解了分支流动的逻辑，用命令行操作和用鼠标点按钮，结果是一样的；如果没理解逻辑，用再高级的工具也只是在更快地制造混乱。

这套策略我在不同规模团队里验证下来的核心就一句话：两条长期分支打底，三类短期分支干活。长期分支是 master 和 dev，它们永远存在、职责固定；短期分支按需创建，干完活就合回去然后删掉。这个结构简单、清晰、好执行，团队里就算有完全没接触过 Git 的新人，培训十分钟也能上手。

2. 核心细节解析与实操要点

2.1 四条核心分支的角色定位

先给出一套最常用的分支设计，照着搭就行。

master/main 分支：永远是稳定可发布的状态。这条分支上的代码只能通过合并进入，不能直接提交修改。每次发布上线，打的 tag 都要从这条分支上生成。它代表的是当前生产环境的真实状态，线上是什么代码，master 就该是什么代码。

dev 分支：日常开发集成分支，所有功能开发完成后先合并到这里。dev 分支上的代码可以是不稳定的，允许有 Bug，但不能有语法错误或启动失败这类低级问题。它是 QA 测试的主要分支，功能联调、测试用例执行基本都在这里完成。

feature 分支：从 dev 拉出来的功能开发分支，命名规则我习惯用feature/功能描述，比如feature/order-refactor。一个需求一个分支，开发完成、自测通过后再合并回 dev。feature 分支只做纵向开发，不做横向耦合，也就是说一个分支对应一个完整的功能点，不要在开发 A 功能时顺手改 B 模块的代码。

hotfix 分支：从 master 拉出来的紧急修复分支，命名规则是hotfix/问题描述或者hotfix/版本号-修复点。修复完合并回 master 和 dev 两条分支。这是唯一不按正常流程走的情况，因为它处理的是线上正在发生的事故。

这四条分支的流动关系我用了这么多年没变过，你可以理解成一条生产线：feature 是加工车间，产出的零件送进 dev 这个组装车间，组装完成后质检合格，最后进入 master 这个成品仓库。hotfix 则是质检环节发现成品有问题，回厂重修后再重新入库。

2.2 分支保护规则必须提前设置

分支策略光写在文档里没用，必须在 Git 服务端配置强制保护。现在主流的 Git 托管平台都支持分支保护规则，GitLab 和 Gitea 都有内置支持，GitHub 的对应功能叫 Branch protection rules，阿里云效、腾讯工蜂这类国内平台也都有类似能力。

我对 master 分支的保护规则一般定三条：第一，禁止任何人直接 push，所有改动必须通过 Pull Request / Merge Request 合入；第二，合并前必须至少一人 review 通过，重要项目我会要求两个人；第三，合并前检查 CI/CD 流水线必须通过。dev 分支的保护规则相对宽松，允许直接 push，但建议也开启合并请求模式，方便追踪问题来源。

这三条规则看起来简单，但能解决掉 90% 的分支污染问题。我见过不少团队，策略文档写了一大本，但没有任何强制手段，结果还是有人嫌麻烦直接往 master 上推代码。人是不靠谱的，只有规则是靠谱的，宁可前期配置多花半小时，也别拿线上稳定性去赌每个人的自觉性。

2.3 合并策略怎么选：merge、squash 还是 rebase

关于合并方式，团队里永远有争论：是保持完整提交历史用 merge，还是压缩成一条干净记录用 squash，又或者用 rebase 把提交历史整理成直线。我的选择方式很简单：按分支类型区分使用。

feature 分支合并到 dev，用 squash。这么做的好处是 dev 的历史一目了然，每个功能对应一条提交记录，出了问题方便定位回滚。feature 分支上那些“写了一半”“改了个变量名”“修复 lint 报错”之类的中间提交，对主线来说都是噪音，没必要保留。

hotfix 分支合并到 master，用 merge 并保留合并提交。因为 hotfix 是紧急修复，保留原始的提交记录有助于事后复盘，看清楚当时具体改了什么，这个信息在事故处理中很有价值。

dev 合并到 master，这个操作团队里一般不是频繁发生的，它代表一个迭代周期的结束，用 merge 生成一个合并节点，标记一个版本周期的完成。

rebase 我个人的使用场景比较少，主要用在个人开发分支同步主分支最新代码时。比如你的 feature 分支开发了很久，dev 上已经合入了别人的代码，你想在自己的分支上让代码保持最新，可以用git rebase dev把改动垫到最新代码之上。但是有一点要保持清醒：rebase 会重写提交历史，多人协作的分支上严禁使用，否则会搞得大家本地和远端对不上。

2.4 分支命名规范和提交信息规范

这点看起来是表面功夫，但经历过的人都知道关键时候有多救命。我见过一次严重的线上回滚事故，肇事提交的信息是“fix bug”，所有人都不知道改了什么，最后是逐个看 diff 才找到问题点。

分支命名必须让人一眼看出在干什么。我常用的几类前缀是这样的：feature/开头的是新功能开发，bugfix/开头的是常规缺陷修复，hotfix/开头的是线上紧急修复，release/开头的是发版准备分支，docs/开头的是文档更新。每个前缀后面跟简短描述，用短横线连接单词，不要用空格。

提交信息我要求遵循简单的三段式结构：标题 + 空行 + 正文说明。标题不超过五十个字，说明这个改动做了什么；正文写清楚为什么做、影响范围、是否需要同步变更。格式是type(scope): subject，type 用 feat、fix、refactor、docs、style、chore 这类约定俗成的词。这套提交规范还有一个衍生好处，就是可以自动生成变更日志，后续做版本发布说明会省很多功夫。

3. 实操过程与核心环节实现

3.1 环境准备：Windows 下 Git 的安装与配置

Git 的分支管理跑在 Git 之上，那先解决环境问题。网上搜 Git 相关的内容，搜索量最大的就是安装教程，可见这块对新手来说确实有门槛。我以 Windows 环境为例，完整过一遍从下载到配置的过程。

第一步，去 Git 官网下载 Windows 版本，对应 64 位系统直接选 64-bit 版本就行。下载后运行安装包，安装过程中有几个关键选项需要注意。

组件选择阶段，默认勾选的项目可以保留，但建议额外勾上“Git Bash Here”和“Git GUI Here”，这样右键菜单里能快速打开命令行工具，非常方便。

默认编辑器选择，我建议选 Visual Studio Code 或其他你日常在用的编辑器，如果用默认的 Vim，新手很容易卡在提交信息编辑界面出不来。

PATH 环境变量配置，这一步有两种做法：选中间项“Git from the command line and also from 3rd-party software”比较稳妥，这样 Git 命令可以在 PowerShell、CMD 和 Git Bash 里通用；如果你追求后台进程直接调用 Git，可以选最下面一项，但一般没必要。选“Use bundled OpenSSH”保持默认即可。

行尾符转换配置，这步对中文环境尤其重要。推荐选第一个“Checkout Windows-style, commit Unix-style line endings”。Git 会在检出时把换行符转成 Windows 的 CRLF，提交时转成 Unix 的 LF，避免因为换行符不同导致整个文件被标记为改动。如果你已经在团队里，需要统一这个设置，宁可多花时间也不要让换行符问题隔三岔五来找你。

安装完成后，打开 Git Bash，先验证安装是否成功。

git --version

能输出版本号就说明安装完成了。接着配置全局身份信息，这一步必须做，否则提交代码时会报错，而且提交记录里没有正确作者信息的话，后续追溯问题会非常痛苦。

git config --global user.name "Your Name" git config --global user.email "your_email@example.com"

这里注意，邮箱最好用公司统一的企业邮箱或者 GitHub 上绑定过的邮箱，这样提交记录上能对应到人。如果公司有代码托管平台，一般平台和 Git 之间是关联关系，提交邮箱和平台账号邮箱一致的时候，提交记录才会自动关联到你的账号头像。

还需要配置一下默认分支名。新版本 Git 安装后的默认分支可能是 master，也可能是 main，不同版本之间有差异。我在团队中为了统一，一般会在安装后执行一次这个命令：

git config --global init.defaultBranch main

这条命令让以后新建仓库时默认分支是 main，而不是 master，避免不同开发者的仓库默认分支名不统一导致混乱。当然如果你所在团队的历史仓库都用 master，就不要改这个配置，跟着团队现有的习惯走，一致比正确更重要。

最后建议配置 SSH 密钥。很多平台现在虽然支持 HTTPS 方式推送代码，但每次都要输密码实在影响体验。用 SSH 的话，一次性配置完一劳永逸。

ssh-keygen -t ed25519 -C "your_email@example.com"

一直回车生成到默认目录后，把公钥内容复制出来，粘贴到 Git 平台的 SSH Keys 设置里就可以了。公钥文件一般是~/.ssh/id_ed25519.pub，用 cat 命令直接查看内容后复制。

cat ~/.ssh/id_ed25519.pub

3.2 从零开始部署一套分支工作流

现在模拟一个真实场景：你入职到一家新公司，技术负责人说“你来给团队搭一套分支管理流程”，那我会按下面的顺序操作。

第一步，初始化仓库或确认远端仓库状态。克隆远端仓库下来，然后确认当前分支和远端追踪关系：

git clone git@github.com:your_team/project.git cd project git branch -a git remote -v

第二步，检查仓库是否已有 dev 分支。如果没有，就基于 master 创建并推送到远端：

git checkout -b dev git push origin dev

创建完 dev 后，去平台端设置分支保护规则。以 GitLab 为例，在 Settings → Repository → Protected Branches 里把 master 和 dev 都加进去，指定允许合并的角色为 Developer 以上，允许推送的权限 master 设为 None（即禁止直接 push），dev 设为 Developer 以上。这样一来，团队所有成员的代码都不能直接推到 master 分支上。

第三步，建立团队规范文档。我不会一上来就写几十页的 Git 手册，一般就两页 A4 纸的内容：分支类型和命名规则、合并流程和权限说明、常用的命令速查表。文档建好后放进仓库的 docs 目录，并在 README 里加上链接。

第四步，团队培训。前面搭好的制度如果没有培训落地，一周后就会有人破坏规则。我会花半小时给团队过一遍完整的操作流：从 dev 拉 feature 分支、在 feature 上开发提交、推送到远端发起 Merge Request、code review 通过后合并回 dev，这一套流程让每个人当场动手走一遍。

在推进过程中，注意团队的习惯差异。比如有人喜欢在提交信息里写中文，有人习惯英文；有人喜欢每个小改动都 commit，有人攒一个大 commit。我的建议是，提交信息的语言不做强制要求，但提交频率上，尽量保持逻辑独立、粒度适中，不要一个 commit 里又改需求又修 Bug，也不要一个需求写二十个碎得不能再碎的 commit，方便 review 也方便回滚。

3.3 日常开发完整操作流演示

下面用一套日常开发的操作流程演示给大家看。假设当前我在 dev 分支上，产品提了一个“用户积分商城”的新需求。

首先同步远端最新的 dev 代码：

git checkout dev git pull origin dev

从最新的 dev 拉出功能分支：

git checkout -b feature/points-mall

开发过程中的提交就正常写，比如完成了商品列表接口，就提交一次：

git add . git commit -m "feat(points-mall): add product list api"

如果开发过程中有其他功能合并到了 dev，我需要在本地同步对方的改动。用 rebase 还是 merge，根据团队约定走。我团队的习惯是用 rebase：

git fetch origin dev git rebase origin/dev

开发完成后，推送分支到远端：

git push origin feature/points-mall

然后在平台创建 Merge Request，源分支选 feature/points-mall，目标分支选 dev，填写描述信息。描述里我会写明关联的需求链接、改动说明、影响范围、测试情况，这样 reviewer 能快速了解改动背景。

合并连带清理：MR 合并后把远端分支和本地分支都删掉：

git branch -d feature/points-mall git push origin --delete feature/points-mall

这里有一个细节要注意：git branch -d只能删除已合并的分支，如果分支上有未合并的改动，会删除失败，这是 Git 的保护机制。如果确实想强制删除未合并的分支，用-D参数，但这条命令会丢掉所有未合并提交，操作前务必确认没有需要保留的东西。

3.4 发版流程与 hotfix 处理实录

发版时我的做法是：当 dev 分支测试通过，准备发布新版本，从 dev 拉一个 release 分支，冻结功能开发，只做缺陷修复和版本号修改。release 分支命名带上版本号，比如release/v1.2.0。

为什么不是直接从 dev 发版？因为从 dev 合到 master 这个过程需要稳定冻结的条件，如果不切 release 分支，测试过程中发现的问题修复提交会和其他新功能开发混在一起，造成版本内容不纯粹。release 分支解决的是“最后一公里”的版本收敛问题，它在发布期间替代 dev 成为准生产分支。

release 分支验证通过后合并到 master 并打 tag：

git checkout master git pull origin master git merge --no-ff release/v1.2.0 git tag -a v1.2.0 -m "release: version 1.2.0" git push origin master --tags

同时把 release 分支合并回 dev，保证 dev 包含版本号修改和所有修复：

git checkout dev git merge release/v1.2.0 git push origin dev git branch -d release/v1.2.0

线上突发事故是最能检验流程的时刻。有一次我们的支付模块线上报错，用户下单被卡住，需要紧急修复。这时候不用走完整的开发流程，直接从 master 拉 hotfix 分支：

git checkout master git pull origin master git checkout -b hotfix/payment-timeout

修复完成后先合并回 master：

git checkout master git merge --no-ff hotfix/payment-timeout git tag -a v1.2.1 -m "hotfix: fix payment timeout issue" git push origin master --tags

再把修复同步到 dev：

git checkout dev git merge --no-ff hotfix/payment-timeout git push origin dev

注意这个顺序是有讲究的：先发布修复（master），再同步到 dev。如果反过来，dev 里的新功能还没经过完整测试，可能无法立即发版，线上等待时间就拉长了。这里核心是保住线上稳定，这是第一优先级。

3.5 团队协作中的 code review 要点

分支管理最终的落地环节是 code review。我这边要求所有合并到 master 和 dev 的代码都必须经过至少一个人 review，重要模块必须两个人以上，这个要求在分支保护规则里已经通过平台配置强制落地了。

review 时我看几个点：改动是否在分支描述声明的范围内、是否存在无关的杂项改动、命名是否清晰规范、是否有明显缺陷或安全隐患、是否有单元测试覆盖。如果发现无关改动，我会直接打回：一个 MR 只做一件事，这是分支管理的基础逻辑，否则后续定位问题又要靠脑补。

好的 review 文化需要培养，核心是就事论事，不要针对人。我给团队里定的调子是：review 里看到问题是为了让代码更好，不是评价能力。新人感受到这一点后，会越来越愿意主动发起 MR，而不是因为怕被挑刺就闷着头在一个分支上写一个月。

4. 常见问题与排查技巧实录

4.1 分支删了代码不见了怎么办

最典型的操作场景：一个人在某分支上工作了一段时间，但忘了合并，后来分支被清理掉了。或者强制删除了有未合并提交的分支，代码找不到了。这时的第一反应是不要慌，Git 的设计给了我们安全网。

先看是不是真的删没了。Git 对未合并的分支删除有保护机制，用-d删不掉，只有-D能强制删。如果是这种情况，你还有最后一根救命稻草：reflog 操作日志。

git reflog

执行后能看到本地的所有 Git 操作记录，包括每次 checkout、commit、merge、reset 的 HEAD 变化。找到分支删除前最后一次指向的 commit 哈希，通过这个哈希就能恢复分支。比如我看到最后一步是3f4a2b1 HEAD@{2}: checkout: moving from feature/api-refactor to dev，那这个 3f4a2b1 就是 feature 分支的最后提交。

git branch feature/api-refactor 3f4a2b1

在 reflog 追加记录时会自动保留以前的操作，大多数情况下能找回；但如果过了太长时间、系统自动清理了 reflog，那可能就找不回来了。所以 Git 的安全底线是：提交过的代码有迹可循，但没提交到仓库的改动只能听天由命。

4.2 分支冲突的处理思路

在团队协作中，代码冲突是不可避免的。很多新人看到冲突提示就紧张，生怕手一抖搞坏代码，实际上冲突处理是有固定套路的。

Git 生态中的冲突标识分两类：一类是内容冲突，同一文件的同一区域被不同人改过；另一类是逻辑冲突，代码能合并但运行时会出问题。合并时提示的冲突是第一种，相对好解决。解决流程是：打开冲突文件，搜索<<<<<<<标记，一段一段地看两边代码，保留想要的部分，删掉标记符号，保存文件后执行git add，最后git commit完成合并。

逻辑冲突排查相对麻烦，常见的情况是：A 把变量名从orderStatus改成了orderState，同时改了内部逻辑；B 也改了orderStatus相关的其他逻辑代码，Git 合并时语法没冲突，代码能跑，但结果不对。这种只能靠编译、测试和人工 review 来发现。经验是：在 dev 分支上的功能合并最好及时，拖得越久，逻辑冲突排查的成本就越高。

4.3 误提交到 master 或 dev 怎么办

即使制定了规则，总会有人误操作。比如不小心把只开发到一半的代码直接推到了 dev 分支，或者有人绕过保护规则误合了不该合的内容。处理思路根据影响范围分几种情况。

如果错误提交只是在本地的 dev，还没有 push 到远端，使用 reset 即可：

git reset --hard HEAD~1

这个命令会把 HEAD 指向上一个提交，同时工作区和暂存区都回到上一个提交的状态。注意它是破坏性的，本地未提交的改动也会一并丢失，使用前确认没有想留的东西。

如果错误提交已经 push 到了远端 dev，并且影响到了其他人的开发，那么用 revert 生成一个反向提交更安全：

git revert HEAD

这个命令会新生成一个提交，把指定提交的改动在内容上反转回去，而且能在提交历史中留下清晰的恢复记录。相比于 reset 后在远端强推（force push），revert 不会改写已经共享的历史，不会导致其他人在下次 pull 时出现莫名其妙的基线错乱。对于 dev 这类协作分支，我的原则是：能 revert 就不要 reset。

4.4 常见 Git 操作速查表

这些命令是我日常使用频率最高的，整理成表格方便查阅。很多人喜欢用图形界面就觉得自己不需要掌握命令，但使用命令行在遇到复杂情况时，理解程度和排查能力会明显更有优势。

4.5 我在实际项目里踩过的坑

要分享的坑不是从文档里看来的，基本都是用真实代价换来的。第一次搞砸是大四实习时，我直接在 master 上开发，项目上线前一天发现需求理解错了，重写代码时改乱了原有功能，最后整个版本延期。那次之后我才彻底理解分支隔离的价值。进入团队后我也亲眼见过同事在 dev 上直接改了线上 Bug，结果下次发版时这个修复被合到其它版本里反复回滚，最后花了三个小时才定位到问题。

另外一个实际工作中踩过的坑是自动化发布流程与分支策略脱节。团队之前用 Jenkins 自动构建，触发条件设置为“提交到 dev 分支自动构建测试环境”，有一段时间不停有同事反馈测试环境不稳定，结果查下来是因为有人在自己改错代码时把半成品推到 dev，触发构建后大家用的都是坏包。解决办法是给 dev 加分支保护规则，合并须过 MR，同时在构建流程上改为 MR 合并后触发，而不是 push 触发，从机制上规避误操作。

回滚的教训也值得一说：有一次发版到生产后发现数据迁移脚本有严重问题，需要在发布系统不能立即回滚的情况下，先在代码层快速修复。当时因为团队把版本回滚和代码回滚混在一起处理，导致线上数据不一致，整个团队熬夜排查。正确的做法是代码回滚和数据库迁移是两条链路，代码回滚应该快，数据库迁移的错误需要单独评估回滚方案，不能误操作一起回滚，否则越回滚问题越多。

分支管理的落地从来不靠某一次操作，而是靠持续的习惯和制度。每次多问一句“我这个改动应该从哪个分支拉”“合到哪个分支去”，长期坚持下来，团队协作的质量就拉开了差距。

5. 一条让自己少走弯路的分支管理心法

写到这里聊点跟工具无关的东西。我这些年做过的项目多了，发现一个很有意思的现象：分支管理的好与坏，跟团队规模、技术栈、项目复杂度都没有必然关系，而是取决于团队里有没有一套“大家都遵守且能执行的约定”。

工具层面，Git 本身非常灵活，几乎能做到你想做的任何事。但如果使用者没有共同的目标，这个灵活性就是混乱的源头。每个人按自己的习惯开分支、合并、提交，Git 既能支持你，也能让项目变得不可维护。我见过有的团队三四个人做一个小项目，master 上却有二十多个平行的长期分支，没人说得清它们各自的功能和现状。这种状态不是工具问题，是协作方式问题。

所以我一直认为，分支管理本质上是一套代码协作的规则。规则的价值不在于“规定人怎么操作”，而在于“让所有人都按同一个预期推进”。有了这套预期，每个人看到分支名就知道它在干什么，看到合并记录就知道这个功能曾经怎么进来的，看到冲突提示就知道该找谁一起解决，团队协作效率和稳定性才有保障。

这想必也是标题里“入行时学到的，我一直用到现在”的真正原因——工具会迭代、平台会更换、团队会流动，但围绕一套清晰的协作规则的自觉，是可以跨越时间和团队迁移的资产。我自己后来换工作、搭团队时，第一件事永远是先跟团队对齐这套规则，然后才谈业务和技术选型。因为一套跑顺的分支管理，救过我的发布日、加过我的班，也逐步塑造了我对代码协作这件事的基本判断。

希望这篇内容对你有实在的帮助。如果你在配置过程中遇到问题，可以在评论区聊具体报错信息，我看到了都会尽量回复。