一个三年Android开发的总结－git基础知识与协作开发

开发中的常见问题

在自己开发软件的过程中，总是会碰到如下的问题，甚至更多：

如何向他人分享代码或在不同地方看已写的代码：比如在家里写了测试程序，在公司想复用；亦或是自己写的软件包含很多的代码和资源，想分享给他人，要记得拷贝，而且如果有几处小修改，还得重新再拷贝；

如何查看修改了哪些文件：软件里好几个文件都有修改，但是间隔几天，想梳理下改动了哪些文件，哪些地方；要是再想看看前段时间做的新功能，都涉及到哪些文件呢？

如何得知一小段代码修改的原因：是否因为一段代码忘了注释，让人始终想不起当时和什么样的功能逻辑相关？

如何随时给出较稳定的版本：一段时间的修改测试后，软件相对稳定，怎么保存起来，在需要的时候方便的取出？

在没有版本控制软件之前，有自己的方法，比如准备了专门的存储区域，将源码压缩，以时间或功能说明来命名保存；再配合对比工具，来查看代码差异；在有了git这样强大的工具后，事情变得那么轻松和自然。

git基本概念

先从本地角度理解，在一个文件夹里，有一个代码仓库，它记录了你对仓库里代码资源的所有你想要保留的操作：新增文件，修改文件，删除文件，再具体些可以是你，在什么时间，由于什么原因，对哪些文件的哪些部分，做了怎样的改动，改动的历史是怎样的。

如果加上合作的概念理解，有一个公共的仓库在大家都可以访问到的地方，所有人将这份仓库拷贝到自己本地；本地仓库和公共仓库都留下了所有人想让别人看到的对代码资源的操作记录及操作原因等信息。

关联到git，那么这个仓库，就是repository，在.git目录下保存了你的所有操作，当你把操作信息推送（push）到远端的公共仓库（remote），其他人就能从公共仓库拉取（pull）后查看这些信息

git使用

新建仓库：找个文件夹，执行git init命令，这里就是一个你的新的仓库；

使用远端的公共仓库：git clone 远端url，就会将远端仓库信息，拷贝到本地；

拉取最新代码：git pull orign，从clone的仓库上，获取远端最新的修改信息；那么分享代码，或者随时随地查看自己最新的代码，只要clone一份，或者在已clone的代码仓库上pull一下；

修改代码：在代码上肆意驰骋，然后：我去，改得如脱缰野马，忘了都改了什么

查看改了哪些文件：git status，列出当前的状态，增删改了哪些文件

查看改了哪些地方：git diff，查看所有文件的具体修改，也可携带完整文件路径，查看单个文件的修改

恢复被修改的文件：git checkout 要恢复的文件或路径，将指定文件或路径恢复到修改之前的状态

提交修改：奔腾好久，终于改好，保存下阶段成果；

git add 增删改的文件，懒人用git add .（没看错，我是个点），或者git add –all；

git commit -m “修改原因”，保留下我的足记

查看提交：git log，看看我都做了什么，当然也有别人的提交

推送到远端前犹豫了:git reset HEAD^1，回到一次提交前的状态；嗯，刚看到别人写的提交说明都好规范，那我想改改提交说明（其实是测试的时候发现有问题），改完后重新做提交；

推送到远端:git push origin，推送上去后，别人也能看到我的修改；

推送远端后后悔了:完了，又发现严重问题，大家估计都编译不通过了，有后悔药不，

撤消修改，git revert

再提交，推送修改

当发现是自己犯傻，可以再git revert，如果还没push到远端，可以git reset

标记稳定版本：一番折腾，终于有稳定版本了

标记版本：git tag 自己起个名字吧

切换到标记版本：git checkout 那个名字

算是已经解决了最初的问题，那么多个人合作会是啥样呢

git协作开发

一个人想怎么来怎么来，但是随着共同协作开发的人数越多，遇到的问题也会越多，同时随着版本的增加，又将引入新的问题。

在讲述协作开发解决这些问题前，先增加分支（branch）相关的概念

原来直接clone下来修改并提交代码的那个，可以理解成主分支（master）；

新建分支：git branch 新分支名 所基于的分支，或者git checkout -b 分支名；当你做一个新功能时往往需要很长时间，而随时提过来的bug又要紧急修复，怎么办？那可以在做新功能时，新建分支；修改功能时，再建新分支；

关联远端：新建的分支git branch –set-upstream 关联的远端分支，如果想直接推送当前的修改到对应的远端分支，也可以是git push -u origin 本分支名

合并修改到主分支：git merge 外来分支，将其它分支合并到此分支；因此要git checkout在主分支上（合并代码到主分支），或是其它要合并代码的分支

后悔合并：在合并完后push之前，如果后悔，可以git reset；已经激动的push之后，还可以git revert 记得-m参数为1

再看协作的方式：

只有一个分支，即主分支：人数就2-3人，也没有啥规矩，直接在主分支上修改提交

功能与修复bug：需要紧急修复问题时，可以先缓存当前修改（git stash后一篇文章介绍），修复问题后提交

主分支保留，每人有固定分支：适合版本稳定，基本不会再对已发布的稳定版本做修改，同时人数不太多，代码review迅速

功能与修复bug：在自己的分支上修改，然后提交merge请求到主分支，在gitLab等上可以进行代码review，并决定是否需要合并；merge前可以一直push代码；但是此时要是新功能和bug修复都推送到远端了，review代码的人就该痛苦了

稳定版本的bug修复：此时不得不基于稳定版本创建新分支，修复问题

主分支稳定，不断创建新分支：不以人来固定分支，而是新功能，新的bug修复为原因不断创建新分支，

功能与修复bug：根据问题或功能创建分支，完成后提merge请求，等待review和合并，没有及时对待也无所谓，一般不影响后续提交

稳定版本bug修复：基于稳定分支创建新分支，修复问题，如果此问题也要在新版本修复，可以git merge到新版本，或者git cherry-pick到新版本

此种方式是要理解git上分支的廉价，多版本多功能可同时进行，灵活性高。具体可以参看下图：



大家可以根据自己的实际情况来选择，如果想理解其中的具体使用方法和原理，推荐看git book，有中文版，也可以看后续文章。欢迎关注微信公众号“编程阳光”，你的关注是我持续的动力。转载请注明出处：http://blog.csdn.net/w7849516230