分支管理必读#
A successful Git branching model
Github 网络问题#
如果在本地 Terminal push 不上去代码，可以尝试在 /etc/hosts 中加入下面代码，明确指定 github.com 的 IP 地址。
140.82.112.4 github.com另外也可以尝试修改 DNS，防止被污染。
Xcode 项目依赖#
使用 Clash 魔法
git config --global https.github.com.proxy socks5://127.0.0.1:7890
# unset
git config --global --unset https.github.com.proxyCommit Message 规范#
- Feat 新功能（feature）
- Fix 修补bug
- Docs 文档（documentation）
- Style 格式（不影响代码运行的变动）
- Refactor 重构（即不是新增功能，也不是修改 Bug 的代码变动）
- Test 增加测试
- Chore 构建过程或辅助工具的变动
自动生成 Change Log#
使用这个项目 conventional-changelog
npm install -g conventional-changelog
cd my-project
conventional-changelog -p angular -i CHANGELOG.md -wps：有适用于 vscode 等编辑器的插件。
参考 Commit message 和 Change log 编写指南 - 阮一峰的网络日志
工作区、暂存区、缓冲区#
在 Git 中，工作区（Working Directory）、暂存区（Staging Area） 和 仓库（Repository） 是三个核心概念，它们共同构成了 Git 的工作流程。以下是它们的简要介绍：
1. 工作区（Working Directory）#
- 定义：工作区是你在本地文件系统中看到的目录，包含项目的所有文件和文件夹。
- 作用：在这里你可以编辑、添加或删除文件。
- 特点：
- 工作区中的文件可能是已跟踪的（tracked）或未跟踪的（untracked）。
- 已跟踪文件是 Git 已经管理的文件，未跟踪文件是新增的或未被 Git 管理的文件。
- 命令：
git status：查看工作区的状态（哪些文件被修改、哪些未跟踪）。git add：将工作区的修改添加到暂存区。
2. 暂存区（Staging Area）#
- 定义：暂存区是一个临时区域，用于保存你准备提交的更改。
- 作用：将工作区的更改分阶段提交，可以选择性地添加文件或部分更改。
- 特点：
- 暂存区是工作区和仓库之间的缓冲区。
- 通过
git add将工作区的更改添加到暂存区。 - 通过
git commit将暂存区的内容提交到仓库。
- 命令：
git add <file>：将文件添加到暂存区。git reset <file>：将文件从暂存区移回工作区。
3. 仓库（Repository）#
- 定义：仓库是 Git 存储项目历史记录的地方，包含所有的提交、分支和标签。
- 作用：保存项目的完整历史记录，支持版本回退、分支管理和协作开发。
- 特点：
- 仓库分为本地仓库和远程仓库。
- 本地仓库存储在
.git目录中，远程仓库存储在服务器上（如 GitHub、GitLab）。 - 通过
git commit将暂存区的内容提交到本地仓库。 - 通过
git push将本地仓库的更改推送到远程仓库。
- 命令：
git commit：将暂存区的内容提交到仓库。git log：查看仓库的提交历史。
工作流程示例#
- 修改文件：在工作区编辑文件。
- 添加到暂存区：使用
git add将修改的文件添加到暂存区。 - 提交到仓库：使用
git commit将暂存区的内容提交到本地仓库。 - 推送到远程仓库：使用
git push将本地仓库的更改推送到远程仓库。
总结#
| 区域 | 描述 | 关键命令 |
|---|---|---|
| 工作区 | 你正在编辑的文件和目录，包含已跟踪和未跟踪的文件。 | git status, git add |
| 暂存区 | 临时保存你准备提交的更改，可以选择性地添加文件或部分更改。 | git add, git reset |
| 仓库 | 存储项目的完整历史记录，包含所有的提交、分支和标签。 | git commit, git log, git push |
通过理解这三个区域的关系，你可以更好地掌握 Git 的工作流程，高效管理代码版本。
git submodule#
git submodule add <repository> <path> #添加子模块
git submodule init #初始化子模块
git submodule update #更新子模块
git submodule foreach git pull #拉取所有子模块更新本地submodule代码为最新
git submodule update --recursive --remote如果你已经克隆了项目但忘记了 —-recurse-submodules，那么可以运行 git submodule update —-init 将 git submodule init 和 git submodule update 合并成一步。如果还要初始化、抓取并检出任何嵌套的子模块， 请使用简明的 git submodule update —-init —-recursive。
push 了错误的文件#
需要恢复到上一次的修改到缓冲区，
把 HEAD 指到上一版
git reset --soft HEAD^修改文件
维持上次 commit 的信息
git commit -a -c ORIG_HEAD强制 push
git push origin {your-branch} -frebase#
rebase 的提交会破坏 Git 的时间线，是一种对外部分支不安全的提交方式，尽量只在自己分支用。
下游分支更新上游分支内容的时候使用 rebase
上游分支合并下游分支内容的时候使用 merge
更新当前分支的内容时一定要使用 --rebase 参数
合并最后四个 commit，最后提交的时候需要 push -f
git rebase -i HEAD~4彻底搞懂 Git-Rebase - Jartto’s blog
推荐的工作流程#
# 1. 开始新功能
git checkout -b feature/awesome-feature
# 2. 开发并定期提交
git add .
git commit -m "实现功能A"
# 3. 更新主分支代码
git checkout main
git pull --rebase
# 4. 整理功能分支
git checkout feature/awesome-feature
git rebase -i main # 整理提交
# 5. 测试后合并
git checkout main
git merge --ff-only feature/awesome-feature
git push origin main
# 6. 清理分支
git branch -d feature/awesome-feature通过采用这些方法，你可以显著减少不必要的 merge commit，保持 Git 历史的清晰和可读性。选择哪种方法取决于你的团队规模、项目需求和个人偏好。
⚠️ 注意事项#
何时不适合使用 Rebase：#
- 公共分支：已经推送到远程且其他人正在使用的分支
- 团队约定：如果团队明确要求保留合并历史
- 审计需求：需要完整记录所有合并操作的项目
Rebase 的风险：#
- 会重写提交历史
- 可能导致冲突需要手动解决
- 对新手可能不太友好
GitHub 技巧#
Commit message 可以通过 #13 这样的字符串指定 PR 或 Issue，Github 中大多项目尤其喜欢在 message 后面用括号专门包起来，比如 Fix xxx problem (#13)。
fast-forward#
git merge 时默认是 fast-forward 方式。而 --no-ff 指的是强行关闭 fast-forward 方式，即会产生一个 merge commit。
