对于scm这个岗位来说，基线升级应该是这个岗位需要的必备技能了，现在来说说我司进行高通代码基线升级时选择的方式方法，供大家参考，也供自己学习积累。
git这个工具大家都并不陌生，但是对于不经常提交代码的我来说，在进行基线升级时对于选择git merge 还是git rebase的方式进行了再三考察，最终的结论（其实我现在也不是很明白）：总的原则是，只对尚未推送或分享给别人的本地修改执行变基操作清理历史，从不对已推送至别处的提交执行变基操作，这样，你才能享受到两种方式带来的便利。
参考链接：
git 变基
当前状态：开发任务分叉到两个不同分支master、experiment
当前目标：整合不同分支，master
1.分支合并git merge
整合分支最容易的方法是 merge 命令。 它会把两个分支的最新快照（C3 和 C4）以及二者最近的共同祖先（C2）进行三方合并，合并的结果是生成一个新的快照（并提交）。
$ git checkout master
$ git merge experiment
2.变基 git rebase
提取在 C4 中引入的补丁和修改，然后在 C3 的基础上应用一次。使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上，像“重新播放”一样。
将 C4 中的修改变基到 C3
$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command
原理：首先找到这两个分支（即当前分支 experiment、变基操作的目标基底分支 master）的最近共同祖先 C2，然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件，然后将当前分支指向目标基底 C3, 最后以此将之前另存为临时文件的修改依序应用。
master分支的快进合并
$ git checkout master
$ git merge experiment
结论：这两种整合方法的最终结果没有任何区别，但是变基使得提交历史更加整洁。 你在查看一个经过变基的分支的历史记录时会发现，尽管实际的开发工作是并行的，但它们看上去就像是串行的一样，提交历史是一条直线没有分叉。
一般我们这样做的目的是为了确保在向远程分支推送时能保持提交历史的整洁——例如向某个其他人维护的项目贡献代码时。 在这种情况下，你首先在自己的分支里进行开发，当开发完成时你需要先将你的代码变基到 origin/master 上，然后再向主项目提交修改。 这样的话，该项目的维护者就不再需要进行整合工作，只需要快进合并便可。
请注意，无论是通过变基，还是通过三方合并，整合的最终结果所指向的快照始终是一样的，只不过提交历史不同罢了。 变基是将一系列提交按照原有次序依次应用到另一分支上，而合并是把最终结果合在一起。