1
chmlai 2014-05-23 14:48:17 +08:00
git-flow
|
2
chmlai 2014-05-23 14:48:35 +08:00
或者github-flow
|
3
tywtyw2002 OP @chmlai 看了一下 主要说流程比较多,但是说怎么写commit很少。
比如我们某个组员之前的repo 里面commit都是123,qwer之类的。 关于branch,在啥时候需要建branch,模块话开发,是一个模块建立一个branch吗 |
4
wuyexiong 2014-05-23 15:07:07 +08:00
让会的人来, 你给予授权做这件事
|
5
tywtyw2002 OP @wuyexiong 目前来说没有。。都是一帮在校生。
|
6
zhangxiao 2014-05-23 15:15:21 +08:00 3
我的习惯是:
* 每次commit应该保证代码是可正确运行的; * 一次commit原则上应该只关系到一个改动(或者说一个功能); * 一个较大的功能或者改动,应该尽可能分成多次commit,每次都是一个完整的小改动。这样方便review甚至rollback到某个状态; * 注释必须有意义,123,qwer这样的要是我的组员,说一次不听直接走人吧; * 关于分支的用法估计有不同的模式。我个人习惯保持master的健壮和可部署,所以基本所有开发都在branch里,完成之后merge到master。模块化开发其实和branch应该没什么必然联系,如果是耦合较低的模块甚至可以考虑分不同的repository了。 |
7
czheo 2014-05-23 15:20:05 +08:00 via iPhone 2
比较简单的做法是
中央放个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 |
8
czheo 2014-05-23 15:23:16 +08:00 via iPhone
commit要大概写下做了什么,开发完一个小部分就可以commit一次,不怕频繁,但一定要写干了什么
|
9
HackerOO7 2014-05-23 15:26:21 +08:00
我也经常提醒自己,push前不要忘了git pull --rebase
|
10
ChiangDi 2014-05-23 15:28:22 +08:00 via Android
你可以去github看看一些著名的项目的commit,一般不同公司有不同的commit规范。
|
12
tywtyw2002 OP @zhangxiao
1. 如果是最开始写程序,是不可能运行的。写好一些大致的function定义,然后函数留白做commit? 类似 def configRead: pasd 2。模块,是mvc里面的model,目前打算是一个人负责写一个model。 3,对团队开发的流程和分工不是很懂,不知道哪里能学习到相关知识呢? 很多时候都是自己一个人在写东西。而且老师讲的waterfall model基本是软件的开发流程,也不涉及到团队开发的知识。 |
13
zhangxiao 2014-05-23 17:03:39 +08:00
@tywtyw2002 呃,我觉得就算是一开始写也应该是可以运行的吧... 只是功能不全罢了,都是一点一点丰富起来的。
|
14
eclipselu 2014-05-24 00:02:38 +08:00
|