企业官网建设流程全解析

新接手一个项目的时候，我第一件事就是打开终端敲一句：git log --oneline。不为别的，就是想看看这个项目过去经历了什么——谁在什么时候改了什么，为什么这么改，哪次提交埋了雷。这大概就是版本控制带给一个开发者的安全感：你永远知道代码是怎么一步步走到今天的，也永远有回头重来的余地。

这篇东西不是官方文档翻译，是我自己从“SVN时代的老古董”慢慢折腾到“Git日常操作基本不查命令”的经验沉淀。里面会讲清楚Git和其他版本控制的本质区别、装好环境之后的那些坑、日常开发最常用的一套流程、团队协作时最容易翻车的分支和合并，还有我踩过无数次之后总结出来的翻车急救方案。无论你是刚入门想搞明白Git到底是什么，还是用了一阵子但总在关键时刻卡壳，这篇应该都能给你点实在的东西。

1. 先想清楚：Git和你之前用的“版本管理”差在哪

1.1 从SVN迁移过来的那些不适应

很多老开发者是从SVN时代过来的，包括我自己。SVN的模型其实很好理解：一台中央服务器存着所有版本，你从服务器上checkout一份到自己电脑，改完了commit回服务器。这种模型的优点是想明白很简单，缺点也很致命：没有网络就基本没法干重活，而且分支操作又慢又重，多数团队干脆不用分支，所有人挤在主干上开发。

Git给我的第一个冲击是：原来版本库可以整个搬到本地。git clone一下，不光是代码的当前快照，而是整个项目的完整历史都在你电脑里了。飞机上、地铁里，没有网也能commit，等有网了再push。这件事在SVN时代是不可想象的。

还有一个观念转变在于“快照”而不是“差异”。SVN记录的是每次改动产生的diff，Git记录的是每次提交时所有文件的完整快照。听起来好像Git占空间更大，实际上因为压缩和对象存储机制，Git仓库一般比SVN加上一堆历史补丁还小，而且因为每份快照都是完整的，切换分支、回溯版本的速度快得让人感动。

1.2 分布式不只是“人人都有副本”

Git的分布式核心在于：每个克隆出来的仓库都是平等的，没有天然的“主从关系”。你电脑上的仓库和GitHub、Gitee上的仓库，在Git眼里没有本质区别，只是大家约定俗成把某个远程仓库当作“权威”。

这个设计带来一个很有用的推论：你可以自由地在本地随便折腾，搞砸了大不了把本地仓库删了重新clone。因为远程仓库是独立的另一份，本地烧掉也不影响别人。这种“低成本试错”的底气，是集中式版本控制给不了的。

实际用下来，我从Git得到的最大收益反而不是这些技术特性，而是工作习惯的改变。因为Git的commit是本地操作，我会更频繁地提交，每个提交尽量只做一个逻辑改动，提交信息写清楚为什么这么改。这直接让后来回溯历史的时候舒服太多了。

1.3 你就记住三个区一个库

学习Git最怕上来就背命令。我的建议是先建立一个心智模型，后面所有命令都能归位到这张图里：

• 工作区：就是你编辑器里看到的那些文件。
• 暂存区：你git add之后文件去的地方，相当于一个“待提交清单”。
• 本地仓库：git commit生成的每一个版本，都存在这里。
• 远程仓库：git push之后代码到达的地方，是团队共享的权威版本。

日常绝大部分命令无非是在这几个区域之间搬运文件：add从工作区到暂存区，commit从暂存区到本地仓库，push从本地仓库到远程，pull从远程拉回工作区。理解了这个，你甚至能自己推断出一条命令大概干什么。

2. 装好第一套Git环境：三平台安装要点与国内加速方案

2.1 Windows安装：一路Next之外的三个心眼

Windows装Git基本就是去官网下载安装包，但有几个细节我建议留意：

