企业官网建设流程全解析

1. 从“能用”到“规范”，Git到底该怎么玩

这两年我面试过不少开发，也带过十几个人的小团队，发现一个特别普遍的现象：很多人每天都在用Git，但对Git的理解停留在“add、commit、push”三板斧上，遇到冲突就慌，回滚靠复制粘贴，提交信息随便写“更新”“修改”“fix”。你说他不会吧，他天天commit；你说他会吧，仓库历史乱成一锅粥，哪天一个误操作，代码就没了。

Git这东西，说起来是工具，用起来是习惯，管好了是项目资产。一个项目能不能长久健康地迭代，Git使用规不规范，基本能看出七八分。这篇文章我不打算讲什么高深理论，就从一个实际干活的人的角度，把Git从安装配置、日常操作到团队协作规范的完整链路捋一遍。无论你是刚接触Git的新手，还是已经用了一两年但总觉得哪里别扭的老手，这篇都值得花十分钟过一遍。

先交代一下我平时的工作环境：主力机是Windows，跑的是Git Bash；服务器上都是Linux；偶尔在macOS上也有项目。所以下面的内容会覆盖这三个平台，但核心操作和命令是跨平台通用的。

2. 环境准备：Git安装与初始化配置

2.1 三个平台的安装方式

Windows用户最省事的方案是直接去Git官网下载安装包，但官网下载速度有时候不太稳定，我一般推荐用国内的镜像站。下载完双击安装，一路Next。真正需要在意的选项有两个：一个是默认编辑器建议选Notepad++或VS Code，不要用Vim，否则新手在提交时误入Vim界面会懵半天出不来；另一个是PATH环境变量的选项，我建议选“Git from the command line and also from 3rd-party software”，这样以后在cmd和PowerShell里也能直接敲git命令。

macOS用户最简单，装了Homebrew的话一条命令搞定，brew install git。没装Homebrew的，直接下载安装包也行。

Linux用户就看发行版了。Ubuntu系是sudo apt install git，CentOS系是sudo yum install git。云服务器上装Git基本都走这个路子。

注意：装完以后先在命令行输入git --version验证一下。看到版本号说明装好了。Windows用户在cmd或PowerShell里提示“git不是内部或外部命令”，十有八九是当时安装时PATH选项没选对，重装一次即可。

2.2 全球三件套与换行符处理

安装只是第一步，装完必须做初始化配置。核心是这三条：

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

第一条和第二条配置的提交人和邮箱信息，会被写进每一次commit记录里。很多团队代码评审时看提交人，如果这个信息没配好，提交历史里就是一堆“Unknown”。第三条是把默认分支从master改成main，这是近年来Git社区的推荐做法，英文单词main语义上也更中性。

Windows用户还要特别注意一行配置：

git config --global core.autocrlf true

这行配置跟换行符有关。Windows换行符是CRLF，Linux和macOS是LF。如果不做转换，Windows上正常提交一个文件到远端，Linux上打开全篇都是^M乱码。配置了core.autocrlf true之后，Windows上提交时自动把CRLF转成LF，拉取时再转回CRLF，这个坑基本就填平了。

配置完以后，用git config --list查看一下，确认所有配置都生效了再开始干活。

2.3 SSH免密配置：一次配置长期受益

日常开发中，每次push都要输密码是很折磨人的事，而且HTTPS方式在频繁操作时还可能被远程服务器限流。所以我建议第一步就配好SSH密钥。

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

一路回车即可，默认密钥存储在~/.ssh/id_rsa。然后执行cat ~/.ssh/id_rsa.pub查看公钥内容，复制。

去Gitee或GitHub的个人设置里，找到SSH公钥管理（Gitee叫“安全设置-公钥管理”，GitHub叫“SSH and GPG keys”），把公钥粘贴进去，保存。

验证是否配置成功：

ssh -T git@gitee.com

看到“Hi 用户名! You've successfully authenticated”就说明通了。以后clone仓库尽量用SSH地址，git@xxx.git，再也不用输密码了。Gitee生成密钥后会在后台异步绑定，有时候刚配置完会提示失败，等一分钟再试就好，这是正常现象，不用慌。

3. 核心概念：理解Git的工作区、暂存区与版本库

3.1 三个区域各干什么

Git难以理解，网上各种教程也讲得云里雾里，一个核心原因就是没把它的三个区域讲清楚。我打个比方。

