问问 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 很好，但是不是楼主问的问题。。。。。

[wleexi]

先人任务分解。每做完一个做一个 commit。然后合并 commit 后 push

[Aresxue]

从 master 拉测试分支,再从测试拉开发分支,再从开发分支拉取功能点分支，尽量一个功能点一个分支,多个有关联的功能点可以考虑放在一个分支,然后开发时尽可能拆分细致点提交,最后统一合到开发分支上。

[cocoafinish]

@Rwing 我是想题主的主要问题是 纠结如果颗粒化的 Commit 会导致分支被拉长，但是一口气把修改新增的东西全部一起提交，Commit message 里面内容又太过累赘。我觉得使用 Git Flow 可以把在 Dev 分支上颗粒化的提交，到了一定的阶段合并回主分支打 tag，保证主分支的清爽就可以了。
当然也可能是我过分解读了题主的意思。。。

[Takamine]

@Xbluer 嗯，每个人自己的分支开发自己的模块，merge 到公共开发分支，然后再 merge 到版本发布分支。非临时分支（节日活动等）之后会再 merge 到主分支。

[avenger]

merge 的时候怎么合并多次 commit ？

[Youen]

随缘.. 写一点测试通过就 commit 一个

规范点的话应该一个 TASK/BUG 一个 commit 吧?

[SilentDepth]

分支：一个功能点、需求、错误、变更、……
提交：实现一个目标（功能点、需求、……）所需要做的一件事情，可以用一句话较完整地概括的那种。如果一件事情没做完但需要临时切换到其他上下文，提交为 wip，等之后继续工作时 fixup 或者 amend。

[Renco]

今天学习了 rebase 的相关知识 和 squash 功能的用法，大致了解了 git 谢谢大家

[hantsy]

使用 Github Flow 或者 Git Flow。个人比较偏向 Github Flow。

首先一个任务如果复杂的话可以定义成一个 Checklist，Github Issues 支持 Checkbox 形式。

1. 每个任务一个分支（可以先 Fork，再创建 Branch ），此时可以建 PR （每次提交 PUSH 后运行 CI 测试）。

2. 每完成一个 item, 可以 Commit 一次。**保证每次提交的代码是可以通过 CI 测试，是一个 Workable 的单元**，不然根本不可能实现自动部署。如果发现什么遗漏，回归测试错误，立即修正，可以使用 Amend 合并到上一次提交。

3. 所在的 Checklist 完成，关闭 Issue, 直接写在 Commit Message，如：fixes #123。创建 PR （也可以提前建）。

4. 启动 Peer Code Review （如果 PR 提前建，可提前）。 根据意见修改代码等，直到所有的考虑已经实现，所有的测试都通过。

5. 合并到 Master，触发自动部署 Pipeline （可选）。