今天了解 Git，又看到一堆视频和资料，讲得特别复杂。老实说，我并不想把底层的东西都搞得那么清楚，毕竟用工具嘛，先能用起来最重要。

我自己理解的 Git，其实就是一个代码仓库管理器。我们真正需要做的事情，也没那么多。首先是在本地创建一个仓库，然后记住，其实我们有两个仓库：一个是本地的，一个是远程的。

接下来我们要做的，就是让本地和远程能对得上。写完代码之后，把它推送（push）到远程仓库就行。这样，远程就挂着我们最新的代码了。

所以总结下来，Git 对我来说，就是这么个简单的逻辑：本地写 → push 上去 → 同步远程。其他的命令和日志呢？等我慢慢用的时候，跟着ai来，这就已经有了大体的git逻辑了。

接下来你是入职到了一个新项目里面，首先别人说，你把项目拉下来看一下，发过来了一个仓库的url连接。实际上这个就是我们的远程仓库，我们看代码肯定是本地看的对吧，那么我们应该怎么做，就是给代码拷贝到本地呗。

说干就干，我先找个合适的文件夹，比如在桌面上新建一个"工作项目"文件夹。然后右键点击这个文件夹，选择"Git Bash Here"（前提是你已经装了Git客户端）。这时候会弹出一个命令行窗口，接下来就要输入命令了。

第一步，就是把远程仓库克隆到本地。克隆的命令特别简单，就是"git clone"加上远程仓库的URL。比如说，别人发我的URL是https://github.com/example/project.git，那我就输入"git clone https://github.com/example/project.git"，然后按回车。

这时候你会看到命令行里开始显示进度，大概意思就是正在从远程下载文件。等它跑完了，你再看看刚才的文件夹，就会发现里面多了一个和项目同名的文件夹，那里面就是完整的代码了。

推送代码

另一种情况是，你在本地写了个新项目，想放到 Git 上。那就需要从零开始：

echo “# mail” >> README.md # 新建说明文件
git init # 初始化本地仓库
git add README.md # 把文件加入暂存区
git commit -m “first commit” # 提交到本地仓库
git branch -M main # 建立 main 分支
git remote add origin https://github.com/autumuhh/mail.git # 关联远程
git push -u origin main # 推送到远程

这套命令看起来多，其实逻辑很直白：

本地创建仓库（git init）

写点东西并提交（git add + git commit）

告诉 GitHub：远程仓库在哪（git remote add）

把代码推送上去（git push）

这样，你的远程仓库里就有了跟本地一模一样的内容。

统一理解：Git 的简单逻辑

克隆（clone）：远程 → 本地

推送（push）：本地 → 远程

所以整个 Git 的流程，其实就是：

👉 想要代码？就 clone 下来。
👉 想上传代码？就 push 上去。

其他那些复杂的命令和操作，先不用管，等以后用到了再慢慢学。

推送代码

这时候肯定有同学会想，我写的都是加代码，我想推送应该怎么做，那也就是说将我们得代码推送到远程仓库。
我们一般都是推送到自己得分支，或者推送到主分支不建议这个哦。
其实很简单，就是用 git push 命令，把本地分支的内容同步到远程分支。

不过这里要注意一点：
我们一般都会推送到自己新建的分支，这样不会直接影响主分支（main/master）。因为主分支通常是用来放稳定代码的，如果大家都往主分支乱推，很容易出现冲突或者把项目搞坏。

所以常见的做法是：

在本地先创建一个属于自己的分支，比如：

git checkout -b feature/login

这里的 feature/login 就是分支名，你可以根据自己做的功能来起名字。

然后在这个分支上写代码、提交：

git add .
git commit -m “完成登录功能”

最后把分支推送到远程：

git push origin feature/login

这样，远程仓库就会多出一个 feature/login 分支。别人要看你的代码，可以直接切换到这个分支。等你的功能做完并测试通过，再由团队里的同学发起合并（Pull Request），把你的分支合并到主分支。

总结

推送到自己分支：安全、独立，不会影响主分支。

主分支（main/master）：要保持干净和稳定，一般不要直接推。

协作流程：本地写 → 提交 → 推送到自己分支 → 提交合并请求。

这样一来，团队协作就清晰了，主分支永远稳定，每个人都能在自己的分支上自由开发。

