我现在的做法是，
本地创建 networking，编辑，commit
git checkout master
git pull origin master
git merge networking
git push origin master
git checkout networking
git merge master

也就是说，networking 压根儿不丢到服务器上，全在本地开发
经测试，jack和rose各自维护自己的branch，服务器只有一个master，完全没问题

@66450146 这意思是不是说

git checkout develop
git merge networking

??

@kemingcao 作为程序员，必须要会懒，我可没那么勤劳把几十个api都写个脚本，然后每次测试参数不同都要去更改脚本
烦不烦

@kemingcao 答非所问。我问的是网站，不是curl。几十个请求，每个都写curl，不嫌烦吗？生产率不能提高吗？

@sexoutsex2011 postman is wonderful

@akfish 太快了哈哈哈

@defia @clino 好，我现在知道 golang 的非阻塞了。但是，数据库锁怎么解决呢？
要么建立一个线程专门做数据库操作，所有协程最终都以 FIFO 方式排队？这样会不会太慢？
可是如果多个写操作同时操作数据库，那交给数据库自行解决？还是业务负责锁机制？

@clino 是的，我在3楼和5楼也说到了这个。

那么，业务进程怎样做到并发呢？不管是golang的goroutine，还是ios的gcd，都是在一个进程内的并发方案。那么，对于这种成千上万的web请求，有没有办法在1个或少量进程的情况下实现并发处理多个请求呢？

@jasontse 感觉回复。但是我2/3楼提到的问题呢？golang哪怕有协程这种并发机制，但是业务进程始终只能一次处理一个请求吧？这个如何做到高并发呢？
以及，哪怕做到了业务进程高并发，但是数据库写操作锁又怎么解决呢

如果 nginx 能用各种方式实现真正的超高并发，但是业务进程怎么做到这点呢？
假如服务器每秒收到1万个请求，难道要创建1万个业务进程去处理请求？

@clino 哦，原来是这样啊。那是否有可能出现这种情况：
worker1 接收到请求，转发给业务进程，然后 worker1 就玩儿蛋去了
业务进程处理好这个请求后，将结果返回给nginx, 但是却是 worker2 这个接盘侠接收，并将结果返回给客户端？

人家说了 •Share 2% Ad traffic.

对这句话想吐个槽：谢谢锤子科技的友情赠送
锤子科技有空赠送手机，不如先满足已经订货的用户的期待。

@zzutmebwd 科技史上唯一一个三次押宝成功的公司就是IBM，唯一一个

@hjiang 必须的。在 _Notifications 里创建了实例，必然是avos的服务器成功接收我的请求了呀

做的像 http://v2ex.com/t/126578#reply14 一样吊炸天