第一，安装过程中有个“Adjusting your PATH environment”选项，务必选“Git from the command line and also from 3rd-party software”。这样装完后CMD和PowerShell里都能直接敲git命令，不用每次都去开Git Bash。

第二，行尾转换那一步，建议选“Checkout as-is, commit as-is”。旧版安装器默认会把换行符转成CRLF，这在Windows下确实省事，但遇上项目里已经有LF换行文件的时候，容易在diff里看到整文件变动，看起来很吓人。直接改成“原样检出、原样提交”，把换行符的处理权交回项目里的.gitattributes，后面会少很多莫名其妙的diff噪音。

第三，如果官网下载速度感人，可以用国内镜像。清华、中科大这些镜像站都同步了Git的Windows安装包，下载速度基本是秒杀级的。这个没什么不好意思用的，工具只要来源可靠、校验一下哈希值，用镜像完全没问题。

提示：装完后第一件事，在终端里敲git --version确认安装成功。能正常输出版本号，环境就没问题。

2.2 macOS和Linux的一行命令

macOS上最简单的方式是装Homebrew之后跑brew install git，装完就是最新稳定版。Linux的话，Debian/Ubuntu系是sudo apt install git，CentOS/RHEL系是sudo yum install git。一般发行版自带的Git版本可能偏旧，但日常使用足够，不用追新。

mac用户还有一个选择：装Xcode Command Line Tools，它会附带一个Git。但这个Git版本有时候偏旧，而且更新依赖系统更新，不如Homebrew独立管理的版本灵活。我用Homebrew装完会顺手看一眼git --version，确保PATH里生效的是我自己装的那个。

2.3 安装完必做的全局配置

Git装好后有两项配置必须做，不然commit时会报错或者生成本地身份不明的提交。这就是全局用户名和邮箱，作用只有一个：让你的提交记录上能显示“这是谁干的”。

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

这里有个细节容易踩坑：这个邮箱最好用和你代码托管平台账号一致的邮箱，这样平台能把你的提交关联到账号上，绿色小方块贡献图才会长出来。改完之后可以敲git config --list看看所有配置项，检查有没有写错。

我自己还会顺手设两个额外配置，一个是默认的编辑器：

git config --global core.editor "code --wait"

这样commit时如果忘了写-m，会弹出VS Code等编辑器让你输入信息，比默认的Vim友好太多了。另一个是提交信息模板，适合规范要求严格的团队，不过这个不急，等你有需求再研究。

3. 桌面开发者的日常三板斧：clone、commit、push/pull到底在做什么

3.1 clone：把整个项目连同历史一起拿下来

新加入一个项目，第一件事通常是git clone。以Gitee为例，仓库页面会给出两种地址：HTTPS和SSH。新手阶段用HTTPS就行，虽然每次push可能要输入账号密码，但胜在零配置。等你频繁推送的时候，再换SSH（这个后面专门讲）。

git clone https://gitee.com/用户名/仓库名.git

执行完之后，工作目录里会出现一个和仓库名一样的文件夹，里面就是项目的全部文件和历史。你可以直接cd进去开始写代码。这里有个小技巧：如果你想clone下来的目录换个名字，就在命令末尾加上目标目录名：

git clone https://gitee.com/用户名/仓库名.git my-project

3.2 commit之前，先搞清楚暂存区到底在拦什么

很多Git新手最困惑的命令是git add：我明明已经保存文件了，为什么还要add？这是因为Git不想把工作区所有变动一股脑塞进一次提交，它给了你一个挑选的环节——暂存区。

我常用的提交流程是这样的：

# 1. 先看当前状态，搞清楚改了什么 git status # 2. 对每个文件审视一下，确认无敏感信息后加入暂存区 git add src/index.js # 3. 如果文件多且都是同一件事的改动，可以整个加入 git add . # 4. 提交，写清楚这次改动的意图 git commit -m "修复登录接口在token过期时不返回明确错误码的问题" # 5. 推送到远程 git push

