假设你现在要开发一个功能：
手机号登录。
标准流程不是直接开写，而是先同步主分支。
git checkout main
git pull origin main
这一步很重要。
如果你的 main 已经过时，后面合并时更容易出现冲突。先拉最新代码，等于从一个干净、最新的起点出发。
接着，创建功能分支：
git checkout -b feature/login
这行命令做了两件事：
feature/login现在你就可以放心开发登录功能了，比如：
开发过程中，不建议把所有修改攒到最后一次性提交。...
很多刚学 Git 的人，都会这样写代码：
git checkout main
git pull
git coding...
git push
看起来很顺手，问题也往往来得很突然。
某一天，你会发现：同事的代码被覆盖了，半成品功能进了主分支，一个小 Bug 影响了整个项目。更麻烦的是，出了问题之后，很难快速回滚。
这就是团队开发里很少直接在 main 分支写代码的原因。
更常见的做法是：
一个功能，一个 feature 分支。
比如团队同时开发几个功能：
main
├── feature/...很多人第一次学 Git 分支时，都会觉得它像一种“黑魔法”。
明明：
更离谱的是：
git checkout dev
短短一秒钟，整个项目居然就“变了”。
于是很多人开始背命令：
git branch
git checkout
git merge
git rebase
命令会用了。
但心里始终有个疑问：
Git 分支，到底是什么？
这篇文章，我们不聊复杂源码，也不讲晦涩概念。
只做一件事：
用人话，真正理解 Git 分支的工作原理。
看完之后，你会明白：
很多人学 Git 时，最先记住的命令是：
git add .
git commit -m "fix bug"
git push
可一旦项目真正开始协作，你会发现：
真正有价值的，不是“怎么提交代码”，而是“怎么理解代码为什么变成现在这样”。
这时候，git log 就开始变得重要了。
它不是一串无聊的提交记录。 它更像项目的“时间机器”。
你能从里面看到：
很多高级开发者排查问题时，第一反应不是打开 IDE，而是先看 git log。
很多人第一次用 Git 时，都会遇到一个很尴尬的问题：明明已经写了 .gitignore，为什么文件还是被提交上去了？
比如：
node_modules/
.env
dist/
看起来没毛病，对吧？
可现实往往是：node_modules 还在 Git 里，.env 也已经被提交过，甚至团队成员一拉代码，发现你的本地配置、日志文件、构建产物全都混进了仓库。
.gitignore 是 Git 里非常基础的文件，但它背后的规则并不总是直觉化。今天这篇文章，我们就用最接地气的方式，把 .gitignore 的写法、常见坑和最佳实践一次讲清楚。
| 命令 | 中文注释 |
|---|---|
gi... |
很多人觉得 Git 难，其实真正高频使用的命令可能只有几个。别一上来学分支和工作流，先完成你的第一次提交。代码管理的第一步，不是复杂，而是开始。
git --version
# 查看 Git 是否安装成功
git config --global user.name "你的名字"
# 配置 Git 用户名
git config --global user.email "你的邮箱"
# 配置 Git 邮箱
cd git-demo
# 进入项目目录
git init
# 初始化 Git 仓库
git add hello.txt
# 添加指定文件到暂存区
git ...很多人在开发时，都会遇到这样一种情况：
这时候最常见的问题就是：
“如何把一个已有代码目录，配置成 Git 仓库？”
今天这篇文章，就带你完整走一遍。
适合：
全部通用。
简单理解：
Git 会在你的项目里创建一个：
.git/
隐藏目录。
这个目录会记录：
也就是说：
...