前言
一个项目的分支，一般包括主干 master 和 开发分支 dev，以及若干临时分支
分支命名规范
分支: 命名: 说明:
主分支 master 主分支，所有提供给用户使用的正式版本，都在这个主分支上发布
开发分支 dev 开发分支，永远是功能最新最全的分支
功能分支 feature-* 新功能分支，某个功能点正在开发阶段
发布版本 release-* 发布定期要上线的功能
修复分支 bug-* 修复线上代码的 bug
验证分支 demo-* 技术调研，完成后删除该分支
关联和操作远程分支
- 假设有一个远程分支为 dev，在本地建一个同名分支，然后执行下边的 pull 操作（第一次执行pull操作），就可以完成本地和远程分支的关联。
- 以后就可以进行日常的 pull 和 push 操作，注意需要多一个 origin 关键字
建立本地同名分支 git branch dev
拉取远程分支 git pull origin dev
推送远程分支 git push origin dev
git操作流程
//暂存
git add .
//提交
git commit -m fix-xxxxx（举例）
//拉取最新
git pull
//处理冲突，重新返回开头，操作，直到没有冲突
//处理冲突完成，推送代码
git push
commit 命名规范
- feat: 一个新功能
- fix: 一个 bug 修复
- docs: 仅仅修改了文档，比如 README, CHANGELOG, CONTRIBUTE 等
- style: 不影响代码逻辑的修改，比如空格、格式缩进、删除分号等
- refactor: 代码重构
- perf: 提升性能的改动
- test: 增加或修改测试
- chore: 改变构建流程、或者增加辅助工具、依赖库等
多人协作模式
add commit pull push 的顺序
- 一般来说，本地开发时要随时进行 add 操作，执行 add .
- 一般来说，每天需要将最新的开发分支 dev，进行一次远程提交（可能有merge）
- 对于 commit 和 pull 操作的先后顺序，有两个方案，如下：
- 方案一，在本地修改与远程代码无冲突的情况下，优先使用：pull->commit->push 的流程
- 方案二，在本地修改与远程代码有冲突的情况下，优先使用：commit->pull->push 的流程
- 尽量使用方案一，因为方案二会增加不必要的 merge 记录
- 最后进行 push
pull 后的冲突处理
- 如果 pull 或 push 失败报错，则因为远程分支比你的本地更新，需要先用 git pull 试图合并
- 如果合并有冲突，则解决冲突，并在本地重新 commit；
- 没有冲突或者解决掉冲突后，再用 push 推送远程分支
冲突处理
- 当执行 pull、push、merge等操作时，如果发生冲突，git会在命令行提示并列出所有的冲突文件
- 这时，需要在项目中查看每一个冲突文件，git会对文件中各处的冲突进行标记，标记一般为这样：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> dev
- 其中，<<<<<<< HEAD 和 ======= 之间的内容，为远程分支版本
- ======= 和 >>>>>>> dev之间的内容，为本地开发分支版本
- 你要做的就是选择使用其中的一个版本，同时将另一个版本的代码删除掉
- 处理该文件所有的标记冲突
- 处理git命令提示的所有冲突文件中的冲突
- 处理完成后，重新进行 pull 或 commit 操作
- 如果没有再报错，就可以执行push