这是一个创建于 5423 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在赶一个项目，工作量大，难度不大不小，就是很细很碎=。=
一直在用Git做版本管理，上班的时候是每天要回家的时候会提交一次。检查今天的改动，然后按模块提交。放假在家就惨了，每天不用合上笔记本，都是写到很困了才会去睡...睡醒了继续写...按照我的提交习惯就没有很好的做版本控制了=。=
所以请教下大家，你们都使用多大的颗粒度来管理提交的？提交的时间一般是在？
谢谢~~
一直在用Git做版本管理，上班的时候是每天要回家的时候会提交一次。检查今天的改动，然后按模块提交。放假在家就惨了，每天不用合上笔记本，都是写到很困了才会去睡...睡醒了继续写...按照我的提交习惯就没有很好的做版本控制了=。=
所以请教下大家，你们都使用多大的颗粒度来管理提交的？提交的时间一般是在？
谢谢~~
 | 1 rociiu 2011-02-08 21:21:06 +08:00 以实现一个ticket为单位 或者 一个完整可用功能 如果功能比较大可以用branch,完了merge回master 'git stash'也挺方便如果一个东西做一半又不想提交可用这个 |
 | 2 myrual 2011-02-08 21:25:53 +08:00 颗粒度这个概念不知道是怎么来的。我虽然能理解，但是觉得很变扭。 我一般是觉得某个部分工作可以确认有效，或者等待确认有效的时候就会commit一次。 一旦确认完成，再次commit。 因此我一般至少2个小时小时可能就会commit一次。 这可能跟我个人工作习惯有关，我一般是把一个大的工作切分成可度量可测试的小块任务，每完成一块，就commit一次，这样对于进度的预测会准确一些，自己的心情也会相对舒服一些。 |
 | 3 iwinux 2011-02-08 21:34:15 +08:00 我用的是 hg。我参照了这篇文章提到的方法 http://nvie.com/posts/a-successful-git-branching-model/ 1. 每涉及一个 feature 就 branch 一次，在这个 branch 中代码提交得很频繁。 2. feature 完成后再 merge 回主开发分支 3. 主开发分支测试完再 merge 回 default 分支。 4. 大概每天 push 一次到 bitbucket.org 4. 代码发布时以 default 分支为准 |
 | 5 xuwenhao 2011-02-08 21:45:36 +08:00 每个redmine上的issue作为一个branch，branch里随时提交，完成后merge回trunk |
 | 7 roamlog 2011-02-08 21:48:27 +08:00 |
 | 10 kayue 2011-02-08 22:58:18 +08:00 1. 按 ticket 2. 最起码不能够 commit 未完成的 code （会令网站运行不了的 code） |
Select Language