提交(commit)、克隆(clone)、推(push)
http://blog.csdn.net/l_ji_l/article/details/79238181
1 提交代码到远程仓库
现在在项目可以提交(commit)到本地仓库，并进而push到码云上的远程仓库。
右键点击项目，依次选择Team-Commit，在下面的界面中输入Commit message、选择相应的需要提交的Files，然后
点击Commit and push(提交到本地仓库并且push到远程仓库)，如果选择Commit仅仅提交到本地仓库。
推送远程仓库
克隆服务器端仓库后，会在本地建立一个一样的仓库，称本地仓库。在本地进行commit操作将把更新提交到本地仓库，然后可以将服务器端的更新pull到本地仓库进行合并，最后将合并好的本地仓库push到服务器端，这样就进行了一次远程提交。
2.ignore忽略掉提交的内容
在提交的内容上面右击选择ignore就可以了， 会有一个.gitignore的配置文件出现。
如果想取消掉忽略的话在配置文件里面删除掉就可以了
八_解决推送冲突
多人协作开发的情况下，往服务器推送更新时难免出现冲突，所以推送之前需要解决服务器端的最新版本和本地仓库的冲突。Pull操作就是把服务器端的更新拉拢到本地仓库进行合并，解决好合并冲突后，就可以顺利push到服务器分支了。
假设现在Mairo兄弟在用GIT协作开发NewSuperMairoBro游戏，目前服务器端的mushroom.java文件的内容如下：
MairoBro克隆出代码后，Mairo哥哥做了如下修改
Mairo弟弟做了如下修改
然后Mairo弟弟先push代码，Mairo哥哥使用pull来合并本地仓库和远程仓库，将发行文件出现冲突，此时GIT会自动合并冲突的文件，如下图所示：
很明显自动合并的冲突文件不能直接使用，我们可以手动调整，右键发生冲突的文件，选择Team -> Merge Tool
第一项是将GIT自动合并过的文件和服务器端文件进行对比
第二项是用本地最新版本的文件和服务器端文件进行对比，建议用此项
接下来就是熟悉的对比界面
Mairo哥哥将冲突文件修改如下
然后右键点击此冲突文件，选择Team -> Add to index再次将文件加入索引控制，此时文件已经不是冲突状态，并且可以进行提交并push到服务器端
解决合并冲突后，Mairo弟弟只需要将服务器中合并后的版本pull到本地，就完成了一次协作开发的代码合并。从历史记录中可以看到，从mushroom开始历史进入分支，先是mushroomA的记录，然后是mushroomB的记录，最后历史分支合并。
九_Rebase和Merge的区别
Rebase和Merge操作最终的结果是一样的，但是实现原理不一样。
从上面的MairoBro例子可以知道pull大概对历史记录进行了怎样的合并操作，其实默认pull的操作就是一个分支的merge操作，如下图重现一下：
Mairo弟弟的提交记录如下：
Mairo哥哥的提交记录如下：
首先是Mairo弟弟把更新push到服务器，这样服务器端的记录就和Mairo弟弟本地的记录是一样的，接着Mairo哥哥执行pull操作，现在分析下pull是如何操作的。
l pull默认就是先把服务器端的最新记录更新到本地的Remote Tracking中对应的mirror分支
l 接着对Local的mirror分支和Remote Tracking的mirror分支进行merge操作
Merge操作后的结果就是会新增加一个merge记录节点，如下所示：
从上图可以看出，mushroomA是在mushroomB之前的，这个时间关系不取决于谁先执行push，而取决于本地仓库中谁先执行commit。所以merge会按照时间顺序严格的记录每一次commit。
接下来看看rebase，其实rebase也是把两个分支进行合并的操作，当Mairo弟弟push更新后，服务器端的mirror分支的历史如下：
Mairo哥哥本地的历史如下：
现在Mairo哥哥不是执行merge操作，而是执行rebase操作，最后结果如下：
很明显的区别是没有出现分支的记录，而且注意到mushroomA*，请注意这个记录和mushroomA不是同一个记录，我们先分析下rebase操作下，Mairo哥哥的历史记录都做了哪些变化：
l 先将当前分支的更新部分保存到临时区域，而当前分支重置到上一次pull的记录
l 然后将服务器端的更新添加到当前分支，此时当前分支和服务器端分支是一样的
l 最后将原分支的更新部分mushroomA提交到当前分支的后面，就是要在mushroomB的后面添加mushroomA的更新，当然此时更新记录已经不是之前的mushroomA了，如果出现冲突则使用对比工具解决冲突，最后记录变成mushroomA*。
如果Mairo哥哥提交过mushroomA1、mushroomA2、mushroomA3，那么执行rebase后会对mushroomA1、mushroomA2、mushroomA3分别顺序执行上图所示的合并，最后记录为mushroomA1*、mushroomA2*、mushroomA3*。很显然rebase操作更复杂，冲突的概率也更高，并且不是按照时间顺序记录。