常年使用 git 的你们一般如何规范 commit 和 push 的频率？

[LioMore]

以前不懂这些的我经常就是git commit -m 'modified xxx'
然后立刻马上git push

后来发现这样项目动态的页面会有很多推送到分支的记录，一个 commit 一条记录，不是很美观

请问 如何规范 commit 和 push 的频率才能让团队查看项目动态的时候更加舒心且可读性高呢

[ibcker]

稳定了就 push

[nino]

你自己的 repo 开发的时候随意 push 没关系， pull request 之前用 rebase -i 整理好 commit

[LioMore]

我希望能有一个对何时 push 有个清晰的定义，以规范团队中的 push 行为

[FrankFang128]

这个看人 怎么规范都没用

[ShadowStar]

push 和 commit 没有必然关系
commit 通常应该按照功能 /模块 /修正来
push 应该及时

[gzxultra]

How to Write a Git Commit Message
http://chris.beams.io/posts/git-commit/

[weifengzi2009]

我是干一件小事 commit 一次，然后一个任务完成了 push 一下

[Wangxf]

我用 git2 个月了，反正功能实现了，我测试没问题了就 push ，有时候强迫症犯了空格没对齐也 push 了

[lavadore]

反正都是自己开一个分支出来，随便怎么弄，最后合并前整理下就行了

[timothyye]

开发分支随便 push
发布版本用另外一个分支，发布的时候再合并……

[sinxccc]

尽可能快的 commit ，本地不要留太久未跟踪的代码，最多最多不要超过一天。

能编译通过，能通过 smoke test 的时候就可以 push ，如果觉得功能修改比较大会影响 feature 的时候就开新 branch ，然后约定满足什么条件的时候可以 merge 。

[Kilerd]

完成一个功能就 commit 一次。

完成一次任务 就 push 一次。

[ddou]

1. 完成了一个独立功能或改了一个 bug ， push 一次。功能较大的话，完成一个模块也可以。
2. 每次 push 确保本地测试完全通过
3. 如果本地提交记录较多，比较乱，建议 push 之前，本地先 git rebase -i, 可以合并多个提交，修改提交顺序，以及更改 commit message 。
4. 涉及多分支开发合并的，尽量 rebase 后，在 merge ，确保 commit history 清晰
5. 多 push ，避免本地代码丢失，前功尽弃

[df4VW]

推到自己的 branch 上多频繁都无所谓啊，要合并的时候再 squash pick 下美化下 commit 记录就好了

[sudoz]

master 分支只给小组长或项目负责人， dev 分支随便提交，等测试合格了合并到 master

[wubotao]

用 git commit --amend
实在不行 squash 一下就可以了。

[otakustay]

尽可能多地 add
以可运行为节点 commit
以功能完备为节点 push
以可提测 /上线为节点 merge

[h0wardc]

git-flow cheatsheet
http://danielkummer.github.io/git-flow-cheatsheet/

[fhefh]

mark~~

[LioMore]

这个问题可以关闭了，当时我还年轻，现在这个答案我自己心里数了