在 SegmentFault，解决技术问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。
一线的工程师、著名开源项目的作者们，都在这里：
获取验证码
已有账号？
标签：至少1个，最多5个
初始化一个新的代码仓库，做一些适当配置；
有两种取得 Git 项目仓库的方法。第一种是在现存的目录下，通过导入所有文件来创建新的 Git 仓库。$ git init
第二种是从已有的 Git 仓库克隆出一个新的镜像仓库来。$ git clone git:///schacon/grit.git如果希望在克隆的时候，自己定义要新建的项目目录名称，可以在上面的命令末尾指定新的名字：$ git clone git:///schacon/grit.git mygrit
开始或停止跟踪某些文件；如何让 Git 忽略某些文件，或是名称符合特定模式的文件；
//此为注释 – 将被 Git 忽略//忽略所有 .a 结尾的文件*.a//但 lib.a 除外!lib.a//仅仅忽略项目根目录下的 TODO 文件，不包括 subdir/TODO/TODO//忽略 build/ 目录下的所有文件build///会忽略 doc/notes.txt 但不包括 doc/server/arch.txtdoc/*.txt//ignore all .txt files in the doc/ directorydoc/*/.txt此外，你可能还需要忽略 log，tmp 或者 pid 目录，以及自动生成的文档等等。要养成一开始就设置好 .gitignore 文件的习惯，以免将来误提交这类无用的文件。
要从 Git 中移除某个文件，就必须要从已跟踪文件清单中移除（确切地说，是从(1)暂存区域移除），然后提交。
如果删除之前修改过并且已经放到暂存区域的话，则必须要用强制删除选项 -f（译注：即 force 的首字母），以防误删除文件后丢失修改的内容。另外一种情况是，我们想把文件从 Git 仓库中删除（亦即从暂存区域移除），(2)但仍然希望保留在当前工作目录中。换句话说，仅是从跟踪清单中删除。比如一些大型日志文件或者一堆 .a 编译文件，不小心纳入仓库后，要移除跟踪但不删除文件，以便稍后在 .gitignore 文件中补上，用 --cached 选项即可：$ git rm --cached readme.txt
$ git mv README.txt README$ git statusOn branch masterChanges to be committed:
(use "git reset HEAD &file&..." to unstage)
README.txt -& README
其实，运行 git mv 就相当于运行了下面三条命令：$ mv README.txt README$ git rm README.txt$ git add README如何既快且容易地撤消犯下的小错误；如何浏览项目的更新历史，查看某两次更新之间的差异；以及如何从远程仓库拉数据下来或者推数据上去。
git提交一个文件，会提交一个commit对象，代表此次commit。其指向一个tree对象，里面包含了此次提交的文件对象的一个索引：
多次提交后，如下：
新建一个分支:这会在当前 commit 对象上新建一个分支指针$ git branch testing或者$ git checkout -b iss53等于$ git branch iss53$ git checkout iss53
要切换到其他分支，可以执行 git checkout 命令。我们现在转换到新建的 testing 分支：$ git checkout testing现在，在testing分支和master分支分别提交一次，就会如下：一般这种情况是，有重大版本的时候，先在下一个版本开发，如果上一个版本要改bug，再切回上一个版本，再新建一个分支去改bug，改完合并，等下个版本开发完后，两个分支再合并。
git分支合并
$ git checkout master$ git merge iss53
git branch 命令不仅仅能创建和删除分支，如果不加任何参数，它会给出当前所有分支的清单：$ git branch
要从该清单中筛选出你已经（或尚未）与当前分支合并的分支，可以用 --merged 和 --no-merged 选项（Git 1.5.6 以上版本）。比如用 git branch --merged 查看哪些分支已被并入当前分支（译注：也就是说哪些分支是当前分支的直接上游。）：$ git branch --merged
master之前我们已经合并了 iss53，所以在这里会看到它。一般来说，列表中没有 * 的分支通常都可以用 git branch -d 来删掉。
删除已合并分支
$ git branch -d testing
0 收藏&&|&&1
你可能感兴趣的文章
1 收藏，235
1 收藏，617
5 收藏，523
分享到微博？
我要该，理由是：你的位置： >
> Git由浅入深之分支管理
感谢作者熊建刚授权发布。
作者：熊建刚，前端开发工程师，毕业于北京交通大学，专注前端，喜好尝试新技术，热爱分享。个人邮箱：，博客地址：。
责编：陈秋歌，寻求报道或者投稿请发邮件至chenqg#csdn.net，或加微信：Rachel_qg。
了解更多前沿技术资讯，获取深度技术文章推荐，请关注。
几乎所有的版本控制系统都以分支的方式进行操作，分支是独立于项目主线的一条支线，我们可以在不影响主线代码的情况下，在分支下进行工作。对于传统的一些版本控制工具来说，我们通常需要花费比较多的时间拷贝主线代码，创建一个分支，并且对分支的管理效率也越来越不令人满意，而如今备受推崇的Git确实名副其实，Git中的分支非常轻量，我们可以随时随意创建任意数量的新分支，几乎感觉不到什么延时，而且对分支的操作也很高效，如，切换分支，暂存内容，分支合并，分支提交等。
Git分支的与众不同
上面我们提到相对于其他大多数版本控制系统，Git分支是轻量且高效的，为什么呢？答案是：传统的版本控制系统存储的数据是文件的变更，而Git则是存储一系列的文件快照（snapshot）。
Git分支的这些特性，使得分支对我们几乎没有什么限制，一般针对每一个功能或需求都可以随意创建分支，而在传统的版本控制系统，这样几乎是不现实的。
当我们向服务器提交数据时，Git会存储一个提交对象（commit object），这个存储对象包括一系列有用信息，详见。
Git主干分支（master）
master，有主人，大师的意思，在Git是通常作为主干分支，Git初始化仓库时，默认创建的分支名就是master，就像默认的远端主机别名是origin一样，大多数人不会修改它，这并不说明它与别的分支有什么区别，你可以随意修改名称。
在Git中，除了默认的master主干分支，我们创建的每一个分支，一般可分为两种：
长运行分支（Long-Running branch）:与master并行，长期存在使用的分支，如用以测试项目稳定性或作为主分支；
主题分支（topic branch）：针对每一个需求或功能或bug而暂时创建的分支，一旦任务完成，即可能回收。
分支指针（HEAD）
Git中有一个HEAD指针，始终指向当前分支，如图可见，项目当前处在master分支，之前一共有三次提交：
上图可见，第一行显示了当前项目所有分支，HEAD -& master表明当前所处分支为master，我们可以总结如下图：
我们可以在项目根目录.git文件下找到一个HEAD文件：vi .git/HEAD,其内保存了指向当前分支最新提交的指针：
该指针指向refs/heads/分支名文件，我们进入.git/refs/heads/目录，其下以分支名为文件名列出了所有分支：
我们查看当前分支文件，执行vi master:
可以看到，其内存储的就是当前分支的最新一次提交对象ID。
创建分支（git branch, git checkout -b）
接下来，假设有一个需求A，我们创建一个分支work-a:
git checkout -b 分支名
-b参数声明为创建新分支。
等价于以下两条指令：
git branch 分支名
git checkout 分支名
切换分支（git checkout）
git checkout 分支名表示切换到该分支，上文提到指定-b配置即说明创建新分支。
注：在切换分支前，一定确保当前分支的修改已经提交或者缓存。
多分支并行
我们经常会遇到同时需要开发多个功能和需求，或者突然发现线上bug需要紧急处理，我们只需要提交当前分支修改，然后切换到主干分支，从其基础上再切出一个新分支fix-bug1:
可以看到，在work-a分支上我们新增了一次提交：
b287b8eeb4cc6989。
现在我们在fix-bug1分支上修复bug后，进行提交：
可以看到，在fix-bug1分支上多了一个提交：ca270e6，现在整个结构就变成如下图：
合并分支（git merge）
我们已经修复了某bug或完成了功能开发，这时要做的是把代码并入主干，，当然一般公司或团队都需要经过代码审查，才能并入主干，在此略过不谈，分支合并相关指令：
git merge 分支名
该指令告诉Git将指定分支合并到当前分支，当然是可能出现冲突的，我们按照指示解决冲突，即可。
现在我们先切换到master分支，然后把fix-bug1分支并入主干：
可以看到执行git merge指令后，状态信息显示：
第一行Updating，告诉我们提交记录更新至ca270e6;
第二行Fast-forward，即快速推进，说明Git直接将当前分支推进到指向新提交对象;
后面是merge的内容信息。
非快速推进合并（NO FAST-FORWARD）
现在，我们再次创建一个分支fix-bug2，并进行几次修改提交：
多次提交后，状态如下：
我们通过非快速推进方式合并分支进主干分支：
如上图，指定–no-ff即声明进行非快速推进合并，第二行的Merge made by the ‘recursive’ strategy表明通过非快速推进方式合并，我们发现除了分支上进行的提交记录外，Git创建了一个新的提交对象：7a657a,使用
git log –graph指令查看其信息:
如图，快速推进方式合并入主干的fix-bug1分支的提交记录直接并入主线，且不会创建新的提交对象；而对于非快速推进方式合并的fix-bug2分支，其提交历史也都保存，但是并未进入主线，而是保存了一条支线，同时，在主线上创建一个新的提交对象。
最后描述其结构如图：
非快速推进与快速推进合并（FAST-FORWARD & NO FAST-FORWARD）
从上例，对比一下两种方式合并分支的异同：
提交对象都会保存；
报存提交对象方式不同：快速推进方式是直接在主线（合并主分支）上，添加这些提交对象，即直接移动HEAD指针；而非快速推进方式是将提交对象保存在支线，然后在主线新建一个提交对象，修改HEAD指针及新建提交对象的指针，而且此新建提交对象有两个父提交对象（即有两个parent指针）。
合并后分支指向不同：快速推进合并后，两个分支将同时指向最新提交对象，而非快速推进合并后，合并主分支指向新建的提交对象，另一分支指向不变。
我们查看一下新创建提交对象：
可以看到该提交对象中有两个指针指向父提交对象，一个指向主线中的父提交对象，一个指向fix-bug2分支合并而来的支线父提交对象。
三路合并（THREE-WAY MERGE）
除了之前提到的两种合并的情况，其实还存在这样一种情况，就是现在假如我完成了work-a分支的开发，需要将其并入主干，我们能看到当前master主干分支已经推进到7a6576了，而work-a分支指向b287b8,两者有共同祖先提交对象6d50f6,我们将其合并：
上图第二行表明此次是通过非快速推进方式合并，我们查看提交对象记录图：
结构如图：
我们发现，三路合并结构是在需要合并的两个分支的最新提交对象的基础上，创建一个新提交对象(4ae14b)，将合并主分支（即执行合并指令时，当前所处分支）的HEAD指针前移指向该提交对象，该提交对象有两个父提交对象，分别为合并前待合并分支的最新提交对象（即b287b8和7a657a）。
关于三路合并需要明确：
三路合并其实是一种非快速推进合并方式；
三路合并的前提是两个分支有共同祖先提交对象；
分支冲突（conflict）
在合并分支，不可避免会发生冲突，当我们在两个分支对同一文件同一部分进行不同修改后，发起合并时就会提示有冲突，假设我们有work-b分支，在其基础上切出新分支work-b-1，然后在两分支上分别对README.md文件同一部分进行不同修改并提交，然后将work-b-1分支合并到work-b分支：
发现README.md文件有冲突，查看该文件：
如上图，列出了两个分支的不同修改，HEAD表明当前分支的修改内容，下面是work-b-1分支的修改，我们选择需要保留的内容，删除其他无关信息和内容，然后保存该文件，查看当前状态：
根据提示，解决冲突后提交：
对于创建过但并未删除的分支，我们可以查看分支列表，依然使用git branch指令，不传入任何参数：
图中列出了所有分支，前面带星号的表示当前分支，当然我们还可以查看指明最新提交信息的分支列表，可以添加-v参数：
除了可以查看所有分支列表，Git还支持筛选已合并或未合并至当前分支的所有分支：
–merged参数指明筛选已合并分支；
–no-merged参数指明筛选未合并分支。
删除分支（git branch -d）
当分支合并入主干后，也许我们不再需要那个分支了，我们需要将其删除，使用指令：
git branch -d 分支名
之前介绍到使用git branch是创建新分支，而指定-d参数，说明需要删除该分支：
远程分支（remote branch）
我们注意到，前文所讲述的分支都是存在本地的，即本地分支，还需要了解远程分支，如[remote]/[branch]这种形式，表示是远端主机的某分支，，其实远程分支和本地分支基本理论概念还是相同的，区别是有些指令不同而已：
git checkout -b test origin/develop
以上指令即从远程分支(远端主机origin上的develop分支)切出新的本地分支test分支。
跟踪分支（TRACKING BRANCH）
前文已经介绍了本地分支和远程分支的概念及操作，那么这两类分支之间应该有某种关系将他们关联起来，本地项目都需要与远端主机仓库同步（pull & push）,当我们从一个远程分支切出（创建）一个本地分支时，这个分支就叫跟踪分支（tracking branch）,而远程分支叫上游分支（upstream branch）。
当我们克隆一个远端仓库时，会默认创建一个跟踪分支master，其上游分支就是远端主机别名/master。
创建跟踪分支
创建跟踪分支指令如下：
git checkout -b 本地分支名 远端主机别名/远程分支名
当然也可以不指定分支名，使用远程分支同名：
git checkout --track 远端主机别名/远程分支名
修改跟踪关系
有时候，可能需要为本地分支设置其上游分支，添加-u参数：
git branch -u 远端主机别名/远程分支名
以上指令就指明当前分支跟踪某远端主机的远程分支。
查看跟踪分支（git branch -vv）
使用以下指令查看分支的上游分支：
git branch -vv
上图输出信息第二行表明master分支跟踪远程origin/master分支，ahead 7表明本地有7个提交未推到服务器，其他分支不是跟踪分支，没有上游分支。
删除远程分支
对于不再需要的远程分支，是可以删除的：
git push origin --delete test
以上指令删除远端主机origin的test分支，但是在垃圾回收之前，Git服务器仍然会保留分支数据，我们可以很方便的恢复数据，之后会详细介绍。
变基（rebase）
Git中有两种方式整合不同分支的修改：第一种是前文介绍的合并（merge），另一种就是本节的主题变基（rebase）。
变基其实与前文提到的三路合并（three-way merge）颇有渊源：
如图work-a分支与主干master分支合并后，创建一个新提交对象，我们还可以通过变基完成两个分支的修改整合，由于work-a分支已合并到master分支，我们在work-a分支再提交一次修改e0ae7dc,然后我们将work-a分支对master分支进行变基：
执行变基时，由于两个分支对同一文件同一部分进行了不同修改，会提示冲突，需要解决冲突，我们修改文件解决冲突，然后查看状态：
上图，第一行 onto 4ae14b3说明当前分支针对4ae14b3快照进行变基，第三到第五行分别说明：
第三行：解决冲突然后执行git rebase –continue指令继续变基；
第四行：执行git rebase –skip指令，跳过解决冲突；
第五行：执行git rebase –abort指令，终止变基，回到分支变基前状态。
下面第6到第八行说明：
第七行：使用git reset HEAD 指令撤销某文件变更；
第八行：使用git add 指令标记冲突为已解决状态。
最后一行no changes added to commit (use “git add” and/or “git commit -a”)，说明尚未标记冲突，需要使用指令标记变更，在继续执行变基：
如上图，变基后，在主线上创建新提交对象640b83,并修改work-a分支指针指向该提交对象：
之后我们可以正常的合并：
变基后合并
如图，主线分支更新提交对象到640b83a，第二行Fast-forward说明此次合并属于快速推进合并方式，结构如下：
三路合并与变基
基于上例，三路合并，整合修改变更后会保留分支的原始提交记录，新创建提交对象有两个父提交对象，一个在主线上，一个在待合并分支上；而变基则不能保留待合并分支的原始提交记录，主线上新建的提交对象只有一个位于主线上的父提交对象。更多变基相关内容计划单独出文介绍。
至于到底选用哪种方式整合变更，变基还是合并，这个一直有争论，没有哪一种方式绝对合理，我们只需要把握一个原则：无论变基还是合并，你应该只操作本地历史记录，任何已经推到服务器并入主干的内容和提交历史不应该更改。
转载请注明： &
与本文相关的文章Android 代码版本控制Git - 简书
Android 代码版本控制Git
引言：对于Git的使用已经有一段时间了。不会太多的命令行操作，主要使用基于Android Studio和Eclipse对git进行使用。仓库的创建，代码的提交、更新、冲突解决等等。
时间：日12:12:27
作者：JustDo23
版本：[ Git ][ Windows ][ 2.6.4 ][
01. 下载安装
打开Git的选择自己需要的平台下载最新版的Git并进行安装。
02. Android Studio中配置
如果需要在Android Studio或Eclipse等开发工具中进行使用，都需要进行相关的配置。在Android Studio中指定git.exe的安装路径。
配置之后点击界面的Test按钮进行测试。执行成功之后会提示当前安装的Git版本信息。
03. 新建项目
在Android Studio中新建一个Android项目。
在Git服务器GitBlit中同样新建一个项目。
在以上截图中，如果选择了加入RedMe或加入.gitignore后期操作会变得复杂。
创建成功之后会跳转一个提示界面。提示学习Git以及提示代码推送操作步骤。
04. 仓库连接
服务器仓库建立完成之后，需要在本地建立仓库，同时将本地仓库和服务器的仓库建立连接。
切换到刚才在AS上新建项目的根目录下。
右键 选择 Git Bash Here 。
执行init指令初始化仓库。
执行add指令，将本地仓库与服务器仓库连接。
git remote add origin ssh://admin@192.168.1.149:29418/JustGit.git
05. 配置AS可以使用Git
在配置完成git.exe的路径之后，还需要进行一步操作，配置之后在AS中才会有Git相关的选项。配置如下：
这一步操作其实在其他地方也有可能会遇到，例如，你从别的地方copy了一份含有git的代码。当你利用AS从本地打开该项目之后就会发现没有git相关操行的入口了。此时，进行上述的操作，就可以了。
操作之后，会在AS左下角的工具栏中发现多出一个Version Control的标签。同时，许多文件都使用红色的。这一点是和SVN类似，文件的颜色表明了文件在Git仓库中的不同状态。
06. 忽略文件
Git下面有有个.gitignore的文件。这个文件主要是来配置Git将哪些文件进行过滤，进行忽略的。Git是代码版本控制管理的工具，版本控制就是对一个文件进行追踪，进行监控，记录各个版本信息。需要忽略的文件就不需要再进行监控了。
那么，哪些文件需要进行忽略呢？根据个人经验，编译生成的文件，集合环境IDE自动生成的文件等等都可以进行忽略。因为这些文件每更换一个环境就会发生改变。关注这些文件的版本变化，不仅没有任何作用，反而会加重开发者的负担，甚至影响工程的编译和开发。所以忽略这些文件以及忽略文件的配置就显得十分重要。
在AS中切换到Project视图。下图框选的部分都是需要进行忽略的。部分不忽略没有关系，比如gradle文件是可以不进行忽略。
07. 配置忽略文件
打开根目录下的.gitignore文件，配置如下
/local.properties
/.idea/workspace.xml
/.idea/libraries
# 以下是可以选择的 用#进行注释
gradle.properties
gradlew.bat
打开app目录下的.gitignore文件，配置如下
配置成功之后，被忽略的文件颜色从红色变成了黑色。说明配置成功。
08. 添加代码到Git索引
忽略文件配置完成之后，就可以放心大胆的将代码提交到本地仓库了。提交之前需要进行添加追踪，添加索引的操作。因为代码文件颜色还是红色，红色代表没有添加至索引，需要执行add操作。
继续之前的操作，同样在AS的Project视图下，选择项目的根目录，然后在菜单栏中选择 VCS 选择 Git 选择 Add
这里需要注意的是，选中项目根目录之后，后续操作的操作范围就是整个项目目录结构。如果是选择app目录，那操作范围缩小了。也就是说，先用鼠标选择操作范围，然后再执行相应的操作。这一点还是比较重要的。
09. 将代码提交本地仓库
将文件添加索引之后，文件的颜色就从红色变成了绿色。继续之前操作，同样选择项目的根目录，然后在菜单栏中选择 VCS 选择 Git 选择 Commit Directory
点击之后，会提示选择需要Commit的文件，以及填写这一次Commit的描述
重要提示，这一步操作的时候，需要认真查看自己提交的代码，确认需要提交的就勾选，否则就不要勾选提交。另外，这里 Git 强与 SVN 的地方，就是提交描述是必须填写的，不填写就无提交。
点击Commit，进行提交，同时会提示一些警告，初学Git的人不用害怕。继续点击Commit
提交成功之后，会在左下角的菜单栏进行提示，界面提示的信息是一定要注意看的。
走到这里不要想着大功告成，代码提交完毕了。在Git中Commit操作只是将代码提交到本地仓库了。将代码提交至服务器仓库，需要通过Push操作才可以。
10. 更新服务器代码
走到这一步，我们需要将服务器仓库中的代码进行更新。其实按照上边操作服务器现在仍然是个空仓库，没有任何代码可以进行更新。如果之前勾选了加入RedMe或加入.gitignore，那么更新操作就十分必要了。这一步操作进行更新代码，一方面是为了确保万无一失，另一方面是为了强调更新的重要性，强调在以后的使用过程中不要忘记了代码更新。
在Git中通过Pull操作来进行代码更新。在菜单栏中选择 VCS 选择 Git 选择 Pull
点击Pull之后，进入如下界面
点击ssh连接后边的刷新按钮，提示进行连接，进行ssh安全连接
点击Yes进行连接，同时提示输入密码
很显然，没有任何可以进行更新的文件。同时，我们看到本地仓库和服务器仓库已经切实的建立了连接。
11. 将本地仓库代码提交到服务器仓库
上边已经提到，代码还没有提交到服务器仓库中。在Git中通过Push操作来进行代码更新。在菜单栏中选择 VCS 选择 Git 选择 Push
点击 Push之后，会提示之前Commit的记录，将这些Commit的记录push到服务器，同时还会显示每一次的Commit注释。
点击 Push之后，需要输入密码。
点击 OK之后就开始将代码Push到服务器，成功之后，会在右下角有提示。
接下来，打开浏览器，查看刚才提交的记录。
走到这一步，完成了git的配置，仓库的创建，忽略文件，代码更新，代码提交等等操作。最重要的就是从无到有，完成了第一次的代码提交。
以上所有操作都是使用管理员账号admin进行操作的。接下来使用另一个账号也就是搭建服务器时候创建的账号just，进行仓库的克隆，代码的提交，更新，冲突的解决等等。
所以明确一下，两个账号相当与两个开发者，通过git仓库URL可以判断使用的是哪个账号。
账号：admin
账号：just
13. 仓库的克隆
克隆服务器仓库到本地需要使用服务器仓库URL进行克隆，打开浏览器，使用账号just进行登录，登录之后可以获取到该账户的仓库URL。
打开Android Studio点击File选择New选择Project from Version Control点击Git
弹出对话框，输入仓库的地址，点击Clone进行仓库的克隆
输入密码，克隆之后，选择使用一个新的界面进行打开
打开刚才克隆的项目之后，会提示Gradle目前没有配置，点击OK进行自动配置
配置结束之后，克隆完毕。可以到磁盘目录查看刚才克隆的项目。
14. 克隆方法
除了上边的克隆方法外，还有其他一些路径，总体而言都是大同小异。建议使用上边提到的第一种方法。不推荐使用以下的方法。
第二种方法：
第三种方法：
其实这两种是相同的，只不过路径不同。点击Git之后，同样是弹框提示输入仓库地址，不同的是，Clone之后会提示是否打开，
打开之后会提示进行gradle的配置
配置之后依旧是打不开的，因为没有提交本地SDK路径配置的文件local.properties
所以，以这两种方式clone之后，应该使用open an existing Android Studio Project的方法进行项目的打开。
所以，这两种打开路径并不进行推荐。
15. 一个流程
将仓库克隆之后，就可以进行开发。这里简单整理一个操作的流程：
更新服务器代码
进行本地代码开发
开发结束，更新服务器代码
这一步更新之后，可能更新成功，也可能更新失败。
更新失败，可能是本地某个文件有改动，服务器这个文件同样有改动
更新成功或失败，都可以继续往下操作
本地代码Commit
更新服务器代码
本地带Push到服务器
这个流程是笔者自己总结的，也是比较推荐，其中有多次代码更新，也是Pull操作。在多人协作开发的过程中，服务器的代码是随时有可能变更的，可以在浏览器中进行查看，多次更新代码好处多多。
使用just账号进行一个流程的实践。
更新服务器代码
在项目中新建一个类JustActivity，当这个类建好之后，会提示将其添加到Git索引
勾选Remember，以后新建的文件会自动添加到索引。添加索引参考以上第八点讲到的知识。
JustActivity的代码如下
* 账号：just
public class JustActivity extends Activity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
Log.e("just", "This is just .");
更新服务器代码，服务器没有任何变动，这里更新不下东西。更新之后，会在界面左下角工具栏中显示信息，Version Control的标签内显示更新的文件。
Commit操作，参考第九点讲解
Push操作，参考第十一点讲解
提交之前需要明确当前用户对服务器仓库是否有权限，没有权限需要进行权限的添加
提交之后，打开浏览器，查看提交的记录。
打开账户admin的项目，进行代码更新。
17. 冲突解决
冲突的出现：
修改了同一个文件的不同地方
这种冲突解决比较方便，更新之后会自动进行合并。
修改了同一个文件的同一地方
这种冲突需要手动进行合并。
为了演示冲突的解决，两个账号修改进行同一文件同一行代码，账号admin先提交代码，账号just更新遇到冲突，并进行解决。按照如下操作：
两个账号中MainActivity的代码如下
public class MainActivity extends AppCompatActivity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
账号admin在MainActivity中添加一行代码，结果如下
public class MainActivity extends AppCompatActivity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
Log.e("conflict", "This is admin");
账号just在MainActivity中添加一行代码，结果如下
public class MainActivity extends AppCompatActivity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
Log.e("conflict", "This is just");
账号admin进行代码的更新与提交。没有冲突，账号admin很轻松的将代码提交至服务器，打开浏览器可以看到提交记录。
账号just进行代码的更新。因为本地文件和服务器文件都有改动。所以提示更新失败了。
账号just进行代码的Commit
账号just进行代码的更新。会弹框提示代码冲突。
同时，可以看到文件中也有进行标识冲突的地方
进行代码合并可以手动在代码文件中进行修改，也可以点Merge进行对比合并。
通过界面的 双向箭头 和 叉号进行代码的合并
点击界面的Apply完成合并
账号just合并结束，没有任何错误的时候，需要进行代码的Commit
账号just进行Push操作，提交代码
打开浏览器查看提交记录
账号admin进行代码更新
冲突解决完毕。合并结果如下：
public class MainActivity extends AppCompatActivity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
Log.e("conflict", "This is admin");
Log.e("conflict", "This is just");
18. 查看历史
如有需要查看某个文件的历史记录，选中文件，右键选择Git选择Show History
19. 文件还原
文件还原的功能其实就是用来帮我们后悔，或者是回退的操作。这里举出两个使用的地方：
如有对某个文件进行修改之后，不想将其Commit，希望还原回旧版本，选中文件，右键选择Git选择Revert
对于已经添加add的文件，如果你不想继续对其添加索引，可以进行撤销add，方法就是还原
Git的使用基本完成
对于Git命名行操作，并没有接触太多
Git中的分支操作没有涉及
就是想要不断进步。