Github 长期分支设置保护, 只能通过 Fork + PR 提交进行 Review, 要求必须写单元测试. Review 完交给持续集成跑单元测试和代码检测并检查测试覆盖率. 之后机器人( https://github.com/barosl/homu)会根据持续集成返回的结果来合并 PR.

@kinghui <script src="https://gist.github.com/coldnight/b5114a570f148c7aa124e4da3fb362a8.js"></script>

加个 wrapper 包装一下:
```
@gen.croutine
def _proxy(method, *args, **kwargs):
try:
ret = yield method(*args, **kwargs)
except ErrorYourWantCatch:
# logging or something else
ret = None
raise gen.Return(ret)


@gen.coroutine
def get(self):
http_client = AsyncHTTPClient()
response1, response2 = yield [_proxy( http_client.fetch, url1),
_proxy( http_client.fetch, url2)]
```

@that24 我感觉这已经超出了 git flow 范畴. 其实可以用 --no-ff 合并主题分支, 然后结合 cherry-pick :D

@that24 develop 合并到 release 也得等 develop 稳定之后再合并到 release, 这个稳定的过程难道不就是测试的过程吗?
另外我觉 topic 分支合并到 develop 应该是自测的部分, 单元测试等.

合并到 develop 分之后再提交给测试

生产环境的配置和测试环境的配置应该隔离开来.

然而对小公司并不是好消息, 20 个人的组织 50 个项目目前是 100$ 但是新的付费计划需要 25 + (15 * 9)

换 Awesome 之类的平铺式窗体管理

吓得我赶紧把可读写的数据库连接关了.

乐视,掌阅 应该也用 Python, 至少我有认识的人在这两家公司任职. 另外个人觉得东西学精了都赚钱.

为什么你们都直接拷 virtualenv, 难道我打开方式不对: pip install -U -r requirements.txt

不乐意使用 powerline font 可以使用 airline 代替

支持, 不过 Python 已经有成熟的静态网站生成器 https://github.com/getpelican/pelican

@syv2 两个代表不同的意思, raise error 是重新抛出该异常, raise 是传递该异常. Traceback 的表现会有不同, 单独使用 raise 能更精准的从 Traceback 中定位抛出异常的位置.

@kinghui 比如一些 Vim 插件就这么做:

https://github.com/klen/python-mode/tree/master/pymode

https://github.com/Valloric/YouCompleteMe/tree/master/third_party

还不如直接将所有依赖的第三方库直接下载下来放在项目目录下, 感觉比这种黑科技靠谱多了.