你的项目文件夹就是工作区，也就是你编辑器里看到的那些文件；暂存区是存放你想要提交的文件列表的缓冲区，你可以理解成快递打包台；版本库是仓库的“存档点”，每次commit就是往存档点里写入一个快照。

工作区改了文件，你需要git add把文件放到暂存区，然后git commit把暂存区的内容正式归档到版本库。有人会问，为什么不直接commit呢？非要add一下，多此一举。这个设计恰恰是Git好用之处：它让你能分拣改动。一个项目里同时改了bug和新功能，你可以把bug相关文件先add、commit，新功能的文件后add、commit，历史记录干净清晰，评审和回溯的时候非常方便。

原始仓库的git status是个好帮手，它永远告诉你当前工作区和暂存区的状态：哪些文件被修改了，哪些文件在暂存区，哪些文件还没被跟踪。

3.2 .gitignore：从一开始就挂好挡板

配置好环境之后，下一步是给项目建立.gitignore文件。很多新手忽略这一步，结果node_modules、target、vender等依赖目录被提交到仓库里，仓库体积迅速膨胀，clone慢得像蜗牛，还会造成跨平台的冲突。

.gitignore基本的逻辑就是告诉Git：“这些文件不要管我”。一个常见的Java项目.gitignore长这样：

target/ *.class *.jar *.war *.log .idea/ *.iml .DS_Store

前端项目的node_modules同理。如果一个文件已经被跟踪了，再写进.gitignore是不生效的，得先执行git rm -r --cached 目录名把它从版本库里移除，只移除跟踪关系不用删本地文件，然后再提交.gitignore。

实操心得：.gitignore一定要在项目最开始就建好。中途加规则很麻烦，别人本地已经提交过node_modules再改规则，会有很多扯皮的事。

4. 核心操作：日常开发用到的Git命令全景

4.1 五个核心命令

日常开发中，90%的操作都落在五个命令上：add、commit、status、log、pull和push。掌握这五个，就能保证基本的协作开发不犯错。

git add src/main/java/com/example/UserService.java git commit -m "feat(user): add user registration API"

这里add可以精确到单个文件、多个文件、某个目录，或者git add .全部添加。个人建议：一天工作结束时不要无脑git add .，先git status看一遍改了哪些，再决定提交哪些文件。养成“看后add、想后commit”的习惯，比任何工具技巧都重要。

commit的提交信息不是随便写的。我见过最极端的例子是，整个仓库存活记录的提交信息全是“1”“2”“3”“aa”“bb”。这种记录别说同事看不懂，写提交的人自己过三个月回来看，也一脸茫然。所以后来我们团队定了一个规范格式：

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

type的取值有：feat（新功能）、fix（修bug）、docs（文档）、style（格式）、refactor（重构）、test（测试）、chore（构建或辅助工具）。scope指功能模块，subject是简短描述。举个例子：feat(user): 增加用户注册接口，一眼就知道这次提交做了什么、影响哪个模块、是功能还是修复。

4.2 分支管理与合并

分支是Git最强大的武器。团队开发里没有分支协作，所有人直接往main上推，后果就是冲突不断、历史混乱、出问题无法回滚。

我的工作流是：每开发一个新功能，从最新的main切一个新分支。

git checkout -b feature/login-page

这个命令创建并切换到新分支。然后在这个分支上开发、提交、推送到远端同名的分支上。功能开发完成后，发起合并请求到main，经过review之后合入。

合并方式有两种，merge和rebase。merge的特点是保留完整的合并历史，有个merge commit；rebase的特点是历史线性，像是分支上的提交直接“接”到了main末尾。对新人来说，我建议先用merge。rebase会改写提交历史，处理不好就是灾难，适合有经验的人在自己正在开发的功能分支上使用，不要对共用的主分支执行rebase。

当然，还有一个小众但高能的操作，git cherry-pick。它可以把另一个分支上的某个commit单独“复制”过来执行。

git cherry-pick commit哈希值

比如线上出了严重bug，修复后不想把整整一个功能分支合并上去，只想把那个fix提交拉到hotfix分支上发版，cherry-pick就是正解。

4.3 同步远程仓库与多源名配置

本地仓库和远端仓库之间的同步是每天的必修课。新手对这个流程有个非常大的误区，以为push之前一定要pull。其实不然。push之前要pull，是因为远端可能有人更新了代码，你需要在本地先把变化合进来，解决冲突，再推送。如果整个分支只有你自己在维护，没有远端变化，那直接push没有任何风险。

