标签：style blog http color 使用 strong
你需要知道的几个Git视图eclipse>Window>Show View>Other>Git
Git Reflog视图：可以查看所有分支的所有操作记录（包括（包括commit和reset的操作），包括已经被删除的commit记录。Team > show in history（即git log），是不能查看已经删除了的commit记录的。
Git Repositories视图：Git仓库视图，非常实用的，请务必要打开。
Git Staging视图：Git暂缓区（stage/index）视图。这个视图里面也可以进行commit操作，但是请记得先将修改的文件移动到Staged Changes中。
Git Tree Compare视图：比较视图。Compare With时会调出，可以在这个视图中查看比较详情。
通过将.gitignore文件添加到仓库，其他开发者更新该文件到本地仓库，以共享同一套忽略规则。对于每一级工作目录，创建一个.gitignore文件，向该文件中添加要忽略规则。
使用场景：
我们使用.gitignore文件来忽略util工程的中间文件(class)文件的存放路径
/bin |
注：
忽略只对未跟踪文件有效，对于已经加入到版本库中的文件无效。在文件忽略之前，一定要保证要忽略的文件没有添加到git索引中。
对于未跟踪的文件，我们可以创建.gitignore文件。对于已经跟踪的文件，我们可以这样做：git update-index --assume-unchanged <files>这样，即使已经更改了文件，用git status也不会看见文件已经更改。但在使用时需要小心，取消这种设定可以使用：git update-index --no-assume-unchanged <files>。对应eclipse>team>advanced>assume-unchanged和no-assume-unchanged。这样做的效果，只是说git认为这些文件没有被改动过，它认为这些文件的状态就是对应的版本库中存的最近的commit id里面的状态，所以，commit的时候，a.txt文件也不会被提交。比如说a.txt文件的内容改了，但是使用了assume-unchanged，然后由于服务器上有代码的更新，进行了更新操作（pull），如果服务器上a.txt内容也改了，那么，本地的a.txt文件就会直接变成服务器上面的a.txt文件，你本地之前修改的内容会被丢弃；如果服务器上面a.txt文件内容未被更改，那么，本地的a.txt文件依然是你改动过的效果。
Assume unchanged - Resources can be flagged "assume unchanged". This means that Git stops checking the working tree files for possible modifications, so you need to manually unset the bit to tell Git when you change the working tree file. This setting can be switched on with the menu action Team > Assume unchanged and switched back with the menu action Team > No Assume unchanged.
本地仓库的文件忽略规则可以在.git/info/exclude文件中添加。这些忽略的文件不会提交到共享库中，因而不会被协作者所共享。忽略只对未跟踪文件有效，对于已经加入到版本库中的文件无效。
使用场景：util仓库中，忽略src-mycore目录下的文件。
创建D:\esendev\gitrepos\util\.git\info\exclude文件，在 exclude文件写入“/src-mycore”，重启eclipse即可。
1、选中新增或修改文件
2、Team>add to index；
3、Team>commit，在弹出的窗口中选择提交的文件、输入提交的描述信息后，点击右下角的Commit。
说明：
作者（author）和提交者（committer）之间究竟有何差别，其实author指的是实际作出修改的人，committer指的是最后将此工作成果提交到仓库的人。所以，当你为某个项目发去补丁，然后某个核心成员将你的补丁并入项目时，你就是作者，而那个核心成员就是提交者。
查看当前状态 Git Staging视图（eclipse>Window>Show View>Other>Git>Git Staging）。Git的stage让你在提交的时候清楚的知道git将要提交哪些改动。
这个视图里面也是可以进行提交操作的，但请注意，如果一个文件改动加入 stage 后再次改动，需要把该文件再次拖到 stage 中才可以进行提交操作，否则提交的内容不包括后续改动的。
如果一个文件改动加入 stage 后再次改动，则后续改动不改变 stage。即该文件的改动有两个状态，一个是标记到 stage 中并将在下次提交时入库的改动，另外的后续改动则不被提交，除非再次使用 git add 命令将改动加入到 stage 中。
eclipse>Team>Show in History
如果想让提交时间显示年月日，show里面的Relative Dates去掉勾
特别说明：
1.在push之前可以做的操作，为避免给其他人造成麻烦，不要在push后再去改注释！
2.如果在提交之后，发现刚刚提交的信息有问题，应该如何操作？
eclipse>Team>commit，有可能需要点一下Amend previous commit按钮，就能发现注释框中出现最后一次提交的信息了，编辑后，点击Commit。就能在Show in history中看到最后一次提交的信息已经变成修改后的结果了
3.如果自己修改了代码，点了commit，然后又点了Amend previous commit，就会出现把别人上一次提交的代码改掉了的情况。这是错误的做法！请大家注意一下这个按钮的使用场景。
下面具体说说如何修改最后一次提交记录：
假设我们最好一次的提交记录是这样的
需要将“BUG”字样修改为“ISSUE”，那么，在保证分支是干净的（即不存在未提交的代码）情况下，eclipse>Team>commit，给出如下提示
点“Yes”，我们需要追加修改最后一次提交。出现下图的提交窗口，在提交窗口中“Commit message”中将“BUG”字样改为“ISSUE”字样，这就是修改最后一次提交的内容了。
修改完毕后，点击Commit，在历史视图中我们可以看到最后一次提交已经变样子了。id号、Message、Committed Date均有变化，其他的未变。
这样一来，就成功修改完毕了。
History视图：Show>Find Toolbar
点击某个文件，eclipse>Team>Show Annotations
使用这个，可以明确看到该文件被改过的详细情况，如下图：
如果没显示author，需要调整一下设置:Show Author
撤销已经提交操作
eclipse>Team>Show in history中，选中Revert Commit
git revert撤销某次操作时，此次操作之前和之后的commit和history都会保留，并且把这次撤销。HEAD指针向前移动，但是内容会变，一前一后，改动效果抵消。
如下图，在7661767上进行Revert Commit操作，会形成2条提交记录，一条是“ 提交1 ”，一条是“ Revert “提交1” ” 。
如果你已经将commit id为7661767的改动推送到远程仓库，那么就请使用这条命令，速度修正错误的修改，并将fac7afa的commit推送至远程仓库。
reset soft 重置HEAD指针，索引和工作区不变
reset Mixed 重置HEAD指针和索引，工作区不变
reset Hard 重置HEAD指针、索引、工作区
选中需要退回的commit，右键Reset>Hard(HEAD,Index and Working Directory)即可。状态就变回去了，包括HEAD指针、索引、工作区
特别说明：在push之前可以做的操作，为避免给其他人造成麻烦，不要在push后再去改注释！
场景：最后一次提交是69eb636，然后向合并69eb636至6fce61a的提交信息，因为都是对功能1的修改
1、History视图中，选中6fce61a，右键Reset>Soft(HEAD Only)
可以看到，马上History视图发生变化，HEAD指向6fce61a。此时，Index和Working Directory都没有变，状态是69eb636的
2、Team>Commit，点一下Amend previous commit按钮，出现6fce61a的注释，修改掉6fce61a的注释为你需要的合并注释，点击commit
3、效果如下，可以看到，提交信息变成一次了
如果没有看到上述效果，把Show>Additional Refs的勾去掉。
eclipse>Replace With
场景：如果某个文件modified.txt修改有误，而且你没有提交这个modified.txt文件。想要退回未修改前或某次提交的状态，可以使用eclipse>Replace With>Commit，在弹出的对话框中选中要恢复的最近的commit id即可。
eclipse>Team>Show in history中，结合ctrl键选中你要比较的2条commit记录，右键Compare with Each Other或Compare with Each Other in Tree
eclipse>Compare with，这个比较可以比较分支、commit等等，范围比较广。
eclipse>Team>Synchronize Workspace 当前工作树（就是project里的源码）与当前的分支做同步对比
eclipse>Team>Advanced>Synchronize 在多分支情况下，可以选择一个分支，进行同步对比。
同步视图，用于查看差异，不进行其他用途。
关于History视图中的Quick Diff：
1.配置eclipse>Window>Preferences>General>Editors>Text Editors>Quick Diff ，√Enable quick diff、√Show differences in overview ruler，Use this reference source - A Git Revision.
2.打开要比较的文件，在该文件变更的历史记录中选择你需要快速比较的那条记录的commit id，右键Quick Diff>Set as baseline即可。很快就能通过颜色的不同看出文件增删减的简要情况。
Git使用git fetch和git pull来完成远程更新任务。
git fetch命令：从远程获取最新版本到本地
git pull命令：获取远程仓库中最新提交和本地提交进行合并。git pull实际由两个步骤组成的，一个是获取操作（git fetch），另一个是合并操作（git merge），即：git pull = git fetch + git merge
由此可以见，在实际使用中，git fetch更安全一些。因为在merge前，我们可以查看更新情况，然后再决定是否合并。
操作入口：eclipse>Team>Remote>fetch from或eclipse>Git Repositories>某个Git仓库>fetch
下图代表获取远程仓库origin中所有分支的最新代码
Git 中的分支，其实本质上是个指向 commit 对象的可变指针，Git 会使用 master 作为分支的默认名字，它在每次提交的时候都会自动移动，指向最后一次提交对象。Git使用一个名为HEAD的指针，指向你正在工作的本地分支，这样你就可以知道当前在哪个分支下面工作。简单来说，Git下的branch不是一条线，branch其实就是一个指针，指向某个commit，然后根据这个commit的信息往前回溯就可以找到整个branch的记录了，他不是线形的，而是个无环有向图。
eclipse>Git Repositories>某个Git仓库，branches下有2个目录，Local下对应的是本地所有的分支，Remote Tracking下对应的是远程跟踪分支。
分支上有小勾的代表你目前正位于这个分支上。也可以使用命令git branch来查看目前位于哪个分支上。
Please, commit your changes or stash them before you can switch branches.
切换分支的时候最好保持一个清洁的工作区域。要么你把改动的结果全部commit，要么把改动的结果存到stash中去。否则，这些修改的文件将会在没有任何征兆的情况下 “意外”地被带到新版本里面去。比如one分支上开新分支two，然后切到two分支，改了些东西，又没有commit而直接切换回one分支，那么，改动的文件也会显示到one分支中。也就是说，在由two切换回one时，必须先对two的修改进行一次commit操作。
方法一：eclipse>Team>Switch to
方法二：Git Repositories视图中Local里面有，直接双击即可。
方法三：Git Repositories视图中，选中你要切换的分支，右键，选择checkout。
如果Git Repositories视图中Remote Tracking里面有你要切换的分支，直接双击切过去即可。
eclipse>Team>Switch to>Other>Remote Tracking
切过去的时候会出现提示，这个提示告示你，目前的状态处于detached HEAD状态（分离头指针状态），是不可以在这个切过去的远程分支上面工作。如果需要工作，需要把创建一个本地分支，然后把这个远程分支合并到本地分支上。
方法一：基于某次提交创建新分支：eclipse>Team>Show in history中，Create Branch
方法二：eclipse>Team>Switch to>New Branch
方法三：Git Repositories视图，选中某个分支，右键，Create Branch
远程分支就是本地分支push到服务器上的时候产生的。
首先要有一个本地分支one，然后选择push，把本地的one分支push到远程服务器上就可以了。这样，别人在fetch全部远程仓库的更新的时候，就会看到这个远程的one分支了。
如果需要同步远程仓库的分支，或者说是远程仓库有新的分支了，你需要查看，可以使用fetch来获取远程仓库的更新信息。
操作入口：eclipse>Team>Remote>fetch或eclipse>Git Repositories>某个Git仓库>fetch
注：
eclipse>Team>Advanced>Rename Branch 或Delete Branch
eclipse>Team>Remote>Push，Remote ref to delete
注：
分支删除成功的截图如下：（下图就是删除xui中4bi分支的效果）
操作入口：Git Repositories视图-某个仓库-Stash Changes
用stash保存进度时，stash对话框显示files的个数，是Git Staging视图中Unstaged changes的个数，Staged changes的个数是不显示的。
如果在工作区的修改尚未完成时需要切换到别的分支进行工作，改如何保存当前尚未完成的工作进度？
场景：testing仓库的one分支上工作，修改了hello.txt文件，还没有改完，需要切换到另一个分支master上进行工作
one分支hello.txt文件修改前
修改后，未进行commit操作
这时，需要切换到master分支，我们知道，在切换分支前，最好将你的修改提交或放入stash中，这里，我们不想提交对hello.txt文件的修改，那么，先在工程上面右键Team > add to index ，然后去Git Repositories视图，在testing仓库上右键选择Stash Changes。
在弹出的对话框中输入进度信息
然后，你就可以切换到master分支上工作了
在master分支上工作完后后，切换到one分支。切换到one分支，调出之前保存的工作进度，我们需要在那个工作进度上面进行工作。
可以看到Git Repositories视图中出现了Stash Commits的字样。选择需要恢复的工作进度，点Apply Stashed Changes就能恢复到之前在one分支上的工作进度了。
如果Apply Stashed Changes时提示conflicts，这说明保存在stash中的文件与目前的最近一次提交的内容出现冲突了，手工解决一下冲突，把出现冲突的文件改好，然后add to index。至于要不要commit，根据具体情况判断。
Git Repositories视图中Tags
git tag查看目前有哪些tag。
eclipse>Team>Show in history中，Create Tag
Git Repositories视图中Tags，选中某个tag，Delete Tag
删除远程tag：
方法一：
git push origin --delete tag <tagname>
方法二：
git tag -d <tagname>
git push origin :refs/tags/<tagname>
eclipse>Team>Advanced>Tag
输入tag的名字、tag message，在Advanced中选择要打tag的commit id，右边窗口Existing tag中选择你要替换的Tag，勾选Force replace existing tag，最后点击OK即可
操作入口：eclipse>Team>Remote>fetch或eclipse>Git Repositories>某个Git仓库>fetch
有未提交修改的情况下，不要执行可能会冲突的操作！在执行有冲突的操作前，先查看以下暂存区和工作目录，保证其中没有修改。
合并一：自动合并：
①修改不同的文件；②修改相同文件的不同区域；③同时更改文件名和文件内容（svn 不能很好的处理情况这种情况）
合并二：逻辑冲突
典型情况：④一个用户修改一个文件的文件名，而另外的用户在其他文件中引用旧的文件名。⑤一个用户修改了函数返回值而另外的用户使用旧的函数返回值。解决方案：每个开发人员都为自己的代码编写可运行的单元测试，项目每次编译时都要执行自动化测试，捕捉潜藏的bug。
合并三：冲突解决
⑥两个用户修改了同一文件的同一区域
解决方案：用户协商后手动改
合并四：树冲突
⑦一个用户将某个文件改名，另一个用户将同样的文件改为另外的名字。这种因为文件名修改造成的冲突，称为树冲突。
解决方案：用户协商后手动改
场景1：本地分支之间的合并：master上新开分支one，然后分别在master、one上面做了一些提交操作，现在需要将one分支上的修改合并到master分支。在git中，merge是把两个分支最新的快照和二者最新的共同祖先进行三方合并，产生一个新的提交对象。
先切换到master分支上，Merge，选择one分支进行合并。
Merge时有2个选项，Commit或Squash，根据情况选择使用哪种情况的merge。
Squash选项的含义是：本地文件内容与不使用该选项的合并结果相同，但是不提交、不移动HEAD，因此需要一条额外的commit命令。其效果相当于将one分支上的多个commit合并成一个，放在当前master分支上，原来的commit历史则没有拿过来。判断是否使用squash选项最根本的标准是，待合并分支上的历史是否有意义。如果在one分支上提交非常随意，那么一定要使用--squash选项。版本历史记录的应该是代码的发展，而不是开发者在编码时的活动。这样一来，用户可以户自行提交，提交的时候可以写上一些正式的commit log。只有在one分支上每个commit都有其独自存在的意义，并且能够编译通过的情况下（能够通过测试就更完美了），才应该选择缺省的合并方式来保留commit历史。
如果没有出现冲突，则会出现“Fast-forward”或者"Merged"的提示，代表合并完成。
或者
如果出现“Conflicting”的提示，则说明有冲突（如下图的sys.js文件，可以看到，红色的冲突标记），可以用merge tools查看，如下图：
合并模式：第一项是将GIT自动合并过的文件和服务器端文件进行对比，第二项是用本地最新版本的文件和服务器端文件进行对比，建议用此项
用户手动修改，修改完后，Team>add to index（表示你解决了这个冲突），Team>commit（commit信息会自动带上合并冲突说明的），这才算是合并完毕。
一旦加入暂存区，就表示解决了冲突，可以进行提交操作了。
如果出现“Failed”的提示，可能是有一些未提交的文件在干扰。
场景2：本地仓库的master分支与svrdev服务器的master分支的合并。
步骤：
1.执行合并操作时，检查一下当前的分支，如master分支，最好保持一个清洁的工作区域（即改动的结果全部commit），否则可能会出现不必要的麻烦，如本地未提交的改动有可能会被冲掉，导致你修改的代码丢失。有未提交修改的情况下，不要执行可能会冲突的操作！
2.eclipse>Team>Merge，如下图，表示把origin/master分支合并到Local下的master分支
3.其余部分操作同场景1
操作入口：eclipse>Team>Rebase
注意事项：rebase操作会改变提交的历史记录，所以，永远不要衍合那些已经推送到公共仓库的更新，会给别人造成麻烦。在衍合的时候，实际上抛弃了一些现存的 commit 而创造了一些类似但不同的新 commit。如果把rebase当成一种在推送前清理提交历史的手段，并且rebase那些不准备推送到公共仓库的commit，那么，是不会有问题的。
场景：在本地的master上进行了几次修改操作，svrdev服务器的master分支也有几次新的提交。那么，在切换到本地master上，然后eclipse>Team>Rebase，选择远程仓库的master分支进行衍合。形成的效果看起来像是在人家都改完后，再把自己的修改提交上去。
选择想要衍合进去的分支
合并时如果没有问题，会给予如下提示
如果出现冲突，会给予类似下面的提示
出现冲突时，Action to perform(要执行的操作)有四个选项：
Next steps里面描述的也很明确，当你解决了冲突，可以选择Rebase>Continue（继续合并）或Rebase>Abort（终止合并）
出现冲突一般是要解决的，选择第1项，然后使用Team>Merge Tool视图查看有哪些文件是冲突的，冲突的文件改好后，点击Team>add to index。
【注意，Team>add to index之后不需要点Team>Commit。rebase操作会自动完成对冲突解决的提交，并对分支中其他提交继续执行rebase操作】
Team>add to index后，Team>Rebase>Continue Rebase，继续进行下一个合并操作。如下图：
如果有多个冲突的，就重复上面的做法，最后，出现下图，代表rebase成功了。
简单来说，merge和rebase操作从最终效果来看没有任何区别，都是将不同分支的代码融合在一起，但是使用的原理和生成的历史线图不一样。
| merge合并 | rebase衍合 | |
|---|---|---|
| 原理 | 把两个分支最新的快照和二者最新的共同祖先进行三方合并，产生一个新的提交对象。简单来讲就是把把大家的修改综合下，形成一个新的提交对象。 | 先找到两个分支（你所在的分支和你想要衍合进去的分支）的共同祖先，提取你所在分支每次提交时产生的差异（diff），把这些差异分别保存到临时文件里，然后从当前分支转换到你需要衍合入的分支，依序应用每一个差异补丁文件。效果看起来是在人家都改完后，再把自己的修改提交上去。 |
| 日志 | 生成的log是多条线汇合在一起 | 生成的log是一条线 |
| 图 |
一开始，master分支有2次提交，C1和C2。local/master上进行工作，进行了2次提交，C5和C6。与此同时，remote/master分支上产生了新提交C3和C4。使用merge，将remote/master分支上C3和C4的改动合并到local/master上，这时，local/master上会形成一个新的提交C7。 C3是9点提交，C5是10点提交，C4是11点提交，C6是12点提交。形成的commit顺序是C7-C6-C4-C5-C3-C2-C1。 |
一开始，master分支有2次提交，C1和C2。local/master上进行工作，基于C2进行了2次提交，C5和C6。与此同时，remote/master分支上产生了新提交C3和C4。在local/master上rebase衍合remote/master分支，发生了如下变化： ①local/master上的C5和C6会被取消掉，这2次的改动会保存在临时文件里面； ②local/master分支会转换到remote/master分支，此时，local/master和remote/master都指向C4； ③新的C5‘和C6‘（C6‘提交只是C6提交的克隆，C5‘提交只是C5提交的克隆）被嫁接到C4上，将发生的改动重演一遍，于是local/master上成了一条线的改动效果。 C3是9点提交，C5是10点提交，C4是11点提交，C6是12点提交。形成的commit顺序是C7-C6‘-C5’-C4-C3-C2-C1。旧的提交C5和C6过一段时间会被丢弃。因为git有一个gc命令（该命令用来压缩历史信息,以节约磁盘空间），它会把一些废弃的提交丢弃掉。 |
| conflict | 出现冲突时，只需解决一次 |
出现冲突，可能需要解决多次 如果修改比较多，预期conflict比较多时，建议merge；如果修改比较少，预期不太会有conflict出现，那么，用rebase。 |
git cherry-pick，其含义是从众多的提交中挑选出一个提交应用在当前的工作分支中。该命令需要提供一个commit id作为参数，操作过程相当于将该提交导出作为补丁文件，然后在当前HEAD上重放，形成无论内容还是提交说明都是一致的提交。
Gliffy 
Edit 
Zoom 
Zoom A - B - C - D one
/
D - E - F - G - C‘ master
把one分支上C提交应用在master分支上，形成C‘
1 切换到one分支，Team>Show in History，找到C的commit，右键，Open in Commit View
2 切换到master分支
3 在C的提交视图中，选择Cherry Pick的图标
4 弹出对话框，形如“ Are you sure want to cherry pick commit ‘XXX‘ onto branch ‘master‘? ” 确认提交应用无误后，选择OK
5 如果顺利，就会正常提交；如果在cherry-pick的过程中出现了冲突，就跟普通的冲突一样，手工解决，然后add把改动添加到索引中，最后执行commit提交
情景：svrdev服务器上有git的仓库testing，开发人员user1需要将该仓库代码下载到本机172.21.1.6
方法一：克隆testing库并导入eclipse中
eclipse>File>Import>Git>Projects from Git>URI，在弹出的对话框中输入URI，形如ssh://git@svrdev/testing
方法二：克隆testing库
eclipse>Git Repositories视图 
根据情况选择，一般是选择中间那个选项，Clone a Git Repository and add the clone to this view，输入连接 ssh://git@svrdev/testing
这个只是做了一个clone的操作，还没有将testing导入到eclipse中。你需要eclipse>File>Import>Git>Projects from Git>Local，选择testing
eclipse>Team>Remote>Push
例如，把本地master分支的内容推送到origin仓库中的master分支上，如下图
操作入口：eclipse>Team>pull
如果报错“The current branch is not configured for pull. No value for key branch.master.merge found in configuration”，请自行配置一下执行pull时的参数，比如本地master分支pull远程origin/master分支时，应该有如下配置（Git Repositories视图中右键master分支，选择Configure Branch）
可以看到，默认情况下，pull = fetch + merge。从远程origin/master分支获取最新版本并merge到本地master分支。形成非线性的log记录。
如果勾选了下面rebase选项，则是执行 fetch + rebase。从远程origin/master分支获取最新版本并rebase到本地master分支。形成线性的log记录。
crtl+H , Git Search ，方便我们进行搜索工作，比如搜索某个人的提交日志之类的
Egit操作指南参考：http://wiki.eclipse.org/EGit/User_Guide
标签：style blog http color 使用 strong
原文地址：http://www.cnblogs.com/cdr-cool/p/3845370.html
