add files

团队协作.md

+
+
+
+1. SVN集中式的版本控制系统,所有人的工作快照都存放在同一个地方
+2. Git分布式的版本控制系统，Git每个人都有自己本地仓库，可以在自己的本地仓库提交更改。对于你自己的 电脑来说你使用的是集中式系统的开发方式，仓库中的所有更改都存放在自己的机器上。当你准备好自己的工作共享给别人时，链接到远程仓库，将自己的分支推送上去。
+
+共同维护的模型
+
+. 单个共享的仓库，每个人都拥有自己对仓库的共享写入权限，目前公司的模型
+. 并列贡献者仓库的模型 。 上游保留了仓库的完整控制，决定谁拥有项目仓库的读写权限。贡献者克隆派生项目，修改副本后通过合并请求或拉去请求提交这些更改。
+
+分支的策略的几种约定
+
+1. 主线开发分支，项目的主分支应该只包含经过测试的工作，并且绝不应该被破坏
+2. 功能分支和集成分支 所有新的工作都在一个功能分支上完成，这个分支的小到恰好能容纳一个完整的想法
+3. 一些分支通过一个集成分支与其他开发者完成的工作保持同步。等到软件发布前，构建管理员可以挑选那些功能集成到这个版本。添加多个功能分支和一个集成分支后一直可以保证代码一直是可部署的
+
+
+Gitflow
+在理想的协作团队中，功能将在你开始的工作前在工单中进行描述，并且分支名会包含这个工单名。[ticket_id]-[terse-title] 命名约定。比如一个工单 "1234" ，功能时修改失效链接， 分支名分为 "1234-fixing_links"
+最初，软件项目只有一个develop分支,在开发分支上添加新的功能，直到没有新功能需要做了，将这个时间点叫做功能冻结。此时会从开发分支上创建一个新的分支，只有Bug修复能提交到这分支上去。功能冻结是或许并不是所有功能都完成了，所以任然有工作被提交至develop分支，如果发现了Bug。这些bug同样需要被"向后"并入develop分支。
+经过一段时间所有bug会被宣告发现修复。此时所有经过了指令保证测试的代码都被提交到master分支上。接着就可以部署了。
+
+当然现实中有一些需要立即修改的Bug，需要从产品分支拉出一条新的分支，他不应该包含除了修复Bug以外的任何工作，当修完分这些Bug后，将分支合并到产品分支和开发分支。
+
+
+
+更新分支
+ 将基变解释为在一个已有的时间线上重放已有的提交
+ . rebase 命令用于更新分支
+ . merge 命令用于引入全新的工作
+
+----------------
+
+
+
+ 根据计划发布软件
+
+ 1. 从一个基本的提交开始，创建一个master
+ 2. 打上 v1.0的标签
+ 3. 将代码推送到集中式代码托管系统
+
+----------------
+
+1，新建develop 分支，在develop 分支上进行产品的开发
+2. 新功能的添加 创建功能分支
+3. 完成开发后将develop分支并如qa测试分支
+4. qa测试分支完成后将qa分支并入master分支，打上发布版本的标签
+
+
+发布后的补丁
+
+有时候部署的代码存在错误，如果这个bug需要在下次软件发布前得到快速修复，这时就需要一个计划外的修复，这些部署通常称为补丁。在补丁中，工作不是从develop分支开始，而是从maser分支开始，确保更改只引入了部署代码中发现的问题的修复
+
+工作流
+1. 创建一个新的补丁分支，通常以hotfix开头，迁出master分支而不是develop分支
+2. 生成标签名的列表，定位到最新打上标签的发布
+3. 从master 最新打上的标签发不上，创建一个新的分支 使用hotfix- 【工单号】 -【工单的描述】(hotfix-123-fix_error_links)
+4. 修复bug
+5. 将通过测试的补丁并入master分支
+6. 将master分支上的最新提交打上最新发布的版本号，如v1.01
+7. 将经过测试的补丁并入develop分支，保证下次软件正式分布的时候不会丢失
+
+
+-------
+
+![GitLab工单](issue.png) 
+![issue.png](issue.png)
+
+
+
+
+