试想一个场景：你使用 git reset --hard commitID 把��地开发代码回滚到了一个之前的版本，而且还没有推到远端，怎么才能找回丢失的代码呢？ 你如果使用 git log 查看提交日志，并不能找回丢弃的那些 commitID。 而 git reflog 却详细的记录了你每个操作的 commitID，可以轻易的让你复原当时的操作并且找回丢失的代码。 当然，如果你丢失的代码都没有提交记录，那么恭喜你，你的代码真的丢了。
压缩提交记录这也是一个很实用的功能，前文提过，我们在开发中的时候尽量保持一个较高频率的代码提交，这样可以避免不小心代码丢失。但是真正合并代码的时候，我们并不希望有太多冗余的提交记录，而且 rebase 合并代码的时候，会把每个 commit 都处理一下，有时候会造成冗余的工作。 所以，压缩日志之后不经能让 commit 记录非常整洁，同时也便于使用 rebase 合并代码。
那么，如何压缩commit记录呢？ ✦ 使用 git log 找到起始 commitID ✦ git reset commitID，切记不要用 --hard 参数 ✦ 重新 git add && git commit ✦ git push -f origin branchName，因为会有冲突，所以需要强制覆盖远端分支，请务必谨慎。 ✦ 合并到 master 中，然后更新远端 master。
此外还有两种压缩日志的办法： git commit --amend：追加 commit 到上一个 commit 上。 git rebase -i：通过交互式的 rebase，提供对分支 commit 的控制，从而可以清理混乱的历史。
从实际应用来说，三种日志压缩都很优秀，git reset 更简单，git rebase -i 更细腻。
git rebase，合并代码前文简单介绍了 git rebase 和 git merge 的区别，坦率讲，他们各有优劣。 git rebase 能让你的 commit 记录非常整洁，无论是线上回滚还是 CodeReview 都更轻松；但却是一个有隐患的操作，使用时务必谨慎。 git merge 操作更安全，同时也更简单；但却会增加一些冗余的 commit 记录。
这儿简单说说 rebase 的合并流程和注意事项吧。看下图
有三个点需要注意： ✦ rebase 先找出共同的祖先节点 ✦ 从祖先节点把 pay 分支的提交记录摘下来，然后 rebase 到 master 分支 ✦ rebase 之后的 commitID 其实已经发生了变化 尤其是第三点，经常会让人误操作，所以务必注意。
试想一下，开发过程中，如果我们频繁的 rebase master 分支，会有什么后果呢？
当你不断 rebase master 的时候，其实你本地的 d 都变成了 d` ，再要和远端 pay 分支保持一致，你的本地分支 commit 记录已经不堪入目了。
另外要注意，绝不要在公共的分支上使用 rebase！！！
所以，为了安全，团队可以考虑采用 merge。
pull request，方便CodeReviewGit 不仅提供了代码托管以及代码开发的帮助，还提供了代码审核类似的功能。 当我们在功能分支开发完成之后，可以发起一个 pull request 请求，选择需要对比的两个分支
它会创建一个 pull request，制定相关人员来对代码进行 review。 通常情况下，团队应该鼓励交叉 review，涉及到公共代码的时候，一定要让相关人 review。
git hook，Git 的生命周期这个大多数人应该都，听说过，git操作有它自身的生命周期，在不同的生命周期，我们可以做一些自动化的事情。
举两个简单的例子： ✦ pre-commit的时候我们可以做 eslint ✦ post-commit的时候，我们可以做利用 jenkins 类似的工具做持续集成
当然还有更多的声明周期，具体可以参考 Git 钩子
git submodule && git subtree，管理第三方模块