项目开发的git版本控制
关键思想是：每个人开发用自己的分支，保持与主分支同步，避免直接推主分支，合并通过 PR，由 reviewer 控制质量。

✅ 项目协作开发中的 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，让管理员审核+合并