企业官网建设流程全解析

Git这玩意儿，我第一次接触的时候是真懵。当时觉得不就是写个代码、存个档嘛，为什么非要跟命令行打交道？后来带过几批新人，自己也踩了无数坑，才慢慢摸清了初学者真正需要的东西——其实没那么多，翻来覆去就是十几个常用操作而已。Git的定位是分布式版本控制系统，它的核心价值就两条：一是把代码历史完整记下来，想回退、想对比、想追责都有据可查；二是让多人同时干活不打架，各改各的，最后合并回来。这篇文章就是给完全零基础的你准备的，不扯Git内部对象模型那种深东西，我直接用实际场景带你走一遍：安装配置、本地提交、分支操作、远程协作、问题排查，每一步都是真实项目里天天要用的。你跟着敲一遍，基本就能应付日常开发了。

1. 装好Git环境：入门第一步不能含糊

很多人一开始就被安装劝退了，尤其是Windows用户。Git官网下载慢得跟蜗牛一样，而且安装界面全是英文，不敢点。这里我把三个主流系统的装法都过一遍，你照着选一个就行。

1.1 安装包的选择与下载

Windows用户优先找国内镜像，比如阿里云、清华的镜像站，下载速度舒服多了。拿到安装包后一路Next是能装完的，但有两个选项我建议你手动改一下：

• 在“Select Components”那一步，把“Git Bash Here”和“Git GUI Here”勾上。以后你在文件夹里右键就能直接打开命令行，方便很多。
• 在“Choosing the default editor”那一步，默认是Vim，新手最好换成别的编辑器，比如VS Code或Notepad++。因为Vim的退出方式对新手太不友好了，你不知道怎么保存退出会被困在里面。

装完之后在桌面或任意文件夹右键，看到“Git Bash Here”这个选项，说明安装成功了一大半。macOS用户可以直接用brew install git，装出来就是最新版；Linux用户更简单，Ubuntu系列用sudo apt install git，CentOS系列用sudo yum install git。装完统一跑一句git --version验证，能输出版本号就是成功。

提示：实际开发中很多人还会装小乌龟（TortoiseGit）这类图形化工具有，但你作为初学者，我强烈建议先用命令行。图形化工具屏蔽了太多细节，出了问题你根本不知道它背着你执行了什么命令。

1.2 初次配置：用户名和邮箱是提交的身份证

这也是新手最容易跳过的一步。你不配置直接commit，Git要么报错要么用乱七八糟的默认信息。Git要求每一条提交记录都有一个作者署名，这个署名就是你在git config里配置的用户名和邮箱。打开Git Bash，执行：

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

配置完了可以看一眼：

git config --list

这里有个小细节，--global意思是全局配置，对所有仓库生效。如果某个特定项目要用不同的名字，可以在那个项目目录下去掉--global配置一遍，这就是局部配置，优先级更高。所谓“身份证”的意思是，这些信息会跟着你的提交记录永久保存，今天配错了，以后翻历史都是错的，所以第一次就配准确。

1.3 验证安装与选择终端

配置完还是那句git --version，确认一切正常。接下来你几乎所有的Git操作都会在一个终端里进行——Windows推荐用Git Bash，不要用自带的cmd，因为很多命令行为在cmd里会出奇怪的问题；macOS和Linux用内置终端就行。

