一、基本命令
1. git init
作用：在当前目录下初始化一个全新的空 Git 仓库，生成隐藏的 .git 文件夹。
用法：git init
执行完后，当前文件夹就从普通目录变成了 Git 可以管理的代码仓库，后续操作基于这个初始化环境。
2. git add
作用：把工作区修改过的文件，添加到 Git 的暂存区，为下一次提交做准备。
用法：
- 添加单个指定文件：
git add 文件名.py - 添加当前目录下所有新文件夹和修改过的文件：
git add . - 添加指定目录下的所有内容：
git add src/
3. git commit
作用：把暂存区里所有已经 add 的内容，正式保存到本地 Git 仓库中，生成一条带唯一标识的提交记录，永久写入版本历史。
用法：
- 直接附带提交说明：
git commit -m "完成xxxx" - 不带 -m 参数，会打开文本编辑器，要写详细提交说明后保存退出：
git commit
4. git push
作用：把本地仓库的新提交，同步上传到远程的 Git 仓库（GitHub、Gitee、GitLab），让远程服务器和本地保持一致。
用法：
- 第一次推送当前分支时，指定远程仓库和分支名：
git push -u origin main - 后续推送当前分支的新提交，直接执行就行：
git push
注意：推送前要确保本地分支的提交历史和远程分支没有冲突，否则 Git 会拒绝推送，需要先拉取远程最新代码合并后再尝试推送。
5. git pull
作用：从远程仓库下载最新的提交记录，并且自动把远程的新代码合并到你当前的本地分支里，相当于「git fetch + git merge」的组合操作。
用法：
- 拉取当前分支对应的远程分支的最新代码并自动合并：
git pull
使用场景：多人协作开发时，每次开始写新代码前，先执行一次 git pull，就能拿到团队其他人刚提交的最新代码，避免后续提交时出现大量冲突。
二、分支、合并、变基
1. 分支
概念：是一个指向具体提交的可变轻量指针。
作用：从主线分出多条开发线并行，互不干扰。
用法：
git branch feature-login # 创建分支 git checkout feature-login # 切换分支（或 git switch feature-login） git checkout -b feature-login # 创建并切换 git branch -d feature-login # 删除已合并的分支2. 合并
概念：将两个分支的开发历史整合到一起的操作，但并不会修改已有的提交记录。
类型：
- 快进合并（Fast-forward）：目标分支没有新提交，直接移动指针，不产生合并提交。
- 三方合并：两边都有新提交，产生一个合并提交（merge commit），有两个父提交。
用法：
git checkout main git merge feature-login冲突处理：
git add <冲突文件> git commit使用场景：
- 功能开发完成后，把 feature 分支合回 main。
- 把 main 的最新改动合进自己的功能分支，保持同步。
- 团队约定保留完整历史、需要看到“何时合并了什么”时。
3. 变基
概念/作用：把当前分支从分叉点开始的所有提交，全部提取出来，放到目标分支的最新提交之后。
用法：
git checkout feature-login git rebase main这会把 feature-login 上独有的提交，搬到 main 最新提交之后。
使用场景：
- 功能分支开发中，想同步 main 的最新改动，又不想产生一堆合并提交。
- 提交历史太乱，想整理成干净的提交再合并。
- 本地提交尚未推送，想修改提交信息或合并零碎提交。
黄金法则：不要对已经推送到共享远程仓库的提交做变基。
三、团队协作规范（Issue 和 PR）
规范
- 唯一主责人原则：每一个模块、每一项任务只能指定 1 名最终负责人，协作人可以有多个，但最终结果的出口必须唯一，避免多人决策导致的效率内耗。
- 五要素对齐原则：所有分工必须明确回答 5 个问题：最终交付物是什么、谁是唯一主责人、需要谁提供什么输入、责任人拥有什么决策权限、完成的验收标准是什么。
- 角色边界清晰原则：以通用研发团队为例，各核心角色的责任边界要明确划分。
Issue
用来记录 Bug、需求、任务，方便团队沟通。
填写规范：
1. Bug 类 Issue 必填项：
- 清晰的标题：[模块名] 点击登录按钮无响应
- 复现步骤：一步步写清楚怎么操作能 100% 复现问题
- 实际结果：当前操作后出现的错误现象
- 预期结果：正常情况下应该出现的正确效果
- 环境信息：浏览器版本、系统版本、项目版本号
2. 新功能类 Issue 必填项：
- 清晰的标题：[用户中心] 新增头像上传功能
- 功能背景：为什么要做这个功能，解决什么问题
- 功能细节：核心交互逻辑、边界场景说明
- 验收标准：满足什么条件才算这个功能开发完成
PR
在改完代码后，发起一个合并请求，让团队负责人审核代码，审核通过后才会合并到主分支。
填写规范：
- 规范标题：使用类型: 简短描述改动内容的格式
- 改动说明：详细描述本次 PR 做了什么改动，解决了什么问题，对应关联的 Issue 编号
- 自测说明：写清楚自己做了哪些场景的测试，附上测试截图或者测试结果
- 变更清单：列出本次改动涉及的所有文件和核心改动点，方便审核人快速定位重点
