2019-11-03葛老师，请问提交代码的原子性，除了提高git技巧外，在工程上有什么需要注意的点吗？比如软件架构，设计模式。这方面应该随着语言和项目的不同会有较大的差异，有没有什么通用的原则？作者回复: 工程上，主要是解耦和增量开发。解耦好理解，把功能进行拆分。而增量开发这个一般大家提的不多。主要是在实现功能的时候，考虑怎么样实现最小子功能，即时这个子功能不能暴露给用户。我以后抽空详细写一下，通过代码的实际例子来解释应该更清楚。
2019-10-23从来不用rebase, 一直用merge，看来要好好学习下rebase了作者回复: http://onlywei.github.io/explain-git-with-d3/#rebase
交互式的界面学rebase。推荐看看 ：）
2019-10-23学习了，这两种方式我都会，也经常用。
我比较喜欢线性的提交历史，不喜欢merge。
但有个比较纠结的是。
比如采用第二种方式：
单独开发某个功能，也是采用小步走的方式，这样一个功能分支开发完后，可能有很多小的commit。
如果这些commit都线性的推到远程，感觉也不好。
目前只能先自己用rebase合并一些分支，然后再推。
如果是使用git merge —no-ff的方式，这些小commit就可以保留，在历史中可以看到完整的开发过程。
但是这样分支看上去就临时分叉了。
不知道老师推荐用哪种方法。
课后思考题一
我能想到的笨办法：
1。先备份当前分支，比如git branch temp
2。git reset —hard HEAD^
3。修改并git commit —amend —no-edit
4。git cherry-pick 后面的commit 😄
或者git checkout temp ；git rebase xxx 刚才修改后的commit （不知道可不可行）展开作者回复: 1-----
> 但有个比较纠结的是...
我一般是使用为rebase或者cherry-pick，把这些分支上的都放到合并到一个分支上，不使用merge --no-ff命令。
至于提交的粒度，就要考虑原子性了。尽量是单个提交只完成单个需求。当然，有些时候如果bug fix很小，也可以选择把多个bug fix合并成一个提交。
2-----
> 1。先备份当前分支，比如git branch temp
> 2。git reset —hard HEAD^
> 3。修改并git commit —amend —no-edit
> 4。git cherry-pick 后面的commit 😄
> 或者git checkout temp ；git rebase xxx 刚才修改后的commit （不知道可不可行）
这两种办法都可以，都很好！
还有第三个办法，我一般是把提交交换顺序，把要修改的提交放到HEAD处修改。
另外，我还第一次见到--no-edit。我以前都是用 commit --amend -a -C HEAD来完成类似功能 ：）
2019-10-23第一种太烧脑了，对开发人员的git技能要求太高了，大部分的开发人员都不能正确驾驭，感觉工作中更多的是以第二种为主，然后在某个branch内部结合第一种的情况比较容易驾驭。很头疼的问题是很多老同事没有深入学习git的主动性和激情，稍微复杂点儿的操作就让别人帮忙操作。作者回复: >第二种为主，然后在某个branch内部结合第一种的情况比较容易驾驭
的确是这样。第1种操作的确是要求比较高。而且如果有比较多的提交的话，rebase的overhead会比较大。所以单独的分支上不推荐，产生太多的提交。
> 很头疼的问题是很多老同事没有深入学习git的主动性和激情
如果他们能够意识到git的强大能够帮助自己提高研发效率的话，可能就会更愿意投入一些。能不能给他们搞点集体培训什么的？对团队效能提升帮助应该不错 1