还有个隐藏技巧：如果你在VS Code里工作，直接按快捷键Ctrl+`打开内置终端，终端类型选Git Bash（如果没有可以点下拉箭头切换）。这样写代码和敲Git命令可以同屏操作，省得来回切窗口。我自己的习惯就是开着VS Code和Git Bash两个窗口并排，提交代码的时候瞄一眼终端输出，心里踏实。

2. 本地仓库完整闭环：从init到commit不再发怵

本地仓库是你电脑上那个被Git管理的项目文件夹。所有版本历史都存在里面一个叫.git的隐藏目录里。这一部分我们走一条闭环路径：初始化、暂存、提交、查看、回退，每一步我都拆开讲清楚，因为后面所有操作都是在这条链路上升级。

2.1 初始化仓库：git init到底做了什么

假设你有一个项目文件夹，想让Git开始管它，就在文件夹里执行：

git init

执行完之后文件夹里多了一个.git目录（Windows默认隐藏，你要在文件资源管理器里勾选“隐藏的项目”才能看到）。这个目录就是Git的“大脑”，所有提交记录、分支信息、配置全在里面的。我再强调一遍：不要手动改或删.git目录下的任何东西，否则轻则历史丢失，重则仓库整个废掉。

Git init只需要做一次。一个仓库对应一个项目，没必要本来就是个Git仓库的文件夹再重复init，除非你想倒腾子模块之类的进阶玩法，现在不用管。

2.2 提交闭环：add、commit、status、log

这是初学者每天要碰几十遍的四条命令。先说场景：你新建了一个index.html，想把它交给Git管理。第一步是暂存：

git add index.html

暂存（stage）可以理解成“打包区”。你要先告诉Git“这几个文件我这次要管”，它才理会。git add .就是把这个目录下所有改动都暂存。这里有个坑要提醒：git add .会把新文件、修改文件、删除文件的状态都纳入暂存区，但如果你有生成目录、日志文件、编译产物，也会被一并暂存，所以后面我们还要讲.gitignore。

暂存之后用git status看状态，你会看到绿色的“Changes to be committed”列表，说明文件已经进暂存区了。然后是提交：

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

-m后面的信息是这次提交的说明，一定要写得自己能看懂。我看到有人写“修改了一些内容”这样的提交信息就头疼，三个月后你自己都忘了当时改了什么。提交成功之后，用git log --oneline看历史，简洁地显示每一条提交的哈希值和说明。

这几个命令的关系我给你打个比方：git add是把行李放进箱子，git commit是给箱子贴封条写上日期和内容，git log是查看仓库里的所有箱子。提交之前，你随时可以打开箱子重新整理；提交之后，就成历史了。

2.3 撤销与后悔药：restore、checkout、amend

写代码一定会写错，git提供了后悔药。这里有三个场景，对应三个常用场景：

**场景一：工作区文件改坏了，还没add。**你要把它恢复到上一次提交时的内容：

git restore 文件名

git checkout -- 文件名是老版本写法，效果一样。注意这个操作会丢失你的修改，没有确认弹窗，慎用。

场景二：文件已经add进暂存区了，想把它撤出来，但保留工作区的修改。

git restore --staged 文件名

这相当于把行李从箱子里拿出来，但你人还在原地。

**场景三：commit时提交信息写错了，或者发现漏了一个文件。**用--amend来补救：

git commit --amend -m "修正后的提交说明"

--amend的意思是把“最后一次提交”替换掉，不会生成一条新提交记录。比如你提交了A，然后觉得说明不准确，执行amend后，历史里只有一条A'，A消失了。这里有一条非常关键的提醒：amend只适合本地还没推送的提交。如果已经git push到远程了，再去amend，会导致本地历史和远程历史分叉，新手处理起来非常头疼。

2.4 让Git听话：.gitignore文件

我前面一直提生成目录和编译产物，比如Java项目里的target、Python项目里的__pycache__、Node项目里的node_modules。这些文件体积大、改动频繁，而且每次都能重新生成，根本不该进Git历史。解决办法是在项目根目录建一个.gitignore文件：

node_modules/ target/ *.log .env .DS_Store

写完之后再git status，被忽略的文件就不会出现在未跟踪列表里。这个文件本身要提交到Git仓库，这样别人clone你的项目，也能自动忽略这些目录。很多初学者一开始不建.gitignore，结果提交了一堆没用的文件，仓库体积暴涨，后面清理历史又得折腾半天，不如刚开始就做好。

3. 分支操作实战：多人协作不乱套的关键

分支是Git最强大的功能，也是新手从“单机版”迈向“团队协战”的必经之路。简单理解，分支就是从一个时间点分出去的一条独立工作线，你在这条线上随便折腾，不影响主线上别人的工作。等你搞定了，再合并回去。

3.1 分支的创建、切换与删除

先记住一个约定俗成的规范：主分支叫main（GitHub和Gitee默认，旧仓库可能叫master）。工作时永远别直接在主分支上改代码，而是为每个功能开一个分支。创建并切换到新分支：

git checkout -b feature/login

这个命令相当于做两件事：创建分支feature/login并切换过去。老版本要分两步写，现在一条搞定。你自己验证一下当前在哪个分支：

git branch

普通的git branch会列出所有本地分支，当前分支前面有个*。切换分支用git switch或git checkout 分支名，推荐新写法git switch，因为语义明确，不容易和撤销文件的checkout混淆。

分支命名尽量用语义化，比如feature/注册功能、fix/修复登录超时、chore/升级依赖，一目了然。别整test、123这类名字，隔两天你就忘了这分支是干啥的。删除分支用：

git branch -d 分支名

删除已合并的分支用-d，没合并就删要用-D强制删。但要提醒一句：不要删自己没把握的分支，特别是里面的提交还没合并的，删了就真没了。

3.2 合并分支：merge的两种形态

开发完feature/login之后，要把代码合回主分支。先切回main，再执行merge：

git checkout main git merge feature/login

merge有两种结果。如果main从分出去之后一直没动过，Git会直接“快进合并”（fast-forward），把main的指针直接移动到feature分支的最新提交上，历史是一条直线，非常干净。但如果main在中间有其它提交了，Git就会创建一个新的“合并提交”（merge commit），把两边的工作合并到一起，历史会出现分叉再合并的形状。

新手看到merge冲突会慌，但别怕，后面专门讲冲突解决。这里你先记住一个原则：合并前确保工作区是干净的——git status显示“nothing to commit, working tree clean”再merge，免得合并时把你的未提交修改也卷进去。另外，分支合并完，feature/login的分叉点其实已经没用了，直接用git branch -d删掉就行。

3.3 提交前检查：养成一身好习惯

在git add .之前，先花十秒钟看一眼改了什么：

git diff

这个命令显示工作区里哪些文件改动了、改了什么内容。对于新增文件，git diff默认不显示，你之后要git add了再用git diff --cached查看。我的建议是：提交前精确地add，尽量少用git add .一把梭。比如这次只改了登录相关的三个文件，就：

git add src/login.js src/Login.vue src/api.js

这样提交历史里每次改动内容都很聚焦，将来排查问题、做回溯都清爽。最后再git commit -m "实现登录功能：接入后端接口"，完成一次高质量提交。

4. 远程仓库协作：推送、拉取与冲突解决

本地玩转了，接下来把代码放到远程仓库。国内的Gitee、国外的GitHub，概念完全一样，都是帮你托管代码的远程服务器。有了远程仓库，你能在多台电脑间同步代码，别人也能通过它协作。

4.1 克隆与关联远程仓库

两种常见情况。第一种：项目已存在于远程仓库，你想把它拉到本地，直接：

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

Git会把整个项目连同所有历史版本下载到当前目录。需要注意，clone的时候你可以加一个参数指定本地目录名：

git clone https://gitee.com/用户名/仓库名.git 自定义目录名

第二种：本地已经有项目，想关联到远程空仓库。先在远程创建一个空仓库，然后在你本地项目里执行：

git remote add origin https://gitee.com/用户名/仓库名.git

origin是远程仓库的别名，约定俗成，大家都这么叫。查看关联关系用：

git remote -v

如果关联错了想换，先git remote remove origin再重新add。很多新手在本地init之后，直接光push到远程，结果碰到“fatal: 未找到远程引用”之类的报错。原因就是没先关联远程地址，你对照上面几步检查一下。

4.2 SSH密钥配置：免密推送的正确姿势

使用HTTPS地址推送代码，每次都要输用户名密码或Token，很烦。推荐配置SSH密钥，一键免密。配置步骤很简单：

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

一路回车，会生成一对密钥：私钥id_rsa在本地，公钥id_rsa.pub要配置到远程平台。在Git Bash里执行：

cat ~/.ssh/id_rsa.pub

复制输出的一长串字符，粘贴到Gitee/GitHub的“SSH公钥”管理页面。完了之后测试连通性：

ssh -T git@gitee.com

第一次连接会提示是否信任主机，输入yes回车。看到“成功登录”之类的提示就说明通了。之后把远程地址换成SSH格式（git@gitlab.com:用户名/仓库名.git），从此push不再问密码。这是真·一劳永逸的操作，建议一开始就做。

4.3 push/pull与冲突解决

推送和拉取是全流程里最容易出问题的环节。推送到远程：

git push

如果是第一次推送，要把本地分支和远程分支关联起来：

git push -u origin main

这里的-u（全称是--set-upstream）会记住本地分支和远程分支的对应关系，以后直接git push就可以了。拉取远程更新：

git pull

注意，git pull其实是两步操作合二为一：先git fetch把远程更新下载到本地，再git merge合并到当前分支。另一种场景是队友推了新提交，你在推之前需要先pull一下，这是因为远程分支比你的本地分支领先了，Git不允许你用老历史覆盖新历史，必须先把远程的拉下来合并。

如果两人改了同一个文件的同一块代码，Git就不知道该听谁的，于是产生冲突。冲突发生时，你会在冲突文件里看到：

<<<<<<< HEAD 你本地这段代码 ======= 远程或对方分支的代码 >>>>>>> feature/test

解决步骤是：手动打开冲突文件，把<<<<<<<、=======、>>>>>>>这些标记行删掉，决定保留哪边的代码，或者把两边手动合成一段新代码。然后正常走git add 冲突文件、git commit完成合并。别用编辑器一顿乱改忘了删除标记行，提交后历史里会留着丑丑的冲突标记，很丢人。

注意：不要在conflict标记还没清理的情况下就提交代码，轻则编译不过，重则把有问题的代码推给所有人。

5. 初学者高频故障排查速查表

到了实操环节最常踩的几个坑。我按“问题-原因-解决办法”列出来，你遇到的时候直接来查就行。

5.1 三个最常见的fatal报错

问题一：fatal: not a git repository (or any of the parent directories): .git

原因：你当前目录不是Git仓库，或者根本没初始化。解决办法：确认是不是在项目目录下（看有没有.git目录），没初始化就git init，如果是在子目录里，往上一级走进仓库根目录再执行。

问题二：fatal: 'origin' does not appear to be a git repository

原因：你没有关联远程仓库，或者关联地址写错了。解决办法：git remote -v查看当前关联了哪些remote，没有就重新git remote add origin 地址，有误就删掉重加。

问题三：fatal: The current branch has no upstream branch

原因：当前分支没有和远程分支建立追踪关系。解决：git push -u origin 分支名建立关联。写错分支名也会这样，检查一下拼写。

5.2 账号密码缓存与清理

很多初学者配置了HTTPS地址后，密码错了一次，后续操作一直被卡在验证环节。Windows用户最常见的是凭据管理器里存了旧密码。你可以在控制面板里搜“凭据管理器”，找到“Windows凭据”，把里面Git相关的条目删掉，下次push会重新弹窗让你输入。或者用命令行清理：

git config --global --unset credential.helper

如果之前输错了Token、账号密码，多检查一下凭据管理器，别跟命令行死磕。macOS用户则是在“钥匙串访问”里找Git相关的条目删除。这些都是很典型的“疑难杂症”，但处理过一次之后就再也不怕了。

5.3 提交历史整理技巧

有两个高频场景。场景一：想修改最近一次提交的说明，且还没推送，用git commit --amend -m "新说明"。场景二：把多个提交合并成一个，方便别人review代码。比如你开了个分支写了20个commit：“改了一点”“再改一点”“改错了又改回来”，这种提交历史很脏，可以合并。但初学者用git rebase -i容易把历史改坏，我的建议是：先别搞rebase，多练习几周，把基本流程玩熟了再碰它。你要真遇到需要整理的情况，最简单的办法是新建一个干净分支，把改动重新提交一遍，旧分支删掉。

其他排查场景：推送到远程时出现“Merge branchxxx”的自动合并提交，一般是你没pull直接push导致Git帮你自动合了一次，解决方法是以后push之前先pull。遇到“failed to push some refs”则先看具体错误，通常能猜到是分支保护或没pull。

最后说点实在的

从第一次git init到能在团队里顺畅协作，大概就是上面这些命令反复用、反复熟的过程。我见过太多人一开始就想把命令全背下来，其实没必要，你只要把“add→commit→push”这条主链路跑通，再慢慢往里加分支、冲突解决这些分支场景，Git就会越来越顺手。个人体会是：提交信息要写人话、分支要按功能建、推送前一定要pull、宁可多提交不要憋大招。这些习惯看着不起眼，几个月后回头看，就是它们帮你少踩了80%的坑。你把这篇文章里的操作挨个敲一遍，基本就能从“Git小白”毕业了。