答 1

1. 方便 code review
2. 如果发现 commit 有个严重缺陷，需要回滚，功能独立的时候一个 git revert <commit> 就行了，否则就要手工 revert

最好就是一个功能一个 commit，方便回滚和 review。 不过我有时候也是一大堆 bug fix 一起 commit。

一般来说，团队开发应当使用一种项目管理工具，比如说 Github 的 Issue 功能就足够。每做一件事情（事情的粒度酌情而定，也不一定非得是一个功能，符合团队的惯例即可）创建一个 Issue，每一个 Issue 对应一个 Commit。这叫：有因（问题）有果（提交）。

当然，我们处理某个 Issue 的过程中不一定只能做一次提交，关键是 Push 之前要做整理。用 Git 的好处之一就是在 Push 前，一切都是好修改、好整理的，不会影响中心代码库。

所以你可以把针对某个 Issue 的处理分解成一条一条小的 Commit，但是不要每次 Commit 之后立即提交，而是等到整个 Issue 处理完毕之后再整理和 Push。

至于整理，这是一个大话题，可用的办法和策略相当多。比如你可以用分支合并产生一条完整的 Commit；也可以用 Interactive Rebase 进行高可控性的细致调整（如果你没用分支的话），等等。更具体的，就需要你系统的学习 Git 的方方面面了。

顺便一提：无论是分支合并还是交互 Rebase 或是其他什么方式，产生的最终记录应当详细规范的填写 Commit Message，具体怎么写看团队规范，没有团队规范就定一个。比较通行的惯例是：第一行简要概述（或者写 Issue 的 ID ＋ 标题），之后空一行后面写过程概要（用列表方式），或者是详细说明（用段落方式）。如果说提交前有什么注意事项，这一条是最重要的。

谢谢各位。

git 做这个多方便，本地拉分支就可以了，天生就是为了一个功能一个 commit 的需求出现的。技术上很容易做到，这么做的目的上面几位说的也很到位。何必不这么做。

#5 楼 @lalameat 有时候我喜欢，好几个功能做好。。一起 commit，被同事谴责了。。

#6 楼 @moliliang 我刚开始就是所有功能完成提交一次，之后修改了值得提交的就提交一次，方便阅读

不要图方便用 git add ./，应该逐个挑选文件。 还有看看git stash，这个命令很有用。

git 的优势就是本地细粒度提交再整体完成后 push, 所以每当一个的 step 完成后，你就可以本地提交 (前提当然是没有 broken test), 但是 push 的时候就要非常注意了，一定是不能影响功能。

谢谢各位

一个新特性开个新分支，做完了，再 merge 到主分支。如果关于 git 你只想学一点，那么你就学这一点吧（这个不是我说的。。。）！

问题 1。 1，比如你写个项目，其中有个功能是关于滑动效果的。你写出来了，但过了一个月，需要你改一改这块的代码。没 git，你怎么知道哪些功能是和滑动相关的（当然你可以推断，全局搜索什么的）？你看 git comment！你找到你写在哪了，写了什么，就可以开搞了。这么是最清楚，最快的。 如果是多个功能，你需要话更多的经理去考虑，哪些是相关的。

2，出现问题了，有的时候不好 debug，干脆，就 checkout 了。如果两个功能写在一些，你 checkout 的时候会把别的功能也干掉，很不爽。。。

3，做个总结。你这干一样，那干一样，很难完成任务的。

写些项目吧！反正你写着写着就会发现，git 怎么这么好用！

再者，git 用于多人合作。我想看你代码，总不能说，hi，给我给备份。。。

顺便推荐 gitx。

听同事的，搞好和同事的和谐关系是最重要的。

每个人做的 feature 都单独开个分支啊，各自提交各自的，review 并测试 OK 后再合并到主干，使用 gitlab 或者 gerrit 之类工具系统

参见 http://nvie.com/posts/a-successful-git-branching-model/