企业官网建设流程全解析

1. 为什么我劝你放弃手工备份：Git带来的协作方式变革

我刚开始写代码那阵子，工程目录下面永远躺着一堆“终极版”“最终版2”“再改不改版”之类的压缩包，后来又流行同步网盘，于是又多了一堆命名混乱的文件夹。直到有一次我把项目压缩包覆盖错了版本，凌晨三点对着屏幕找补不回来的时候，才真正下决心把版本控制这件事从头梳理一遍。事实证明，从手写代码备份到分布式协作，中间差的不是工具，而是一整套思维方式的转变。

Git这套东西，表面上是一个安装程序、几条命令行，但真正解决的是两个问题：第一，怎么让代码的历史像时间线一样完整可追溯；第二，怎么让一群人协作的时候互相不踩踏、不覆盖、又不丢失任何人的修改。如果你只是一个人写小项目，Git也能帮你告别“xxx最终版V8.zip”这种原始操作；如果你在团队里，Git就是所有人共同工作的那根安全绳。

这篇文章的目标读者很明确：想系统学会Git的开发者、刚入职还没彻底搞懂分支协作的实习生、以及想从手工备份解脱出来的独立开发者。我会按实际使用场景来写，把安装、配置、常用命令、分支合并、远程协作和真实踩坑都放进来，不讲虚的，全是能在命令行里直接敲出来的东西。

1.1 手工备份最深的坑不是备份本身，而是“回溯能力”缺失

手工备份听起来很简单：复制一份代码、改个名字、存到另一个位置。但真正做过一段时间的人都会发现，这种方式存在几个致命弱点：

• 版本多了以后，你根本记不清某个文件夹和另一份压缩包之间到底差在哪
• 你无法快速回答“上周三提交的那版为什么能跑通，这版为什么挂了”
• 团队合作时，两个人同时改同一个文件，总有一个人的修改会默默丢失

Git的厉害之处，恰恰是把“能跑”进化为“可回溯”。每一次commit都相当于一个快照，并且这个快照不是简单复制一份文件，而是记录整个项目在该时刻的状态。配合diff能力，你可以随时看到两个版本之间的每个字节差异。这才是版本控制的核心价值：它给了你一条完整的时间隧道。

我们经常听到一个比喻：Git像单机游戏里的存档系统，commit就是存档，branch就是不同的游戏分支，merge就是把两个存档合并。这个比喻挺贴切的，但还要补充一点——Git的存档不是存“当前画面”，而是存“从上一关到这个关口的完整变化”，所以它还能在某些情况下帮你重演剧情。理解了这一点，后面学命令就不会只靠背了。

1.2 分布式和集中式的关键差异：你的本地就是一份完整仓库

先理解“分布式”这个概念。老牌的SVN是集中式版本控制，服务器保存唯一一份代码历史，你提交任何东西都要联网。Git则是分布式，每个开发者本地都有一份完整的仓库，包括全部历史记录、全部分支、全部标签。

这里有个很直观的场景：我坐飞机改代码，没法联网，但依然可以在本地正常提交代码、切分支、看历史。落地后一旦连上网，执行一次git push就能把这段飞行期间的所有成果同步到远程。而SVN时代，离线的你可能连svn diff都费劲，因为历史都在服务器上。

分布式还意味着你在GitHub、Gitee、GitLab这些平台上看到的是仓库的远程副本，但真实的开发工作永远不会因为远程服务器挂了就停摆。团队里任何一个人本地都有一份完整备份，这在灾难恢复上的意义非常巨大。

这样说下来，你应该能明白为什么Git已经成为行业默认标准。下面我开始讲从零安装、配置到实际组装的整个过程。

2. 环境安装与初次配置：别让第一步卡住你

安装这件事本身不难，但很多人卡在“装完了却不知道下一步要做什么”这个环节。或者说装是装上了，第一次git commit就因为换行符、用户名没配好之类的问题跑不起来。所以我特意把安装和配置放到一起说，一步到位。

2.1 三大平台安装：Windows、macOS、Linux

Windows平台

目前官方主力安装包是Git for Windows，也就是我们常说的Git Bash。你去官网下载安装以后，开始菜单里会出现Git Bash和Git GUI两个入口。安装过程中有几个选项需要注意：

