企业官网建设流程全解析

先说一个很多人在企业里写 git 提交流程时最容易踩的坑：你以为是学命令，其实是在学规则。

我在不同规模的公司都待过，从十几个人的创业团队到几百人的研发部门，git 的用法完全不是一个量级。个人项目里你可以随便 commit、随便 push、不满意就 reset，但在企业里，你动任何一个操作，影响的都不是你一个人。你的一次强推、一次错误 merge、一次没写清楚的 commit message，轻则让别人拉代码冲突，重则把 dev 分支搞崩，然后测试环境、预发环境全部跟着遭殃。

这篇文章我想站在一个老员工的角度，把这几年在企业里实际跑通的 git 使用流程完整地捋一遍。不会只讲命令怎么敲，更多是告诉你为什么要这么用、在什么场景用什么策略、怎么避免那些让人想骂人的操作。新人照着做，至少不会因为 git 操作被同事拉黑。

1. 先把环境配好，别让低级问题浪费大家时间

很多人在公司里遇到的第一批 git 问题，根本不是不会用命令，而是环境没配好。比如提交人的名字显示成一堆乱码、拉下来的文件行尾符不对导致整个 diff 全是红的、明明配了 SSH key 却一直要输密码。这些问题看着小，但在企业协作里非常致命，因为一旦发生在你身上，你给团队带来的是一次次无意义的代码冲突和无效的审查时间。

1.1 用户信息配置：不要忽略全局配置的作用

入职新公司配新电脑，第一件事永远是设置 git 的用户名和邮箱。这个不能随便取，也不能用个人的昵称，因为公司的代码审查系统、CI 流程、自动生成 changelog 的工具，全靠提交记录里的 author 信息来关联到具体的人。用个人邮箱提交的代码，出了问题追溯不到人，审查也匹配不上。

设置方法很简单：

git config --global user.name "你的姓名拼音" git config --global user.email "你的企业邮箱@company.com"

这里有个细节，--global参数表示配置对当前用户下的所有仓库生效。如果你在自己的个人电脑上做开源项目、或者私活，用全局的姓名邮箱没毛病。但在公司的电脑上，我建议除了设置全局的之外，再用公司的项目仓库覆盖一层局部的，防止在多个项目之间切换时提交信息混乱。

等你确定好了自己的身份之后，可以在项目的根目录执行下面的命令确认当前生效的配置：

git config user.name git config user.email

企业里面一个人名下挂在多个 git 账号的情况也常见。碰到这种情况，用局部配置的方式是更稳妥的：在某个仓库目录下不添加--global，单独为这个仓库设置专用的身份信息。这样即使全局配置用错了，仓库一级的局部配置也能覆盖掉。

1.2 SSH Key 配置：一次配置，长期受益

公司的代码仓库一般不走 HTTPS，跑的都是 SSH 协议。很多新人入职之后问的第一句话就是“为什么我每次 push 都要输密码”，原因很简单：你压根没有把本机的公钥加到代码托管平台的账号里。

生成公钥的方式：

ssh-keygen -t ed25519 -C "你的企业邮箱"

连续回车之后，在~/.ssh/目录下会生成一对密钥文件，一个叫id_ed25519（私钥），一个叫id_ed25519.pub（公钥）。把公钥的内容复制到 git 托管平台的 SSH Keys 设置里，之后的所有 push、pull 操作就不会再要密码了。

我看到很多教程推荐用 RSA 2048 位，但放在企业场景下，我更推荐 ed25519。它更短、更快、安全性更高，主流的 git 平台早就全支持了。除非你所在的公司的内部 GitLab 版本老到不支持，否则无脑用 ed25519 就行。

配置完公钥之后，可以用下面的命令测试是不是通了：

ssh -T git@你的git服务器地址

看到Welcome to GitLab或者类似类似Hi xxx! You've successfully authenticated的输出，就说明通了。

