一. 项目版本规范(或API组件开发) 项目的版本号推荐使用语义化版本规范([https://semver.org/lang/zh-CN/](https://semver.org/lang/zh-CN/)), 其基本规则如下: 版本号定义:**..;**比如 1.0.0，采用 X.Y.Z的格式规范，且X, Y 和 Z 为非负的整数。 其中 X 为主版本号, Y 为 次版本号, Z 为修订版本号。 **升级原则:** **1) 主版本号：**功能模块有大的变动时，比如API兼容性做了修改或整个架构发生了变化。 版本号需要递增, 次版本号和修订版本号必须归零，比如 1.1.5这个版本，现在组件的API兼容性发生改变或整个项目结构发生改变，那么主版本号需要递增，因此这个时候版本号变成为 2.0.0; **2) 次版本号:**当模块或组件增加新功能时 或 一些公用的API功能被弃用的时候，也需要递增。 每次次版本号递增时，修订号必须归零。比如 1.1.5 版本，现在模块或组件增加新功能时，那么次版本号需要递增。因此现在的版本变成了 1.2.0; **3) 修订号:**当功能模块或组件的bug修复, 或功能扩充等。 修订使指项目中的bug修复，那么版本号需要递增。比如 1.1.5 版本，现在bug修复好了，那么现在的版本变为 1.1.6了。 [回到顶部](https://www.cnblogs.com/tugenhua0707/p/11921027.html#_labelTop) 二：版本控制系统规范(GitFlow) **GitFlow概念:**GitFlow是使用一个中央代码仓库，它是所有开发者的信息交流中心。它和其他工作流程一样，开发者在本地开发完成，然后将分支代码推送到中央仓库。不同点在于项目中的分支结构。 可以参考:([https://nvie.com/posts/a-successful-git-branching-model/](https://nvie.com/posts/a-successful-git-branching-model/)) 使用GitFlow, 在项目中会存在两个长期分支，主分支(master) 和 开发分支(develop)。 **主分支(master):**该主分支代码用于对外发布的代码(一般指线上已经发布的)。 **开发分支(develop):**用于日常开发。该分支是基于master分支克隆的, 编码工作在该分支上进行。 **功能分支(feature):**该分支是基于develop分支克隆的。该分支的作用主要用于一些新功能的开发,功能开发完毕后需要合并到develop分支。 feature分支可以有多个，它是属于临时分支，当某个功能实现后可以删除该分支。 **测试分支(release): **它是基于develop分支克隆的，产品编码工作完成后，需要把测试分支代码发布到测试环境中，如果在测试环境中发现了一些小bug，那么就直接在该分支上进行修复操作。等测试所有完成后，我们需要把该分支代码合并(merge)到develop分支上。 该分支也属于临时分支, 当功能实现后也可以删除该分支。 **Bug修复分支(bugfix):**  该分支是基于master分支或Tag标签进行克隆的。作用主要用于修复对外发布的分支。修复完毕后，需要分别合并到develop分支和master分支上。本分支也属于临时分支，功能完成后也可以删除该分支。 **基本步骤如下:** 1\. 从远程仓库克隆代码到本地仓库，基本命令比如如下: ~~~ git clone https://github.com/tugenhua0707/gitflow-test.git ~~~ 2\. 在master分支上，创建develop分支，基本命令如下: [](javascript:void(0); "复制代码") ~~~ // 切换到master分支上 $ git checkout master // 基于master分支克隆develop分支，并且切换到develop分支上 $ git checkout -b develop // 推送develop分支到远程仓库 $ git push origin develop ~~~ [](javascript:void(0); "复制代码") 3\. 在develop分支本地仓库基本流程 当某个功能点开发完成后，我们需要将代码提交到本地仓库。 [](javascript:void(0); "复制代码") ~~~ // 提交到缓冲区 $ git add . // 提交修改到本地仓库 /* 如果是修复BUG的话，则注释可以为: "Bug 修改说明" 如果是完成了某一个功能的话，则注释可以为: "Task 修改说明" */ $ git commit -m "Bug 修改说明" ~~~ [](javascript:void(0); "复制代码") 4\. 推送代码到远程仓库 当我们完成一个功能点或阶段工作时，需要将代码推送到远程仓库develop分支上。 ~~~ // 先拉取最新代码, 防止代码冲突 $ git pull // 解决代码冲突后/或代码没有冲突的话, 我们需要将develop分支代码推送到远程仓库中 $ git push origin develop ~~~ 5\. 功能分支(feature) 此时此刻，我们项目中某一个模块需要添加一个新功能，我们可以在develop分支上克隆一份代码来, 然后进行对应某个功能开发。当然在团队 合作中，我们可以创建多个功能分支。比如叫 feature1，feature2，依次类推来命名.... [](javascript:void(0); "复制代码") ~~~ // 从develop分支中克隆一份代码下来，且切换到对应的 feature1 功能分支上。 $ git checkout -b feature1 develop // .... 然后进行开发，开发完成后提交代码到远程仓库 // 功能开发完成后，我们需要把该功能分支再合并到我们的develop分支上, 切换到develop分支上来，然后进行如何合并命令 $ git merge feature1 // 合并完成后该分支，我们可以把该功能分支删除 // 删除本地分支 $ git branch -d feature1 // 删除远程分支 $ git push origin --delete feature1 ~~~ [](javascript:void(0); "复制代码") 6\. 将代码发布到测试分支(release) 如上在develop分支上代码开发完成后，我们需要提测到测试环境中，因此我们需要将代码发布到测试分支release。 执行基本命令如下: [](javascript:void(0); "复制代码") ~~~ // 切换到develop分支上来 $ git checkout develop // 创建并切换到release分支来 $ git checkout -b release // 推送到远程仓库中 $ git push origin release ~~~ [](javascript:void(0); "复制代码") // ..... 在测试中有bug时，直接在该测试分支(release)中修改。 测试完成后，需要将 测试分支(release) 代码合并到develop分支中。 ~~~ // 切换到develop分支上 $ git checkout develop // 执行合并操作, 将release分支代码合并到develop分支上(如果有冲突，需要解决冲突，再合并) $ git merge release ~~~ 当开发和测试代码都没有问题的时候，需要将代码发布到线上后，此时需要把develop分支代码合并到master上。 ~~~ // 先切换到master分支 $ git checkout master // 合并develop分支代码 $ git merge develop ~~~ 7\. 线上发布完代码后，需要打开Tag(里程碑Tag包) ~~~ // 创建里程碑Tag $ git tag -m "Task v1.0.0发布" v1.0.0 // 推送里程碑Tag到远程库 $ git push origin v1.0.0 ~~~ 8\. 发布完成后，线上Bug修复工作流 1) 获取到Bug产品的软件发布的版本号 2) 基于里程碑Tag创建分支: ~~~ // git checkout -b [创建的分支名称] [里程碑Tag的名称] $ git checkout -b bugfix-v1.0.0 v1.0.0 // 就会创建一个 bugfix-v1.0.0 分支，然后进行修改. ~~~ 3）修复代码完成后可以使用如下命令查询修改过的地方 ~~~ $ git diff ~~~ 4) 修改完成后分别合并到develop分支和master分支上 [](javascript:void(0); "复制代码") ~~~ /* 合并到develop分支 */ $ git checkout develop $ git merge bugfix-v1.0.0 // 提交到远程仓库develop分支下 $ git push origin develop /* 合并到master分支下 */ $ git checkout master $ git merge develop // 提交到远程仓库master分支下 $ git push origin master ~~~ [](javascript:void(0); "复制代码") 5) 创建新的里程碑Tag ~~~ $ git checkout master $ git tag -m "Bug 修复某某bug" v1.0.1 // 推送到远程仓库中 $ git push origin v1.0.1 ~~~ [回到顶部](https://www.cnblogs.com/tugenhua0707/p/11921027.html#_labelTop) 三：github Issue 任务管理 github Issue是目前相对来说比较流行的任务管理工具，它可以帮助我们了解项目的进度、资源的分配情况。 在团队协作中，每个issue可以代表一个任务，我们的每一项任务可以创建一个Issue，Issue的完成后由自己关闭掉。 每个Issue应该包含问题的标题和描述信息，使后来的人一看标题和描述就可以知道该issue是那个项目下的，该项目会有那些基本功能点。 **3.1 基本用法** 在我们的Github代码仓库中都有一个Issues面板，如下图所示:  1）在如上所示的 Filters 中，我们可以对分类进行过滤查询。方便管理所有的类目。 2）在如上所示的 Labels中，Issue可以贴上标签，有利于分类管理和过滤查看，默认有9个标签。我们可以对9个默认标签进行修改或删除操作，我们有可以新建自己的标签，如下图所示:  对于一些稍微大一点的项目，每个Issue至少应该有两个Label, 一个表示性质, 另一个表示优先级的。 表示优先级的Label，可以参考下面的级别: **高优先级(High)：**表示对系统有重大影响，只有解决它之后，才能完成其他任务。 **普通优先级(Medium):**对系统的某个部分有影响, 用户的某一部分操作会达不到预期的效果。 **低优先级(Low):**对系统的某个部分有影响，用户几乎感知不到。 **微不足道(Trivial):**对系统功能没有影响，一般是视觉效果等，比如字体或颜色不满意。 添加如上标签后，如下图所示:  3) 在如上的 Milestones 中，它叫做里程碑，用作Issue的容器，相关的Issue可以放在一个 Milestone 里面。 我们可以新建一个 Milestone, 在Issues面板的首页，点击Milestones按钮。然后我们再接着点击 New milestone 按钮，然后填写 Milestone的名称和内容，可以指定到日期时间，如下图所示:  在如上设置完成后，我们就可以创建一个Issue了，进入Issue面板，点击新建 "New Issue" 按钮。就会进入新建Issue页面，如下图所示：  如上就是新建Issue界面，左侧是填入Issue的标题和内容，右侧是四个配置项。我们分别来看下右侧四个配置项的具体含义: **Assignees:**人员 **Labels:**标签 **Projects:**项目 **Milestone:**里程碑 **Assignee** Assignee 选择框用于从当前仓库的所有成员之中，指派该Issue给某个人，目前我这边只有我自己，如下所示:  如上我们只要选择一个人即可。 **Labels** Issue 可以贴上标签，这样有利分类和过滤查看，如下是我刚刚新建的所有标签，如下图所示:  新建完成后，可以变成如下看到，如下图所示:  Projects： 指具体的那个项目，我这边目前，可以为空，不填吧。 **Milestone:**指里程碑，也就是可以理解为该项目什么时候完成的。如下图所示:  如上就是我们刚刚新建的日期时间。 新建一个Issue如下所示:  然后效果就变成如下所示:  最后填写完成后，我们点击最右侧下面的 "Submit new issue" 按钮，即可提交，然后我们就可以在Issue面板中可以看到我们的issue列表信息了，如下图所示:  当我们的这个项目有任何功能点已经完成了，或者状态发生改变了，或者上线了(如果上线了，我们需要关闭该项目)。我们需要自己手动去改变该项目的状态，如下图所示，进入该项目的目录下进行更改状态:  如上该上面完成及上线后，我们需要关闭该issue，因此我们可以点击该issue的详情页，点击最底部的 close issue 按钮，如下图所示:  如上就是github中的issue在团队协作中项目管理的基本操作了。