Git常用开发工作流程丨青训营笔记Git 工作流程通常涉及多个步骤，特别是在团队合作开发的场景中。以下是一个常见的 Gi

Git 工作流程通常涉及多个步骤，特别是在团队合作开发的场景中。以下是一个常见的 Git 工作流程，假设你是在一个团队中进行协作开发，并且从创建自己的工作分支开始：

1. 克隆远程仓库

首先，你需要从远程仓库（例如 GitHub、GitLab）克隆项目：

 git clone <repository-url>

这会将远程仓库复制到你的本地机器上。

2. 创建并切换到自己的分支

为了不影响主分支（通常是 main 或 master），开发新功能或修复 bug 时，应在自己的分支上进行工作：

 git checkout -b <your-feature-branch>

这里 <your-feature-branch> 是你新创建的分支的名字，通常会根据你正在开发的功能或修复的内容命名。

3. 在分支上开发

现在你可以在你的分支上进行开发工作。你可以修改代码、添加新文件或删除旧文件。

4. 添加更改

完成开发后，你需要将修改过的文件添加到暂存区：

 git add <file1> <file2>  # 添加特定文件
 # 或者
 git add .  # 添加当前目录下的所有更改

5. 提交更改

将添加到暂存区的更改提交到本地仓库，通常你还需要为每次提交写一个清晰的提交信息：

 git commit -m "描述你的更改"

6. 拉取远程仓库的最新更改

在推送之前，确保你已经同步了远程仓库的最新更改，特别是从主分支（main 或 master）获取最新的更新，以避免冲突：

 git checkout main  # 切换到主分支
 git pull origin main  # 拉取远程主分支的最新内容

7. 合并主分支的更新到你的工作分支

为了保证你的工作分支和主分支保持同步，你需要将主分支的更改合并到你的分支中：

 git checkout <your-feature-branch>  # 切换回你的分支
 git merge main  # 合并主分支的更新

此时，如果有冲突（冲突是指多个开发人员修改了同一文件的同一区域），你需要手动解决冲突，保存更改后重新提交。

8. 推送你的分支到远程仓库

当你在本地的开发工作完成并且已经合并了主分支的最新更新后，你可以将你的工作分支推送到远程仓库：

 git push origin <your-feature-branch>

9. 创建 Pull Request（合并请求）

接下来，你需要在远程仓库平台（如 GitHub、GitLab）上发起一个 Pull Request（PR），请求将你的工作分支合并到主分支。

在发起 PR 时，可以添加描述，说明你做了哪些更改。
其他团队成员会对你的代码进行审查，提出改进意见或建议。

10. 代码审查与合并

如果代码审查通过并且没有问题，管理员会将你的分支合并到主分支。

在某些情况下，你可能需要根据审查意见做进一步的修改，然后再次推送到你的分支上，更新 PR。

11. 删除本地和远程分支

当你的分支成功合并到主分支后，通常需要删除这个分支：

删除本地分支：

 git branch -d <your-feature-branch>

删除远程分支：

 git push origin --delete <your-feature-branch>

总结

这个 Git 工作流程总结如下：

克隆仓库
创建并切换到工作分支
开发和修改代码
添加和提交更改
拉取主分支的最新更改
合并主分支到工作分支
推送工作分支到远程仓库
创建 Pull Request 请求合并
代码审查与合并
删除本地和远程分支

这个流程能够确保开发团队在多个人员同时工作的情况下，代码始终保持一致和清晰，同时减少了代码冲突的风险。

Git 提交规范对于确保项目历史记录清晰、代码审查顺利进行以及团队协作的高效至关重要。一个良好的 Git 提交规范通常包括提交消息的格式、提交内容的要求等。下面是一套常见的 Git 提交规范和最佳实践：

1. 提交消息格式

提交消息通常包括三个部分：标题（Subject line） 、正文（Body） 和 页脚（Footer） 。其中，标题是必填的，正文和页脚是可选的。