这里有个很容易被忽略的坑：公司给的电脑上可能装了多个 Git 客户端，比如 Git Bash、Sourcetree、VS Code 内置终端。它们的 SSH 配置路径可能不一样，公钥配完之后发现只有某个终端有效，其他终端依然要输密码。这种情况多半是终端里设置的HOME环境变量不一致。可以在出问题的终端里执行echo $HOME看一下实际读取的~/.ssh/是哪个目录，确认公钥真实落在该目录下。

1.3 行尾符配置与编码规范：把团队差异扼杀在配置里

公司团队通常是多系统混用的，Windows、macOS、Linux 的开发者都有。Unix 系统用的行尾符是 LF（换行），Windows 用的却是 CRLF（回车+换行）。如果你不做任何配置，提交到远程的代码会在行尾符上反复横跳，最终的结果就是：明明只改了一行代码，整个文件的 diff 全部显示为修改。

解决方案是提交前统一配置 core.autocrlf：

• Windows 上执行：git config --global core.autocrlf true
• macOS/Linux 上执行：git config --global core.autocrlf input

对应的原理是，Windows 上检出代码时自动把 LF 转成 CRLF，提交代码时把 CRLF 转回 LF；Unix 系统检出时保持 LF，提交时保持 LF。这样所有提交到远程仓库的代码，统一使用 LF，换行差异就被自动屏蔽了。

在此基础上，强烈建议团队在仓库根目录放一个.gitattributes文件，按文件类型强制指定行尾符：

* text=auto *.js text eol=lf *.ts text eol=lf *.json text eol=lf *.md text eol=lf

.gitattributes是仓库级别的配置，只要提交到远程，团队所有人拉下来都会生效，比每个人手动设置core.autocrlf靠谱得多。

2. 企业分支模型：分支怎么建，直接决定你的代码会不会出事

个人开发也好、小团队两三个人也好，直接在master或main上提交可能根本感觉不到有什么问题。但企业项目一旦到了几十人协作的规模，没有一套分支规范，代码迟早要乱。我在实际带项目的过程中，见过太多因为乱建分支导致的合并事故。

2.1 企业里最常见的主干开发分支模型

目前国内互联网公司用的最多的，是一套非常简单的模型：master作为的主干分支，始终保持可发布状态；develop作为集成分支，日常开发的功能分支合并到这里；功能分支从develop拉出，完成后合并回develop；发布时从master拉一个release分支做最后的测试和修复，验证通过后合并回master并打 tag。

这套模型的优点是简单、直观、覆盖大部门场景。缺点是如果你的项目迭代节奏特别快，develop分支会经常处于不稳定状态。很多公司为了规避这个问题，干脆直接砍掉develop，让每个功能分支直接从master拉出，合并时通过 MR（Merge Request）做评审，评审通过后直接合回master。

还有一类公司采用 trunk-based development 的做法，所有开发人员直接在一个共享的主干分支上协作，通过小的、频繁的提交来避免长命功能分支带来的合并地狱。这对团队的纪律性要求极高，一般在坚决践行持续集成的团队里才会见到。

对于大多数读者来说，我建议你先把下面这套最主流的规则跑明白：

这个表是给团队定的规矩，照做就不会出大乱子。

2.2 功能分支的生命周期与管理技巧

功能分支的命名里面有大学问。我在有的公司里见过不少人随手创建一个分支叫fix、test、123，这种名字过一周你自己都不知道这是干什么的，更别说别人了。

功能分支的标准做法是：用类型前缀加需求描述。比如你要开发一个“个人中心优化”的需求，分支名就是feature/profile-optimization。如果公司接入了项目管理工具，通常会把 Jira 或者 Tapd 的单号加进去，形如feature/PROJ-123-profile-optimization。等到代码审查和问题追溯的时候，一看分支名就知道是哪个需求、哪张单子。

