005、Git远程协作：连接GitHub/Gitee，掌握Push、Pull与团队协作规范

从一次深夜合并冲突说起

上周团队里新来的小伙凌晨两点给我打电话，说他的git push被拒绝了，本地分支和远程分支“好像都有修改”，现在代码全乱了。我让他把终端截图发过来——好家伙，他直接在main分支上改了三天代码，从来没pull过，远程仓库早被其他人更新了十几个提交。

这种场景太典型了。很多初学者以为 Git 远程协作就是“上传下载”，结果一遇到冲突就手足无措。今天咱们就聊聊怎么正确连接远程仓库，以及那些教科书里不会写的团队协作潜规则。

连接远程仓库：别只会用 HTTPS

第一次克隆仓库，很多人顺手就复制了 HTTPS 链接：

gitclone https://github.com/username/repo.git

这没问题，但每次push都要输密码，烦不烦？如果你经常推送代码，建议配置 SSH 密钥：

# 生成密钥（如果还没有）ssh-keygen-ted25519-C"your_email@example.com"# 然后一路回车就行，不用设密码（方便），当然设了更安全# 把公钥复制到剪贴板cat~/.ssh/id_ed25519.pub|pbcopy# Mac# 或者cat~/.ssh/id_25519.pub|clip# Windows# 去 GitHub 或 Gitee 设置里找到 SSH Keys，粘贴添加

之后克隆就用 SSH 地址：

gitclone git@github.com:username/repo.git

从此告别密码输入，特别是用 CI/CD 工具时，SSH 密钥几乎是必选项。

注意：公司内网 GitLab 可能要求用 HTTPS 加访问令牌，具体看公司规定。但个人项目强烈推荐 SSH，省心。

Push 之前，先 Pull 一下

我见过最经典的错误流程：

gitadd.gitcommit-m"fix bug"gitpush origin main# 直接失败，因为远程有更新

然后就开始慌，乱用git pull --force，把同事代码冲掉了。

正确姿势永远是这样：

# 先拉取远程最新代码（fetch + merge）gitpull origin main# 如果有冲突，解决冲突，再提交gitadd.gitcommit-m"merge remote changes"# 最后推送gitpush origin main

更专业的做法是使用--rebase：

gitpull--rebaseorigin main

这会让你的提交“挪到”远程最新提交之后，保持线性历史，看起来更干净。但 rebase 会改写历史，团队新手慎用，容易把自己搞晕。

分支策略：别在 main 上直接改

那位凌晨求助的小伙犯的最大错误，就是在main分支上直接开发。规范的团队协作应该这样：

# 1. 每次新功能开新分支gitcheckout-bfeature/login-page# 2. 在这个分支上开发、提交gitadd.gitcommit-m"add login form"# 3. 开发过程中定期同步主分支gitcheckout maingitpull origin maingitcheckout feature/login-pagegitrebase main# 或者 merge main# 4. 推送到远程（第一次推送需要设置上游）gitpush-uorigin feature/login-page# -u 参数以后就可以直接 git push，不用指定远程分支了

为什么这么麻烦？因为隔离风险。你的实验性代码不会污染主分支，即使写崩了，删掉分支重来就行。而且代码审查（Pull Request/Merge Request）必须基于分支。

团队协作的潜规则

提交信息怎么写

别写“修复bug”“更新代码”这种废话。好的提交信息像这样：

feat(auth): add OAuth2 login support fix(api): handle null pointer in user query docs(readme): update installation steps

用feat、fix、docs、style、refactor、test、chore开头，后面括号标注模块，冒号后写具体改动。这是 Angular 团队的规范，很多项目都在用。

什么时候该 Pull Request？

• 新功能完成时
• 修复重大 bug 时
• 任何可能影响其他模块的修改

小修改（比如改个错别字）可以直接合并，但最好也走流程，养成习惯。

冲突解决谁负责？

谁产生冲突，谁负责解决。如果你pull时发现冲突，说明你本地修改和远程修改冲突了，你得自己解决。别指望别人帮你调，他们不知道你的代码逻辑。

解决冲突后一定要测试，特别是合并别人的代码后，跑一遍关键流程。我见过有人解决冲突时把别人的重要判断语句删了，导致线上报错。

那些容易踩的坑

1. 密码缓存问题

如果你用 HTTPS，Git 可能会缓存密码，突然某一天要求重新输入。这时候可以配置缓存：

gitconfig--globalcredential.helper cache# 缓存15分钟gitconfig--globalcredential.helper'cache --timeout=3600'# 缓存1小时

或者用 manager 工具（如 Git Credential Manager for Windows）。

2. 推送错了分支

不小心把feature分支推到了main：

# 先删除远程错误推送gitpush origin--deletemain# 但注意：如果团队其他人已经拉取了，别这么干！会坑队友

所以推送前一定要git branch -a确认当前分支。

3. 强制推送的灾难

gitpush--forceorigin main

这是核武器，除非你百分百确定只有你一个人在用这个分支，否则别用。更安全的是--force-with-lease，它会检查远程分支是否被别人更新过。

个人经验建议

1. 每天开工第一件事：git checkout main && git pull，保持主分支最新。
2. 推送前：跑一遍git log --oneline --graph，看看提交历史是否整洁。
3. 遇到冲突别怕：冲突只是 Git 提醒你“这里需要人工判断”，不是错误。用 VS Code 或 IDE 的冲突解决工具，比手动找<<<<<<<标记舒服多了。
4. 分支命名：用feature/xxx、bugfix/xxx、hotfix/xxx前缀，一目了然。
5. 保护主分支：在 GitHub/Gitee 设置里开启分支保护，禁止直接push到main，必须通过 Pull Request。这是团队协作的底线。

远程协作最核心的不是命令，是默契。和团队约定好流程，比任何高级技巧都管用。刚开始可能觉得繁琐，等经历过一次“代码丢失事故”或“线上回滚灾难”后，你就会明白这些规范为什么存在。

Git 不是魔法，它只是把你和队友的修改编织成历史的工具。织得好，项目脉络清晰；织得乱，就是一团毛线球。慢慢来，你也能成为那个“解球”的人。