kookeeper 1.0.0

data/docs/zh-CN/BIGKEEPER_FILE.md

@@ -0,0 +1,84 @@
+# Bigkeeper 文件
+
+首先，我们在主项目 Podfile 所在的目录加入 **Bigkeeper** 文件。
+
+## 配置版本
+
+```
+version '2.8.8'
+```
+
+版本号的用途有：
+
+- feature 和 hotfix 流程里面做为分支名前缀的一部分，方便后期通过版本号匹配分支；
+- release 流程里面做为发布版本号，影响范围包括业务模块和主项目。
+
+## 配置主项目
+
+```
+home 'BigKeeperMain', :git => 'git@github.com:BigKeeper/BigKeeperMain.git', :pulls => 'https://github.com/BigKeeper/BigKeeperMain/pulls'
+```
+
+这个配置包含三个部分：
+
+- 主项目的名字；
+- 主项目的 git 远程仓库地址；
+- 主项目的 pull request / merge request 页面地址，完成某个 feature / hotfix 时，会自动打开这个页面，让开发者提交 pull request / merge request。
+
+## 配置模块源
+
+```
+source 'git@git.elenet.me:LPD-iOS/LPDSpecs.git, elenet-lpdspecs' do
+  modules do
+    ...
+  end
+end
+
+source ...
+  ...
+end
+```
+
+考虑到我们的业务模块可能属于不同的源，所以配置业务模块之前，要先在最外层配置源信息：
+
+- 源 git 地址；
+- 源名称。
+
+配置这个主要是方便对我们关心的源执行 `pod repo update`，从而节省命令执行的时间。
+
+## 配置业务模块
+
+```
+modules do
+  mod 'BigKeeperModular', :git => 'git@github.com:BigKeeper/BigKeeperModular.git', :pulls => 'https://github.com/BigKeeper/BigKeeperModular/pulls'
+  mod ...
+end
+```
+
+这个配置包含可以配置多个业务模块，建议是把当前所有非第三方库都加入到这个配置里面：
+
+- 业务模块在 Podfile 中的名字；
+- 业务模块的 git 远程仓库地址；
+- 业务模块的 pull request / merge request 页面地址，完成某个 feature / hotfix 时，会自动打开这个页面，让开发者提交 pull request / merge request。
+
+## 配置用户自定义信息
+
+```
+user 'perry' do
+  mod 'BigKeeperModular', :path => '../BigKeeperModular'
+end
+```
+
+如果用户需要配置一些自定义信息，比如业务模块在本地的路径，就可以增加一个这样的配置。
+
+这个配置同样支持对指定的用户名（上述配置用户名为 perry）配置多个业务模块，目前支持的是：
+
+- 配置业务模块的本地路径，通过这个路径，我们就可以在主工程直接对业务模块做一些 CocoaPods 和 git 相关的操作。
+
+> 注：
+>
+> 1. 默认用户名是 git global config 的 user.name；
+>
+> 2. 默认我们会把本地路径配置成 `../{业务模块在 Podfile 中的名字}` 的形式，因为大部分情况下，我们会把项目都放在同级目录下，这也是我们推荐的；
+>
+> 3. 另外，在使用 bigkeeper 相关功能时，如果某些业务模块并没有 clone 到本地，bigkeeper 会根据之前配置的业务模块远程 git 地址 clone 业务模块仓库到**主项目同级目录下**。

data/docs/zh-CN/FEATURE&HOTFIX.md