• 默认编辑器如果你不熟Vim，建议选Notepad++或者VS Code，免得以后进入commit编辑器以后不知道怎么退出
• “Adjusting your PATH environment”选项保持默认的“Git from the command line and also from 3rd-party software”即可
• 行尾转换，我建议Windows用户选择“Checkout Windows-style, commit Unix-style line endings”，这样团队里不同系统的文件不会在每一行上都产生diff

安装Git for Windows时用的协议、HTTPS代理这类选项，保持默认就能跑通日常使用。

macOS平台

macOS系统自带一个古老版本的Git，但你大概率不想用它。推荐直接安装最新版，两种方式都可以：一是从官网下载安装包，二是用Homebrew安装。我个人更推荐Homebrew，因为方便后续升级：

brew install git

装完后用git --version验证，看到的版本如果是最新的就对了。

Linux平台（以Ubuntu/Debian为例）

sudo apt update sudo apt install git

不同的发行版包管理命令不同，CentOS、Fedora那条线是sudo yum install git或者sudo dnf install git，这点不展开了。装完以后跑一句git --version确认即可。

提示：不要只看“版本号明明出来了”就觉得万事大吉，有些系统自带的git会老得离谱。如果版本过旧，部分命令行为会和文档不一致，建议装官方源里的新版。

2.2 安装后的三件套配置：用户名、邮箱、默认分支名

很多新手第一次提交时报错或者提交者的名字乱七八糟，就是跳过了这一步。Git每次提交都会记录“谁在什么时候提交了什么”，而它读取的就是全局配置里的用户名和邮箱。所以安装完成后的第一件事是：

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

这里的名字和邮箱不一定要和托管平台注册信息完全一致，但强烈建议一致，否则提交记录里显示的人会和对不上号，团队协作时容易混乱。

还需要检查一个重要的行为：Git默认的主分支名。以前是master，现在很多平台和工具链已经转向main。你可以直接设置全局默认：

git config --global init.defaultBranch main

这样以后git init出来的仓库默认就是main分支，避免后面还要手动改名。怎么看当前配置？执行：

git config --global --list

这会把上面所有全局配置打印出来，一目了然。

2.3 SSH免密配置：本地密钥生成与托管平台部署

日常提交代码有两种常用认证方式：HTTPS和SSH。HTTPS简单直接，但每次push都要输入用户名密码（或者Personal Access Token），用久了很烦。SSH配置一次之后就能免密操作，这也是团队开发里几乎人手一份的能力。

生成密钥就用下面这条命令：

ssh-keygen -t rsa -b 4096 -C "你的邮箱"

执行过程中会让你选保存位置和密码短语，默认回车一路下去就行。生成完成以后，公钥在~/.ssh/id_rsa.pub，私钥在~/.ssh/id_rsa。把公钥内容复制出来：

cat ~/.ssh/id_rsa.pub

然后登录你使用的托管平台（GitHub、Gitee、GitLab都支持），在个人设置里找到“SSH Keys”相关的菜单，把公钥粘贴进去保存即可。

验证是否配置成功：

ssh -T git@github.com ssh -T git@gitee.com

如果第一次连接出现询问，输入yes继续。看到“Hi xxx! You've successfully authenticated”之类的提示就说明通了。

这里有个细节值得注意：一台电脑上如果需要同时使用多个平台，比如既用GitHub又用Gitee，可以在~/.ssh/config里按Host区分不同的私钥文件，避免认证身份串掉。这个属于进阶操作，但能满足“多个托管平台同时用”的常见场景。

3. 核心命令从零跑通：从仓库初始化到提交回滚

装好、配好之后，接下来就是真正使用时的核心链路。很多教程会按照init、add、commit这个顺序讲，我也从这条线展开，但我会把每一步背后的原理讲清楚，这样你不至于只会敲命令而不知道发生了什么。

3.1 init、add、commit：第一次提交背后的对象模型

进入一个项目目录，执行：

git init

此时目录里会出现一个隐藏的.git文件夹，整个仓库历史都存在这里。很多人会问：为什么我不能直接把.git删了？答案很简单，删了历史就没了，这相当于把存档文件格式化。

把文件加入暂存区：

git add index.html git add . # 添加所有改动 git add src/ # 添加某个目录

git add这个概念是Git新手最不理解的地方。它到底在干什么？它把文件快照放到了“暂存区（staging area）”，也就是一个准备好但还没正式写入历史的等待区。你可以理解为：你先挑选好哪些改动要放进下一次提交，然后再commit。这给了你很大的控制权，可以只提交部分文件，也可以反复调整。

然后是提交：