分支创建之后，日常操作就在这个分支上提交。你需要注意一个时间点：功能分支在本地待到什么时候该推到远程？我的建议是，任何时候都可以推。哪怕代码没写完，推到远程也不丢人。关键是不要让功能分支的代码在本地存太久，否则一次电脑故障，几天的工作全部白费。推到远程还有一个好处：别人可以提前看到代码，有问题及时纠正，不用等到最后合并的时候才发现方向错了。

功能开发完成、自测通过后，先在本地把 develop 最新的代码合进来，解决完冲突，再推到远程，发起合并请求。这条流程后面单独展开讲。

2.3 分支保护：不靠自觉，靠规则

在企业里不要让每个人都拥有向主干分支直接提交的权限。做代码管理和分支保护不是不信任同事，而是为了把“人犯错”的可能性降到最低。代码托管平台（GitLab、GitHub、Gitee）都支持分支保护规则，一般建议至少保护master分支和develop分支。

受保护的分支通常会有这些限制：

• 不允许直接 push，只能通过合并请求合并
• 合并请求必须有至少一个 Reviewer 批准
• 合并前必须通过 CI 检查
• 不允许强制推送

这四条规定能拦住 90% 以上的低级事故。趁早养成通过 MR/PR 合代码的习惯，后面受益无穷。

3. 写一封让人不想骂人的 Commit Message

如果你接管过一个没有任何提交规范的历史仓库，打开git log，看到的全是一堆update、fix、修改、test，还会看到直接把没删干净的调试代码提交上去的记录，内心绝对是崩溃的。commit message 在企业里不是一个点击就完事的动作，它是团队协作和代码审查的基础。

3.1 为什么 Commit Message 比你想的重要

假设你们团队的代码出了线上故障，你需要在十分钟内定位到是哪一次提交把问题引入的。这时候如果你的提交信息写着“修改了一个问题”，你只能一个一个代码 diff 去看。但如果你写的是“修复订单超时导致重复支付的问题”，看到提交信息的一瞬间，你就能判断这次提交是否和当前故障相关。

Commit message 还承担着自动生成 changelog、关联需求单号、方便代码回滚的功能。很多公司的发布系统会根据 commit message 自动生成发布说明，你乱写直接影响的就是你们的发布效率和追溯能力。

我见过一些团队连 commit 内容都不好好的写，一个功能五分钟写完了，commit message 却憋了十分钟，最后写了一句“啊啊啊终于搞定了”。这种消息毫无信息量，属于典型的负资产。

3.2 一套可以直接照用的提交信息格式

不需要引入复杂的工具，我们团队实际执行的 commit message 格式是这样的：

<type>(<scope>): <subject>

其中 type 表示提交类型，scope 表示影响范围，subject 是简短的描述。常见 type 有以下几种：

• feat: 新功能
• fix: 修复 bug
• docs: 文档变更
• style: 代码格式调整，不影响逻辑
• refactor: 重构代码
• perf: 性能优化
• test: 增加或修改测试
• chore: 构建过程或辅助工具的变动

示例：

git commit -m "feat(订单): 增加超时自动取消功能" git commit -m "fix(支付): 修复回调验签失败导致重复入账的问题"

如果公司的需求管理系统是 Jira 或者 Tapd，通常还要把单号挂上去，方便之后追溯需求来源：

git commit -m "fix(支付): 修复回调验签失败导致重复入账的问题 (#PROJ-123)"

这行消息的含义是：本次提交修复了支付模块的验签问题，问题来源于单号 PROJ-123。之后任何一个人看到这行提交，都能立刻知道目标和来源。

3.3 规范提交的辅助工具与终极原则

手动写规范 commit message 需要自律，但在多人团队里，自律是最靠不住的。最简单的做法是利用 husky 和 commitlint 这类工具，在提交代码的时候自动化检查 commit message 是否符合约定规范。

