说到团队协作，版本控制已经是必不可少的一环。
说到版本控制，git 当之无愧成为了首选。
git 的使用已经成为了团队开发的必备技能，当然介绍它的文章也多之又多，这里我就不一一介绍了。今天我想和大家分享一下 git 使用过程中的一些心得。
commit 应该如何使用
commit 是 git 的最小单位，每一个 commit 都会自动生成一个 hash 值来唯一标记。
commit message 是提交说明，即该 commit 做了什么。
我认为，每个 commit 都应该具备一下几点原则：
- 只做一件事情，即完成一个功能点，或者修复一个 bug，或者其他。
- 保持 commit 的完整性，即可以通过编译、通过代码风格检查、通过测试。
- 有完善的 message 信息。
commit 是 git 使用中最常见的命令，使用过程中遵循这几个原则，不仅可以方便同伴了解自己的开发内容和开发进度，对于后续代码维护的信息查询和历史版本追溯起着重要的作用。
rebase 真的很强大
commit 要遵循以上原则，就离不了 rebase 了。
rebase 可以完成的功能：
- 合并 commit，用于合并完成同一件事情的 commit 或者是该 commit 的 fix 用于保证该 commit 满足上面的原则。
- 修改 commit message，重新整理 commit 的提交信息。
- 编辑，在某个特定的 commit 的版本下，对代码进行编辑。可能是对上一个 commit 的完善或者新的功能点的插入。
- 删除 commit。
- 排序，更改 commit 的提交顺序。
- rebase 使用最多的场景应该是解决冲突和整理代码。
整理代码就不用说了吧，为了保证 commit 满足上面的原则或者更符合正常的思维逻辑，要对代码进行整理。
解决冲突是指远端分支的更新和你当前的更新操作的是同一个文件和位置的代码时，将两个更新做一个对比，手动决定留那一部分的更新或者是两者都需要。
我在这里说几个我的小建议：
- rebase 之前最好本地备份分支。善于备份可以避免在失误的情况下丢失一部分代码，使自己的劳动付诸东流。
- 预期本地更改与远端更新有冲突时，先解决冲突，再整理代码。分两次进行 rebase，减少操作过程过于复杂造成失误或者思路混乱的问题。
rebase 和 merge 有什么区别
rebase 上面已经介绍过了，merge 顾名思义，就是将远端分支合并到本地分支。
在 git 的拓扑图上，rebase 是将当前的提交移动到远端更新的提交节点之后，即把远端的更改挨个应用到当前分支的每个 commit 上；merge 是将远端分支与当前分支进行合并，生成一个新的 commit。
如果当前更改与远端更新存在冲突，rebase 会在每一个 commit 上去应用该更改，并判断是否有冲突进行修复；merge 之后在合并时判断是否有冲突。
开发过程中尽可能的使用 rebase，这样既可以保证每一个 commit 满足上面的原则，又可以使得提交记录更改清晰，方便整理代码。
慎用 pull
pull 是相当于执行了 fetch 操作和 merge 操作，开发过程中如果出现远端分支更新需要同步，尽量使用 fetch + rebase 操作，也可使用 git pull --rebase。
cherry-pick 或许能解决你的问题
cherry-pick 是将一个特定的 commit 应用到当前分支。
如果你出现一下场景获取它能帮你解决问题：
- 开发功能过于庞大又长时间没有和远端仓库保持同步。
- 当前提交中需舍弃一部分 commit，rebase 操作分险过大。
- 基于开发分支开发的功能需立即上线，需将代码直接提交到上线分支。
操作很简单，在对应的分支上进行 cherry-pick 操作即可，使用 commit 唯一表示的 hash 信息。
分享
最后给大家分享几个学习 git 的网站，刷完这个你对 git 一定会有一个全新的认识。