Git 作为目前最知名的版本控制工具，早已成为开发者日常工作中不可或缺的利器。虽然长期使用积累了不少经验，但在实际开发中仍然会遇到各种值得记录的问题，因此专门创建这篇博客作为实践笔记，后续将持续更新补充。

本文主要记录个人在 Git 使用过程中的经验总结和疑难问题解决方案，内容偏重实践心得而非系统教学。需要说明的是，个人项目中的 Git 使用无需拘泥于严格规范，完全可以根据习惯自由操作；但若涉及团队协作或开源项目，则建议遵循既定的版本控制规范。

Commit 规范

commit 提交信息其实没有强制性的规定，个人使用时也完全可以不用在意这玩意，我的笔记仓库和备份仓库甚至是直接使用 update 2025_01_22 10:30:56 这种形式提交信息的。但是如果是在多人协同或者开源项目中，建议还是规范一下提交信息，这样方便自己和他人快速高效的查看提交的代码内容。

即使你不是多人协同开发，个人开发项目时也建议遵循一下规范，毕竟有不少时候我们会忘记当时开发的某样功能的逻辑和场景需求，通过清晰明了的 commit 的信息可以一窥我们当时的想法和思路

编写良好的 Commit messages 可以达到3个重要的目的：

加快代码 review 的流程
帮助我们编写良好的版本发布日志
让后续的维护者了解代码里出现特定变化和 feature 被添加的原因

目前业内主流推荐是 Angular 项目的 Git Commit Guidelines

# 完整版本
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

# 精简版本
<type>: <subject>

type 表示这次提交的类型，主要有以下几种：
- feat : 新增功能
- fix : 修复bug
- docs : 仅文档更改
- style : 不影响代码含义的更改（空白、格式设置、缺失分号等）
- refactor : 既不修复bug也不添加特性的代码更改
- perf : 改进性能的代码更改
- test : 添加缺少的测试或更正现有测试
- chore : 对构建过程或辅助工具和库（如文档）的更改
- delete : 删除功能或文件
- modify : 修改功能
- build : 改变构建流程，新增依赖库、工具等（例如webpack、gulp、npm修改）
- test : 测试用例的新增、修改
- ci : 自动化流程配置修改
- revert : 回滚到上一个版本
scope 非必选项，表示本次 commit 设计的业务/模块范围；
subject 简明扼要的阐述下本次 commit 的主旨；建议：使用祈使句，首字母不要大写，结尾无需添加标点；
body 同样使用祈使句，在主体内容中我们需要把本次 commit 详细的描述一下，比如此次变更的动机
footer 描述下与之关联的 issue 或 break change

多数情况下我们都是使用精简版即可，完整版使用的情况非常少；精简版无论是个人开发使用，还是团队协同开发使用都是非常棒的选择。

单次提交注意事项：提交问题必须为同一类别；提交问题不要超过三个；如果发现提交的 commit 不符合规范，git commit --amend -m "新的提交信息" 或 git reset --hard HEAD 再重新提交一次。

分支规范

以下内容是在多人协同开发时，团队的一些心得规范，如果你是独狼作战可直接忽视

业界常见的两大主分支（master、develop）、三个辅助分支（feature、release、hotfix）的生命周期

分支名称

master ：主分支，也是用于部署生产环境的分支，需要确保 master 分支稳定性。master 分支一般由 release 以及 hotfix 分支合并，任何时间都不能直接修改代码。
develop ：开发环境分支，始终保持最新完成以及 bug 修复后的代码，用于前后端联调。一般开发的新功能时，feature 分支都是基于 develop 分支创建的。
feature ：开发新功能时，以 develop 为基础创建 feature 分支。分支命名时以 feature/ 开头，后面可以加上开发的功能模块，命名示例：feature/user_module 、feature/cart_module。
test ：测试环境分支，外部用户无法访问，专门给测试人员使用，版本相对稳定。
release ：预发布分支，UAT测试阶段使用。一般由 test 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。
hotfix ：线上出现紧急问题时，需要及时修复，以 master 分支为基线，创建 hotfix 分支。修复完成后，需要合并到 master 分支和 develop 分支。分支命名以 hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似。

分支与环境

系统开发过程中常用的环境：
DEV 环境：用于开发者调试使用；
FAT 环境：功能验收测试环境，用于测试环境下的软件测试者测试使用；
UAT 环境：用户验收测试环境，用于生产环境下的软件测试者测试使用；
PRO 环境：生产环境，对外投放提供用户使用。

分支	功能	环境	可访问
master	主分支，稳定版本	PRO	是
develop	开发分支，最新版本	DEV	是
feature	开发分支，实现新特性		否
test	测试分支，功能测试	FAT	是
release	预上线分支，发布新版本	UAT	是
hotfix	紧急修复分支，修复线上问题		否

网络问题

这个可以说是使用 github 的一个重要门槛，使用代理这个我就不多说了，毕竟用能上 github 的同学基本都是知道的不需要我废话了。但是如果你的代理网络不是那么稳定，或者你想用一些免费稳定的，我这里推荐使用 Watt Toolkit(原名 Steam++) 来临时代替一下，这个软件本身是一个加速器，主要用来给 steam 进行网络加速，但它也内置了一个给 github 加速的功能，稳定性是非常可以的（默认情况下它是通过修改本地 hosts 文件配置来进行网络加速的，正常情况下它不会影响你原 hosts 文件中的内容）

遇到的网络问题

error: RPC failed; curl 56 Recv failure: Connection was reset
error: 4667 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output

这是我前几天遇到的一个问题，在我 clone 一个 github 仓库代码时出现的问题，表现出来的流程是：能够拉取到 git 信息和配置文件，但在下载仓库文件时出现了网速过慢的情况，并且临近下载完毕时会报出上面的错误信息，根据信息得知是连接被重置了。这种问题一般出现在仓库文件过多过大的情况下，我的这个仓库是一个「前端项目集合」，有很多个练习使用的前端项目被集中的放到了一起，但有对非必要文件进行屏蔽，当前仓库的大小也只有 16MB 左右，远远算不上大型仓库。其实可已通过页面上的 download ZIP 下载代码包，但这样的代码包是没有 git 配置和信息的，我必须使用 git clone。

网上提供的一些解决方案是：1、使用镜像替代访问；2、使用一些代理网站加速下载；3、修改 git 配置，设置传输缓存的阈值；4、换个代理。

第一种方法不适合我的仓库，这个仓库只是一个练习代码集合，很难被镜像仓库代理，尝试了也基本都是 400 错误。
第二种方法是可以下载到仓库代码的，但是是压缩包形式的，没错，这其实和直接在 github 仓库页面 download ZIP 是一样的结果，不符合我的预期。
第三种方法是对 git 进行一些配置上的调整，我也尝试了，但很可惜 clone 速度只是从原来的 20KB 提升到了 40KB 左右（WOW，网速翻倍嘞hhhhh），但可惜最后还是会出现上面的连接重置问题。

调整 git 配置的命令

# 取消相关的网络限制
git config --global http.lowSpeedLimit 0
git config --global http.lowSpeedTime 999999

# 设置传输缓存的阈值
git config --global http.postBuffer 524288000