在 Node 项目里，安装一个 commitlint 的配置并加上 husky 的 pre-commit 钩子，提交时 message 不规范就不允许提交。这能把规范直接变成硬性门槛，而不是靠团队成员之间的互相提醒。

不过工具是次要的，终极原则只有一句话：让别人只看你的 commit message，就能知道你这次提交做了什么、为什么做。满足了这个标准，你这个提交记录就是一个优质的协作资产。如果还做不到，哪怕直接去抄那套<type>(<scope>): <subject>的格式，也比你随意写强一百倍。

有一点特别提醒：不要一个 commit 夹带一堆无关的改动。代码审查时，审查者看到一个提交里既有新功能、又有样式调整、还顺手改了配置，是非常头疼的。一次提交只做一件事，保持原子性。比如你改了 A 功能和 B 的样式，那就拆成两次提交。这样后续项目回溯的时候，能力便定位到精确的代码变化范围。

4. 企业协作流程：从拉代码到合入的全链路实操

环境配好了，分支建好了，提交规范也定好了，接下来就是日常的工作流。很多新人在这一环最容易迷茫，因为频繁的 fetch、pull、rebase、merge 操作，看着每个命令都认识，串在一起就不知道怎么合理用了。

4.1 拉取代码的正确姿势：fetch 和 pull 的区别

先说一个基础概念：git fetch和git pull的区别。

• git fetch只把远程分支的更新下载到本地，但不会自动合并到工作区
• git pull是fetch加merge的组合操作，下载更新并自动合并到当前分支

企业协作中我更推荐的做法是：显式 fetch，看清楚了再决定怎么处理。

比如你正在自己的功能分支上开发，同事刚往 develop 合并了新代码，你想把最新的 develop 合进来。如果你直接git pull origin develop或者git pull，git 会把这个分支的新提交直接 merge 进当前分支。如果本地有未提交的改动，它还会打断你，有时候还会自动产生一个莫名其妙的 merge commit（在 pull 配置为 merge 模式下）。

我推荐的流程是：

# 第一步，把远程最新状态拉下来 git fetch origin # 第二步，查看本地和远程 develop 的差异 git log --oneline develop..origin/develop # 第三步，确认无误后再合并 git merge origin/develop

这有什么好处？好处是你不会在不知情的情况下，把一个别人刚引入的坏代码合并进自己的分支。你先把差异看清楚，判断什么时候合、怎么合，主动权在你手里。

4.2 合并 vs 变基：功能分支要不要用 Rebase

这是个老生常谈但永远有人搞不清的话题。简单说：

• merge会把两个分支的历史合并到一起，产生一个 merge commit，历史会出现分叉
• rebase会把当前分支的提交“重新放到”目标分支的顶端，历史是线性的

在企业里，我见过两种截然不同的态度。有的团队坚决只用 merge，因为简单，不用理解 rebase 的原理；有的团队坚决只用 rebase，因为历史清晰，git log 是一条干净的直线。

我的建议是：功能分支拉基础代码时，用 rebase；功能分支合入主干时，用 merge。

原因很简单。功能分支在自己拉代码的阶段，还没推到远程，或者只有你自己在维护，随便 rebase，把分支上的提交挪到最新的 develop 顶上去，不会影响别人。这个过程能让你的分支始终保持清晰线性。

等开发完成了，要把功能分支合回 develop 时，用 merge 工具产生一个 merge commit，表示“这个功能在这里整体完成”。这样主干上的历史能清晰地看到功能的引入点，方便回滚和追溯。

具体操作：

# 在自己的功能分支上 git checkout feature/profile-optimization # 把 develop 最新的代码 rebase 到当前分支 git fetch origin develop git rebase origin/develop

rebase 遇到冲突时，git 会停在有冲突的提交处，解决完冲突后执行git add，然后git rebase --continue，继续往下走。如果你中途发现 rebase 搞砸了，可以用git rebase --abort一键回到 rebase 之前的状态。