commit信息是最值得花心思的地方。我见过太多“update”和“修改”这样的提交信息，等三个月后翻历史根本不知道那次改动做了什么。推荐格式是第一行用一句话概括“做了什么”，如果需要细节就空一行再补充。一句好的提交信息应该能回答：这个改动解决了什么问题、为什么用这种方式解决。

3.3 push和pull的拉锯战：保持同步的正确姿势

单人开发时push和pull都不会出大问题，最怕的是多人协作时大家同时改同一个文件。我想给的建议是：push之前先pull。这不是简单的习惯问题，而是避免冲突的核心策略。

git pull origin main git push origin main

git pull实际上做了两件事：先git fetch把远程最新的提交拉到本地仓库，再git merge把这些提交合并进你的当前分支。如果远程分支在你上次pull之后没有变化，这个操作就是无痛的；如果有变化且和你本地改的文件不重叠，Git会自动合并，同样无痛；只有改动到同一个文件的同一个区域时，才会触发冲突。

我自己的节奏是：开始干活前pull一次，写完提交准备push前再pull一次，把同步频率提上来。冲突这东西，差异越小越容易自动合并，攒了一整天最后一次性pull，那是把难题留给未来的自己。

3.4 从文件生命周期理解.gitignore

还有一个日常绕不开的坑是.gitignore。这个东西的作用是告诉Git哪些文件不要纳入版本控制。最常见的包括：依赖目录（node_modules、vendor）、编译产物（dist、build）、本地配置（.env、.idea、.vscode）、日志文件。

为什么要忽略这些？因为版本控制管理的应该是有价值、有业务含义的内容，而不是机器生成的东西。node_modules别人clone下来跑个npm install就能生成，没必要每个文件都进仓库，不然仓库会膨胀得又慢又难用。本地配置带了个人偏好，提交上去还会污染别人的开发环境。

我见过最痛的一次事故，是同事把含有数据库密码的.env文件提交进了仓库。后来发现时已经推送了几十个提交，而要“洗掉”这个文件在历史中的所有痕迹，操作相当麻烦。所以请谨慎对待.gitignore，初建项目时就把该忽略的配好，别等事故出来再后悔。

4. 分支合并：团队协作里最容易翻车的环节

4.1 分支不是炫技，是给“进行中的工作”一个隔离区

分支大概是Git相对SVN最碾压级的功能。SVN的分支是目录拷贝，又慢又占空间，所以没人爱用；Git的分支只是一个指向某个提交的指针，创建分支瞬间完成，切换分支也就是改个指针的事。成本低了，玩法就多了。

我理解的Git分支哲学是：不同分支代表不同的工作上下文。主分支（main或master）永远是稳定可发布的；功能分支（feature/xxx）用来装一个新功能的开发；修复分支（hotfix/xxx）用来紧急修线上bug。这样每个人在自己的分支里折腾，互不干扰，等一个功能完整了再把分支合回主干。

创建一个新分支很简单：

git checkout -b feature/user-login

这个命令等于两步：git branch feature/user-login创建分支，git checkout feature/user-login切换过去。新版本的Git还提供了git switch -c feature/user-login这个更语义化的写法。记住一个原则：在你决定开始做一件事的时候，先开一个分支，永远别直接往main上提交。

4.2 merge和rebase的选择：没有绝对正确，只有场景合适

分支合并有两种主流方式：merge和rebase。这事在技术社区吵了好多年，我说下自己的实践经验。

git merge feature/user-login的结果是：创建一个新的合并提交，把功能分支的改动合入当前分支。它的特点是历史完整，你能看到“有一个功能分支在这里并入了主干”，适合团队协作，因为每个提交都是真实发生过的，没有篡改。

git rebase main的结果是：把你当前分支的提交“搬家”，重新放到main分支的最新提交之后。它的特点是历史是线性的，看起来非常整洁，像一条直线一样往前推进。适合个人开发分支保持历史清爽。