git commit -m "初始化项目：添加首页结构"

这条命令执行后，暂存区里的内容被打包成一个commit对象，同时记录作者信息、时间戳、上一个commit的引用。这一个commit就是时间线里的一个新节点。

其实Git底层是一个对象数据库，每个文件内容、每棵树、每次提交都是一个对象，commit之间通过哈希链起来。你不用背这些概念，但理解“commit是一条链”很有用，因为后面你学rebase、reset的时候，本质上都是在操作这条链。

3.2 log、status、diff：看清每一次变化

提交了几次以后，你得学会看历史。最常用的三个命令：

git status # 查看工作区状态：哪些文件被改了、哪些还在暂存区 git log --oneline # 简洁版提交历史 git diff # 查看工作区里还没暂存的改动内容 git diff --cached # 查看已暂存但还没提交的改动内容

git status可以说是日常用得最多的命令，它就像一面“镜子”，告诉你当前处于什么状态。新手最容易犯的错是指着某个文件说“我明明改了，怎么push上去了没变化”，这种情况十有八九是没git add、没git commit，文件还停留在工作区没进历史。

git diff的威力在于，它不是简单告诉你“哪个文件变了”，而是精确到具体行的增删。联调定位问题的时候，git diff配合git log -p基本能还原出任何一段代码的前世今生。

3.3 改错了怎么办：checkout、reset、revert的三个层级

写代码不可能永远一次写对，所以“撤回”能力是刚需。Git的撤回有三个层级，千万别搞混：

工作区级别的恢复

如果只是改了某个文件但还没git add，想放弃修改，用：

git checkout -- index.html # 或者新版写法 git restore index.html

这条命令会把工作区的文件恢复到最近一次提交的状态，所有未暂存的修改直接丢弃。

暂存区级别的撤回

如果已经git add了，但还没commit，想从暂存区里取消添加，用：

git reset HEAD index.html # 或者 git restore --staged index.html

注意，这个操作不会改文件内容，只是把文件从暂存区挪回工作区，修改还在。

历史提交级别的回退

如果已经commit了，却发现提交错了，这时候要看情况选择reset还是revert。

git reset是回退到某个历史提交，比如：

git reset --hard HEAD~2

这会把HEAD指到前两代提交，同时工作区也被重置，那条时间线之后的提交就看不到了。危险在于reset会重写历史，如果已经push到远程共享分支，直接reset再强制push会导致其他成员的本地历史和远程不一致，容易引发事故。

git revert则是生成一个反向提交，把某次提交的改动撤销掉，但保留原来的提交记录。它最适合用在已push到远程的公开分支上：

git revert <commit-hash>

团队协作中，凡是动到共享远程分支的历史，请优先使用revert而不是reset，这是我在实际项目里踩过不止一次坑以后总结出来的铁律。

3.4 提交信息规范：为什么commit message比代码更值钱

很多人提交的时候随手写一条“修改”或者“fix”，当时觉得无所谓，一个月后回来看历史，完全不知道当时到底干了什么。代码写出来的目的是让人读，而提交信息的作用是让你在回溯历史时快速理解“这次提交的意图”。

我自己的团队里约定了一套简化版规范：

示例写法：

git commit -m "fix: 修复订单列表分页参数错位问题"

更完整的写法甚至可以加正文，比如说明“因为什么原因导致，用什么方案解决，可能影响哪些模块”。多人协作时，git blame和git log会因为你写清楚了commit message而变得极其有用。与其说这是“规范化要求”，不如说这是对自己三个月后的自己负责。

4. 分支与合并：分布式协作的关键玩法

分支是Git最迷人的设计之一。很多新手对分支有恐惧感，觉得它会搞乱代码，实际恰恰相反——分支是保护代码秩序最有效的工具。你要是理解不了分支，协同开发时就会永远徘徊在“谁改了谁的文件”的泥潭里。

4.1 为什么分支是廉价且高效的

Git的分支本质上只是一个指向某个commit的指针，创建分支的成本极低。所以在Git里，为每个功能、每次修复都开一个独立分支，是完全没有负担的。相比之下，手工备份时代你要为一个实验性改动复制整个项目文件夹，还不敢随便删，Git里你只需要：

git branch feature-login git checkout feature-login # 或者直接用下面这条一步到位 git checkout -b feature-login