标题（必填）

长度：标题不应超过 50 个字符。
动词格式：使用动词的祈使语气，像是 "Add"、"Fix"、"Update"，避免过去时（例如 "Added"）。
首字母：首字母大写。
结尾：不要以句号结尾。

格式：最好遵循 type: 简短描述 的格式，例如：

 feat: 添加用户登录功能
 fix: 修复页面加载时的崩溃问题

提交类型（type）

常见的提交类型如下：

feat：新功能
fix：修复 bug
docs：只修改了文档
style：代码风格（空格、格式、分号等），不影响功能
refactor：代码重构（既不是新功能也不是修复 bug）
test：添加测试或修改现有测试
chore：构建过程或辅助工具的变动，不涉及生产代码的变动
perf：提高性能的代码改动
ci：与持续集成相关的更改

正文（可选）

长度：一行不应超过 72 个字符。
内容：说明你为什么做了这个改动，而不仅仅是改动了什么。解释问题的背景以及为什么选择这样的方案。

格式：正文和标题之间应有一个空行。例如：

 feat: 添加用户登录功能
 
 增加了一个简单的用户登录模块，用户可以通过用户名和密码进行认证。
 同时修复了会话过期的相关问题。

页脚（可选）

页脚用于引用相关的任务编号、PR 链接，或者说明是否有重大的变动。可以包含以下内容：

关闭的 Issue：如果此次提交关联了某个 Issue，可以在页脚引用它：
```
 Closes #123
```

重大变动：如果有重大变动，标注 BREAKING CHANGE: 说明。例如：

 BREAKING CHANGE: 数据库字段 user_id 改为 userId，导致老版本的接口不可用。

2. 单一目的的提交

单一提交：每次提交应该专注于一个功能、一个改动或一个修复。不要将多个不相关的改动混在一起提交，这样有助于代码回溯和问题排查。

3. 提交频率

及时提交：你应该在每个逻辑性完整的阶段进行提交，而不是等待很长时间后一次性提交所有工作。
避免提交过于频繁：每个提交都应该有实际意义，不要为一些微小的、无意义的改动创建单独的提交。

4. 提交内容要求

避免提交调试代码：确保在提交前移除所有临时的调试代码，如 console.log、debugger 等。
遵循项目的代码风格：在提交前，请确保代码符合项目的代码规范，避免因为格式问题触发不必要的讨论。

5. 合并提交规范

合并分支时，避免使用默认的合并提交消息：合并提交时，默认的合并消息如 "Merge branch 'main' into feature-branch" 并不清晰。可以使用 --no-ff 提供自定义的合并提交消息，或者进行交互式合并。

使用 --no-ff 保留合并提交记录：
```
 git merge --no-ff <branch-name> -m "合并 <branch-name>，解决冲突并完成功能开发"
```

6. 提交前检查

检查差异：在每次提交前使用 git diff 查看更改，确保所有更改都是预期的。
```
 git diff
```
运行测试：确保所有代码在提交前通过了现有的单元测试，并且没有引入新的错误。

7. 使用交互式 rebase（可选）

如果你在自己的分支上进行了多次提交，最后需要合并到主分支时，可以使用 git rebase -i 命令，将多个提交合并为一个更简洁的提交，或者修改提交历史，保证提交历史的可读性。

 git rebase -i HEAD~3  # 交互式 rebase 最近 3 次提交

你可以使用这个功能将多个细小的提交合并成一个更有意义的提交。

总结

一个典型的 Git 提交规范可能如下：

 feat: 添加用户登录功能
 
 增加了一个简单的用户登录模块，用户可以通过用户名和密码进行认证。
 同时修复了会话过期的相关问题。
 
 Closes #123

这套提交规范不仅提升了提交记录的可读性，还提高了团队协作的效率，有助于代码审查、问题追踪和版本管理。