目前存在问题
- 每个项目分支众多，命名混乱，有的分支用于测试，有的用于代码合并，有的分支用于开发，有的分支已经被废弃，分支跟标签混淆，时间久了无法了解分支的具体用途。混乱疯狂的分支合并操作，多个分支互相合并，出现问题难以回滚。以
cpp-ethereum项目为例，截止到2018/09/12为主，有如下42个分支(标签我就不列了)。all-static async_pbft_fork_v1.6 branch_release_v1.2.2_alpha develop develop-jamvm develop-jamvm-v1.6 develop-memory develop-memory-0930 develop-module develop-v1.6.0-java-native develop.1.5.1.3.log feature-externCall feature-nonce feature-pbft feature-sina-nonce feature-websockets jamvm-submodule jvmDevDemo jvm_dev_0913 master monitoring origin/develop-jamvm release_for_test_1.2.0.0_alpha release_for_test_1.2.1.0_alpha release_for_test_1.2.888.0_alpha release_for_test_1.3.1_alpha release_for_test_1.3.2_alpha release_for_test_1.3.3_alpha release_for_test_1.4.0.1_alpha release_for_test_1.5.0.1_alpha statechannels_baseon1.5 test_1.6.0.1 v1.2.2_alpha v1.4.0_branch v1.4.0_branch_bug20171212 v1.5 v1.5.3.30_sina v1.5.3.9-online v1.5.4 v1.5.5 v1.6 zk - 打出来的标签"无效"
目前打标签均由Jenkins自动打的，Jenkins打标签的流程是由测试人员选择特定的分支，而这些分支往往是开发分支。如果出包成功，则马上给项目打上标签，给测试人员去测试。当然，如果测试人员将所有的测试通过了，那么由Jenkins打的标签有效。如果测试未通过，那么该标签则是一个无效的标签！ - Juice 包不完整
现在打出来的Juice整包，没有包含需要的配套的Dapp，以及启动链的客户端。每次需要搭链的时候，客户端与Dapp都不知道去哪里找。拿过来的客户端或Dapp也不能确定是否跟底层配套。底层开发人员对客户端不熟，客户端开发人员对底层不熟，由此因"开发环境"问题耽误底层开发人员时间。除了打包不完整，出包结构也要做调整。如Web版本的包有底层有其他，唯独没有启动底层的Web。monitor包有无需要用到的底层。 - 项目代码混乱
以console项目为例，里面有基于electron框架写的钱包客户端代码，有使用Java语言写的后台控制台，还有使用Solidity语言写模块合约。试想，三个项目同时进行同时提交代码，如果合并的时候，负责客户端代码的人员遇到其他两个项目的冲突如何解决？ 如果客户端代码出了问题，我想跟历史代码进行比较，那么就可能大段其他两个项目更改的代码。还有问题是客户端将node_modules代码进行引入。
解决流程
- 集中管理
创建一个juice项目，将能独立的项目都拆分出来，以 git submodule 方式管理juice用到的所有项目，一是Jenkins打包将以此项目为标准，二是方便随时能checkout出一个经过测试验证过的整个juice可用的代码，也方便整个开发人员了解其他项目。大概设想目录结构如下：
juice/
├── cpp-ethereum/ # JUZIX Ethereum C++ client
├── console # 提供钱包管理功能的矩阵元区块链控台+WEB前端
├── monitor # 矩阵元联盟链监控后台monitor
├── Client-web/ # 矩阵元客户端和JUICE客户端的仓库
├── DApp-monitor # 矩阵元联盟链监控Dapp monitor
├── DApp-console/ # 区块链控制台DApp
├── ...... # 其他一些Juice项目或待拆分项目
└── inner-contracts/ # juzix ethereum inner contract-
分支规范
- master-ooo： 主分支，经测试测试无误之后，由测试人员操作Jenkins在该分支上打标签正式发布。保存每个版本所有的发布记录。
- release-ooo-x.x： 测试分支，开发人员编码完成之后，推送到此分支，由测试打包发布。此分支也做代码评审合并分支。保存整个版本的所有开发记录。此分支。
- develop-ooo-x.x： 开发分支，开人员编码工作在此分支上进行。下一个版本出来之前删除。
- hotfix-xxxxxx： master分支出现的bug紧急修复分支。修复完合并到master分支。合并完成由开发人员删除。
- feature-xxxxxx： 比较大的功能，从develop分支拉出来开发的功能。开发完成合并到develop分支，合并完成由开发人员删除。
其中ooo代表名称，比如master-sina，master-open-source。x.x代表版本(其实版本号也是没必要要的)，比如release-sina-1.5。xxxxx代表说明，比如hotfix-bug1111(紧急修复bug)，hotfix-permission-leak(紧急修复权限漏洞)，feature-nonce(开发nonce功能)，feature-pbft(开发pbft功能)。后面说的分支，均只用前面的部分进行描述。
上述分支只是供参考，具体依据实际项目个人变通。比如cpp-ethereum多人开发，不建议大功能在develop分支上面直接开发，当然，很少改动可以在develop分支直接开发没问题。如果只是个人负责单个项目，可以直接在develop分支进行开发。但是需要注意的是master, release分支永远不要作为开发分支。
-
Jenkins打包大概流程
- 各个负责人将develop合并到release分支，将代码审核无误之后，将代码push到远程分支，通知测试人员打包。后期应做到用钩子，Juice整个项目有推送自动打包。
- Jenkins将获取各个项目release分支上的最新代码，进行打包。
- 测试人员测试出的包。
- 测试人员测试无问题，测试人员回到Jenkins，以步骤1打包的代码状态打标签推送到服务器，测试有问题，回到步骤1。
主要工作量及时间预估
- 整理代码，将该拆分项目进行拆分，删除无效的分支。(3day)
- 由于之前Jenkins打包是在Linux平台进行，在Windows打包的客户端没有由Jenkins打包。需要Jenkins触发一台Windows服务器，进行打包。打包完成之后将客户端拷贝回来。(4day)
- 按照上述流程，修改Jenkins打包流程。(3day)
资源需求
- 用于给客户端，Dapp构建的Windows 10服务器。
- 开放开发人员删除标签，分支的权限。上述hotfix, feature如果需要协助，需要推送到服务器，合并完成需要开发人员删除。
- 给参与Juice项目人员开放所有Juice相关项目。鼓励以juice项目开发，并了解其他相关项目原理。
Git Flow 流程参考