这里有一个关键禁忌：千万不要对已经推送到公共远端的分支作 rebase。因为 rebase 会改变提交的 hash，你推送之后，别人本地基于旧 hash 的提交会全部失效，直接导致一堆冲突。这就是标题说的“挨骂”情形之一。

4.3 代码审查与合并请求（MR/PR）的标准流程

企业里代码合入主干，一定要通过 MR/PR，绕过这个流程直接 push，你就是在给自己和团队埋雷。

标准流程分这几步走：

第一步，确认功能已开发完成、自测通过，本地 test 脚本全部跑绿。

第二步，把远程 develop 最新的代码合并或变基到自己的功能分支，解决完所有冲突。

第三步，把本地功能分支推送到远程：

git push origin feature/profile-optimization

第四步，在代码托管平台发起合并请求，源分支选feature/profile-optimization，目标分支选develop。标题写清楚需求内容，描述里写好改动说明、影响范围、测试情况，还可以关联需求单号。

第五步，等待 Review。审查者提出意见后，你在本地修改，commit 后推送即可。MR 会自动更新。

第六步，MR 通过、CI 通过后，合入 develop。现在主流平台都支持“合并时压缩提交”或者“合并后删除源分支”，建议开启。合入后确认源分支被删除，避免仓库里堆积大量无用的功能分支。

这套流程里有一个容易挨骂的点：发起 MR 前不拉最新的 develop、不看冲突就直接提交。审查者在 MR 里看到几百个冲突文件，你这个 MR 基本是废的。正确的做法是，发 MR 之前，先确认冲突为零，能本地解决的不要在 MR 里体现。

4.4 冲突解决：不要慌，分三步走

冲突是 git 使用中最让人头疼的部分，但也是最能体现基本功的部分。遇到冲突，我总结了一套三步走的思路。

第一步，搞清楚冲突范围。git 会明确告诉你哪些文件冲突了。不要打开一堆文件乱看，先把冲突列表过一遍，判断这是内容冲突还是格式冲突。有时候只是因为行尾符不同导致的伪冲突，那一开始配置好.gitattributes就不会有。

第二步，逐个文件解决冲突。打开冲突文件，里面会有<<<<<<<、=======、>>>>>>>标记。<<<<<<<和=======之间的是当前分支的内容，=======和>>>>>>>之间的是要合并进来的内容。根据业务需求决定保留哪一边，或者同时保留、修改成新内容，然后删除这些标记符号。

第三步，解决完所有冲突后，重新 add 和 commit。merge 冲突解决后直接git commit，rebase 冲突解决后git rebase --continue。

很多团队用可视化的合并工具，比如 VS Code 的源代码管理视图、Beyond Compare、IntelliJ IDEA 自带的合并工具。我个人的经验是：可视化工具只是辅助，你首先得知道冲突产生的原因，否则工具越强大，你改起来越乱。

4.5 发布与回滚：打 Tag 是底线

企业项目发布，不是代码合进 master 就算完事了，还要在合入的位置打上版本标签。tag 的作用是给历史打一个路标：这个提交是 v1.0.0，这个提交是 v1.0.1。出了线上问题，需要回滚，直接根据 tag 切分支就行，比通过时间去翻提交历史靠谱得多。

打 tag 的方式：

git tag -a v1.0.0 -m "Release version 1.0.0" git push origin v1.0.0

推荐使用附注 tag（-a参数），它记录了打 tag 的人、时间、说明，比轻量 tag 信息更完整。

发布之后如果发现严重问题需要回滚，可以直接在当前 master 上还原：

git revert v1.0.0

git revert会生成一个新的提交，把目标提交的改动全部反向应用一遍。它和git reset的本质区别是：revert 不改变历史，适合已经推送到远端的分支；reset会重写历史，只适合在本地操作。

