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

[tywtyw2002]

最近需要带领一小搓程序猴去写一套关于某组织的信息管理系统和app。涉及到多人开发以及代码管理的问题。

我平时干运帷比较多，做开发的时间比较少，只做过独立开发，而且git用的很烂。

目前对于git只是会用命令（很早之前读过git pro），但是不知道该在什么时候和如何去用。

比如说该多少个文件需要commit一次，commit的内容应该如何去写。
在什么情况下去见branch等等。

过几天需要跟组员去讲解git的使用流程，所以过来求助一些关于git的使用规范。

之前搜过v2ex，发现大家问的问题大多是关于如何去使用某个git命令的。

[chmlai]

git-flow

[chmlai]

或者github-flow

[tywtyw2002]

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

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

[wuyexiong]

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

[tywtyw2002]

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

[zhangxiao]

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

[czheo]

比较简单的做法是
中央放个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

[czheo]

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

[HackerOO7]

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

[ChiangDi]

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

[wuyexiong]

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

[tywtyw2002]

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

类似
def configRead：
pasd

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

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

[zhangxiao]

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

[eclipselu]

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