问问 V 友们 Git 提交的规范

[Renco]

一般你们是根据修改的功能点或者新增的功能点，执行一次提交命令，多次提交.

还是一口气把修改新增的东西全部一起提交，然后 Commit message 写一起 message 里面内容太过累赘有影响吗

[luozic]

按 feature 链接备注也是可以的

[tt67wq]

http://whatthecommit.com/

[ysc3839]

多次提交

[xiaket]

不管怎么样, 都是 git commit -v. 看着 diff 提交, 觉得不合适就放弃

[gamexg]

多次提交

即使有时候是一次完成很多修改后提交，也是拆分开，分别提交每个功能点。

[ieiayaobb]

规范的是需要 squash 一下，变成一个 commit 再 push

[TimePPT]

拆分功能点多次提交啊，否则回滚时候能逼死人。

[Renco]

@ieiayaobb squash 一下，变成一个 commit 那 squash 之前的 commit 信息还能看到吗

[blindie]

一是可以的，但是一般来说开发过程是混乱的，相关改动中间会隔几个提交。
二如果 commit 过大，review 是没人会主动看。
message 太多，是肯定不行的。如果有相互依赖，为何不直接写在代码中。如果没有依赖，那应该开多个分支分别开发。
合适的做法是善用 cherry-pick, rebase, commit --amend 整出一个符合逻辑的一到多次 commit。如果 message 能合并成一个，那直觉是考虑该不该合成一个 commit。
重点就是每个 commit 的改动需要内聚。（不管以后是查看历史还是 revert 等等才能发挥出版本管理的优势）

[xujif]

功能分支多个 commit，或者有些规范会要求一个 commit 不停的 amend。
但是 master 总是 squash 成一个 commit。

[Renco]

@xujif 了解了，也是，每次合并分支的时候 会有一大堆 commit 的信息，master 分支突然就被拉的很长

[wispx]

@tt67wq #2 "Copy-paste to fix previous copy-paste", 这个秀

[Takamine]

自己分支多次提交，最后提交上去的时候是一个 。

[Xbluer]

@Takamine #13 建一个私有分支修改代码，然后 merge 回公共分支？

[luozic]

gitflow 的 commit github 的每次 tag 还有合并策略可以看看

[cocoafinish]

咦，这么没人提 Git Flow

“主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做 Develop。

这个分支可以用来生成代码的最新隔夜版本（ nightly ）。如果想正式对外发布，就在 Master 分支上，对 Develop 分支进行"合并"（ merge ）。”

摘抄自 阮一峰老师的博客: http://www.ruanyifeng.com/blog/2012/07/git.html



我的理解是 Develop 分支可以按功能点多次提交，然后到一定阶段 Merge 回 Master 分支。
这样 Develop 有详细的 Commit 记录，同时也保证了主分支的清爽。
不知道有没有理解错～

有用的链接
https://nvie.com/posts/a-successful-git-branching-model/

翻译：
https://blog.devorz.com/2019/04/18/A-successful-Git-branching-model/

[cocoafinish]

@cocoafinish 这么->怎么

[rbe]

自己的分支多次提交，是为了防止有 cherry-pick 和 revert 等的需求
最后 git rebase master -i 来做 squash 提交，精简信息对 master 分支查看历史比较有利

[jinliming2]

squash 是不经常用的一个功能，一般只在 master 上用。
通常是在 开发分支上进行团队开发，团队中的每个人又在开发分支上迁出多个功能或修复分支进行开发。功能分支和修复分支完成后合并到开发分支。等到开发分支上面的各个功能都稳定之后，合并至主分支发布版本。其中主分支通常为 master，开发分支为 dev，功能分支和修复分支各自起名字。
一般来说，dev 分支处于开发阶段，代码改动量较大，功能变化较大，所以应该尽可能的保证 commit message 尽可能详细，越细越好，这样也更容易发现问题。而代码一旦合并到 master 分支，就表示功能基本稳定了，要发布版本了，版本都发布出去了，精细的历史信息用处就不太大了，所以在 dev 到 master 的时候可以只在 master 上保留关键的信息，其他信息就不用合到 master 了，保持主分支的干爽。
所以 squash 很少用，日常开发基本直接 commit，amend 是在确实应该合并的时候用的。

[Rwing]

@cocoafinish gitflow 很好，但是不是楼主问的问题。。。。。