切换到新分支后，你在里面随便改，主分支（比如main）完全不受影响。直到你确认功能稳定，再把分支合并回去。这就像你在同一台电脑上开了多个虚拟机互不干扰，但每个虚拟机之间又共享底层文件系统——这就是Git的设计哲学：隔离与协作并存。

在我之前待过的一个项目组，团队十来个人，如果所有人都在main上直接提交，代码基本每天都会冲突。后来强制改成“每个功能一个分支、提交后走检视再合并”，冲突现象直线下降，出了问题也能精准定位是哪个分支引入的。

4.2 merge与rebase的真实差异与选择逻辑

分支做完以后，合并有两种主流方式：git merge和git rebase。说句实话，这两个命令有很多争议，不少初学者也容易用混。我从结果导向来说清楚它们的区别。

merge是把两个分支的历史“接在一起”，会产生一个合并提交。比如你在feature分支上提交了3个commit，main分支上也有2个新commit，merge以后的时间线会出现一个明显的汇总点，历史是“分叉后再汇合”的形状。它的优点是保留了真实的并行开发过程，适合团队公共分支。

rebase是把当前分支的提交“重新播放”到目标分支的顶部，比如：

git checkout feature git rebase main

它不会产生合并节点，而是把你的提交一个个“垫”到main最新提交之后，历史看起来像一条直线。优点是非常清爽，缺点是它改变了提交的哈希值，相当于改写了历史。

我的实际建议：

• 个人功能分支要并入公共分支，且想让历史干净，用rebase
• 多人协作的公共分支之间，避免rebase，直接用merge
• 禁止对已push到共享远程的分支执行rebase或reset --hard，否则其他人的本地仓库会被搅得天翻地覆

4.3 合并冲突处理：从慌到稳

无论用merge还是rebase，只要两个人改了同一块代码，就必然会出现冲突。第一次遇到冲突的人往往会慌，看到满屏的<<<<<<<、=======、>>>>>>>就觉得完了。其实冲突处理有非常清晰的套路。

冲突发生后，先用git status看哪些文件冲突，打开文件你会看到类似这样的标记：

<<<<<<< HEAD 当前分支的内容 ======= 传入分支的内容 >>>>>>> feature-branch

你的任务就是把这段内容整理成最终想保留的样子，删掉所有冲突标记。改完之后：

git add 冲突文件 git commit -m "merge: 解决订单列表分页冲突"

就这么简单，整个过程的心理负担主要来自对未知的恐惧。解决冲突时有一点很重要：不要只留自己的代码，也不要迷信对方的代码，要弄清楚两边的修改意图。我见过很多冲突解决完以后把另一个人的功能覆盖掉的，那就是灾难了。

4.4 小团队常用工作流：Git Flow简化版与Feature Branch模式

我参与过的团队，规模从几个人到几十个人都有，实际落地的工作流其实不需要教科书里那么复杂。这里分享两套真实运行过的工作流。

Feature Branch模式（适合3~10人小团队）

• main始终保存可发布的稳定版本
• 每个人开发新功能时从main切出feature分支，命名类似feature/用户登录
• 功能完成后合并回main
• 合并回main之前至少有一个同事review过代码

这套流程简单，几乎没有学习成本，很多小公司实际用的就是它。

Git Flow简化版（适合有发布节奏的团队）

• main：生产版本
• develop：日常集成分支
• feature：从develop切出，开发完并入develop
• release：从develop切出，做发布前准备，修完bug并入main和develop
• hotfix：从main切出，紧急修复，修复后并入main和develop

如果你们团队有明确的发版周期，或者要维护多个线上版本，Git Flow值得考虑；如果是高速迭代的互联网产品团队，Feature Branch配合持续交付已经足够。千万不要教条化地套用流程，一切以“减少摩擦、降低出事故概率”为目标。

5. 远程协作实战：从remote到Pull Request

本地操作熟悉以后，就得开始打交道远程仓库了。这一步很多人会跳过原理直接push，但一旦遇到SSH认证、上游更新这类问题，就不知道从哪里下手。我尽量把远程协作的完整链路拉通。

5.1 关联远程仓库：git remote的增删改查

本地项目要推到远程，第一步是关联远程仓库地址：

git remote add origin git@github.com:yourname/yourrepo.git

origin是远程仓库的默认别名，不是强制名，只是行业惯例。查看现有远程：

git remote -v

这个命令会列出所有远程仓库的地址和你本地的拉取/推送权限。如果地址配错了，可以修改：

git remote set-url origin 新地址

不需要远程仓库了也可以删除：

git remote remove origin

