摘要：GIT中有三种重置功能，分别是soft、mixed、hard，区别如下：lSoft -当前分支重置到指定commit记录位置，索引和工作树不变；lMixed -当前分支重置到指定commit记录位置，索引被更新，工作树不变；lHard -当前分支重置到指定commit记录位置，索引和工作树都更新。貌似不好理解，首先要理解GIT的三个区域（工作树、索引区、仓库），可以参考文档《GIT简介》。先做soft的测试，新建Soft.java文件，可以看到此文件未添加到索引控制先进行一次提交，提交后在History窗口中重置此次提交，如图：重置后查看工作树，如图从上图可以看出，soft文件还存在，说明重置
阅读全文
随笔分类 - | RevisionControl |
摘要：MairoBro来做fetch和rebase的测试，首先Mairo弟弟在client中添加文件OPQ分别提交，并push到服务器，如图：此时服务器端的历史已经被更新，但是Mairo哥哥的remote tracking中mirror分支并没有更新到最新的记录，如图：所以需要更新remote tracking中的分支，使得它与服务器端的分支同步，右键点击资源库选择Fetch这样就更新了本地的remote tracking中的分支，使得它和服务器端分支同步。然后Mairo哥哥在本地的private中添加文件ABC，并分别提交到本地仓库中。然后将本地mirror分支和remote tracking中的
阅读全文
摘要：此小结为什么说是简单解析呢，因为rebase和merge的选择问题讨论比较激烈，笔者也没有一个定论，而且git也处于研究发展阶段，很多理论还没有完全的纯熟。对于一个多人开发团队频繁提交更新的情况，如果使用merge会使得历史线图非常复杂，并且merge一次就会新增一个记录点，如果使用rebase就是完全的线性开发。上图所示是Merge和Rebase的两个结果，显然你不想要merge的混乱结果吧，你能告诉我merge图中那条线是master分支吗？所以给出如下建议，如果同一文件反复修改或提交次数比较多，预期会出现很多的conflict，那么可以使用merge合并，仅需要解决一次冲突即 可（不过，
阅读全文
摘要：Rebase和Merge操作最终的结果是一样的，但是实现原理不一样。从上面的MairoBro例子可以知道pull大概对历史记录进行了怎样的合并操作，其实默认pull的操作就是一个分支的merge操作，如下图重现一下：Mairo弟弟的提交记录如下：Mairo哥哥的提交记录如下：首先是Mairo弟弟把更新push到服务器，这样服务器端的记录就和Mairo弟弟本地的记录是一样的，接着Mairo哥哥执行pull操作，现在分析下pull是如何操作的。l pull默认就是先把服务器端的最新记录更新到本地的Remote Tracking中对应的mirror分支l 接着对Local的mirror分支和Remo
阅读全文
摘要：多人协作开发的情况下，往服务器推送更新时难免出现冲突，所以推送之前需要解决服务器端的最新版本和本地仓库的冲突。Pull操作就是把服务器端的更新拉拢到本地仓库进行合并，解决好合并冲突后，就可以顺利push到服务器分支了。假设现在Mairo兄弟在用GIT协作开发NewSuperMairoBro游戏，目前服务器端的mushroom.java文件的内容如下：MairoBro克隆出代码后，Mairo哥哥做了如下修改Mairo弟弟做了如下修改然后Mairo弟弟先push代码，Mairo哥哥使用pull来合并本地仓库和远程仓库，将发行文件出现冲突，此时GIT会自动合并冲突的文件，如下图所示：很明显自动合并的
阅读全文
摘要：克隆服务器端仓库后，会在本地建立一个一样的仓库，称本地仓库。在本地进行commit操作将把更新提交到本地仓库，然后可以将服务器端的更新pull到本地仓库进行合并，最后将合并好的本地仓库push到服务器端，这样就进行了一次远程提交。先提交一次到本地仓库然后push到服务器端的mirror分支，Team -> remote -> Push完成推送后，可以在服务器端mirror镜像的log中查看到此次记录
阅读全文
摘要：此小结的前提是已经搭建GIT服务器，并通过SSH协议连接，可参看文档《RHEL下搭建GIT服务器》 《WindowsXP下搭建GIT服务器》《GIT服务器使用基础》。本文使用RHEL5.5系统下的GIT-2012-01-11，用户 root/password，GIT仓库统一存放在/app/gitspace目录下。首先通过shell工具连接到服务器，建立空仓库gitdemo，此时的ssh访问地址如下,分别由协议名称、用户名、IP、端口、git仓库目录组成。ssh://root@192.168.1.101:22/app/gitspace/gitdemo打开GIT资源库窗口，选择克隆资源库现在已经把
阅读全文
摘要：Team -> Show in history可以查看版本历史提交记录可以选择对比模式
阅读全文
摘要：此时我们尝试做一次提交l Team -> Commit…如上图所示，Author和Committer会默认为Git配置的用户信息。下面的Files窗口中可以看到此次提交的文件，其中有非常多带有NC_HOME的文件，此时可以猜测出，在我们的project中链接的NC_HOME也被GIT默认到版本控制中了，如下图：显然NC_HOME和out是不需要进行版本控制的，我们可以通过配置.gitignore来排除这两个文件夹打开Navigator窗口，在project根目录中添加.gitignore文件，将需要排除控制的目录写入.gitignore文件中再次尝试commit，需要提交的文件已经被过滤
阅读全文
摘要：新建NC module projectl File > Team > Share Project 选择GIT创建仓库后，在$workspace\demo目录下的.git文件夹，就是git的仓库地址。和CVS、SVN不同，GIT不会在每一个目录下建立版本控制文件夹，仅在根目录下建立仓库同时，eclipse中的project也建立git版本控制，此时未创建分支，处于NO-HEAD状态文件夹中的符号”?”表示此文件夹处于untracked状态，这样就成功创建GIT仓库。
阅读全文
摘要：配置个人信息，最重要的是user.name和user.emaill Preferences > Team > Git > Configurationl New Entry
阅读全文
摘要：一、安装EGIT插件http://download.eclipse.org/egit/updates/或者使用Eclipse Marketplace，搜索EGit
阅读全文
摘要：首先介绍几个版本控制软件相互比较的重要依据，更详细的比较请参考文中链接：*版本库模型（Repository model）:描述了多个源码版本库副本间的关系，有客户端/服务器和分布式两种模式。在客户端/服务器模式下，每一用户通过客户端访问位于服务器的主版本库，每一客户机只需保存它所关注的文件副本，对当前工作副本（working copy）的更改只有在提交到服务器之后，其它用户才能看到对应文件的修改。而在分布式模式下，这些源码版本库副本间是对等的实体，用户的机器出了保存他们的工作副本外，还拥有本地版本库的历史信息。*并发模式（Concurrency model）:描述了当同时对同一工作副本/文件进
阅读全文
