远程仓库协作：打通本地与团队的最后一公里
说实话，版本控制这件事，如果只在自己机器上折腾，那跟单机游戏没区别。真正的痛点永远出现在“多人怎么写同一份代码”上。我记得刚带团队那会儿，有个同事直接在 master 上改代码，一 push 就把别人的修改覆盖了——嗯，那天下午全组都在回滚。后来我们老老实实把远程仓库协作流程定下来，再也没出过这种乱子。
远程仓库配置
先把远程仓库和本地连上。这一步看似简单，但配置不对，后面所有操作都会报错。
认证方式：SSH 还是 HTTPS？
我个人的习惯是：小团队、私仓用 SSH；公仓或者你经常换机器，用 HTTPS 加 token。两种方式各有适用场景：
| 方式 | 优点 | 缺点 | 我推荐 |
|---|---|---|---|
| SSH | 一次配置，不用反复输密码 | 需要生成密钥、配公钥 | 长期项目、个人主力机 |
| HTTPS | 门槛低，浏览器直接克隆 | 每次 push 要输密码（或 token） | 临时环境、 CI/CD 机器 |
先看看当前仓库有没有配远程：
git remote -v如果啥都没显示，就得手动加：
git remote add origin git@github.com:yourname/repo.git
git remote add origin https://github.com/yourname/repo.git提示：origin 只是默认名字，你可以改成任何名字。但团队里大家都用 origin 最省事。
配置 SSH 密钥（一次搞定）
我曾经被 SSH 权限搞到怀疑人生，后来总结出标准流程：
- 检查是否已有密钥：
ls ~/.ssh/id_ed25519.pub，没有就生成：
ssh-keygen -t ed25519 -C "youremail@example.com"- 把公钥复制到剪贴板：
cat ~/.ssh/id_ed25519.pub
# 然后手动复制- 去 GitHub / GitLab → Settings → SSH Keys → 粘贴保存
- 测试连通：
ssh -T git@github.com
# 看到 "Hi yourname! You've successfully authenticated" 就对了踩坑提醒：不要用 rsa 了，ed25519 更安全又快。如果公司内网用自签证书，HTTPS 可能报 SSL 错误，这时候只能走 SSH。
推送与拉取：别让代码在本地烂掉
配置好远程，接下来就是日常操作：推 和 拉。但这里面有个很多人忽略的细节——fetch 和 pull 的区别。
推送（git push）
把本地分支的提交推送到远程：
git push origin main
git push -u origin feature-login # 第一次推新分支用 -u 建立跟踪关系以后只需要 git push 就行，不用再写 origin 分支名。我习惯每完成一个功能点就 push 一次，不要攒十几个 commit 再统一推，冲突会让你怀疑人生。
拉取：fetch 和 pull 你选哪个？
很多人只用 git pull，但我要说：先 fetch 再 merge 更安全。
| 命令 | 做了什么 | 风险 |
|---|---|---|
git pull | fetch + merge 一步到位 | 自动合并可能搞出冲突还不自知 |
git fetch | 只下载远程最新数据，不合并 | 安全，你可以先看看再决定怎么合 |
我的做法：
git fetch origin # 下载最新远程分支信息
git log origin/main # 看看别人改了啥
git merge origin/main # 确认没问题再合并
# 或者用 rebase
git rebase origin/main你想想看，如果直接 git pull，万一自动合并了一堆垃圾，你还得手忙脚乱地 reset。多花十秒钟 fetch 一下，心里踏实得多。
Pull Request / Merge Request 流程
把代码推到自己的分支上只是一个中间步骤。真正让团队协作跑起来的，是 PR（GitHub） 或 MR（GitLab） 这个“审查 — 讨论 — 合并”的循环。
一个标准 PR/MR 长什么样？
以 GitHub 为例，流程大概是这样：
- 从
main切出一个新分支，比如feat/user-auth。 - 本地开发、commit、push 到远程同名分支。
- 在 GitHub 网页上点 “Compare & pull request”。
- 写清楚标题、描述、关联的 issue 号。
- 指派人 reviewer，等他们 review 通过。
- 合并（可以选择 merge commit、squash 或 rebase）。
- 删除远程分支，清理本地：
git branch -d feat/user-auth
关键点是：不要让 review 变成走过场。我自己在 PR 描述里会写 “改了什么”、“为什么改”、“影响范围”、“测试结果”。Reviewer 看得清楚，我也省得反复解释。
GitLab Merge Request 略有不同
GitLab 把 PR 叫 Merge Request，核心逻辑一样，但多了几个实用功能：
- 可以在 MR 描述里写
/assign @me快速指派。 - 支持 WIP（Work In Progress）前缀，防止还没写完就被合并。
- 可以设置“合并后删除源分支”的默认勾选。
我司现在用 GitLab，团队约定所有 MR 必须至少一个 approver 才能合并。这个可以在仓库 Settings → Merge requests 里配。
为啥非要搞 PR/MR？
说白了，就是给代码加一道“质检门”。直接往 main 上 push，代码大概率藏 bug。而 PR 给了所有人一个机会：
- 发现逻辑漏洞
- 检查命名是否规范
- 确保测试覆盖了边界
- 顺便大家互相学习
我曾经在一个项目中遇到：代码在本地测试全绿，push 到 PR 后 CI 直接跑挂了，因为 .env 文件没提交但代码中写死了本地路径。review 的时候被同事一眼看穿。如果没有 PR，这个 bug 就进了生产环境。
合并策略怎么选？
GitHub 和 GitLab 都提供三种合并方式，区别在于历史记录的整洁度：
| 策略 | 效果 | 适用场景 |
|---|---|---|
| Create a merge commit | 保留所有中间提交，加一个 merge commit | 想完整保留开发过程 |
| Squash and merge | 把分支上所有提交压成一个，再 merge | 主分支希望保持单次提交的原子性 |
| Rebase and merge | 把分支的提交 rebase 到 main 顶部，再 fast-forward | 想要线性历史，没有 merge commit |
我个人的偏好是：feature 分支用 squash and merge。因为开发过程中可能有十几条“fix typo”、“WIP”、“debug”之类的提交，压成一个“feat: 用户认证”干净利落。等以后看 git log 时，每一行就是一个完整功能，一目了然。
注意：不要在主分支上乱用 rebase merge。如果团队里其他人基于你的分支工作过，rebase 会改写历史，对方 pull 时直接冲突炸裂。我亲眼见过一个小伙子在公共分支上 rebase 后强制推送，导致全组 repo 不一致，最后花了半天才恢复。
好了，远程仓库协作的核心就是这些。配好认证、用好 push/pull/fetch、走规范的 PR/MR 流程、选对合并策略。这几个环节做好了，团队协作就能从“混乱”变成“有序”。下次遇到冲突合并时，你心里就有底了。