一个稳妥的更新方式是：

git pull --rebase

它先把本地未推送的提交“搬”到远端最新提交的后面，避免产生多余的merge commit，让历史保持线性。如果出现冲突，停下来解决冲突，git add冲突文件，然后git rebase --continue。如果搞复杂了，可以git rebase --abort，回到pull之前的状态重新来过。

我在服务器上管理的项目里，遇到过一种情况：git要求指定参数来使用某条命令。比如在Windows的git bash上clone一个包含中文文件名的仓库，仓库路径显示又会因为中文编码问题出现乱码。有些IDE工具在集成Git时会自动添加一些优化命令参数，比如：

git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks status

这个命令看着长，但拆开很简单。-c是按项目覆盖某一条配置；diff.mnemonicprefix=false是让diff结果里显示明确的a/和b/前缀；core.quotepath=false是让中文文件名正常显示而不是转成八进制转义序列；--no-optional-locks是禁止Git在只读命令执行期间拿一些非必要锁，避免并发时锁冲突。小乌龟（TortoiseGit）这类图形客户端内部经常用这种命令。理解了它的逻辑，你在自己敲命令时也可以按需求组合参数，不必死记。

5. 实操复盘：一整套Git工作流是怎么转起来的

5.1 用一个完整的场景串起全部操作

下面我用一个实际场景把上面的操作串起来。假设现在要从零开始，把本地的项目托管到Gitee上。

第一步，在Gitee上新建一个空仓库，不勾选任何初始化选项。拿到仓库的SSH地址：git@gitee.com:yourname/project-demo.git。

第二步，在本地项目目录执行：

git init git add . git commit -m "chore: init project skeleton" git remote add origin git@gitee.com:yourname/project-demo.git git push -u origin main

这里有个很小但很关键的细节：git remote add origin 地址是把本地仓库和远端建立关联的仪式。我见过有同学直接改.git/config文件去改远端地址，结果改错了格式，整个仓库推不上去。之后就长记性了，一律用命令操作。如果加了远程仓库地址后再修改，可以用git remote set-url origin 新地址。

-u参数的意思是--set-upstream，把main分支与origin/main关联。以后就不需要再指定远端和分支了，直接git push和git pull都知道找谁。

第三步，再拉一个开发流程。新建分支开发：

git checkout -b feature/user-register # 写代码... git status git add src/ git commit -m "feat(user): add register service" git push -u origin feature/user-register

页面提示创建合并请求，经过评审后合入main。然后回到本地：

git checkout main git pull git branch -d feature/user-register

开发完成，远端和本地分支都会清理掉。

第四步，如果发现main上有了别人的新提交，而你的本地main落后了，你在开发分支上想要同步这段变化：

git fetch origin git rebase origin/main

记住fetch和pull的区别：fetch只更新远端追踪分支的状态，不会动你当前工作区的文件；pull会直接合并到你当前分支。先fetch观察，再决定怎么整合，永远不会因为本地未提交的改动被打断而导致一堆槽糕的问题。

5.2 版本回退的高阶操作

Git最香的一点就是：代码出错可以回滚，你永远不会丢历史。

日常我最常用的回滚命令是git log --oneline查看提交历史，找到出问题的那次提交哈希值。如果只想撤销某一次的变更内容，保留后面的历史，用：

git revert 哈希值

git revert的妙处在于它不是把历史删掉，而是生成一个新的commit，把那次提交的改动反着执行一遍。这样历史里完整保留了“这次错了”和“这次改了”，适合已经推到公网分支的提交。

如果commit一直没push，只在本地，想要直接丢弃某次提交之后的所有改动，用：

git reset --hard 目的地哈希

这个命令非常危险，会把你工作区、暂存区、版本库全部恢复到目标状态，所有未提交的改动灰飞烟灭。我给自己定的一条铁律：reset --hard之前必须先git stash保存当前工作区，或者先提交一次标记为“wip不要动”，留着后悔药。

如果只是提交信息写错了，要修改最近一次提交的信息：

git commit --amend

这个命令会把上一次的提交替换成新的提交。只要还没推送，就随便用。但推送到远端后再amend就会重写公共历史，而且之后push会失败，需要强制推送才能覆盖远端。所以我一直强调，公共分支的提交历史不要改。

5.3 解决冲突的正确打开方式

冲突是Git协作里最让人头大的一环，但本质上非常机械。当远端有人也改了你正在改的同一个文件的同一段代码，git就不知道该保留谁的版本，于是它停下来说：你自己看着办。