打开这个项目文件夹，你可以用VS Code或者其他编辑器打开看看。这时候，你已经成功地把远程仓库的代码拉到本地了。这一步是不是特别简单？

不过别急，拉下来之后，你可能还需要切换到指定的分支。那什么是分支呢？

分支的基本概念

简单来说，分支就是Git用来分离不同开发线路的一种方式。想象一下，你在写一本小说，主线剧情是一条分支，而你可能还想尝试一些不同的情节发展，这时候你就可以创建一个新的分支来写这些副线剧情。这样，主线和副线互不影响，你可以随时在不同的剧情发展之间切换。

在Git中，分支的原理也是类似的。每个分支都是一个独立的代码版本线，它们共享同一个代码库的历史，但可以有自己独立的修改。

为什么要有分支呢？最主要的原因就是方便多人协作和功能开发。如果所有人都在同一条代码线上工作，很容易发生冲突，而且也不好管理不同阶段的代码。有了分支，每个人可以在自己的分支上独立开发，等开发完成后再合并到主分支。

一个项目通常会有很多分支，比如开发分支、测试分支、主分支等等。这时候你可以用"git branch -a"命令来查看所有的分支，包括本地和远程的。输入这个命令后，你会看到类似这样的列表：

• master
• develop
• remotes/origin/master
• remotes/origin/develop
  前面带"remotes/origin/“的是远程分支，不带的是本地分支。当前所在的分支前面会有一个”*"号。

切换分支

如果需要切换到某个分支，就用"git checkout 分支名"命令。比如说，大家都在开发分支上工作，分支名叫"develop"，那你就输入"git checkout develop"，这样你的工作区就切换到develop分支了。

切换分支后，你会发现你的工作目录里的文件内容也会跟着变化，变成你切换到的那个分支的内容。这就像是你在不同的"平行宇宙"之间切换一样。

现在，你已经成功地把项目拉下来，并且切换到了正确的分支。接下来，你就可以开始看代码、修改代码了。当你改完代码后，就需要把你的修改保存并同步到远程仓库。这时候，我们要用到Git的一个重要概念——暂存区。

什么是暂存区？

暂存区就像是一个"购物车"。你在超市里买东西，不会拿一件就去结账一件，而是先把要买的东西放进购物车里，最后一起结账。Git的暂存区也是一样，你修改了多个文件后，先把它们添加到暂存区，确认没问题了，再一起提交。

为什么要有暂存区呢？因为有时候你可能修改了多个文件，但并不想把所有修改都一次性提交。有了暂存区，你可以选择性地把某些修改放入暂存区，其他的修改暂时不放进去，这样提交的时候就只提交暂存区里的内容。

如何使用暂存区？

当你修改完代码后，首先要用"git status"命令查看一下哪些文件被修改了。输入这个命令后，你会看到类似这样的提示：

On branch develop
Changes not staged for commit:
(use “git add …” to update what will be committed)
(use “git restore …” to discard changes in working directory)
modified: index.js
modified: app.js

Untracked files:
(use “git add …” to include in what will be committed)
new-file.js

这说明index.js和app.js被修改了，但还没添加到暂存区；new-file.js是一个新文件，Git还不认识它。

现在，你需要把这些文件添加到暂存区。添加的命令是"git add"，后面跟上文件名。如果你想添加所有修改的文件，可以用"git add ."（注意这个点是必须的，它代表当前目录下的所有文件）。

比如，你只想添加index.js，可以输入"git add index.js"；如果你想添加所有文件，就输入"git add ."。

添加完之后，再用"git status"命令查看，你会发现这些文件的状态变了，它们现在在暂存区里了。

提交修改

当你确认暂存区里的内容没问题了，就可以提交了。提交的命令是"git commit -m ‘你的提交信息’"。这里的提交信息非常重要，它要简明扼要地描述你做了什么修改，这样别人看你的提交历史时，就能清楚地知道你这次修改的内容。

比如，你修复了一个登录页面的bug，就可以输入"git commit -m ‘修复登录页面无法正常登录的bug’“。提交信息要尽量具体，不要写一些模糊的话，比如"修改了一些东西”。

提交成功后，你的修改就被保存到了本地仓库的历史记录里。这时候，你可以用"git log"命令查看提交历史，看看你都做了哪些提交。