我的建议是：个人分支上可以随便rebase整理历史，但一旦分支推到了远程、有多人协作，就不要rebase了。因为rebase本质上是在改写提交历史，别人已经基于旧提交拉了分支的话，你改写后他们再pull会撞得头晕眼花。也就是说，远程分支的历史尽量用merge来维护，本地还没push的分支，你可以放心地用rebase来整理。

4.3 冲突解决：一场不惊悚但需要耐心的和解

冲突是合并时双方改了同一个文件的同一段代码造成的，Git不知道哪边是对的，于是停下来让你做决定。表现形式是一个文件里出现了这样的标记：

<<<<<<< HEAD 这是当前分支的版本 ======= 这是被合并分支的版本 >>>>>>> feature/user-login

解决方案不是背命令，而是：打开文件，逐段审视，把需要的代码留下，多余的删掉，连同三行标记一起删除，然后保存文件，git add这个文件，继续git commit。

我第一次遇到冲突的时候慌得不行，根本不敢动那些尖括号。后来我的流程固定成：先git status看哪些文件冲突了，然后一个个打开编辑器处理，处理完git add，最后commit。现在遇到冲突基本麻木了，内心毫无波澜。

注意：解决冲突时最重要的是和同事沟通。如果双方改动确实都重要，别自己默默删掉别人的逻辑。我处理棘手冲突时，会直接找写那部分代码的同事确认意图，这比花一小时猜他的思路划算得多。

4.4 分支工作流：小团队怎么玩不翻车

分支工作流有很多种理论模型，什么Git Flow、GitHub Flow，但小团队真用起来，我建议保持简单：

• main：永远保持可发布状态。任何合入main的代码都经过了测试。
• feature/xxx：每个功能开一个分支，完成后发起合并。
• hotfix/xxx：紧急修复线上问题，从main直接拉分支，修完合回main。

合并的时候可以在本地执行git merge，也可以在平台上走Pull Request或Merge Request流程。我倾向于在平台上走，因为代码评审这件事在平台上做，比本地默默合并更有利于质量把控。哪怕团队只有两个人，互相review一遍都能挡住很多低级错误。

5. 翻车自救指南：我踩过的那些Git坑和修复命令

5.1 commit信息写错了，不是世界末日

提交之后发现信息写错了——这是新手最常见的事故。解决办法有两个，取决于这个提交有没有被push到远程。

如果还在本地，直接用：

git commit --amend

这个命令会用暂存区内容创建一个新的提交，并替换掉最近的一个提交。它不仅改信息，还能追加文件，比如你发现上次漏了一个文件没提交，可以git add那个文件后同样执行git commit --amend，把漏掉的内容补进上一个提交。注意：amend的本质是改写提交历史，所以绝不要对已经push到远程的提交使用amend，否则你是把自己的历史改写了，推上去会和别人的克隆不兼容。

如果已经push了，就不要强行删掉重来。谨慎一点的方案是重新提交一个修正：

git commit -m "修正上轮提交的拼写错误"

虽然历史里会留下“多了一个修正提交”的痕迹，但这是诚实且安全的做法，团队同步时不会出问题。

5.2 reset三级火箭：soft、mixed、hard怎么选

git reset是用来撤销提交的命令，但它有三个模式，区别在于撤销到什么程度：

• git reset --soft HEAD~1：撤销最近一次commit，但保留改动在暂存区。相当于“提交错了，但我还留着add过的状态，重新commit就行”。
• git reset --mixed HEAD~1（默认模式）：撤销commit，也撤销暂存，但保留工作区改动。相当于“回到commit之前，所有改动变成未add的状态”。
• git reset --hard HEAD~1：撤销commit，同时丢弃工作区改动。相当于“这个提交我不要了，相关改动也全部丢掉”。

我最想强调的是：--hard是危险操作。它没有任何确认提示，一旦执行，工作区里没有提交过的改动会直接消失，而且很难找回。我自己只在极其确定不想要那些改动的时候才用，平时能用soft和mixed解决的绝不碰hard。