这里有一个常见问题：很多人复制HTTPS地址总是免不了每次输密码。如果已经配好了SSH密钥，直接把远程地址换成SSH格式就行，上面提到的set-url就是干这个的。

5.2 push、pull、fetch的区别与时机

远程协作的核心操作其实就这么三个：push、pull、fetch。它们的区别必须搞清楚，否则很容易遇到“明明pull了怎么还说落后”的怪象。

• git fetch：从远程下载所有最新commits到本地，但不动你的工作区文件和当前分支
• git pull：等于git fetch+git merge（或git rebase），把远程更新拉到本地并自动合并
• git push：把本地commit推送到远程，更新远程分支

举个实际场景：我早上开工第一件事是git pull，保证本地基于最新代码工作；下午写完代码git push，把成果分享给队友。而如果我只是想知道远程有没有新变化，又不想立刻合并到工作区，就用git fetch。

需要特别注意的是，git pull默认行为是merge，如果你希望是rebase，可以配置：

git config --global pull.rebase true

这样每次pull都会以rebase方式应用本地提交，历史更线性。这个配置适不适合你，取决于团队的合并习惯。我的团队就开了这个配置，因为我们的分支历史非常整洁，很少产生冗余的merge记录。

5.3 多人协作的典型流程：以Pull Request/Merge Request为例

现代托管平台都支持Pull Request（GitHub叫PR，GitLab叫Merge Request）。它的核心价值不是“合并代码”，而是“合并前让代码被讨论、审核、测试”。

标准流程大概是：

1. 从最新main上切一个功能分支
2. 在分支上完成开发，提交多次
3. 推送分支到远程：

   git push origin feature-login

4. 在托管平台网页上发起Pull Request，指定目标分支main
5. 同事在PR里review代码、留评论、提修改意见
6. 你在本地继续修改，再次commit并push，PR会自动更新
7. 审核通过后，点击合并，删除远程分支

这套流程保证了任何代码进公共分支之前，至少被两个人看过。我实际使用下来，最大的收益不只是减少bug，而是让团队里每个成员都清楚别人正在做什么，代码规范也会在评论里自然沉淀。

5.4 常见远程问题排查：ssh认证失败与git open /dev/null or dup failed

远程协作最容易踩的坑就是认证问题。最常见报错是：

Permission denied (publickey). fatal: Could not read from remote repository.

这种提示十有八九是SSH密钥没配好。排查顺序我一般是这样：先跑ssh -T git@github.com看认证是否通过，如果失败，检查当前用的私钥是不是对应公钥已添加到平台；再看~/.ssh/config里是否为你自己的Host配置了错误的IdentityFile；最后确认本机ssh-agent是否正常加载了私钥。

另一个我遇到过不止一次的报错是：

git open /dev/null or dup failed: No such file or directory fatal: unable to fork?

这个报错看起来毫无头绪，其实多半出现在Windows环境或某些终端模拟器里，和进程句柄、终端输入状态有关。我遇到过的典型场景是Git Bash窗口突然失去标准流，或系统打开文件句柄受限。通常的解决办法很朴素：

• 重启终端窗口，重新进入项目目录
• 如果是WSL或虚拟机里出现，检查终端是否正常分配了标准输入输出
• 偶尔是因为杀毒软件或系统安全策略拦截了Git的子进程，临时退出安全软件再试一次
• Windows下还可以检查一下环境变量里GIT_SSH之类的配置是否指向了不存在的程序

互联网上关于这个报错的解释五花八门，但绝大多数情况下它不是一个“仓库数据问题”，更多是本地终端环境问题，不需要动Git仓库本身。

6. 高频疑难杂症与最佳实践：我踩过的坑都在这

写到这里，基础的安装、命令、分支、远程都已经跑通了，但真正决定你和Git相处得愉不愉快的，是一些零碎但发生频率极高的细节问题。这一章我把平时问得最多、也最容易卡住人的几个点拿出来集中处理。

6.1 .gitignore不生效的原因与正确写法

“我明明在.gitignore里写了target/，为什么git status还是能看见target目录里的文件？”这个问题我至少被问过二十次。原因很简单：.gitignore只对“还没被Git跟踪的文件”生效。如果你的文件在那之前已经被git add或者git commit过，Git已经记住它了，这时候加进.gitignore当然不会自动忽略。

解决办法有三种：

