前端项目git操作命名规范和协作开发流程

前言

一个项目的分支，一般包括主干 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