🧑💻Git版本控制-HowieCong
1. 项目初始化与仓库创建
git init命令初始化一个本地git仓库- 在github创建一个远程仓库，将本地仓库与远程仓库，
git remote add origin [远程仓库地址]
2. 分支管理策略（采用常用的分支开发模式）
- 以
master或main为主分支，存放稳定可上线的代码 - 开发新功能的代码时，从
master分支创建特性分支，例如feature/[功能名称]，在特性分支上进行编码规则；git chekout -b feature/login，-b表示创建并切换到新分支上，好处在于可以不同功能的开发隔离出来，避免互相干扰 开发完一部分功能的代码时，将修改的文件添加到暂存区，使用
git add [文件路径]；使用git commit -m ''本次提交的内容''提交代码到本地仓库- eg：修改了
login.js,就可以使用git add login.js把文件添加到暂存区；使用git commit -m '修改了登录页面逻辑'
- eg：修改了
保持分支更新
- 将
master或main主分支的更新合并到自己的特性分支，避免分支之间的差异过大导致后续合并困难 - 使用
git checkout [master或main主分支]切换到主分支，然后进行git pull拉取到最新的代码 - 再切换回特性分支，使用
git merge [master或main主分支]的更新合并到特性分支
- 将
合并分支到主分支，定期将特性分支的代码合并回
master/main主分支，合并前确保在特性分支进行测试，避免问题代码带入master，使用git rebase操作提交历史- 挖坑：为什么不用
git merge操作提交历史呢？ - 答案：1.根据团队习惯选择 2.
git rebase更简洁线性，但git rebase操作相对复杂
- 挖坑：为什么不用
3. 提交规范
团队成员遵循统一的提交规范，有助于生产清晰的提交历史，方便后续回溯与版本管理
- eg：使用Vue的提交规范格式
<type>(<scope>):subject
- eg：使用Vue的提交规范格式
- 每次提交，附带详细的提交说明，解释代码的变更原因、解决的问题
- 特别是涉及关键业务逻辑或架构调整的提交，以便其他团队成员理解
4. 代码审查
- 完成功能开发后，将特性分支推送到远程仓库，但在特性分支合并到
master之前，进行代码审查（Code Review） - 可以利用Git平台的Pull Request（PR）机制，开发人员提交PR后，团队成员对其代码进行审查，提交修改意见
- 审查重点：代码质量、是否符合编码规范、功能实现是否正确、有无安全隐患等
- 被审查人员：根据反馈意见修改代码，重新提交审查，直到代码通过审查，方可合并到
master分支，确保master复制代码的高质量
5. 发布和标签管理
- 发布版本：根据项目的部署流程而不同，可能是将代码打包后部署到测试环境、预生产环境，最后到生产环境
打标签
- 使用
git tag -a v1.0 -m "版本1.0发布，包含什么什么功能" - 通过标签快速定位，使用
git checkout v1.0
- 使用
❓其他
1. 疑问与作者HowieCong声明
- 如有疑问、出错的知识，请及时点击下方链接添加作者HowieCong的其中一种联系方式或发送邮件到下方邮箱告知作者HowieCong
- 若想让作者更新哪些方面的技术文章或补充更多知识在这篇文章，请及时点击下方链接添加里面其中一种联系方式或发送邮件到下方邮箱告知作者HowieCong
- 声明：作者HowieCong目前只是一个前端开发小菜鸟，写文章的初衷只是全面提高自身能力和见识；如果对此篇文章喜欢或能帮助到你，麻烦给作者HowieCong点个关注/给这篇文章点个赞/收藏这篇文章/在评论区留下你的想法吧，欢迎大家来交流！
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。