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

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

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

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

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

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

@zclHIT 不是不推荐做 rebase 吗

有空就 commit

git rebase -i

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

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

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

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

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

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