关于HEAD~1这个写法：它表示“当前提交的上一个提交”。HEAD~2就是往上数两个，以此类推。想撤销多个提交的时候，先数清楚要退几步，最好配合git log --oneline确认。

5.3 已经push的提交怎么撤销：revert才是团队安全的那个

如果错误提交已经push到远程，正确姿势不是reset，而是git revert。

git revert HEAD

revert和reset最大的区别是：reset是“回到过去，抹掉历史”，revert是“新增一个提交，把之前某次提交的改动反向恢复”。revert的历史是增长的，所有提交记录都保留着，所以不会和其他人的克隆产生冲突。你可以放心地revert一个已经远程同步的分支上的提交，然后push，所有同事正常pull即可。

我有时候会听到有人说“push错了就reset然后push --force”，这个操作在单人分支上确实能行，但在多人协作分支上非常危险。因为你本地reset之后，远程历史和你本地历史就分叉了，push --force会强行把远程历史改成你本地的样子，其他同事再pull时Git会发现两边历史不兼容，场面相当混乱。force push这件事，除非你有十足把握，否则离它远点。

5.4 干到一半想换个分支：stash这个杂物间

场景很常见：你在feature分支开发，写着写着突然线上有个紧急bug要马上修。你说换分支就换，但工作区还有改到一半的文件，直接git checkout main会报错，因为Git不想让你带着未提交的改动乱跑。

这时候git stash就是那个救命的杂物间：

git stash

这条命令会把所有未提交的改动暂存起来，工作区恢复到上一次提交的干净状态。然后你可以放心切到main分支处理紧急问题。等修完了，再回到原分支，把暂存的改动取回来：

git stash pop

我一开始总是记不清stash和pop，后来把stash理解为“暂时寄存”，pop是“取回来”，就好记了。还有git stash list可以查看暂存的列表，如果你想暂存多次，可以用git stash save "描述信息"来区分。

5.5 误删分支或误丢提交：reflog是时间机器

有人问过我：分支误删了还能找回吗？答案是大概率可以，只要你记得提交的哈希值。这个值可以在git reflog里找到。

reflog记录的是你本地仓库里所有HEAD变更的历史，本质上就是你的操作流水账。哪怕你reset了、分支删了，只要提交对象还在仓库里，reflog里就有记录。恢复误删分支的办法是：

git reflog # 找到目标提交的哈希值，比如 abc1234 git branch restore-branch abc1234

这样就能创建一个新分支指向那个提交，内容就找回来了。我的经验是，Git的对象模型决定了大部分操作都不是物理删除，而是“丢弃引用”，所以遇到误删先冷静，reflog翻一翻，能救回来很多看起来已经没救的提交。

6. 远程仓库细节：SSH密钥、平台配置与VSCode集成

6.1 HTTPS还是SSH：开发者的第一道选择题

和平台通信有两种认证方式：HTTPS和SSH。HTTPS的优点是零配置，clone地址直接能用，缺点是push时每次都要输用户名密码（取决于客户端是否记住了凭据）。SSH的优点是一旦配好密钥，push和pull完全免密，缺点是初次配置有点门槛。

我建议日常开发用SSH。理由很实在：频繁push时不用反复输密码，而且密钥认证的安全性比密码高一个量级。配置过程在网上搜一圈可能看得眼花缭乱，其实核心就三步：

第一步，在Git Bash里生成密钥：

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

中途会让你输入保存路径和密码。路径直接用默认即可，密码如果你想每次用密钥时都验证，就设一个；嫌麻烦就留空。生成的密钥有两个文件：私钥（id_rsa）和公钥（id_rsa.pub），私钥务必自己放好，公钥才是要到处贴的。

第二步，查看公钥内容：

cat ~/.ssh/id_rsa.pub

