问问 V 友们 Git 提交的规范

[Renco]

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

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

[wleexi]

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

[Aresxue]

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

[X3nr8yv6bfvk89um]

@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 （可选）。