大家 commit 的颗粒度是怎样的？

[JCZ2MkKb5S8ZX9pq]

• 简单来说就是稍微改点就 commit。
• 还是改到一定程度，阶段性 commit。

---

• 理论上是不是应该是 branch 出来改，阶段性改完再 merge 回 master。
  到时候可以删掉过程分支，这样 master 看上去漂亮点。
  但说实话，实际操作的时候，我习惯还没这么好……

---

• 比如经常改一些注释说明，过一会儿又想起来了稍微改点，就频繁 commit 了。
• 或者有些时候直接在 ide 里改参数测试，退到命令行毕竟有点麻烦，于是参数变了，要不要 commit 进去。
• 类似这样的细节问题挺多的，想问问看大家的习惯是什么样的？

[zclHIT]

@ericgui 谈不上指教，因为在两次迭代之前，可能会基于上次的 release 进行 hotfix，所以需要 release 分支

[littlewing]

新开一个自己的 br，随便 commit，然后 rebase

[zclHIT]

@realpg 如果单 master 分支，打 tag 的方式，在 sprint1 我完成了功能 A，做了 sprint2 的时候做了功能 B 做了一半，还没有到 sprint2 release 阶段但是需要尽快 hotfix 功能 A 的话，怎么办呢 0.0 求指教。。。

[zunceng]

@FrankHB 我觉得你可以试试 这个工具的 workflow https://www.phacility.com/phabricator/
可以先发一个 pre-commit review ，过程中可以修改更新，完成后合并成一个 Diff 提交到 repo 中

[zclHIT]

@ericgui 更正。。。/ ***两次迭代之间*** /

[ericgui]

@zclHIT 不是不推荐做 rebase 吗

[yuankui]

有空就 commit

[LoNeFong]

git rebase -i

[AstroProfundis]

一个任务 /功能 / issue 开一个分支，然后每改一个小点就 commit 一次，尽量让一个 commit 只做一件事情，形成一个可能有多个 commits 的分支
这样的好处是 rebase 的时候处理冲突要容易很多，因为每个 commit 改的内容少写 commit log 也基本一句话完事，并且 review 也方便一些
然后 pr 回 master, 在合并的时候如果不希望 commit 记录太乱可以 squash

[hantsy]

本地 Commit 几次，有什么遗漏, 下次 Commit 的时候 --amend。
已经提交的在合并到 Master 之前，rebase -i upstream/master

[GopherTT]

想想 review 的时候如何不难受 你就怎么 commit

[rizon]

回想了一下自己 commit 的几个场景
1、临时做一些测试性的代码，不是测试用例，是那种要大范围临时改代码，这时候我就会把代码 commit 之后随便改着测试完事后一个 revert 撤销掉。当然也可以用 stash 代替。
2、需要拉其他人的代码就得先 commit 再 pull，不想用 stash 或自动本地 merge 是为了预防把我代码覆盖掉
3、每天下班前提交一次，就算功能没写完只要能正常编译通过不影响其他人用就行了。
4、感觉这段写的很好，以防丢失 commit 之后赶紧 push 一下会比较心安。
5、这段还没 commit 的代码想要重写一下，先 commit 之后再改

[wangyzj]

一个功能一个 commit 或者一个 bug 一个 commit

[FrankHB]

@zunceng Phabricator 我一直有计划要上的，主要是看 BitBucket 都要下线 hg 了，找公用的 hosting site 还不如自己内部直接维护全套的。不过这玩意儿整个部署起来还是麻烦，而且也没法解决 VCS 内部不能感知 diff 语义的更根本的问题。可能总有一天这部分也得自己造轮子了。