求关于 git 的使用规章（style）

git-flow

或者github-flow

@chmlai 看了一下 主要说流程比较多，但是说怎么写commit很少。
比如我们某个组员之前的repo 里面commit都是123，qwer之类的。

关于branch，在啥时候需要建branch，模块话开发，是一个模块建立一个branch吗

让会的人来, 你给予授权做这件事

@wuyexiong 目前来说没有。。都是一帮在校生。

我的习惯是：
* 每次commit应该保证代码是可正确运行的；
* 一次commit原则上应该只关系到一个改动（或者说一个功能）；
* 一个较大的功能或者改动，应该尽可能分成多次commit，每次都是一个完整的小改动。这样方便review甚至rollback到某个状态；
* 注释必须有意义，123，qwer这样的要是我的组员，说一次不听直接走人吧；
* 关于分支的用法估计有不同的模式。我个人习惯保持master的健壮和可部署，所以基本所有开发都在branch里，完成之后merge到master。模块化开发其实和branch应该没什么必然联系，如果是耦合较低的模块甚至可以考虑分不同的repository了。

比较简单的做法是
中央放个repository，大家clone到本地。
master永远不开发。只用来做merge管理。
开发时从master开branch，开发完一个完整功能后马上merge回master，并push master到中央repo。确保master始终是可以跑的程序。
本地master定期从中央repo pull别人开发的内容。
branch按自己需求开，比如搞坏了一个branch你就把它删除了从master重新开一个就好了。

以上方法小团队基本够用，要专业一点的话架个gitlab用Github flow或者git-flow，用pull request做code review

commit要大概写下做了什么，开发完一个小部分就可以commit一次，不怕频繁，但一定要写干了什么

我也经常提醒自己，push前不要忘了git pull --rebase

你可以去github看看一些著名的项目的commit，一般不同公司有不同的commit规范。

@HackerOO7 就算你忘了...git也会提醒你的 哈哈哈

@zhangxiao
1. 如果是最开始写程序，是不可能运行的。写好一些大致的function定义，然后函数留白做commit？

类似
def configRead：
pasd

2。模块，是mvc里面的model，目前打算是一个人负责写一个model。

3，对团队开发的流程和分工不是很懂，不知道哪里能学习到相关知识呢？ 很多时候都是自己一个人在写东西。而且老师讲的waterfall model基本是软件的开发流程，也不涉及到团队开发的知识。

@tywtyw2002 呃，我觉得就算是一开始写也应该是可以运行的吧... 只是功能不全罢了，都是一点一点丰富起来的。

https://github.com/douban/code 不用谢～