2019-10-23git rebase -i 确实很好很强大，哈哈！
课后思考题
1.git cherry-pick 应该可以间接实现
2.git push -f / git rebase 已提交的代码后再git push -f 是危险操作。
人少时，吼一嗓子，再使用。人多时还是放弃吧。哈哈！
可是我经常这么干。🤦♂️
git push -f 后，轻则已拉取代码回本地的人需要手动修复下环境，重则之后推送的分支会被丢失。
（别人以为已经提交了，哪知还有人敢强推代码）
如果时间久了，别人本地分支也没留记录，可能代码就需要手敲了。（概率很小，但也可找回历史提交）展开作者回复: 看来@我来也 是git的高手呀！分析得非常到位。👍👍👍
3
2020-01-16思考题留言区有同学已经答得很帅了，想了下就是做不到答得更好，只对第二个问题大概做一下补充，其实这个本体本质上还是git rebase和远端库共享的潜在冲突的问题，所以从这一点上讲，远端是fork的私库，任何共享都是基于TBD的CI基础上完成就非常重要了，对发布出去的东西，还是得注意品质，后悔药在git世界里不是没有，只是可能会让大家都很痛苦，发出去的东西就当泼出去的水，一路向前，不要回头
其实进来这里就是纯赞的，我本来以为我经常PR之前用git rebase -i仔细梳理就算是会了git了，但是看第一个场景git add -p我就直接跪了，也许以前见过，但是真没印象，一点也没有，我甚至没想过还可以这么干，虽然我不太认同这么部分的管理更新吧，要做这种部分提交，我觉得很大程度上是设计上没太想好，自己本地库这里还在debug的感觉；但是git的强大真的可见一斑展开作者回复: git add -p 我个人还是常用的。因为在写代码的时候，常常会看到一些小的地方需要修改，就顺手改了。但是在产生提交的时候又不合适放到一个提交里，所以用git add -p 去分开。
另外TUI的git工具tig有一个命令`1`可以非常方便地进行git add -p的操作，可以一行一行的进行挑选。所以拆分也很方便。
2019-10-22思考题
可以通过强制push: git push -f 覆盖掉在远程的分支，不过这样做确实很危险。作者回复: 是的。可以在本地修改git历史，然后git push -f推送到远端共享分支。
再追问一步，这样做的危险性是什么呢？
2019-10-211.很棒，历史提交操作这块以前没概念，一直都是手动来，导致增加很多提交，学习了，练习下应用到工作去。
2.现在工作主要用idea，用git的拉推提交回滚啥的简单操作都是直接在idea上。涉及到拆分提交这类操作就要切命令行敲git 指令。感觉操作不连贯。老师工作中是纯命令的吗？这些操作跟idea是否有对应？如果有应该怎么做？
3.git-history，小工具，但看历史变更更直观，推荐使用。作者回复: 我大部分的Git操作是在命令行中。主要使用原生的Git命令，以及tig，还有gitin。在VSCode中使用Git Graph插件做一些读历史提交的工作。
IDEA我最近没有高频使用。以前使用的时候也没有大量使用它的GUI的Git部分。
git-history，你指的是这个吗？
https://github.com/pomber/git-history 1
2019-10-21没用过 没看懂(╥╯^╰╥) 看来还得拿栗子实践一下作者回复: Git很好玩的 ：）