这一条是企业里很多人容易犯的致命错误：发布后发现线上有问题，顺手就git reset --hard <commit>，然后git push -f，把公共分支的历史改得七零八落。如果你的公共分支被保护了，这种操作根本推不上去。即便没推上去自己本地改爽了，下一次 pull 也会把本地弄得一塌糊涂。

5. 常见“挨骂场景”与规避技巧

很多坑只有被骂过才记得住，但我不希望读者真的靠挨骂长记性。下面这些是我总结的、团队里出现频率最高的“危险操作”和对应的规避方案。

5.1 高频翻车场景与应对方式

这些场景里最危险、最容易造成工作成果丢失的是git reset --hard和git push -f的组合操作。强推会直接改变远程分支的历史，其他人只要基于旧历史做过提交，全部会乱套。

5.2 大文件提交事故：后果能有多严重，以及怎么救

有的仓库用了几年之后，clone 下来要花十分钟，体积几个 G。查到最后往往是有人把编译产物、打包资源、数据库备份文件直接提交进去了。这类文件体积大、更新频繁，一旦进入 git 历史，就算后面删掉，它依然存在于历史记录中，永远占据着仓库体积。

处理方式分两级：

第一级是预防。在项目根目录的.gitignore里，提前把依赖目录、构建产物、本地配置文件、IDE 配置全部忽略掉。最基本的忽略清单：

node_modules/ dist/ build/ *.log .env .DS_Store .idea/ .vscode/

第二级是补救。如果不小心把大文件提交到了历史里，并且还没合并到主干，最快的办法是修改提交，把问题文件从提交中移除后重新提交。如果已经混进历史好几版了，就需要借助工具重写历史。

这里有一个更稳妥的思路：遇到历史中被混入的大文件，与其自己折腾 rebase 重写历史，不如直接和团队沟通，约定一个时间点，把当前主干重置到某个干净基线，再让所有人按新基线重新拉分支。因为重写历史的操作会对团队所有人产生影响，涉及协作的动作最好先对齐，不要一个人闷头操作。

5.3 解决“忘切分支就改代码”的标准姿势

很多人应该遇到过这种尴尬：在develop分支上忘了新建功能分支，直接改起了代码。改到一半突然发现不对，但又不敢提交，怕污染公共分支。

正确姿势很简单：

# 把当前未提交的改动暂存起来 git stash # 创建并切换到正确的功能分支 git checkout -b feature/profile-optimization # 把暂存的改动恢复回来 git stash pop

git stash会把工作区中未提交的改动保存到一个临时栈里，切完分支用git stash pop恢复。pop 之后如果有冲突，解决方式和普通的合并冲突一样处理。

这里有个小细节：git stash pop和git stash apply的区别。pop 会应用暂存的改动并从暂存栈中移除；apply 会应用改动但保留暂存内容。日常用 pop 就够，apply 多用于需要同时多处应用同一份暂存的极端场景。

5.4 Reflog：你的救命稻草

很多人在 git 操作失误之后，尤其是不小心执行了git reset --hard，就以为提交永远找不回来了。实际上 git 的 reflog 会记录你本地仓库中的每一次 HEAD 变动。哪怕你“丢”了一个提交，只要它在 reflog 中有记录，就可以找回。

# 查看本地 HEAD 的历史变动 git reflog

输出长这样：

e4f1a2b (HEAD -> feature/xxx) HEAD@{0}: commit: feat(订单): 增加超时自动取消功能

如果你发现当前 HEAD 丢了之前的某次提交，可以直接：

git reset --hard e4f1a2b

当然 reflog 不是万能的，它的记录默认 90 天之后会被清理，而且只对本地操作有效。但作为一道保险，它在关键时刻能救命。我建议每个人至少要知道它的存在。

6. 给新人的几条实际操作建议

除了上面这些流程和规范，还有几条比较零碎但很重要的实操建议。说零碎，是因为它们不构成一个完整章节，但在企业协作中个个关键。

