git同步仓库

Q1:本地进行了修改，他人从远程提交了修改，为了避免冲突，提交时应该怎么做。

Q1:本地进行了修改，他人从远程提交了修改，为了避免冲突，提交时应该怎么做
1. 首先保存本地修改
```
git stash
```
1. 拉取远程更新
```
git pull origin master
```
1. 恢复本地修改
```
git stash pop
```
1. 如果有冲突，解决冲突后提交：
```
git add .
git commit -m "你的提交信息"
git push origin master
```

Q2: 如果本地没有任何修改

git pull origin master//拉去远程更新

如果想完全同步

git fetch origion master
git reset --hard origin/master

Q3: 初始化一个本地文件夹成为git 仓库，通过ssh向远程提交代码的过程

Q3: 初始化一个本地文件夹成为git 仓库，通过ssh向远程提交代码的过程
1. 初始化本地 Git 仓库：
```
git init
```
1. 配置 Git 用户信息（如果还没配置）：
```
//可以通过这种方式查看
git config --list
git config user.name
git config user.email
```
```
git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
```
1. 生成 SSH 密钥（如果还没有）：
```
ssh-keygen -t rsa -C "你的邮箱"
```
密钥默认保存在 C:\\Users\\你的用户名\\.ssh\\ 目录下
1. 查看并复制公钥内容：
```
type C:\\Users\\Zhang.G.S\\.ssh\\id_rsa.pub
```
将输出的内容复制到 GitLab/GitHub 的 SSH Keys 设置中
1. 添加远程仓库：
```
git remote add origin git@gitlab.com:你的用户名/仓库名.git
```
1. 添加文件到暂存区：
```
git add .
```
1. 提交更改：
```
git commit -m "初始化提交"
```
1. 推送到远程仓库：
```
git push -u origin master
```

Q4 ：如果是合作开发，每一次上传的流程

Q4 ：如果是合作开发，每一次上传的流程
1. 代码同步与分支管理
```
git pull origin master  # 同步最新代码
git checkout -b feature/xxx  # 创建新功能分支
```
1. 代码审查前的自检
- 检查代码规范
- 运行单元测试
- 确保新代码不会破坏现有功能
- 删除调试代码和无用注释
- 检查敏感信息（密钥、密码等）是否已移除
1. 提交规范
```
# 暂存修改
git add .# 提交代码（遵循提交信息规范）
git commit -m "feat: 添加xxx功能"
```
提交信息格式建议：
- feat: 新功能
- fix: 修复bug
- docs: 文档更新
- style: 代码格式调整
- refactor: 重构
- test: 测试相关
- chore: 构建过程或辅助工具的变动
1. 代码评审流程
```
git push origin feature/xxx  # 推送到远程分支
```
然后在 GitLab/GitHub 上创建 Merge/Pull Request
1. CI/CD 检查
- 等待自动化测试结果
- 确保所有 CI 检查通过
1. 合并主分支
- 获得评审通过
- 解决可能的冲突
- 合并到主分支
1. 清理工作
```
git checkout master
git pull origin master
git branch -d feature/xxx  # 删除本地分支
```
根据具体项目的要求，可能还需要：
- 更新相关文档
- 通知相关团队成员
- 更新项目看板状态
- 记录变更日志

Q5: 如果是独立开发者，每一次上传的流程

开始新功能前

git pull origin master  # 确保本地代码是最新的
git checkout -b feature/xxx  # 创建功能分支（建议保持这个习惯）

开发过程中

经常性小批量提交，保持提交信息清晰：

git add .
git commit -m "feat: 添加xxx功能"

完成功能后

git checkout master    # 切换到主分支
git pull origin master # 确保主分支是最新的
git merge feature/xxx  # 合并功能分支
git push origin master # 推送到远程

清理工作

git branch -d feature/xxx  # 删除本地功能分支

建议：

即使是独立开发，也要保持分支开发的习惯
定期备份代码
保持良好的提交信息格式
在合并前进行完整测试
定期整理和清理分支

这样的工作流程既保持了代码的整洁性，又为未来可能的团队协作打下基础。

Q6: git commit -m 信息的规范：

[type](scope):<subject>
- ***
- ***
<footer>其中常见的type有：
- feat : 新功能
- fix : 修复bug
- docs : 文档更新
- style : 代码格式调整（不影响代码运行的变动）
- refactor : 重构（既不是新增功能，也不是修改bug的代码变动）
- perf : 性能优化
- test : 测试相关
- chore : 构建过程或辅助工具的变动写成scope为修改的那一部分函数，方法，功能subject是具体做了哪些修改footer:
在 Git commit 信息中，常用的功能性 footer 包括：1. 关闭 Issue 相关：
- 这些关键词会在合并到主分支时自动关闭对应的 Issue
- 可以同时关闭多个： Closes #123, #456
2. 破坏性变更标记：
- 表示这次提交包含不向后兼容的改动
- 通常会触发主版本号的升级
3. 引用相关 Issue：
- 建立代码与 Issue 的关联，但不会自动关闭 Issue
4. 依赖相关：
Depends-on: <commit-hash>
Requires: #123
- 表明当前提交依赖其他提交或 Issue
5. 代码评审相关：
Reviewed-by: 张三
Acked-by: 李四
Signed-off-by: 王五 <wangwu@example.com>
- 记录代码评审人员信息
6. 测试相关：
Tested-by: 测试人员
Test-Coverage: 85%
- 标记测试相关信息
7. 文档相关：
Doc-Impact: 需要更新API文档
Documentation: #123
- 指示文档变更的影响举例子：
# 新功能
git commit -m "feat(user): 添加用户注册功能"# 修复bug
git commit -m "fix(login): 修复登录验证失败问题"# 文档更新
git commit -m "docs: 更新API文档"# 包含详细说明
git commit -m "feat(auth): 实现JWT认证- 添加token生成和验证功能
- 集成Redis缓存
- 添加token刷新机制Closes #123"