@@ -0,0 +1,88 @@
+# feature - 功能开发流程 & hotfix - 线上修复流程
+
+> 注：hotfix 除了基础分支是 **master**，其他操作和 feature 一致，所以我们这里以 feature 为例说明。
+
+直接在命令行执行 `big feature --help` 可以查看其提供的所有功能：
+
+```
+NAME
+    feature - Gitflow feature operations
+
+SYNOPSIS
+    big [global options] feature delete
+    big [global options] feature finish
+    big [global options] feature list
+    big [global options] feature publish
+    big [global options] feature pull
+    big [global options] feature push
+    big [global options] feature rebase
+    big [global options] feature start
+    big [global options] feature switch
+    big [global options] feature update
+
+COMMANDS
+    delete  - Delete feature with name
+    finish  - Finish current feature
+    list    - List all the features
+    publish - Publish current feature
+    pull    - Pull remote changes for current feature
+    push    - Push local changes to remote for current feature
+    rebase  - Rebase 'develop' to current feature
+    start   - Start a new feature with name for given modules and main project
+    switch  - Switch to the feature with name
+    update  - Update modules for the feature with name
+```
+
+功能列表如下：
+
+- start：
+  开始一个新的 feature，输入参数依次为：
+  - feature 的名字;
+  - 开发该 feature 需要改动的业务模块名。可以多个，用空格隔开；如果不指定，取 **Bigkeeper 文件中所有的业务模块名**。
+- finish：结束当前 feature；
+- publish：发布当前 feature；
+- switch：切换到一个已经存在的 feature，输入参数为 feature 名；
+- update：
+  更新一个 feature 需要改动的业务模块，输入参数依次为：
+  - feature 的名字;
+  - 开发该 feature 需要改动的业务模块名。可以多个，用空格隔开；如果不指定，取 **Bigkeeper 文件中所有的业务模块名**。
+- pull：拉取当前 feature 主项目和业务模块的远程 git 仓库更新；
+- push：提交并推送当前 feature 主项目和业务模块的本地变更到远程 git 仓库，输入参数为提交信息；
+- rebase：rebase 主项目和业务模块 `develop` 分支到当前 feature；
+- delete：根据 featue 名删除主项目和业务模块所有相关分支；（PS：慎用，因为会删除本地和远程所有相关分支）
+- list：显示当前的 feature 列表。
+
+## 各个指令的使用场景
+
+- 如果需要开发新的功能，使用 big feature start；
+- 开发功能过程中如果发现某个模块其实不用改动，使用 big feature update 来把这个模块从这个 feature 移除；
+- 使用 big feature pull 来同步主项目和相关业务模块远端变更；
+- 使用 big feature push 来推送主项目和相关业务模块变更到远端；
+- 使用 big feature rebase 来 rebase 主项目和业务模块 `develop` 分支到当前 feature；
+- 使用 big feature switch 来切换 feature，比如：两个功能并行开发的时候，就可以用这个命令互相切换了；
+- 功能开发完成，需要单独打包提交测试时，使用 big feature finish 结束开发；
+- 开始进行集成测试，需要将代码 PR 到 develop 分支时，使用 big feature publish；
+- 如果开发过程中突然有新的功能需要紧急开发，直接使用 big feature start 进行新功能开发，旧功能未提交的内容我们会保存在 stash 中。
+
+## 各个指令执行结束后工程的状态
+
+### feature 的工作区
+
+在开始了解各条指令执行后工程的状态之前，我们先了解一下 bigkeeper feature 流程的工作区。
+
+![](../../resources/readme/big-keeper-readme.001.png)
+
+feature 的工作区主要由两部分组成：
+
+- 主项目；
+- 相关业务模块，我们把 Podfile 中引用方式为 `:path => {业务模块本地路径}` 的模块做为相关业务模块。
+
+主项目和每个相关业务模块又有各自的工作区，由三个部分组成：
+
+- 当前代码区改动；
+- stash 缓存区，当用户需要切换新的 feature 时，对于用户来不及提交的改动，我们会缓存到各个项目的 stash 中，（PS：所以代码突然不见了不要担心，都在 git 的 stash 里面），而当用户切换回某个 feature 时，我们会把和该 feature 分支同名的 stash 恢复回来，从而使用户可以继续开发之前未完成的部分，因为需要通过 feature 的分支名来匹配 stash，而 git stash 又没有提供给 stash 命名的功能，所以我们实现了 [bigstash](https://github.com/BigKeeper/bigstash) 来完成这个功能；
+- git。
+
+> 注：
+> 1. 所有的指令我们都做了良好的出错提示和异常恢复机制，当某个步骤报错时，只需要根据提示的错误手动修复问题，重新输入指令，bigkeeper 会继续执行接下来的流程。
+> 2. 所有的代码都会保存在工作区中，除了 delete 操作，bigkeeper 不会删除任何工作区的代码，也就是说：你总是可以在变更区、Stash 中或者远端找到你变更的代码。

data/docs/zh-CN/PODFILE.md

@@ -0,0 +1,43 @@
+# podfile - podfile版本控制流程
+
+直接在命令行执行  `big podfile --help` 可以查看其提供的所有功能
+
+```
+NAME
+    podfile - Podfile operation
+
+SYNOPSIS
+    big [global options] podfile [command options] detect
+    big [global options] podfile [command options] lock
+    big [global options] podfile [command options] upgrade
+
+COMMAND OPTIONS
+    --pod, --podfile=arg - (default: none)
+
+COMMANDS
+    detect  - Detect podname should be locked.
+    lock    - Lock podname should be locked.
+    upgrade - Update module version
+
+```
+
+全局参数如下：
+
+- -pod  --podfile ：podfile文件路径
+
+功能列表如下：
+
+- detect：
+    检测当前同步到本地的项目工程中podfile，得到未锁定的第三方库。
+    如果存在，提示需要指定版本。
+    如果不存在，提示无需指定版本的第三方库。
+
+- lock:
+    检测到存在需指定代版本的三方库后，执行lock指令对所有需要锁定的库进行锁定。
+
+- upgrade:
+    检测配置文件中指定业务库，有无最新可更新版本。
+
+  ## podfile lock 流程
+
+    ![](../../resources/readme/big-keeper-readme.011.png)

data/docs/zh-CN/README.md

@@ -0,0 +1,113 @@
+[English](../en-US/README.md)
+
+---
+
+# bigkeeper
+
+![](../../resources/banner.png)
+
+[![Build Status](https://travis-ci.org/BigKeeper/bigkeeper.svg?branch=master)](https://travis-ci.org/BigKeeper/bigkeeper)
+[![Maintainability](https://api.codeclimate.com/v1/badges/c6dc4161e84fcec9a890/maintainability)](https://codeclimate.com/github/BigKeeper/big-keeper/maintainability)
+[![Gem Version](https://badge.fury.io/rb/bigkeeper.svg)](https://rubygems.org/gems/bigkeeper)
+[![Language: Ruby](https://img.shields.io/badge/language-Ruby-da212f.svg)](https://www.ruby-lang.org/)
+[![License](https://img.shields.io/badge/license-MIT-000000.svg)](https://github.com/BigKeeper/big-keeper/blob/master/LICENSE)
+[![Gitter](https://img.shields.io/gitter/room/BigKeeper/BigKeeper.svg)](https://gitter.im/Big-Keeper/Lobby)
+
+bigkeeper 是一个 **iOS&Android 模块化项目**效率提升工具，旨在帮助有模块化需求的团队更轻松的渡过“半模块化”尴尬期。
+
+使用这个工具后，开发者**在主项目内**即可完成**包括其他业务模块在内**所有代码的编写和管理。
+
+我们借鉴 CocoaPods 的做法，开发团队只需要在主项目中加入一个 Bigkeeper 文件，然后利用我们提供的 `big` 命令，即可更便捷的实现**代码分支**和**业务模块**的管理；另外，通过 `big` 命令提供的流程，也能帮助开发者养成更规范的日常开发习惯，减轻项目管理者的负担。
+
+## 应用场景
+
+在模块化项目的过渡阶段，我们往往会碰到业务拆分不是那么彻底的情况（PS：比如主项目中仍然存在业务相关代码），这样就会导致一系列问题：
+
+- 开发流程方面：开发者在开发一个 feature 时需要维护多个项目的分支，同时还要频繁修改主项目的 `Podfile`;
+- 项目管理者需要花很大精力去和团队成员同步项目管理规范流程，尤其对于新人，挑战很大；
+- 开发过程中如果碰到突发情况需要开新分支处理问题时对当前工作区的保存操作会很繁琐（PS：因为涉及到多个项目）；
+- 日常开发过程中类似 commit、pull、push 等操作比较繁琐（PS：因为涉及到多个项目）；
+- 资源（比如图片）散落在各个业务模块，可能存在重名、重复等问题，难以管理；
+- 业务模块可能存在横向依赖的问题，导致业务模块间耦合严重，不能单独编译运行。
+- 各模块依赖的版本没有统一的同步更新方式，导致各个模块的开发环境不一致，问题百出。
+
+bigkeeper 的出现就是为了解决这些问题。
+
+> 注：也有很多人认为直接做一个完整的组件化项目更合理，而不需要采用这样曲折的方案，但是很多时候我们并没有这么多的精力直接去做这些事情，bigkeeper 存在的价值也是为了帮助开发团队在** iOS&Android 模块化项目过渡阶段**能更轻松的往前走。
+
+## 安装
+
+- 当作 Ruby Gem 使用：
+  在项目的 Gemfile 中加入下面这行：
+
+  ```ruby
+  gem 'bigkeeper'
+  ```
+
+  然后执行：
+
+    $ bundle
+
+- 直接安装：
+
+    $ gem install bigkeeper
+
+## 使用方法
+
+- [Bigkeeper 文件配置](BIGKEEPER_FILE.md)
+- `bigkeeper` 工具使用：
+
+  直接在命令行执行 `bigkeeper` 可以查看其提供的所有功能：
+
+  ```
+  NAME
+    big - Efficiency improvement for iOS&Android module development, iOSer&Android using this tool can make module development easier.
+
+  SYNOPSIS
+    big [global options] command [command options] [arguments...]
+
+
+  GLOBAL OPTIONS
+    --help         - Show this message
+    -p, --path=arg - (default: ./)
+    -u, --user=arg - (default: mmoaay)
+    -v, --ver=arg  - (default: Version in Bigkeeper file)
+
+  COMMANDS
+    feature - Gitflow feature operations
+    help    - Shows a list of commands or help for one command
+    hotfix  - Gitflow hotfix operations
+    image   - Image operations
+    podfile - Podfile operation
+    release - Gitflow release operations
+    spec    - Spec operations
+    version - Show version of bigkeeper
+  ```
+
+  全局参数如下：
+
+  - -p, --path：主项目所在的目录，默认是执行 bigkeeper 命令的当前目录；
+  - -v, --ver：版本号，如果没有指定的话，会以主项目 [Bigkeeper 文件](BIGKEEPER_FILE.md)中指定的版本为准。
+  - -u, --user：用户名，默认是 git global config 的 user.name，会显示在命令提示信息中，比如上述提示信息中的默认用户名是 mmoaay
+
+  功能列表如下：
+
+  - [feature](FEATURE&HOTFIX.md)：功能开发流程；
+  - [hotfix](FEATURE&HOTFIX.md)：线上 Bug 修复流程；
+  - [release](RELEASE.md)：发布流程；
+  - [podfile](PODFILE.md)：Podfile 管理；
+  - [image](IMAGE.md)：图片管理；
+  - [spec](SPEC.md)：spec 管理；
+  - version：查看 bigkeeper 当前版本号；
+  - help：查看 bigkeeper 帮助文档。
+
+## 其他
+
+- [一些建议](RECOMMEND.md)
+- [一些思考]()
+
+## 协议
+
+![](https://upload.wikimedia.org/wikipedia/commons/thumb/f/f8/License_icon-mit-88x31-2.svg/128px-License_icon-mit-88x31-2.svg.png)
+
+bigkeeper 基于 MIT 协议进行分发和使用，更多信息参见协议文件。

data/docs/zh-CN/RECOMMEND.md

@@ -0,0 +1,22 @@
+# 代码管理规范
+
+## 基本原则
+
+- master 分支保证是线上最新包的代码。
+- develop 分支保证是下一个发布包的代码，随时支持发布。
+
+### 开发和测试流程
+
+feature 分支为 feature 开发和提测分支，提测前需要 rebase/merge develop 的代码，测试完成后，pr 到 develop 分支，确定下个版本发布才 accept pr。
+
+### develop 分支 bug 修复流程
+
+单独开分支，fix 完成后，pr 到 develop 分支。
+
+### 发布流程
+
+develop->release->master 瞬间操作，release 不能长期存在。
+
+### hotfix 流程
+
+master 拉出 hotfix，fix 完成后分别 pr 到 master、develop 两个分支，完成后新建发布版本。

data/docs/zh-CN/RELEASE.md

@@ -0,0 +1,60 @@
+饿了么物流模块化效率提升思考 -  发布流程篇
+### 背景
+bigkeeper 的目的是为了在项目的模块化过渡阶段提升效率,在过渡到模块化的过程中要做很多的代码抽离,而越来越多的 Pod依赖(假设用Cocoapods做包管理)对项目管理者的负担越来越大.
+移动端完成一个需求迭代,除了代码开发外,还需要有模块发版,集成,打包,回归这些步骤,而往往在回归到发版的时候,研发同学要花较多时间在发版,这严重影响了开发效率.
+### 解决方案
+为了提高要提高发布流程的发布效率,我们开发了big release 功能是来提升发布效率.首先说明,bigkeeper的开发以及发布流程是完全遵循[git-flow 流程](https://jeffkreeftmeijer.com/git-flow/).
+我们建议直接把`Pods`和`Podfile.lock`移出版本控制系统，因为模块化的操作会频繁进行 `Pods`的增删以及更新，但是这会带来版本锁定的困扰,我们建议把版本锁定的工作从 `Podfile.lock`移到`Podfile`中,为此我们做了一个功能 [big pod](---.).
+`bigkeeper`提供了`release module`模块发版和`release home`主工程发版,每种发版方式分为` start`和` finish`, 这两种方式的最大区别是` start`没有`git push`,不会因为可能存在的问题而污染`origin`仓库,这也留一个口子给研发人员进行二次确认.
+#### 模块发版
+在过渡到模块化和已经模块化的项目中, 会存在很多依赖库, 一般会分为:
+* 业务模块库 
+* 业务基础库
+* 二方库(公司内部库)
+* 三方库
+一般来说,二方库和三方库的版本稳定,而每次业务迭代频繁改动往往就是业务模块库与业务基础库,这这两种类型的库在发布的时候往往因为会因为依赖库的原因而导致发版失败,浪费开发人员的时间.
+所以,模块发布提供了两种解决方案:
+```
+big release module finish ExampleModule
+Options:
+    -s, --spec : 模块需要发布版本
+```
+`--spec`指令决定模块需要发版,如果不需要,那仅会在`master`分支打上`tag`.
+而在`start`指令中我们也做了一些安全性检查:
+* 根据开发流程的分支命名规范(branch: feature/x.x.x),检查当前是否有分支还没有合并到`develop`分支;
+* 检查`master`分支相较于`develop`分支是否有超前的` commit`,防止有不规范的操作导致污染` master`分支代码.
+```
+big release module start ExampleModule
+Options:
+    -i, --ignore : 忽略安全性检查(默认开启)
+```
+#### 主工程发版
+在模块化完成之后,主工程基本上是个壳工程,只会有`Podfile`和配置文件的改动, 根据`git-flow`的规则`bigkeeper`在发布主工程时会从`develop`切出` release/x.x.x`分支,`release`分支是一个暂时性分支,在代码已经并入`master`之后会删除`release`分支.
+`release home start`中有两种模块的引用方式:
+```
+pod 'ExampleModule', '0.1.0'
+or
+pod 'ExampleModule', :git => 'ExampleModule.git', :tag => '0.1.0'
+```
+如果模块没有发布,` bigkeeper`会根据在根据仓库里的最新`tag`和`.cocoapods/repos` 里的已发布版本去找到合适的依赖方式.
+在` release home finish`中有一个需要注意的地方就是` release`分支合并到` develop`之前`reset`掉对` Podfile`的操作,这样保持了不会有在` Podfile`文件不会有冲突.
+### 举个例子
+模块发版:
+```
+big -v 0.1.0 release module start ExampleModule
+big -v 0.1.0 release module finish ExampleModule
+Options:
+    -v : 发布是指定版本号,如未指定,则用bigkeeper文件中的vesion
+```
+主工程发版:
+```
+big -v 0.1.0 release home start
+big -v 0.1.0 release home finish
+Options:
+    -v : 发布是指定版本号,如未指定,则用bigkeeper文件中的vesion
+```
+### 展望
+对于很多中大型公司来说都是自己的CI系统,可以把发版本这种耗时而且占内存的工作放在CI机器上,所以我们也有计划把`release module`最后一步的发版本的步骤留个口子,研发同学可以在这里去触发各自CI系统的发版流程.
+### 结束语
+`bigkeeper`在饿了么物流已经实践了半年多了,从数个模块到现在40+的模块数量,仅`release`流程节省项目管理者非常多的时间,提升了效率而且规范化了开发流程,也希望大家在使用中有` issue`反馈给到我们.
+

data/docs/zh-CN/SPEC.md

@@ -0,0 +1,39 @@
+# spec - spec 管理
+
+## 背景
+
+模块化推进过程中势必存在业务模块间的横向依赖，原则上这种依赖我们都需要通过 router 进行解耦，不能直接源码依赖其他业务模块，因为这样的依赖会导致如下的问题：
+
+- 因为直接横向依赖业务模块，导致业务模块无法独立编译运行。
+- 各个业务模块如果存在大量类似依赖，必将导致后期模块代码依赖错综复杂，难以维护。
+
+## 功能简介
+
+直接在命令行执行 `big spec --help` 可以查看其提供的所有功能：
+
+```
+NAME
+    spec - Spec operations
+
+SYNOPSIS
+    big [global options] spec [command options] add
+    big [global options] spec [command options] analyze
+    big [global options] spec [command options] delete
+    big [global options] spec [command options] list
+    big [global options] spec [command options] search
+
+COMMAND OPTIONS
+    -a, --[no-]all -
+
+COMMANDS
+    add     - Add a spec (Coming soon).
+    analyze - Analyze spec dependency infomation.
+    delete  - Delete a spec (Coming soon).
+    list    - List all the specs.
+    search  - Search a spec with name (Coming soon).
+```
+
+功能列表如下：
+
+- analyze：分析所有指定模块之间的依赖，通常为业务模块。
+- list：显示当前所有的业务 spec。

data/lib/big_keeper/command/client.rb

@@ -0,0 +1,50 @@
+require 'big_keeper/util/leancloud_logger'
+require 'big_keeper/command/pod/podfile'
+require 'big_keeper/command/spec/list'
+require 'big_keeper/util/list_generator'
+
+module BigKeeper
+
+  def self.client_command
+    desc 'API for bigkeeper-client.'
+    command :client do | c |
+      c.desc 'Commands about operate modules.'
+      c.command :modules do |modules|
+        modules.desc 'Get modules list from Bigkeeper file.'
+        modules.command :list do |list|
+            list.action do |global_options, options, args|
+            LeanCloudLogger.instance.set_command("spec/list")
+            path = File.expand_path(global_options[:path])
+            version = global_options[:ver]
+            user = global_options[:user].gsub(/[^0-9A-Za-z]/, '').downcase
+            spec_list(path, user, options)
+          end
+        end
+        modules.desc 'Update modules.'
+        modules.command :update do |update|
+          update.action do |global_options, options, args|
+            LeanCloudLogger.instance.set_command("spec/list")
+            path = File.expand_path(global_options[:path])
+            version = global_options[:ver]
+            user = global_options[:user].gsub(/[^0-9A-Za-z]/, '').downcase
+            spec_list(path, user, options)
+          end
+        end
+      end
+      c.desc 'Commands about features.'
+      c.command :feature do |feature|
+        feature.desc "List all the features including origin."
+        feature.command :list do | list |
+            list.flag %i[v version] , default_value: 'all versions'
+            list.action do |global_options, options, args|
+              LeanCloudLogger.instance.set_command("feature/list/json")
+              options[:json] = true
+              path = File.expand_path(global_options[:path])
+              user = global_options[:user].gsub(/[^0-9A-Za-z]/, '').downcase
+              list(path, user, GitflowType::FEATURE, options)
+          end
+        end
+      end
+    end
+  end
+end

data/lib/big_keeper/command/feature&hotfix/delete.rb

@@ -0,0 +1,40 @@
+#!/usr/bin/ruby
+
+require 'big_keeper/util/podfile_operator'
+require 'big_keeper/util/gitflow_operator'
+require 'big_keeper/util/bigkeeper_parser'
+require 'big_keeper/util/logger'
+require 'big_keeper/util/pod_operator'
+
+require 'big_keeper/dependency/dep_service'
+
+require 'big_keeper/dependency/dep_type'
+
+require 'big_keeper/service/stash_service'
+require 'big_keeper/service/module_service'
+
+
+module BigKeeper
+  def self.delete(path, user, name, type)
+    begin
+      # Parse Bigkeeper file
+      BigkeeperParser.parse("#{path}/Bigkeeper")
+      branch_name = "#{GitflowType.name(type)}/#{name}"
+      version = 'all version'
+
+      modules = BigkeeperParser.module_names
+      modules.each do |module_name|
+        module_full_path = BigkeeperParser.module_full_path(path, user, module_name)
+
+        if FileOperator.definitely_exists?(module_full_path)
+          StashService.new.pop_stash(module_full_path, branch_name, module_name)
+          GitService.new.verify_del(module_full_path, branch_name, module_name, type)
+        end
+      end
+
+      StashService.new.pop_stash(path, branch_name, 'Home')
+      GitService.new.verify_del(path, branch_name, 'Home', type)
+    ensure
+    end
+  end
+end

data/lib/big_keeper/command/feature&hotfix/finish.rb

@@ -0,0 +1,54 @@
+#!/usr/bin/ruby
+
+require 'big_keeper/util/podfile_operator'
+require 'big_keeper/util/logger'
+require 'big_keeper/util/pod_operator'
+require 'big_keeper/util/xcode_operator'
+require 'big_keeper/util/cache_operator'
+require 'big_keeper/util/bigkeeper_parser'
+require 'big_keeper/model/operate_type'
+require 'big_keeper/dependency/dep_service'
+
+require 'big_keeper/dependency/dep_type'
+
+
+module BigKeeper
+
+  def self.finish(path, user, type)
+    begin
+      # Parse Bigkeeper file
+      BigkeeperParser.parse("#{path}/Bigkeeper")
+
+      branch_name = GitOperator.new.current_branch(path)
+      Logger.error("Not a #{GitflowType.name(type)} branch, exit.") unless branch_name.include? GitflowType.name(type)
+
+      # Cache git modules
+      if ModuleCacheOperator.new(path).all_path_modules.empty?
+        Logger.error("Branch '#{branch_name}' is already finished, exit.")
+      end
+
+      ModuleCacheOperator.new(path).cache_git_modules(ModuleCacheOperator.new(path).all_path_modules)
+
+      modules = ModuleCacheOperator.new(path).remain_git_modules
+      # Rebase modules and modify module as git
+      modules.each do |module_name|
+        ModuleService.new.finish(path, user, module_name, branch_name, type)
+      end
+
+      Logger.highlight("Finish branch '#{branch_name}' for 'Home'")
+
+      # Delete all path modules
+      ModuleCacheOperator.new(path).cache_path_modules([], [], [])
+
+      # Install
+      DepService.dep_operator(path, user).install(modules, OperateType::FINISH, false)
+
+      # Open home workspace
+      DepService.dep_operator(path, user).open
+
+      # Push home changes to remote
+      GitService.new.verify_push(path, "finish branch #{branch_name}", branch_name, 'Home')
+    ensure
+    end
+  end
+end

data/lib/big_keeper/command/feature&hotfix/list.rb

@@ -0,0 +1,63 @@
+#!/usr/bin/ruby
+require 'big_keeper/util/bigkeeper_parser'
+require 'big_keeper/util/list_generator'
+require 'big_keeper/service/module_service'
+
+
+module BigKeeper
+  def self.list(path, user, type, options)
+    BigkeeperParser.parse("#{path}/Bigkeeper")
+    home_path = File.expand_path(path)
+    #get home project branches
+    branches = GitService.new.branchs_with_type(home_path, type)
+    #get modules list
+    is_print_log = false if options[:json]
+    #get search version
+    version = options[:version]
+    cache_path = File.expand_path("#{path}/.bigkeeper")
+    json_path = "#{cache_path}/branches.json"
+    begin
+      #get cache file path
+      FileUtils.mkdir_p(cache_path) unless File.exist?(cache_path)
+      file = File.new(json_path, 'w', :encoding => 'UTF-8')
+      begin
+        #get all modules info
+        module_list_dic = get_module_info(path, user, type, version, branches, is_print_log)
+        file << module_list_dic.to_json
+        file.close
+      end
+      #print list
+      generate_list_with_option(options, json_path, version, branches)
+    ensure
+      file.close
+    end
+  end
+
+  def self.get_module_info(path, user, type, version, home_branches, is_print_log)
+    #get module list
+    modules = BigkeeperParser.module_names
+    git_operator = GitOperator.new
+    module_info_list = []
+    modules.each do |module_name|
+      module_full_path = BigkeeperParser.module_full_path(path, user, module_name)
+      #local project verify
+      if !File.exist? module_full_path
+        Logger.default("No local repository for module '#{module_name}', clone it...") if is_print_log
+        module_git = BigkeeperParser.module_git(module_name)
+        git_operator.clone(File.expand_path("#{module_full_path}/../"), module_git)
+      end
+      #每个模块详细信息
+      module_branch_info = ModuleService.new.module_info(module_full_path, home_branches, user, type, module_name, version)
+      module_info_list << module_branch_info
+    end
+    module_info_list
+  end
+
+  def self.generate_list_with_option(options, file_path, version, home_branches)
+    if options[:json]
+        ListGenerator.generate_json(file_path, home_branches, version)
+    else
+        ListGenerator.generate_tree(file_path, home_branches, version)
+    end
+  end
+end