以前不懂这些的我经常就是git commit -m 'modified xxx'
然后立刻马上git push
后来发现这样项目动态的页面会有很多推送到分支的记录，一个 commit 一条记录，不是很美观
请问 如何规范 commit 和 push 的频率才能让团队查看项目动态的时候更加舒心且可读性高呢
This topic created in 3914 days ago, the information mentioned may be changed or developed.
 |
1
ibcker Sep 21, 2015
稳定了就 push
|
 |
2
nino Sep 21, 2015
你自己的 repo 开发的时候随意 push 没关系， pull request 之前用 rebase -i 整理好 commit
|
 |
3
LioMore OP 我希望能有一个对何时 push 有个清晰的定义，以规范团队中的 push 行为
|
 |
4
FrankFang128 Sep 21, 2015 via Android
这个看人 怎么规范都没用
|
 |
5
ShadowStar Sep 21, 2015 via iPad
push 和 commit 没有必然关系
commit 通常应该按照功能 /模块 /修正来 push 应该及时 |
 |
6
gzxultra Sep 21, 2015  1
How to Write a Git Commit Message
http://chris.beams.io/posts/git-commit/ |
 |
7
weifengzi2009 Sep 21, 2015
我是干一件小事 commit 一次，然后一个任务完成了 push 一下
|
 |
8
Wangxf Sep 21, 2015
我用 git2 个月了，反正功能实现了，我测试没问题了就 push ，有时候强迫症犯了空格没对齐也 push 了
|
 |
9
lavadore Sep 21, 2015
反正都是自己开一个分支出来，随便怎么弄，最后合并前整理下就行了
|
 |
10
timothyye Sep 21, 2015
开发分支随便 push
发布版本用另外一个分支，发布的时候再合并…… |
 |
11
sinxccc Sep 21, 2015
尽可能快的 commit ，本地不要留太久未跟踪的代码，最多最多不要超过一天。
能编译通过，能通过 smoke test 的时候就可以 push ，如果觉得功能修改比较大会影响 feature 的时候就开新 branch ，然后约定满足什么条件的时候可以 merge 。 |
 |
12
Kilerd Sep 21, 2015
完成一个功能就 commit 一次。
完成一次任务 就 push 一次。 |
 |
13
ddou Sep 21, 2015
1. 完成了一个独立功能或改了一个 bug ， push 一次。功能较大的话，完成一个模块也可以。
2. 每次 push 确保本地测试完全通过 3. 如果本地提交记录较多，比较乱，建议 push 之前，本地先 git rebase -i, 可以合并多个提交，修改提交顺序，以及更改 commit message 。 4. 涉及多分支开发合并的，尽量 rebase 后，在 merge ，确保 commit history 清晰 5. 多 push ，避免本地代码丢失，前功尽弃 |
 |
14
df4VW Sep 21, 2015
推到自己的 branch 上多频繁都无所谓啊，要合并的时候再 squash pick 下美化下 commit 记录就好了
|
 |
15
sudoz Sep 22, 2015
master 分支只给小组长或项目负责人， dev 分支随便提交，等测试合格了合并到 master
|
 |
16
wubotao Sep 22, 2015
用 git commit --amend
实在不行 squash 一下就可以了。 |
 |
17
otakustay Sep 22, 2015
尽可能多地 add
以可运行为节点 commit 以功能完备为节点 push 以可提测 /上线为节点 merge |
 |
18
h0wardc Sep 22, 2015
git-flow cheatsheet
http://danielkummer.github.io/git-flow-cheatsheet/ |
 |
19
fhefh Nov 5, 2015
mark~~
|
|
20
LioMore OP 这个问题可以关闭了，当时我还年轻，现在这个答案我自己心里数了
|
 |
21
rainbowStay Aug 25, 2023
@LioMore 可否总结下经验？
|
Select Language