第三步，把公钥内容复制到代码托管平台的SSH密钥管理页面。以Gitee为例，在设置里找到“SSH公钥”，把内容粘进去保存。之后可以用以下命令验证是否通了：

ssh -T git@gitee.com

能输出欢迎语就说明配置成功了。这个检查方法几乎适用于所有主流托管平台。

6.2 多账号、多平台怎么不打架

不少人手上同时有GitHub、Gitee甚至公司内网的GitLab，每个平台的密钥不同，怎么管理？

我的做法是给不同的平台生成不同的密钥文件，然后在~/.ssh/config里做映射：

Host github.com HostName github.com User git IdentityFile ~/.ssh/id_rsa_github Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_rsa_gitee

这样Git在连接不同域名时会自动选择对应的私钥，互不干扰。还有一个配套的坑：某些平台的账号会按提交邮箱匹配身份，如果你在不同平台用了不同的邮箱，记得在克隆下来的每个仓库里用git config user.name和git config user.email设置本仓库级别的身份，覆盖全局配置。

6.3 VSCode里用Git：图形化不代表可以不懂命令

VSCode内置了Git支持，左侧的源代码管理面板（一般长着一个“分支”图标）能展现所有改动。它的好处是可视化：改动文件列表、diff视图、暂存操作、提交、推送、拉取，鼠标点几下就行。对于日常开发，用界面完全够。

但我还是建议不要完全依赖图形界面，原因有两点。第一，VSCode的Git面板只覆盖了高频操作，遇到复杂场景（比如冲突的精细处理、rebase过程中途中断）还是得回终端。第二，理解命令会让你在界面操作时知道每一步背后发生了什么，遇到报错不慌。

个人推荐的工作流是：日常add、commit、push、pull在VSCode里点，遇到冲突就打开终端用命令行解决。两边搭配干活，效率和理解都有。

6.4 git worktree：并行开发多个分支的另一种思路

最后聊一个不那么常用但很趁手的工具git worktree。它的作用是：同一个仓库可以检出新分支到独立的目录，同时并行。

场景是这样的：你当前在feature-A分支上开发到一半，突然需要在feature-B分支上做个紧急验证。传统思路不是stash就是clone，但worktree提供了一种更优雅的方式：

git worktree add ../project-b feature-B

这会创建一个新目录../project-b，里面检出feature-B分支。你可以一边在原来的目录里继续开发feature-A，一边在新目录里切换到feature-B干活，两个目录互不影响，但共享同一个对象数据库，不占额外历史空间。

用得多的场景是：同时维护“当前版本”和“下个版本”两条分支，需要频繁在两个版本间切换参照时，worktree比反复checkout舒服得多。如果团队里很多人共用一台开发机（比如某些测试环境机器），worktree还能避免不同分支在同一个工作目录里踩来踩去。

6.5 凭据管理：再也不会被反复要求输密码

如果你因各种原因还是用HTTPS方式，那么运行时反复输密码的痛我深有体会。Windows装Git官方包时自带了一个Windows凭据管理器，你可以在clone的时候让Git帮你记住凭据，之后push就用Windows系统存储里的凭据自动认证。

如果Git没自动启用，可以手动开启：

git config --global credential.helper manager

这个配置在不同平台有不同的后端，思路都是把凭据存到系统安全存储里。如果你发现自己的账号密码已经泄漏在Git历史里了，别只删文件，重点是要处理历史提交里的痕迹，平台上的“删除仓库重建”在某些场景反而是最省心的方案。

我做开发这些年，最深的体会是：Git不是一个需要背完命令才能用的工具，它更像一门“每天用几个高频操作、偶尔翻一次车、翻车后知道怎么救”的手艺。你只需要把clone、add、commit、push、pull、branch、merge这七个操作练到肌肉记忆，再从冲突、reset、stash、revert这些救急方案里慢慢吸收，就已经超过大半开发者了。至于那些花哨的进阶技巧，遇上了再去查，查完做笔记，慢慢地，它们都会变成你的日常。