Git冲突的处理

在多人协作开发中，经常会遇到一个情况：你修改了某个文件，而同时其他人也修改了同一个文件的同一部分内容，这时候就会产生冲突。冲突是Git中非常常见的情况，尤其是在多人同时开发一个项目时。

什么是冲突？

简单来说，冲突就是Git无法自动合并不同人对同一文件的修改。当Git发现两个或多个修改在同一个地方相互矛盾时，它就会标记这个冲突，需要你手动解决。

冲突是怎么产生的？
举个例子：你和同事小明都在develop分支上工作。你在本地修改了index.js文件的第10行，把"Hello World"改成了"你好世界"，然后提交到本地仓库。而同时，小明也修改了index.js文件的第10行，把"Hello World"改成了"Bonjour Monde"，并且已经把他的修改推送到了远程仓库。这时候，当你执行"git push"命令时，Git会告诉你推送失败，因为远程仓库有你本地没有的更新。

当你执行"git pull"命令拉取远程仓库的最新代码时，Git会尝试自动合并这些修改，但因为你们都修改了同一行，Git不知道应该保留谁的修改，这时候就会产生冲突。

如何识别冲突？
当冲突发生时，你会在命令行中看到类似这样的提示：
Auto-merging index.js
CONFLICT (content): Merge conflict in index.js
Automatic merge failed; fix conflicts and then commit the result.

同时，如果你用"git status"命令查看，会发现冲突的文件会被标记为"both modified"（双方都修改了）。

打开冲突的文件，你会看到类似这样的内容：
<<<<<<< HEAD
你好世界

Bonjour Monde

branch-a

这里的"<<<<<<< HEAD"到"=“之间的内容是你本地仓库的修改，”=“到”>>>>>>>> branch-a"之间的内容是远程仓库（或其他分支）的修改。

如何解决冲突？

解决冲突的过程其实就是在这两个版本之间做出选择，或者创建一个新的版本。具体步骤如下：

1. 打开冲突的文件，找到冲突的部分（就是有"<<<<<<<“、”=======“、”>>>>>>>>"标记的地方）
2. 根据实际需求，选择保留你本地的修改，或者保留远程仓库的修改，或者将两者结合起来创建一个新的版本
3. 删除冲突标记（<<<<<<<、=======、>>>>>>>）
4. 保存文件
5. 用"git add 冲突文件"命令将解决完冲突的文件添加到暂存区
6. 用"git commit -m ‘解决冲突’"命令提交解决冲突后的修改

比如，在上面的例子中，你可能决定将两种语言结合起来，改成"你好世界（Bonjour Monde）"，然后删除所有冲突标记。

解决冲突后的操作

解决完冲突并提交后，你就可以继续执行"git push"命令，将你的修改推送到远程仓库了。

需要注意的是，解决冲突时一定要仔细检查代码，确保解决后的代码逻辑是正确的，不会引入新的bug。如果对某些修改不确定，可以和相关的同事沟通确认。

总结一下，冲突并不可怕，它只是Git在告诉你：“这里有两个不同的修改，我不知道该选哪个，需要你帮我做个决定”。只要按照正确的步骤处理，很快就能解决冲突。

推送到远程仓库

提交到本地仓库后，你还需要把这些修改推送到远程仓库，这样其他人才能看到你的修改。推送的命令是"git push"。输入这个命令后，Git会把你本地仓库的修改同步到远程仓库。

不过，有时候推送可能会失败，这通常是因为远程仓库的代码已经被其他人更新了。这时候，你需要先拉取远程仓库的最新代码，用"git pull"命令，然后解决可能出现的冲突，再重新推送。

总结一下，修改代码后的流程就是：修改代码 → git add .（添加到暂存区） → git commit -m ‘提交信息’（提交到本地仓库） → git push（推送到远程仓库）。

总结一下，入职新项目拉取代码的步骤就是：找个文件夹 → 打开Git Bash → 输入git clone + URL → 切换到正确的分支。是不是比想象中简单多了？

其实Git并没有那么难，关键是要记住最常用的那几个命令。用得多了，自然就熟练了。遇到不会的命令，随时查一下或者问AI，慢慢你就会发现，原来Git也就那么回事儿。

有一个基础得了解之后可以看一下另一篇命令捋顺版本
git小白版本