• 从未提交过的场景：直接在.gitignore里写好规则即可
• 已经提交过但想忽略后续变化：先删除缓存，再重新添加
• 最粗暴但有效的场景：把文件从Git历史里移除

很多人在第二种场景用这条命令解决：

git rm -r --cached target/

这条命令会把target/从索引（暂存区）里移除，但保留工作区的文件，之后再加上忽略规则，git status就干净了。

另外要注意.gitignore的语法：target/表示忽略所有名叫target的目录，*.log表示忽略所有.log结尾的文件，!important.log表示“排除例外”。如果你写的规则一直被“误伤”，也可以用git check-ignore -v 文件名来查看是哪条规则最终命中了你这个文件，这个调试命令非常管用。

6.2 历史提交改写：commit --amend与rebase -i的使用边界

开发过程中经常遇到“刚提交完发现漏了一个文件”或“提交信息写错了”的情况，这时候git commit --amend是最方便的工具：

git add 漏掉的文件 git commit --amend -m "修正提交信息"

这个命令会把当前暂存区的改动“合并”进上一次提交，相当于把上一次提交替换成一个新的提交。但注意，它会改写提交哈希，所以只适合还没push到远程的提交，或者你明确知道只有自己在使用该分支的时候。

更夸张一点的场景是改最近多个提交，比如整理多个commit的先后顺序、合并冗余提交，这时用交互式rebase：

git rebase -i HEAD~3

执行后会打开一个编辑界面，你可以对最近3个提交进行操作，比如pick保留、squash合并、reword修改信息、drop删除。这个命令威力很大，但如果使用不当，分支历史会被搅得一团糟。我的建议很简单：个人分支随便改，公共分支永远别动历史。

6.3 本地仓库瘦身、大文件管理与安全提醒

随着迭代时间变长，.git目录可能会变得越来越大，尤其是你往仓库里提交过大文件、安装包、数据库转储文件后，即使后来删掉了，这些大对象依然存在于历史对象里。

处理历史大文件的正规工具是Git LFS（Large File Storage），专门用来管理大文件，做法是把大文件替换成轻量指针提交到Git，实际内容存储在LFS服务器上。如果你的仓库历史已经被大文件污染，还可以用git filter-repo这类工具重写历史，这是一项高级操作，务必在备份仓库之后再进行。

顺带说一个很多做Web开发的人容易忽略的安全细节：如果你的网站目录是Git仓库，并且不小心把.git目录置于Web服务可访问的静态文件目录下，别人就能通过路径直接下载你的源码历史。这就是常说的“git目录泄露”风险。正确做法是在部署时禁止Web服务器访问.git目录，或者在构建目录里干脆不存放Git元数据。我只是提醒这一点，因为这个问题一旦发生，影响的是整个项目源码的泄漏，远比一次代码冲突严重得多。

6.4 团队Git协作的最佳实践清单

最后收拾一下这些经验，给自己做一张贴在最显眼处的清单。这不是标准的PPT式规范，而是真正被验证过、能减少日常摩擦的做法：

1. 提交粒度要小，一个commit只做一个逻辑变更，宁可多提交几次，也不要一个commit塞入十几个文件的混乱改动
2. commit message用约定式前缀，中文或英文都行，团队保持统一
3. 功能开发尽量走独立分支，不直接在main上写代码
4. push之前先pull，pull之前先commit或stash，避免工作区状态不明时做合并
5. 公共分支禁改历史，别用reset --hard、rebase、amend等方式操作已push的提交
6. 不要把大文件、密钥、编译产物提交进Git，该用.gitignore一时一刻都不偷懒
7. 冲突不要独自硬顶，及时找改动相关的人沟通，很多冲突的解法其实需要两个人的共识
8. 定期用git fetch --prune清理本地失效的远程追踪分支，保持本地仓库整洁

里面每一条都是我吃过亏才写下来的，如果你能一条条落实到团队里，Git带给你的就不再是“又一个要学的工具”，而是真正让你敢改代码、敢协作、敢试错的底气。

写这篇文章的时候，我回想了一下自己从最初用压缩包备份代码，到后来慢慢摸清分支、合并、远程协作的整个过程，最深的感受是：Git不是一个需要背命令的学科，而是一套用来管理“变化”的习惯。你不需要把所有命令都记在脑子里，只需要把核心链路跑通、把几个高危操作刻在骨子里，剩下的就是靠实际项目去滋养手感。如果这篇攻略里有一两个点能帮你在下次提交代码时少走一步弯路，那这半天的整理就值了。