冲突发生时，文件里会出现两边的内容和分隔符：

<<<<<<< HEAD 你本地刚刚写在暂存区或工作区的修改 ======= 别人已经推送到远端的修改 >>>>>>> 分支名

我的解决流程是：先读一遍冲突两边的代码逻辑，搞清楚两边的意图，按业务逻辑决定保留哪边、或手动合成两者，然后删除<<<<<<<、=======、>>>>>>>这些标记行，再git add冲突文件，最后把merge或rebase做完。

注意：在解决冲突的时候永远别只用“保留我看得懂的那份”，尤其不要默认以本地版本为准，因为线上出了意外，可能恰恰是别人那份修复了关键问题。拿不准的时候，把两边的作者拉上一起看。

6. 团队协作：一套可落地的Git使用规范

6.1 分支模型

团队协作中，比命令更重要的是一套大家都遵守的规则。我们团队的Git使用规范，最核心的分支模型是这样的：

• main：主分支，代码永远是可发布的状态。所有对外发布、生产环境部署都从main出包。
• feature/*：功能分支，从main切出，功能开发完毕合回main，合完即删。
• hotfix/*：线上紧急修复分支，从main切出，修复完成合并回main，同时合并回develop或相关迭代分支。
• release/*：版本发布分支，从main切出，打预发布版本、做测试修复，测试通过后合回main并打tag。

这个小模型把日常开发、线上修复和版本发布三条线拆开，互相之间不干扰。典型的一个场景：新功能feature-A开发到一半，线上出现严重bug，需要马上发hotfix。在场的人不需要停掉手上的活，因为hotfix和feature分支对应不同工作区，各推各的。

打个tag是我个人的强迫症状。每个发到线上的版本，必须带上tag：

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

版本号采用语义化版本规则：v主版本.次版本.修订号。主版本是重大不兼容更新，次版本是向后兼容的新功能，修订号是向后兼容的bug修复。出问题的时候，git checkout v1.0.0和上一个打过tag的版本做个对比就能定位是哪次提交引入了问题。

6.2 提交规范与Code Review习惯

团队的提交信息要统一格式。我见过网上很多提交规范，最终落地的是“约定式提交”这个流程：

• feat：新功能
• fix：修复bug
• docs：文档变化
• style：代码格式调整
• refactor：既不修bug也不增加功能的代码重构
• test：测试用例相关
• chore：构建过程或依赖工具的变动

写提交信息时，主题行不超过50个字（中文大约15个词），用现在时，小写开头。如果的修改比较复杂，主题下面隔一行写正文，用项目符号说明“为什么”和“怎么影响的”，而不是大量复制“改了什么”。

评审这块，我们内部有个不成文的规矩：合并一个feature分支之前，至少要有一个非作者的同事review过，确认代码风格、逻辑和命名没有问题。不管公司规模多小，把这个流程立起来，仓库质量就会有质的提升。

6.3 常用命令速查表

最后，我把平时使用频率最高的命令做了一张速查表，方便放在手边对照使用。

7. 踩坑实录：高频报错排查与解决方案

7.1 安装和基础环境问题

“git不是内部或外部命令，也不是可运行的程序”

这个问题在Windows上高频出现，本质是git安装后没有把安装目录的bin路径写入系统的PATH环境变量。我当时经历的情况是：安装时选了默认选项，某个安全软件拦截了安装程序修改环境变量的请求，结果装完只用图形界面没问题，一到cmd就报错。

排查方法：先where git看看系统能不能找到git。找不到就去控制面板-系统-高级系统设置-环境变量，把git安装目录下的Git/bin和Git/cmd加进PATH，重启终端。如果找不到安装目录，去“开始菜单-Git-Git Bash”右键打开文件位置，定位到真实安装路径。

**```bash fatal: not a git repository (or any of the parent directories): .git

这个报错一般是你站在一个不是Git仓库的目录里执行了Git命令，或者Git仓库的`.git`文件夹被误删了。先看 `pwd` 确认自己在哪里，再 `ls -a` 看看是否有`.git`目录。如果确实丢了.git，且本地没有备份，那就只能靠远端仓库重新clone了。所以再次强调：每天注意push，本地仓库不等于保险箱。 ### 7.2 远程仓库与认证问题 **Gitee push时提示登录失败，或者IDE提示“Login failed. Check API token or GitLab version”** 这个问题在IDEA集成Git时尤其常见。排查顺序：先确认SSH key是否配置成功，`ssh -T git@gitee.com` 看返回值；再看远端地址是不是用SSH，`git remote -v`，如果显示`https://`开头，说明用的HTTPS方式，IDEA里需要换成SSH地址或配置token。Gitee在2022年之后对HTTPS方式的密码登录做了严格限制，必须用私人令牌。很多人卡在这一步，其实是时代变了：不再支持直接输密码，一手创建私人令牌，一手在IDEA中配置，问题就解了。 **push被拒，提示“rejected”** 这个问题最有代表性的原因是：远端有本地没有的提交。可以用 `git pull --rebase` 先把远端变化拉下来，解决冲突后再push。如果确认本地就是要强制覆盖远端（比如只在本地的测试分支上，推错了想纠正），可以用 `git push --force` 或更安全的 `git push --force-with-lease`。后者在远端被别人更新过的场景下会拒绝强推，那就相当于多了一道保险，我极力推荐用这个参数。 **clone的时候极慢** 小乌龟或命令行clone一个大型仓库，几十兆每秒都跟不上。优先排查是不是走错了协议：HTTPS在某些云服务上反而比SSH慢。其次是仓库本身太大，建议浅clone只拉最近一层历史： ```bash git clone --depth 1 仓库地址

如果后续需要完整历史，再git fetch --unshallow。这不是常规最佳实践，但用来拉取超大仓库确实能解决实际问题。

7.3 日常使用中容易翻车的细节

git pull时遇到“Please commit your changes or stash them”

原因是你有本地未提交的改动，而远端更新与你的文件有重叠。这时候最省心的做法是：

git stash git pull --rebase git stash pop

stash会把工作区的改动暂存到一个临时栈里，拉完代码后再弹出来。如果stash pop时出现冲突，照前面解决冲突的流程处理即可。

文件大小写改名字，提交后远端没有任何变化

Windows默认文件系统不区分大小写，Bug的经典触发场景：目录从Users改成了users，本地看似改名成功，但git diff看不到变化，push上去Linux服务器上就出现了两个目录同时存在的问题。

解决方法是让git显式处理大小写变更：

git mv Users users

或者临时允许大小写敏感率：

git config core.ignorecase false

Git命令卡住不动、假死

在Windows上，这种问题高发于杀毒软件实时扫描繁忙的仓库目录，或者仓库里存在超大文件。Windows用户要在Windows Defender的排除清单里加上代码目录。另外，如果某个文件大于100MB，默认使用HTTP传输时会因为服务端限制直接失败。轻则重试，重则要把大文件清理出仓库，或者配上Git LFS专门管理大文件。

小乌龟提交时中文显示乱码

小乌龟（TortoiseGit）的历史提交中文乱码，一般是客户端显示的编码设置问题。在设置里找到“Git-编辑.git/config”，追加三行配置：

[gui] encoding = utf-8 [i18n] commitencoding = utf-8 [core] quotepath = false

重启小乌龟后，中文注释显示就正常了。这类问题绝大多数不是数据本身乱了，而是显示和解码层面的错位，配置好编码即可。

8. 写在最后：我个人的一点实践体会

前面讲了很多命令和规范，最后说点踩坑后沉淀下来的体会。

Git这个工具，真正给它注入灵魂的是“规范”两个字。对我自己来说，它直接改变了我的工作习惯：我写代码会下意识地保持小而清晰的提交粒度，一个功能点就是一次commit，绝不攒堆儿；我会在动手之前就花30秒想清楚“这次提交信息怎么写才让三个月后的自己看得懂”。

另外一个切身体会是：命令要手敲，不要总依赖图形界面。我见过太多人用SourceTree或小乌龟点按钮点得很熟练，一落到命令行就手足无措。但实际工作中你迟早会碰到只有命令行才能干的环境，比如没有图形界面的开发服务器，比如SSH连过去的跳板机。与其等碰到了再慌，不如平时就把高频命令敲熟。思维上把Git的模式架构建好，图形界面不违背命令行的知识体系，反而是锦上添花。

从某种角度说，Git用得好不好，不取决于你背了多少命令，而在于你是否把版本管理当成代码的一部分来对待。先把仓库建清楚，把分支规范立好，把每次提交写明白，这个项目的历史就会成为团队最靠谱的资产。愿你这篇文章的收获，能转化为明天仓库里那一行行干净清晰的log。