## 团队Git 分支模型  名词解释： 1. `severe bug fixed for production hotfix 0.2`：为生产修补程序0.2修复的严重错误。 2. `incorporate bugfix in develop` 在开发中加入bugfix 3. `major features for next release`：下一版本的主要功能 4. `only bugfixes`：只有错误修正. 5. `bugfixes from release branch may be continuously merged back into develop`：发布分支的错误修正可能会不断合并回到开发中 ### 主分支 在核心部分，研发模型很大程度上靠现有模型支撑的。中心库有2个可一直延续的分支 * master分支 * develop分支 每个Git用户都要熟悉原始的master分支。与master分支并行的另一个分支，我们称之为develop分支。 我们把原始库/master库认作为主分支，HEAD的源代码存在于此版本中，并且随时都是一个*预备**生产*状态。 ### 辅助性分支 我们的开发模型使用了各种辅助性分支，这些分支与关键分支（master和develop）一起，用来支持团队成员们并行开发，使得易于追踪功能，协助生产发布环境准备，以及快速修复实时在线问题。与关键分支不同，这些分支总是有一个有限的生命期，因为他们最终会被移除。 我们用到的分支类型包括: * 功能分支 * 发布分支 * 热修复分支 每一种分支有一个特定目的，并且受限于严格到规则，比如：可以用哪些分支作为源分支，哪些分支能作为合并目标。我们马上将进行演练。 从技术角度来看，这些分支绝不是特殊分支。分支的类型基于我们使用的方法来进行分类。它们理所当然是普通的Git分支。 ### 功能分支 可能是develop分支的分支版本，最终必须合并到develop分支中。 分支命名规则：除了`master、develop、release-*、hotfix-*`之外，[其他](http://www.wuseyun.com/htmldata/tag/50/%E5%85%B6%E4%BB%96.html)命名均可。 功能分支（有时被称为topic分支）通常为即将发布或者未来发布版开发新的功能。当新功能开始研发，包含该功能的发布版本在这个还是[无](http://www.wuseyun.com/htmldata/tag/11/%E6%97%A0.html)法确定发布时间的。功能版本的实质是只要这个功能处于开发状态它就会存在，但是最终会或合并到develop分支（确定将新功能添加到不久的发布版中）或取消（譬如一次令人失望的测试）。 功能分支通常存在于开发者的软件库，而不是在源代码库中。 #### 创建一个功能分支 开始一项功能的开发工作时，基于develop创建分支 ``` $ git checkout -b DD_TASKID_381 develop Switched to a new branch 'DD_TASKID_381' ``` > 本地分支最好按照项目需要命名 `DD_TASKID_381`，表示点点项目任务ID = 381 #### 在任务分支开发项目 这里开始编写代码（当前分支`DD_TASKID_381`），代码编写完后，查看被修改的文件 ``` $ git status On branch DD_TASKID_381 Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.md no changes added to commit (use "git add" and/or "git commit -a") ``` #### 合并一个功能到develop分支 完成的功能可以合并进develop分支，以明确加入到未来的发布。切换到开发分支 `develop` ``` $ git checkout develop Switched to branch 'develop' ``` 合并`DD_TASKID_381`分支到 'develop' ``` $ git merge --no-ff DD_TASKID_381 Merge made by the 'recursive' strategy. readme.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) ``` >` no-ff`标志导致合并操作创建一个新commit对象，即使该合并操作可以`fast-forward`。这避免了丢失这个功能分支存在的历史信息，将该功能的所有提交组合在一起 （如果功能开发完毕）删除本地`DD_TASKID_381`分支 ``` $ git branch -d DD_TASKID_381 Deleted branch DD_TASKID_381 (was b674d30). ``` 推送本地`develop`分支远程到`origin/develop`分支 ``` $ git push origin develop Enumerating objects: 6, done. Counting objects: 100% (6/6), done. Delta compression using up to 4 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 460 bytes | 92.00 KiB/s, done. Total 4 (delta 3), reused 0 (delta 0) To https://git.coding.net/Tinywan/juhepay-dev.git 19ef874..54dee6f develop -> develop ``` ## 实践步骤 * 开发、测试、正式全部使用docker不是环境 * （新人）每次从 `develop `开发分支拉取最新代码，创建自己的分支：`git checkout -b tinywan develop `编写代码 * 编写好代码后切换到 `develop`,在`develop`分支整合已经开发完成的特性 ，开发完成的特性必须合并到develop分支，即添加到即将发布的版本中。 ``` git merge --no-ff tinywan # 推送到远程开发开发分支 git push origin develop ``` * jenkins开始构建。使用自己的账户在[http://jenkins.frp.tinywan.top](http://jenkins.frp.tinywan.top)上使用jenkins工具在任务[测试环境【develop分支】](#) 立即构建。在测试环境可以立即预览修改的内容 * 告诉测试人员可以测试了 * 开发环境代码发布到正式环境，主要就Tinywan负责。请在conding上手动[【新建合并请求】](https://coding.net/u/Tinywan/p/juhepay/git/compare)。合并开发分支到master分支上面 * jenkins开始构建。使用自己的账户在[http://jenkins.frp.tinywan.top](http://jenkins.frp.tinywan.top)上使用jenkins工具在任务[正式环境【master分支】(危险)】](#) * 正式环境可以进行测试代码了