这是一个创建于 3723 天前的主题，其中的信息可能已经有所发展或是发生改变。
以前不懂这些的我经常就是git commit -m 'modified xxx'
然后立刻马上git push
后来发现这样项目动态的页面会有很多推送到分支的记录，一个 commit 一条记录，不是很美观
请问 如何规范 commit 和 push 的频率才能让团队查看项目动态的时候更加舒心且可读性高呢
 | 1 ibcker 2015-09-21 21:14:44 +08:00 稳定了就 push |
 | 2 nino 2015-09-21 21:18:38 +08:00 你自己的 repo 开发的时候随意 push 没关系， pull request 之前用 rebase -i 整理好 commit |
 | 3 LioMore OP 我希望能有一个对何时 push 有个清晰的定义，以规范团队中的 push 行为 |
 | 4 FrankFang128 2015-09-21 21:25:38 +08:00 via Android 这个看人 怎么规范都没用 |
 | 5 ShadowStar 2015-09-21 21:30:26 +08:00 via iPad push 和 commit 没有必然关系 commit 通常应该按照功能 /模块 /修正来 push 应该及时 |
 | 6 gzxultra 2015-09-21 21:31:22 +08:00  1 How to Write a Git Commit Message http://chris.beams.io/posts/git-commit/ |
 | 7 weifengzi2009 2015-09-21 21:40:39 +08:00 我是干一件小事 commit 一次，然后一个任务完成了 push 一下 |
 | 8 Wangxf 2015-09-21 21:42:08 +08:00 我用 git2 个月了，反正功能实现了，我测试没问题了就 push ，有时候强迫症犯了空格没对齐也 push 了 |
 | 9 lavadore 2015-09-21 21:53:11 +08:00 反正都是自己开一个分支出来，随便怎么弄，最后合并前整理下就行了 |
 | 10 timothyye 2015-09-21 21:54:50 +08:00 开发分支随便 push 发布版本用另外一个分支，发布的时候再合并…… |
 | 11 sinxccc 2015-09-21 22:03:32 +08:00 尽可能快的 commit ，本地不要留太久未跟踪的代码，最多最多不要超过一天。 能编译通过，能通过 smoke test 的时候就可以 push ，如果觉得功能修改比较大会影响 feature 的时候就开新 branch ，然后约定满足什么条件的时候可以 merge 。 |
 | 12 Kilerd 2015-09-21 22:04:28 +08:00 完成一个功能就 commit 一次。 完成一次任务 就 push 一次。 |
Select Language