​

✅ 项目协作开发中的 Git 使用规范
假设我和同事在开发一个项目，为了避免互相覆盖代码、造成冲突，我会遵循以下步骤和命令流程：

🔹 1. 确保使用 Git 分支管理（Feature Branch Workflow）
每一个新需求或功能，都会从 main 或 dev 分支新建一个功能分支：

git checkout main # 切换到主分支
git pull origin main # 拉取最新的主分支代码，确保是最新状态
git checkout -b feat/login-page # 创建新功能分支

这样我和同事就可以各自独立在自己的功能分支上开发，互不干扰。

🔹 2. 开发过程中保持和主分支同步，避免冲突
在开发周期中，我会定期从 main 分支同步最新代码，以避免积累冲突：

git fetch origin #从远程仓库获取所有最新的分支更新，但不会自动合并或修改你当前的工作分支。
git rebase origin/main # 或 git merge origin/main

如果出现冲突，我会在本地手动解决冲突，再继续开发。

git rebase origin/main 是什么？

这是一个手动同步远程主分支并“把我的提交平铺在最新主分支之后”的操作。

可以理解为：

我不想直接合并（merge）远程主分支，而是想让我的开发历史“像是刚开始在最新主分支上进行的一样”。

🔹 3. 提交前执行 git pull –rebase 确保顺序正确
git add .
git commit -m “feat: 完成登录页面”
git pull –rebase origin feat/login-page # 拉取远程分支最新代码，并将本地提交“重新叠加”在其上

这一步可以避免本地提交与远程提交冲突，强制推送的情况。

🔹 4. 提交代码并发起合并请求（Pull Request）
git push origin feat/login-page

然后在 GitHub 或 GitLab 上创建合并请求（PR），由我或其他同事 review 后合并到主分支。

🔹 5. 合并策略采用 squash 或 rebase，保持历史干净
团队中推荐使用：

rebase：保持线性提交历史；
squash：合并为一个提交，便于 review。
🔹 6. 上线前，跟项目负责人（或 CI/CD 流程）确认是否允许合并
如果是公司正式项目，通常合并必须走 CI/CD 审核流程；
可能会需要 @团队成员 审核，或通过 Jenkins、GitHub Actions 自动跑测试；

最终合并前：

git push origin feat/user-login

然后在 Git 平台发起 PR，让管理员审核+合并

​