第一条，勤用git status和git log，不要凭感觉操作。每次提交之前git status确认要提交的文件里没有无关内容；每次合并之前git log确认要合并的提交是否符合预期。养成这个习惯，至少能避免一半的低级错误。

第二条，你本地没测试通过的代码，不要往远程推。远程分支是所有协作者共享的，你往远程推垃圾代码，等于把垃圾丢到公共空间。哪怕是在自己的功能分支上，也不建议推无法编译的代码，因为你永远不知道有人会不会手痒帮你进一步处理。

第三条，写清楚 MR 描述。MR 不只是代码分发，它是你写给别人看的沟通文档。改动背景、影响模块、测试方案、有没有破坏性变更，这些信息都在 MR 描述里写清楚，审查的人舒服，你被驳回的概率也小。

第四条，CI 红灯亮了，优先解决，不要直接 merge。在规范的团队里，CI 没通过是不允许合入 MR 的。你见过好多次，已经点下 merge 了，测试才发现编译失败，然后所有人拉下来的 develop 都是坏的。这种情形下，你将赢得全组同事的高度“关注”。

第五条，遇到不确定的命令，先查帮助文档，不要靠猜。你可以随时运行git help <命令>或者git <命令> -h查看完整的选项说明。与其在网络上搜索那些已经过时的教程上的坑，不如直接看 git 自带的文档。

7. 番外：一段标准的日常操作闭环

最后我整理一段最标准的日常操作流程，你可以直接照着做。从你开始接手一个需求，到你的代码成功合入主干，全流程是这样的：

# 确保本地 develop 是最新的 git checkout develop git pull origin develop # 从最新的 develop 拉出功能分支 git checkout -b feature/PROJ-123-profile-optimization # 开发过程中，频繁、小粒度地提交 git status git add 需要提交的文件 git commit -m "feat(个人中心): 增加头像裁剪功能" # 开发完成后，把远端最新的 develop 合入当前功能分支 git fetch origin develop git rebase origin/develop # 处理完 rebase 过程中可能出现的冲突 git add 解决方案的文件 git rebase --continue # 确认一切正常后，推送功能分支到远端 git push origin feature/PROJ-123-profile-optimization # 在代码托管平台发起 MR，目标分支选 develop # 等待 review，根据意见进行修改并重新推送 # 本地确认 MR 已经合并后，切回 develop，拉取最新代码 git checkout develop git pull origin develop # 删除本地已经合并的功能分支 git branch -d feature/PROJ-123-profile-optimization

这套流程写出来，很多人会觉得不就是在重复执行几个基础命令吗。没错，企业里的 git 用得好不好，从来不取决于你掌握了多少冷门命令，而在于你有没有把最基础的流程严格执行的纪律。能力三成，纪律七成。

就拿“删除本地功能分支”这一步来说，多少人的本地堆了几十个已经合并完的分支，自己都分不清哪个还在做、哪个已完成。这就是不遵守流程纪律带来的混乱。

在实际工作里，有些人总喜欢在 git 上搞骚操作，比如用别名定制一堆复杂命令、写脚本自动提交什么的，自己玩得很开心。但在企业协作场景里，我不建议大家把个人的操作习惯强加给别人，尤其是在公共分支上。你的习惯可能是效率，别人的习惯可能就是灾难。把基础流程跑规范，让团队的协作有序推进，比你在终端里秀操作重要得多。

git 这个东西吧，用得越多越能体会到，它本质上是合作契约的工具化。你和同事之间怎么约定分支流程、怎么约定提交规范、怎么约定合并时机，决定了这个工具的最终表现。契约定得好，工具就顺手；契约混乱，命令背得再熟也没用。

希望这篇文章能帮你在团队协作中少踩一些坑，少挨几次骂。如果只能记住一句话，那就记住：在开始任何一个 git 操作之前，先想一想这个操作会不会影响别人。