作为版本控制软件，SVN早已被淘汰了，现在越来越多的开发者都已经拥入了GIT的怀抱。

可是，你一直在使用GIT的方式，真的用对了吗？

下面就给大家列出一些常见的错误使用方式和一些规范和技巧，注意事项。

错误做法1：commit之后立即push

有些人还是停留在SVN的落后思想中，还是使用SVN那种陈旧的提交方式，还特地为自己找了一个看似很合理的借口：

“我这样可以避免发生冲突”，“我不想解决冲突”

你这样真的是很让别人头大啊，对于项目管理来说，这种方式虽然能减少自己代码的冲突解决，但是你会给别人造成很多麻烦。

正确使用git，不要落入svn的使用行为模式： commit + push，这是集中式版本控制系统的最常见工作模式：每一个commit都立即push到server上。

这样就失去了分布式版本控制的灵活性：因为只要还没有push，就有足够的灵活性，我们可以对自己的commits进行修改，甚至删除，在git典型的工作模型中，你每天都可能产生10-30个commits，但我们仅仅需要2~3次的push，只要是不紧急的bug-fix或者feature-develop，都不必要频繁的进行push。

错误做法2：不清理提交历史，就直接push

push之前，记得清理你的提交历史，很多原因导致我们的提交历史图谱是混乱的，通常导致图谱混乱的原因有：

• “我需要多个commit来解决一个bug”；

• “我可能在commit时写了错别字，后来又进行更改”；

• “甚至我在某次提交中，纯粹是为了懒惰，不想使用stash，我可能把很多的修改变更进行了一次临时的commit”；

这些场景都会导致一个混乱的提交历史产生，难以阅读，难以理解，难以让他人看懂，这里的他人也可能是你自己，想想两个月后你再回来看自己的提交历史吧？

提交历史是非常有用的，能够追溯代码来源，谁修改了，改了哪里，产生了什么问题，通常用来后续定位代码问题所在，比如当你的某次提交把别人代码搞丢了的时候，就得通过提交历史来查看你到底做错了什么把别人代码弄丢了。

很幸运的是，git给了我们重新清理的机会：

- 重新修改提交记录（比如修改最近的一次提交记录：git commit --amend）
- 把所有提交放回暂存区，重新进行一次提交（squash）
- 重新对提交顺序进行调整
- 删除某个commit
- 合并某些commit

重新整理commit命令见 git rebase -i

奇淫巧技：cherry-pick

这个命令用于将某个指定的提交copy到当前分支。目的是将某个commit在当前分支上重演一遍。

使用方法：

git cherry-pick [commitId]

比如你在自己分支上改了很多功能，其中一个提交修复了一个bug的，但其他提交都是跟功能特性开发相关，但是这是测试分支、或者UAT分支需要紧急修复你改掉的那个BUG，那怎么把你那个提交放到对应分支上，又不会把其他修改带过去呢？这个情况下 cherry-pick 命令非常有用。

对于rebase命令，需要牢记的一个黄金定律

一句话总结： 只要还未push，都可以安全rebase！

学会使用git rebase -i 清理本地commit历史

命令行中在要清理的分支执行：

git rebase -i [baseCommitId]

会以交互式方式对本地提交进行整理，比如修改commit的注释，合并commit，重新对commit排序，删除某个commit等，以保证push后的提交历史清晰易读有用。

一般使用 rebase -i 清理历史时，往往base就是当前分支的remote tracked branch， 例如:

git rebase -i origin/test

由于经常要使用这个命令，因此可以配置一个全局的别名命令 tidy 来代替上述命令：

git config --global alias.tidy "rebase -i @{upstream}"

然后使用命令：

git tidy

就可以执行清理了！ git tidy就相当于git rebase -i [origin/branchName]

尽量不要使用默认的pull命令

git pull 命令是 git fetch + git merge 两个命令的组合。

而通常情况下我们希望远程仓库的分支历史信息是线性化的，然而pull自带的merge操作会进行分支合并，融合，使得分支历史产生交叉点，如果一次 git pull 操作是快进（fast-forward）模式的话，并没有什么影响，然而如果是一个三路合并（three-way-merge），将会自动产生一个merge commit，其注释信息就例如 “Merge branch 'test' of git@git.xxx.com:xxx-developer/scmv6.git into test”这样，就产生了一个远程仓库的分支合并到本地仓库分支，产生一个交叉点，但实际上这个交叉的合并是完全没有意义的。

对于上面说的这种问题，我们为了保证远程分支历史的可读性，线性化，我们要避免使用 git pull 默认的merge动作，我们需要显式的指定使用rebase操作：

git pull --rebase

这样就明确要求 git pull 产生三路合并时通过变基（rebase，中文变基，也称衍合）来进行合并。但这需要我们时刻注意 git pull 操作使用rebase而不是merge，但我们往往会忘记，因为是人就会有犯错误的可能，因此我们可以：

• 先fetch，然后进行rebase
• 修改pull默认的合并方式，全局配置：pull.rebase = true 或者branch级别配置：branch.branchName.rebase = true

上面两种方式二选一，如果你已经习惯了使用git pull，改用fetch + rebase不习惯或者觉得太麻烦（是人总想偷懒），那么就用第二种方式。

rebase还有一些注意事项

git rebase 命令使我们在分支提交历史管理上用非常棒的方式来进行合并，切片，清理等操作，但要注意的是rebase会使提交历史变成线性的，我们在使用rebase合并时，不希望产生merge带来的分支交叉，但仍希望保留merge清晰的语义，线性的提交历史让人讨厌。

举个栗子：

比如我们将自己的分支text_xxx通过merge合并到了关联远程仓库分支的本地test分支，然后进行了 git pull --rebase 或 git fetch + git rebase；然后查看test分支历史，发现我们合并test_xxx分支的历史都变成了线性的，看不出test_xxx分支合并的信息了，但我们仍然希望保留这个分支历史信息，我们就要使用 git pull --rebase=preserve 命令来保证合并记录。

仍然觉得命令 git pull --rebase=preserve太长，不容易记住，我们可以通过全局配置来修改rebase的默认行为：

git config --global pull.rebase "preserve"

尽量使git merge 强制使用three-way-merge

我们在合并自己的本地分支到远程分支时，如果是一个fast-forward模式的，在合并后删除我们的本地分支，那么远程分支历史图谱上变看不到我们的分支开发记录，我们希望在删除分支后，仍然保证我们的分支历史是清晰可见的，我们就不能使用 ff 方式进行merge，我们需要显式指定：

git merge --no-ff

eclipse操作merge时，要注意勾选：if a fast-forward, create a merge commit 选项。

或者全局配置默认merge操作以防忘记：

git config --global merge.ff false

专专心心做技术经验分享，一门心思搞科技知识普及。我是大师兄，喜欢我的分享的话，点个关注吧！@小影迷大师兄