弥勒鹿1. 为什么每个团队都需要一份"看得见"的提交规范
先说个我真实经历过的场景。前两年团队进了一批新人，其中一个同学特别勤快，一天能提交十几次代码，但每一次的提交信息都是"update""修改""改了一点东西"。刚开始大家没在意，直到有一次线上出了个bug，需要回滚到某个历史版本。我在git log里翻了一下午，愣是没找到"这个功能到底是哪次提交引入的"。那一刻我才意识到，提交信息写得随便，不是小事，它会在项目最需要追溯的时候，变成一堵墙。
所以这篇东西不是写给"会用git"的人，而是写给那些刚进团队、刚接触协作开发、还不清楚"提交代码到底该怎么写"的新同学。它的目标只有一个：让你在团队仓库里留下的每一条记录，都能让三个月后的自己、让接手你代码的同事，一眼看明白"这次改动做了什么、为什么这么做"。
很多新同学会把Git当成一个"代码备份工具"，觉得只要把文件传上去就算完成任务。其实在团队协作里，Git更像是一本团队共同书写的"项目日志"。你每一次commit、每一次合并，都会写进这本日志里。日志写得清楚，大家查问题、做复盘、发版本都顺畅；日志写得潦草，整个团队的协作效率都会被拖累。
我见过很多所谓的"提交规范"文档，上来就甩一堆英文单词和命令，新人看完一头雾水，该怎么写还是怎么写。这篇文章我的写法不一样：先讲清楚"为什么"，再给"怎么做"，最后附上可以直接照抄的示例。你不光能知道规范长什么样，还能理解这套规范背后的逻辑。这样就算以后让你自己定规范，你也能定出一套合情合理的来。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 上岗第一天：把Git环境收拾利索再谈协作
很多新同学遇到的第一道坎，其实不是提交规范本身，而是Git环境压根没配好。我看关联搜索词里，一大半都是"git安装""git配置""git免密""git不是内部或外部命令"这类问题。这些基础工作不搞定，后面全是空中楼阁。
2.1 安装Git，以及那句"git不是内部或外部命令"到底怎么破
Windows用户去官网下载安装包，一路Next就能装好。macOS用户如果装了Homebrew，一条brew install git就完事，没装的话去官网下pkg安装包也行。Linux用户更简单，apt install git或者yum install git按发行版来。这些属于基础操作，我不展开细说。
真正让无数新人卡住的，是装完之后在命令行敲git --version，系统回你一句"git不是内部或外部命令"（Windows）或者"command not found"（macOS/Linux）。这句话的意思是：系统在可执行程序的搜索路径里找不到git这个程序。Windows上八成是安装时没勾选"Add to PATH"，或者装完没重新打开命令行窗口。解决办法是手动把Git的安装目录（默认在C:\Program Files\Git\cmd）加到系统环境变量的Path里，然后重新开一个终端窗口。macOS上如果用的是pkg安装包，通常会装到/usr/local/git/bin，因为路径没注册导致找不到命令，可以用export PATH="/usr/local/git/bin:$PATH"临时加上，或者干脆用Homebrew重装一遍省心。
提示：换电脑、换终端后先别急着干活，敲一句
git --version确认环境正常。这一步十秒钟，能帮你省下后面好几个小时的排查时间。
2.2 让Git记住"你是谁"，这不是可有可无的步骤
装好Git之后，不做任何配置也能用，但如果你直接开始提交，就会遇到一个很尴尬的情况：提交记录里的作者信息是错的或者空的。Git官方文档里有一句话我一直很认同：每一次提交都附带着作者信息，这个信息会永远留在项目历史里。所以提交之前，先告诉Git你是谁。
bash复制git config --global user.name "你的姓名"
git config --global user.email "你的邮箱"
注意这里的邮箱，如果你在公司项目里协作，最好用公司邮箱或者你常用的、和代码托管平台一致的邮箱。因为现在很多托管平台（GitHub、GitLab、Gitee等）都是靠邮箱来关联提交记录和账号头像的。邮箱不一致的话，你的提交虽然显示了对的名字，但在平台上看不到跟你账号的关联，头像是灰的，甚至你那个"提交者"身份都对应不到人。很多新同学在这步嫌麻烦，随便填了一个，后来做代码统计、审批流程的时候才发现对不上，又得改历史，折腾得很。
2.3 SSH免密配置：让push不再每次问密码
关联热词里"git免密""ssh配置教程"扎堆出现，说明这是新人另一个集中翻车点。很多同学的第一个git仓库用的是HTTPS地址，每次push都要输账号密码。一次两次还能忍，一天push十几次真的会心态爆炸。解法就是SSH免密。
流程就四步：
- 生成密钥对：
ssh-keygen -t rsa -b 4096 -C "你的邮箱"，一路回车即可。 - 查看公钥：
cat ~/.ssh/id_rsa.pub，把输出内容完整复制。 - 登录你的代码托管平台，在个人设置的"SSH Keys"或"公钥管理"里粘贴保存。
- 测试连接：
ssh -T git@github.com（以GitHub为例），看到欢迎语就说明通了。
之后把仓库地址从HTTPS换成SSH格式，例如git@github.com:用户名/仓库名.git，再push就不会再要密码了。这里有个小坑：公司的电脑上可能同时存在多个Git账号，比如一个个人GitHub、一个公司GitLab。这时候建议用~/.ssh/config文件来做多账号配置，每个Host对应一个IdentityFile，别图省事把密钥混着用，否则很容易出现一个仓库push到另一个平台、权限报错的问题。
2.4 还有三个值得提前设置的"协作友好"配置
第一个是换行符处理，git config --global core.autocrlf true（Windows）或input（macOS/Linux）。这个配置解决的是Windows和Linux系统之间回车换行符不一致的问题。不配的话，你可能会看到明明没动过的文件，在git diff里显示整片整片的变更，那八成就是换行符在作怪。
第二个是设置默认编辑器，git config --global core.editor "code --wait"。这样当你执行git commit不带-m参数时，会直接打开VS Code让你编辑提交信息，写多行commit信息会很方便。
第三个是配置别名，比如git config --global alias.st status、git config --global alias.lg "log --oneline --graph --all -10"。别名能让常用命令短一截，git lg看分支图特别清晰。这些配置都是锦上添花，但配好了，日常操作的舒适度会明显上一档。
3. 代码提交规范：一条commit信息到底该怎么写
环境收拾利索了，终于到了重头戏：提交信息怎么写。我见过最典型的新人提交信息是"111""aaa""test""fix"。看着好像也是提交了，但毫无信息量。Git协作中，提交信息是给"人"看的，其次才是给工具看的。工具只需要你提交，但人需要你解释清楚。
3.1 一套通用的提交信息结构：type、scope、subject、body、footer
业界最流行的提交规范是Conventional Commits（约定式提交），它规定了提交信息的基本结构。我这里给一个适合团队日常使用的版本：
code复制<type>(<scope>): <subject>
<空行>
<body>
<空行>
<footer>
type：本次提交的类型，是加功能、修bug还是改文档。scope：影响范围，比如模块名、组件名，可以不写。subject：一句话描述本次提交做了什么，简洁明确。body：详细说明，可以写背景、原因、注意事项。footer：可选，一般写BREAKING CHANGE（破坏性变更）或关联的issue编号。
type用哪些值，我建议新团队直接抄下面这张表，先跑起来再造轮子：
| type | 含义 | 示例 |
|---|---|---|
| feat | 新功能 | feat(用户模块): 新增用户注册功能 |
| fix | 修复bug | fix(订单): 修复订单金额计算精度丢失问题 |
| docs | 文档变更 | docs: 更新README部署说明 |
| style | 代码格式调整，不影响逻辑 | style: 调整缩进与import顺序 |
| refactor | 重构，不修bug不加功能 | refactor(购物车): 抽离价格计算逻辑 |
| perf | 性能优化 | perf(列表): 减少重复渲染，滚动帧率提升30% |
| test | 测试相关 | test(登录): 补充验证码失效用例 |
| chore | 构建、依赖、工具配置等杂项 | chore: 升级eslint到v9，调整规则 |
| ci | CI/CD相关 | ci: 新增自动化部署流水线 |
| build | 构建系统变更 | build: 配置webpack多环境打包 |
| revert | 回滚某次提交 | revert: 回滚用户导出功能 |
3.2 写清楚和写废话之间，隔着一条明显的线
很多新同学会问：subject到底写多细才算合格？我的判断标准很简单：把这句话拿给你隔壁的同事看，他不需要打开代码，就能知道你这几次提交改了什么、大概动了哪个文件。 如果达不到这个效果，说明写得太笼统；如果一句话写成了一个小作文，说明颗粒度有问题。
来感受一下，下面这些是反面教材：
update：改了什么？没人知道。fix：修了啥？没人知道。bug修复：比前两个强一点，但等于没写。修改了用户头像上传逻辑，修复了头像在弱网环境下上传失败的问题，同时优化了上传进度条的显示效果：信息量有，但太碎，一条提交干了三件事，后面要回滚时根本没法精准操作。
正面例子长这样：
fix(用户): 修复头像上传在弱网环境失败的问题feat(支付): 新增微信小程序端拉起支付功能refactor(商品详情): 抽取SKU选择逻辑，统一规格弹窗调用
区别在哪？在于每条提交只解决一个逻辑问题、主题明确、范围词（scope）直接指向了涉及的功能模块。你不需要看完整个diff，就能判断这条提交是不是自己要找的那次。
3.3 一份可以直接照抄的小组提交规范示例
具体到每个团队，我建议在约定式提交的基础上，再叠加一层自己的业务规则。比如很多团队用Jira或禅道管需求，那么提交信息里带上需求单号就会非常有用。下面这个模板是我们团队目前实际在用的，新同学来了直接照这个写：
code复制feat(登录): 新增短信验证码登录 [JIRA-1012]
- 集成阿里云短信服务，过期时间5分钟
- 验证码发送接口增加频控：单手机号1分钟1条、1天10条
- 登录成功后返回refresh_token，客户端后续静默续期
Closes #JIRA-1012
这套格式有几个好处：type+scope+subject让"改了什么"一目了然；body里用列表写细分改动点，review的人能对照着看；最后的Closes关联需求单，状态管理自动闭环。如果你团队用的是GitHub PR/MR，还可以把相同规范应用到PR标题和描述上，保持从需求到提交到合并的全局一致性。
3.4 提交信息的"原子性"：一件事，一次提交
提交规范不只是信息的格式，还有一个更重要的原则，叫原子性。意思是一条提交应该只完成一个逻辑任务。你写完新功能、顺手格式化了一个无关文件、又改了个错别字——这三个动作应该拆成三条提交，而不是揉成一条。
为什么？因为代码审查（Code Review）的时候，reviewer想看到的是"这个提交到底改了什么、为什么要改"，如果一条提交里面混着"功能开发+格式调整+老代码清理"，审查难度直接翻倍。更关键的是，项目出问题时可能需要精准回滚某次改动，杂糅的提交会让回滚变成一场灾难——你想撤销功能A，结果格式改动也被一起撤销了。
实际操作的时候，新同学最容易犯的毛病是"一个下午攒了一堆改动，最后一次性commit"。正确的做法是：写完一个功能点，自测通过，立刻commit；再做下一个功能点，再commit。 不要攒着。如果发现改了文件里有属于上个任务的残留改动，用git add加指定文件、甚至git add -p分段添加，把不相关的改动留到后面处理。这个习惯，我会说它是新人在Git协作里最重要的习惯之一。
4. 日常协作流程：从拉分支到合并，一套丝滑的操作序列
提交信息规范搞定了，接下来是更重要的日常协作流程。很多新同学入职第一天被分配了一个需求，然后一头雾水：我是直接在master/main上改吗？我什么时候push？怎么跟别人的代码同步？怎么把代码交给别人review？这一章我把完整流程串一遍。
4.1 先搞清楚分支策略：别在主干上直接写
大多数团队现在采用的是一个简化的分支模型，核心思想是：主干分支（main/master）始终保持可发布状态，开发工作全部分支进行。
main（或master）：生产分支，只有通过审查、测试无误的代码才会合并进来。develop：集成分支，日常开发的功能分支都从这里拉出去，完成后合回来。feature/xxx：功能分支，从develop拉出，一个需求对应一个分支。fix/xxx：修复分支，从develop或main拉出，专门修bug。release/xxx：发布分支，从develop拉出，冻结功能只修bug，验收通过后合并到main并打tag。
新同学只需记住一个黄金法则：不要直接在main或develop上提交代码。 一切改动都先开分支，改完后通过合并请求（MR/PR）合入。这样做的核心价值是：任何代码进入主干之前，都经过了一次review、一轮CI检查，质量有人把关，并且出了任何问题都能通过回滚合并请求快速回退，而不是在一堆历史提交里捞针。
4.2 一条标准的开发操作序列：从拉取最新代码到发起MR
假设你接了一个需求"新增订单导出功能"，完整的操作流是这样的：
第一步，同步最新的主干代码：
bash复制git checkout develop
git pull origin develop
这里先切到develop，再pull拉最新。很多新人容易漏掉pull，直接用自己本地可能过时的code开分支，等开发完一push才发现冲突如山。
第二步，从最新develop拉出你的功能分支：
bash复制git checkout -b feature/order-export
分支命名建议包含类型和需求描述，别用test1、mybranch这种名字。一个团队的分支名就代表了这个分支的任务，命名清楚时，光看分支列表就知道大家在干什么。
第三步，在你自己的分支上写代码、提交。提交命令就是常规的git add + git commit，提交信息按照上一章的规范来写。开发过程中建议小步提交，每次提交都是独立的逻辑单元，不要憋到最后来一发"巨型提交"。
第四步，把自己的分支推到远程仓库：
bash复制git push -u origin feature/order-export
第一次push用-u参数，作用是建立本地分支和远程分支的关联，之后在这个分支上直接敲git push就能推送，不用再加完整的远程分支名。
第五步，在代码托管平台上发起合并请求（Pull Request或Merge Request），把feature/order-export合并到develop。PR/MR的描述里要写清楚：这个需求解决什么问题、改动涉及哪些模块、测试情况如何。然后指定由谁review，等人审批通过后就完成了合并。
4.3 开发期间怎么和团队代码保持同步
一个功能分支可能要开发好几天，这期间团队其他人会不断往develop合入新代码。你的分支就会慢慢"过时"。如果不做同步，等你开发完去合并时，会发现冲突堆积如山。所以建议：
- 每天开始工作前，从develop拉最新代码合并到你的分支：
git checkout feature/order-export && git pull origin develop。 - 开发过程中，只要发现develop有明显更新，就主动同步。
同步有两种方式：merge和rebase。git merge origin/develop会把develop的提交合并到你当前分支，生成一个合并节点，历史会有一点点分叉但可读性还行。git rebase origin/develop则是把你当前分支的提交"摘下来"重放到develop最新提交的后面，历史是一条直线，非常干净，适合那些分支提交比较多的个人开发过程。但对新人来说，我建议前期先统一用merge，因为rebase会改写提交历史，万一操作不当（比如把已经push过的提交又rebase了一遍）就会产生一堆重复提交，处理起来相当麻烦。 等你对Git的提交模型有了手感，再根据团队习惯选rebase也不迟。
4.4 冲突不是世界末日：如何体面地解决冲突
冲突可以说是新人最怕遇到的东西。一看到CONFLICT两个大写字母就手足无措，甚至有人会选择删掉整个目录重新clone。其实冲突就是两行字：Git不知道你改的这一块和同事改的这一块，哪个才是最终答案，需要你来裁决。
冲突会发生在你merge或rebase时。Git会把有冲突的文件标记出来，文件内容里会出现这种标记：
code复制<<<<<<< HEAD
这里是你当前分支的代码
=======
这里是你正在合并进来的代码
>>>>>>> origin/develop
你要做的，是找到每个冲突标记，看两边的代码，决定保留哪个、或者两边都要、或者写一个全新的版本，然后把<<<<<<<、=======、>>>>>>>这些标记行删掉。处理完后，git add那个文件，再继续merge或rebase的后续步骤。
避坑经验是：遇到冲突，先别急着改。 先看冲突文件涉及的功能，如果不确定同事那边的改动意图，就主动去问一下写那块代码的同事，别自己闷头乱改。解决完冲突之后，最好重新跑一遍相关功能的测试，因为冲突解决本质上是一次"代码合并"，合并完代码的行为可能和你预期的不一样，这个坑我踩过不止一次。
5. 提交纪律：这几件事比命令更值得盯住
有了一套操作流程之后，剩下的是"什么该提交、什么不该提交"的判断力。这一块往往是最容易出问题的，也是新同学最需要提前知道的边界。
5.1 敏感信息和构建产物，一概不要进仓库
每个团队仓库里几乎都会出过这样的事故：某个开发同学把.env文件提交上去了，里面写着数据库密码、阿里云AccessKey、各种token。等发现时，这些敏感信息可能已经被爬虫抓走、被扫描工具扫到，甚至已经被利用过一轮了。密码泄露的后果很严重，轻则被刷套餐，重则服务器被打穿。所以Git提交的第一条纪律就是：任何密钥、密码、token、证书、私钥，一律不能提交进仓库。
解法是提前规划好.gitignore文件，把.env、*.key、config/secret.*之类的文件忽略掉。建议项目一初始化就把.gitignore配好，而不是等到出事了再亡羊补牢。如果你已经把敏感信息提交进去了，正确的处理方式是：立即视为已泄露，去平台轮换密钥，然后从仓库中彻底移除历史记录（可以用git filter-repo工具重写历史），而不是简单删掉文件再提交一次——因为历史记录里还留着，等于没删。
还有一个容易踩的雷：不要把node_modules、dist、target、vendor这类构建产物或依赖目录提交上去。这些文件都是能从代码重新构建出来的，放进仓库只会让仓库体积暴涨、clone变慢，还会带来一堆无意义的diff。看很多团队的仓库，光是一个项目的node_modules就占了几百MB甚至几个GB，都是当初有人没注意，把本地依赖包给推上去了。.gitignore挡在第一步，就是成本最低的防线。
5.2 小心"破窗效应"：一条"update"会带坏整个仓库的提交风气
有一个现象我觉得特别值得新同学警惕：如果一个仓库的前几条提交就很随意，后续所有人的提交都会越来越随意。这就是犯罪学里的"破窗效应"在Git仓库里的体现。你看到别人提交都写update，就觉得"我也写update没关系"。结果几个月后，这个仓库的提交历史基本就废了。
反过来，如果团队从一开始就严格执行提交规范，新人进来看到别人的commit信息都清晰规范，自然也会照着写。所以每一条提交信息都不只是"你自己的事"，它在影响整个团队的习惯水位。这不是唱高调，是真实的管理经验：规范的执行力很大程度上靠的是"氛围"，而氛围是由每一条commit共同塑造的。
5.3 提交的颗粒度：宁可多提交，不要一锅炖
很多新同学提交代码是"改到哪算哪"。比如打开IDE，改了三四个文件，每个文件里塞了好几个不相干的改动，最后统一git add . + git commit -m "update"，一次提交搞定。这就是颗粒度失控。
理想的颗粒度是：一次提交对应一个可独立描述的逻辑变更。比如"修复登录页忘记密码的验证码不刷新问题"，这个改动可能涉及一个组件文件、一个API文件，但逻辑目标只有一个，那就是修这个bug。它就可以是一条提交。反过来，如果你还顺手把页面上一个按钮的颜色改了，那个颜色改动应该单独拆成一条style(登录): 调整主按钮颜色为品牌色的提交。
实际操作上，用git add -p分段暂存非常重要。它会把文件的改动按块列出来，让你选择哪些块加入本次提交。这是Git里对新同学最实用但最容易被忽略的命令。配上IDE的分行暂存功能，把一次文件改动拆成多条提交完全做得到。记住一句话：提交得越细，回滚越安全，review越轻松，代码追责也越清晰。
6. 高频翻车现场与救援指南
写规范是为了预防，但实际开发中该翻的车一个都少不了。我整理了新同学最容易遇到的几个Git"事故现场"，每个都给出根因和正确的救援动作。这些内容也正好对应了关联热搜里大量搜索的各类Git报错。
6.1 "git不是内部或外部命令"与"无法将git识别为cmdlet、函数、脚本文件"
这个问题场景在Windows尤其常见。你在CMD或PowerShell里敲git命令，系统给你的回应是找不到git。原因就是前面环境配置部分说的：git虽然装了，但它的可执行目录没有加入系统PATH，或者你当前的终端窗口是在安装git之前打开的，环境变量还没刷新。
排查链路：
- 先用
where git（Windows）或which git（macOS/Linux）看一下，系统能不能找到git可执行文件。 - 找到git安装目录，Windows默认在
C:\Program Files\Git\cmd，确认这个目录在不在系统环境变量PATH里。 - 不在就加上，加完一定要关掉所有旧终端窗口，重新开一个。
- 再敲
git --version验证。
在VS Code的终端里如果报这个错，同样要检查VS Code是不是在环境变量修改之前启动的，修改完PATH后重启VS Code通常就能解决。
6.2 "fatal: not a git repository (or any of the parent directories): .git"
这个报错的直接意思是：你当前所在的目录不是Git仓库，且它的上级目录里也没有Git仓库。新同学常犯的错误是：在项目文件夹里建了一个子目录，然后直接在里面敲git命令，结果报这个错。
根因是：Git仓库是基于"文件夹+.git目录"的，你必须在仓库根目录（或者它的子目录里，因为Git会往上找）执行命令才有意义。如果在一个全新的、还没有执行过git init的目录里敲git命令，就会遇到这个报错。
排查方法：
- 执行
pwd看当前目录，确认你有没有进的太深。 - 执行
ls -a，看当前目录或上级目录是否存在.git文件夹。 - 如果项目还没初始化，就在项目根目录执行
git init。 - 如果代码是从远程clone的，删掉重新clone一次也行，注意clone时的目标目录别选错。
6.3 合并冲突解决到一半，我想放弃，怎么办
新人在解决冲突时经常越改越乱，最后只想恢复原状。这时候Git的救援命令就派上用场了。
如果你是在merge过程中心态爆炸，想回到merge之前的状态：
bash复制git merge --abort
这个命令会取消这次merge，让你的分支回到merge前的样子。同理，rebase进行到一半想放弃，用git rebase --abort。如果你是在解决冲突时手动改乱了某个文件，想重新来，可以对这个文件执行git checkout -- 文件名（或新版Git的git restore 文件名），把文件恢复到最近一次提交的状态，然后重新处理冲突。
注意：
git restore是一个比较新的命令，如果你是老版本Git，可能只有git checkout -- 文件可用。两个命令的作用类似，都是丢弃工作区的改动。凡是涉及丢弃修改的操作，操作前确认你没有未备份的重要改动，这个前提必须唠叨三遍。
6.4 提交信息写错了怎么办：amend、reset、revert三种场景
场景一：刚commit完，发现提交信息有错别字，或者想补充一点内容，且还没有push到远程。直接：
bash复制git commit --amend
这会打开编辑器让你修改上一条提交信息。注意amend的作用是"合并进上一条提交"，不是生成一条新提交。所以它适合还没push的本地提交。
场景二：commit以后发现提交了不该提交的文件，比如把带密码的配置一起提交了，且还没push。处理方式：先把误提交的文件从提交里撤出来。
bash复制git reset --soft HEAD~1
--soft的意思是保留所有改动在工作区，只撤销提交动作。执行完后文件还都在，只是不再处于已提交状态。然后重新git add正确的文件，再git commit一次。这里有个知识点：git reset有--soft、--mixed、--hard三种模式，区别是分别保留所有改动、保留工作区但清空暂存区、全部清空。对新人来说，在不确定的情况下，永远不要用git reset --hard，它会直接丢掉你的代码改动，而且找不回来。
场景三：代码已经push到远程了，发现提交有问题。这时候有两条路：
- 如果你只是想"收回"某次提交的改动，用
git revert <commit哈希>。revert会生成一条新的反向提交，把之前那次的改动撤销掉，历史完整保留，适合已经发布或多人协作的分支。 - 如果你确定这条提交只有你自己在用、且没有人拉过你的分支，可以
git reset回退后强制push（git push --force）。但强制推送会改写远程历史，团队协作时一定要先和队友确认没人基于这个分支开发过，否则会把别人的提交搞丢。这条我建议新人直接禁用，等有了经验再碰。
6.5 clone不到、登录失败、API token报错这类"连不上"问题怎么排查
关联热搜里还有login failed. check api token or gitlab version、git clone https://...这类问题。这些多数是网络和认证问题，常见原因有三种：
第一种，网络原因连不上托管平台。可以试试ping github.com，如果ping不通，大概率是网络访问的问题。这种环境问题要学会自己判断，不要一上来就觉得是git配置错误。
第二种，认证方式不对。你的仓库是HTTPS地址，平台要求你用token或者密码认证，但你输错了或者没输。新版GitHub已经不支持账号密码直接走HTTPS推送，必须用Personal Access Token。GitLab也类似，很多公司内部GitLab要求走token或者SSH。遇到登录失败时，先看平台给的提示，按提示去申请token或配置SSH密钥。
第三种，clone私有仓库却没有权限。确认你的账号已经被添加为仓库成员。找项目负责人加权限，或者确认你是不是用了正确的账号。
排查这一类问题的通用思路：确认网络通不通，确认仓库地址对不对，确认认证方式对不对，确认权限有没有。这三个确认按顺序走一遍，绝大多数"连不上"问题都能定位。
6.6 ".git目录泄露"是怎么回事，以及为什么这个文件夹要当宝贝一样护着
热搜词里有个"git目录泄露如何下载"，这其实是个安全漏洞类的话题。.git目录是Git仓库的"心脏"，里面存储了这个项目的全部历史快照、分支引用、配置信息。正常开发时这个目录只在你的本地，不应该被外部访问到。但有些网站部署时，把整个项目目录直接当静态站点丢到web服务器上，没有屏蔽/.git的访问，于是任何访问者都可以通过https://某网站/.git/直接下载到整个git历史，包括里面曾经提交过的所有代码、配置、密钥——即使你后来删掉的东西，只要提交进过git历史，都能被翻出来。
这给新同学两个直观教训：第一，不要把任何可能存在敏感信息的文件提交进git，因为你以为删掉了，但历史里永远留着。第二，如果你的工作涉及部署网站，部署目录里绝不能把.git文件夹暴露出去，需在服务器配置里显式禁止访问/.git路径。顺手说一句，验证你代码提交历史里有没有泄露过敏感信息，可以自己git log --all --diff-filter=D -- '*.env'之类的命令扫一遍，把删除过的敏感文件找出来。
7. 最后，关于协作习惯的几句大实话
规范和命令写完了，但有一个道理我觉得值得单独说说：Git的规范，从来不是为了限制你，而是为了让整个团队的开发体验更顺滑。 它的本质是一种"社交协议"——你把人家的提交信息写得清清楚楚，人家审查你的代码时也更愿意认真对待；你把自己的分支管理得干干净净，同事合并你的代码时心里也踏实。
在我带过的所有新人里，那些Git用得好的，有一个共同点：他们不把Git当"必须应付的工具"，而是当"跟团队对话的方式"。同样是提交代码，有人只是完成动作，有人在认真传递信息。久而久之，代码也许差不多，但在团队里的声誉和信任度会差出很远。
有几个习惯性建议放在这里，新同学照着做，基本不会踩大坑：
- 小步提交，频繁同步。 改动拆小、提交频繁、每天至少同步一次远程代码，让冲突在刚冒头时就暴露，而不是攒到最后一刻来一次"合并大地震"。
- push之前先看一眼diff。
git status和git diff在commit之前过一遍，确认本次提交的确实是你想提交的东西，没有多带文件、没有误改内容。 - 提交信息规范从加入团队的第一天就执行。 习惯是养成的，先有了"随便写"的惯性，再想纠正就要花好几倍的力气。
- 遇到解决不了的问题，敢于求助。 把报错信息原样贴给同事或搜一下，前提是先把报错信息读一遍——大部分报错信息本身就给出了解决线索。
我最后再分享一个小技巧：给git log配一个好看且信息密集的别名。我现在无论看任何仓库，第一件事都是执行git lg，一眼扫过每个人的提交信息，谁写的规范、谁在糊弄，清清楚楚。你不需要当什么Git大师，但你写下的每一条提交，都是你给团队留下的"手写签名"。希望这篇东西能帮你把这个签名写得像样一点。