分支管理必读 #
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.proxy
Commit 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 -w
ps:有适用于 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} -f
rebase #
rebase 的提交会破坏 Git 的时间线,是一种对外部分支不安全的提交方式,尽量只在自己分支用。
下游分支更新上游分支内容的时候使用 rebase
上游分支合并下游分支内容的时候使用 merge
更新当前分支的内容时一定要使用 --rebase
参数
合并最后四个 commit,最后提交的时候需要 push -f
git rebase -i HEAD~4
彻底搞懂 Git-Rebase - Jartto’s blog
GitHub 技巧 #
Commit message 可以通过 #13
这样的字符串指定 PR 或 Issue,Github 中大多项目尤其喜欢在 message 后面用括号专门包起来,比如 Fix xxx problem (#13)
。
fast-forward #
git merge 时默认是 fast-forward 方式。而 --no-ff
指的是强行关闭 fast-forward 方式,即会产生一个 merge commit。
![](https://raw.githubusercontent.com/tcitry/static/master/uPic/preview.png)