Github在eclipse上的插件egit官方使用指南
例如:It /用户指南
入门
概观
如果您通常不熟悉Git或分布式版本控制系统,那么您可能首先需要阅读 Git for Eclipse用户 。更多的背景和细节可以在Pro Git的在线图书中找到 。
如果您来自CVS,那么您可以找到适用于Git Platform-releng / Git Workflows的常用CVS工作 流程。
基础教程:将项目添加到版本控制
组态
识别你自己
无论何时更改存储库的历史记录(技术上,每当创建提交时),Git都会跟踪创建该提交的用户。身份证包含一个姓名(通常是一个人的姓名)和一个电子邮件地址。这些信息存储在~/.gitconfig
专用**下的文件中 。
EGit会在您创建第一次提交时询问您的信息。默认情况下,这个对话框只显示一次,直到你创建一个新的工作区或在Git首选项页面勾选“显示初始配置对话框”复选框:
如果您想稍后再查看,也可以取消选中“不要再次显示此对话框”。
您可以随时使用Git配置更改此信息,而不是使用此对话框:
- 点击 首选项>团队> Git>配置
-
单击 新建条目 并输入键值对
user.email
和user.name
在Windows上设置主目录
将环境变量添加 HOME
到您的环境变量中。
- 在Windows 7中,在开始菜单中输入“environment”
- 选择“编辑您的帐户的环境变量”
- 点击“新建”按钮。
- 在名称字段中输入“HOME”
- 在值字段中输入“%USERPROFILE%”或其他路径。
-
单击确定,然后再次确定。您刚刚在Windows上添加了主目录。
EGit需要这个路径来查找用户配置(.gitconfig)。 HOME
应该指向你的主目录,例如 C:\Users\Tom
。 确保正确的情况! 例如, C:\users
而不是 C:\Users
可能会导致问题!
如果 HOME
变量未定义,则主目录将通过连接HOMEDRIVE
和 来计算 HOMEPATH
。
如果两个 HOME
和 HOMEDRIVE
没有定义 HOMESHARE
将被使用。
如果HOME
未明确定义,EGit会显示警告 。请记住,如果您在Eclipse运行时设置HOME环境变量,则仍会看到以下警告。您必须重新启动Eclipse才能识别HOME值。
指出系统范围的配置
如果您使用Git for Windows作为EGit的伴侣,请确保EGit知道Git的安装位置,以便找到“系统范围设置”,例如core.autocrlf的设置。转到设置并查看Team> Git> Configuration,然后点击System Settings标签。
如果您在安装Git for Windows时从命令行提示中选择了其中一个选项来使用Git,则系统范围设置的位置将填充一个路径,并且一切正常。如果没有,使用浏览按钮找到Git的安装位置,例如C:\ Program Files(x86)\ Git。
此建议也适用于其他Git包装的用户,例如Cygwin或TortoiseGit下的Git。
非Windows用户理论上应检查此设置,但系统范围设置通常不在非Windows平台上使用。
创建存储库
-
创建一个新的Java项目
HelloWorld
。(在这种情况下,该项目是在Eclipse Workspace之外构建的。)
- 选择该项目,然后单击 文件>团队>共享项目
- 选择存储库类型 Git 并单击 下一步
-
要配置Git存储库,请选择新项目
HelloWorld
-
点击 Create Repository 为项目初始化一个新的Git仓库
HelloWorld
。如果您的项目已经驻留在现有Git存储库的工作树中,则会自动选择该存储库。
- 单击 完成 关闭向导。
-
项目后面的装饰器文本“[master]”显示该项目在主 分支上的存储库中被跟踪, 并且问号装饰器显示
.classpath
and.project
和.settings
文件尚未受版本控制
跟踪变化
- 在项目节点上单击 团队>添加。(这个菜单项可能会读取 最近版本的Egit的Add to Index)
- 在 + 装饰显示,目前该项目的文件添加到版本控制
-
将“bin”文件夹标记为“Git忽略”,方法是右键单击 该文件 夹并选择 Team> Ignore或通过
.gitignore
在项目文件夹中创建 具有以下内容的文件
/箱
-
这
bin
将从Git的被跟踪文件列表中排除该 文件夹。 -
添加
.gitignore
到版本控制(团队>添加):
-
您可能必须设置包资源管理器筛选器才能看到包资源管理器中
.gitignore
显示的内容。要访问过滤器,请选择Package Explorer选项卡右侧的向下箭头以显示View Menu。
-
从视图菜单中选择 Filters ...,将出现Java Element Filters对话框。取消选择顶部条目以显示以开头的文件。(期)如
.gitignore
。
- 在项目上下文菜单中单击 团队>提交
-
输入提交消息来解释您的更改,第一行(后跟一个空行)将成为此提交的简短日志。默认情况下,作者和提交者来自
.gitconfig
主目录中的 文件。 - 您可以点击 Add Signed-off-by 添加 Signed-off-by: 标签。
- 如果您正在提交其他作者的更改,则可以更改作者字段以提供作者的姓名和电子邮件地址。
- 点击 确认 提交您的第一个更改。
- 请注意,提交文件的修饰器已更改。
检查历史
- 从上下文菜单中单击 团队>历史显示以检查资源的历史记录
-
创建一个新的Java类
Hello.java
并实现它 - 将它添加到版本控制并提交您的更改
- 改进你的实现并提交改进的类
- 现在资源历史记录应该显示2个提交此类的提交
- 点击 历史视图中的 比较模式切换按钮
-
双击
src/Hello.java
历史视图的资源列表以在比较视图中打开上次提交的更改
恭喜,您刚刚掌握了使用Git的第一个项目!
GitHub教程
创建本地存储库
- 按照 EGit / User Guide / Getting Started 创建一个新的本地存储库(使用您的内容而不是演示项目)
在GitHub创建存储库
- 在GitHub上创建一个新的存储库
在下一个屏幕上,您可以看到您可能用来访问新的新存储库的URL:
- 单击 SSH 以选择 SSH协议。它可以用于读写访问
- 点击 HTTP 选择 HTTP协议。它也可以用于读写访问。
- 点击 Git Read-Only 来选择 用于克隆的匿名 git协议。这是git支持的最有效的协议。由于 git协议 不支持身份验证,因此通常用于提供对公共存储库的有效只读访问。
Eclipse SSH配置
- 打开Eclipse 首选项 并确保您的SSH2主页配置正确(通常是 〜/ .ssh)并包含您的SSH2**
- 如果您还没有SSH**,您可以在第二个对话框的Key Management (**管理)对话框中生成它们 ,请使用一个好的密码短语来保护您的私钥,更多详细信息请参阅 “使用**密码短语”
- 将您的公共SSH**上传到您的 GitHub帐户设置
推上游
- 点击 团队>远程>推送... 并复制并粘贴新的GitHub存储库的SSH URL
- 如果您位于不允许SSH通信的防火墙后面,请改用GitHub HTTPS URL,并提供您的GitHub用户和密码,而不要使用上传的公用SSH**。要将您的凭证存储在Eclipse安全商店中,请点击 安全商店中的商店。
- 注意: 许多HTTP代理被配置为阻止包含用户名的HTTP URL,因为在HTTP URL中公开用户名被认为是安全风险。在这种情况下,请从HTTP URL中删除用户名,并仅在用户字段中提供该用户名。它将作为HTTP标头发送。
- 点击 下一步 ,在第一个连接上接受GitHub的主机**。
- 输入您的SSH**的密码,然后单击 确定。
- 在下一个向导页面上,单击 添加所有分支规范 以将本地分支名称1:1映射到目标存储库中相同的分支名称。
- 点击 下一步。推送确认对话框将显示将推送到目标存储库的更改的预览。
- 单击 完成 确认您要推送这些更改。
- 下一个对话框报告推送操作的结果。
- 将您的浏览器指向您的GitHub存储库以查看您的新存储库内容已经到达
EclipseCon 2012 Git教程
在这里找到所有练习和幻灯片 。
按照 练习#1 准备Git教程。
概念
Git建立在一些简单而强大的想法之上。了解它们有助于更轻松地了解git如何工作。
知识库
存储库或对象数据库存储构成项目历史的所有对象。此数据库中的所有对象都通过 对象内容的安全20字节SHA-1散列标识 。这有几个好处:
- 比较两个对象归结为比较两个SHA-1哈希值
- 由于对象名称是在每个git存储库中以相同的方式从对象内容中计算出来的,所以相同的对象将以相同的名称存储在恰好包含此对象的所有存储库中
- 一旦创建对象就不会改变(显而易见,因为改变内容意味着必须计算新的散列并分配新名称)
- 通过检查SHA-1对象名称是否仍然是对象内容的安全散列,可以轻松检测到存储库损坏
Git有四种对象类型:
- 一个 Blob对象 存储文件内容
- 一个 树对象 存储的目录结构和包含 的Blob对象 和其他 树对象 与自己的文件系统名称和模式一起
- 甲 提交对象 表示的目录结构的快照的提交时间,并具有连接到它的前身 提交对象,其形成在所述储存库历史库修订一个非循环图。
- 一个 标签对象 是一个符号命名的链接到包含对象名称和关于谁创造了标签和签名信息的一个被引用的对象和可选信息的类型另一个仓库对象。
对象数据库存储在 .git/objects
目录中。对象既可以作为松散对象存储,也可以以包格式存储,将多个对象有效地封装到一个文件中,以便高效地存储和传输对象。
相信
Git通过安全的SHA-1哈希提供了一个内置的信任链,它允许它验证从(可能不受信任的)源获得的对象是否正确并且自创建以来未被修改过。
如果您获得签名标签,例如您可以验证的项目版本,例如标签(例如项目负责人)的公共签名**git可确保信任链覆盖以下内容:
- 签名标签标识一个提交对象
- 提交对象恰好表示一个项目修订,包括其内容和历史记录
- 提交对象包含blob对象树和其他表示项目修订目录结构的树对象
- blob对象包含此项目修订的文件内容
可以使用SHA-1算法检查所有涉及的对象名称的一致性,以确保项目修订的正确性,并以此方式确保可以信任整个历史记录。
指数
在 GIT中索引 是存储在一个二进制文件 .git/index
包含文件名,文件模式的排序列表目录,文件用于有效地检测文件的修改和斑点对象的SHA-1的对象名称的元数据。
它具有以下重要属性:
- 该索引包含生成单个唯一定义的树对象所需的全部信息。例如,提交操作会生成此树,将其存储在对象数据库中并将其与提交相关联。
- 该索引可以快速比较其定义的树与当前工作目录。这是通过在索引数据中存储关于涉及文件的附加元数据来实现的。
- 索引可以高效地存储合并涉及的树之间的合并冲突信息,以便为每个路径名提供有关所涉及树的足够信息以启用三向合并。
分行
Git中的分支是对提交的命名引用。有两种类型的分支,即“本地”和“远程跟踪”分支,用于不同目的。
当地分支机构
无论何时提交对(本地)存储库的更改,都会创建一个新的提交对象。如果没有其他任何方式,要记录存储库中的更改非常困难,特别是当其他提交已添加到存储库时,例如由于远程存储库的更新或检出另一个提交时。
本地分支通过提供可以找到“当前”提交的(本地)名称来帮助完成此任务。当更改提交到本地存储库时,分支会自动更新为指向新创建的提交。
另外,可以将一个所谓的上游配置添加到本地分支,这在与远程存储库同步时会很有帮助。
远程追踪分支
从远程存储库进行克隆和提取时会自动创建远程跟踪分支。本地存储库中的远程跟踪分支总是对应于远程存储库中的(本地)分支,并且这样的分支的名称遵循特定的约定。
远程跟踪分支指向与远程存储库中对应分支相同的提交(在克隆/提取时)。
远程跟踪分支可用于自动创建本地分支的上游配置。
工作目录
工作目录是用于修改下一次提交的文件的目录。默认情况下,它位于.git目录的上一级。进行新的提交通常涉及以下步骤:
- 检出新提交应基于的分支,这将更改工作目录,以便它反映 分支的 HEAD修订。
- 在工作目录中进行修改
- 告诉git这些修改(添加修改后的文件)。这将修改后的文件内容传输到对象数据库中,并准备要在索引中提交的树。
- 将索引中准备的树提交到对象数据库中。
- 结果是一个新的提交对象, 当前分支的 HEAD移动到新的提交。
记录存储库中的更改
您从全新的本地存储库分支结帐开始。每当您想要记录更改的状态时,您都希望进行一些更改并在存储库中记录这些更改的快照。
工作目录中的每个文件都可以 跟踪 或不 跟踪。
- 跟踪的文件是最近一次快照中的文件或新近进入 索引的文件。它们可以是 未经修改, 修改或上演的。
- 未追踪的文件是不在最后一个快照中的所有其他文件,并且尚未添加到 索引中。
当您第一次克隆存储库时,工作目录中的所有文件都将被跟踪 并且 不会被 修改, 因为它们已被新签出,并且您尚未开始编辑它们。
当你编辑文件时,git会识别出自 上次提交以来修改过的文件,所以它们会被 修改。您 阶段 修改后的文件到索引,然后提交阶段性变化和周期重复。
这里说明这个生命周期
任务
创建存储库
在Eclipse中使用Git存储库的注意事项
短篇小说
使用EGit设置Git存储库时,有两个建议可用于创建“生产性”(而不是“操场”)存储库:
-
不要在Eclipse工作区内创建存储库
- 克隆或创建存储库时要小心
- 确保正确使用Git共享向导
-
不要以root身份创建Eclipse项目的Repository
- 确保正确使用Git共享向导
第一种情况是在克隆或创建存储库期间指定工作区文件夹时发生。
当您在工作区中手动创建的Eclipse项目中使用Git共享向导时,如果不采取预防措施(该向导已在最新版本中修复),上述两种情况都会发生。
下面你会发现这些建议的一些动机。
更长的故事
Eclipse工作区和存储库工作目录
可以通过不同的方式创建Git存储库,例如通过从现有存储库进行克隆,从头创建一个或使用EGit共享向导。
在任何情况下(除非你创建一个“裸”存储库,但这里没有讨论),新的存储库本质上是一个本地硬盘上的文件夹,它包含“工作目录”和元数据文件夹。元数据文件夹是一个名为“.git”的专用子文件夹,通常称为“.git-folder”。它包含实际的存储库(即提交,参考,日志等)。
元数据文件夹对于Git客户端是完全透明的,而工作目录用于将当前签出的存储库内容公开为工具和编辑器的文件。
通常,如果这些文件将在Eclipse中使用,则必须以某种方式将它们导入到Eclipse工作区中。为了做到这一点,最简单的方法是检入。“导入现有项目”向导可以从中轻松创建项目的项目文件。因此在大多数情况下,包含Eclipse项目的Repository结构看起来类似于这样的东西:
启示
以上含义如下:
- 将项目设置为Repository的根文件夹可能不是一个好主意
- 原因是你将永远无法将另一个项目添加到此存储库,因为.project文件将占据根文件夹; 您仍然可以将项目添加为子文件夹,但是这种项目嵌套已知会导致遍布各处的许多问题。为了添加另一个项目,您必须将项目移动到存储库中的子文件夹,并将第二个项目添加为另一个子文件夹,然后才能提交此更改。
- 将您的Repository放在Eclipse Workspace之外是一个好主意
- 有几个原因:
- 新的存储库将把Eclipse工作区的完整文件夹结构视为(潜在的)内容。这会导致性能问题,例如在提交前计算更改(例如,将扫描完整的.metadata文件夹); 通常情况下,工作空间将包含死文件夹(例如删除的项目),这些文件夹在语义上与EGit无关,但不能轻易排除。
- 元数据(.git-)文件夹将是Eclipse工作区的一个子元素。目前还不清楚这是否会导致Eclipse进行不需要的文件夹遍历。
- 通过销毁Eclipse工作区,您可以轻松销毁您的Repository
创建一个新的空的Git仓库
您可以先创建一个项目并在之后分享。共享项目向导支持创建Git存储库(请参阅 将项目添加到版本控制)。
您也可以从Git存储库视图创建一个新的空的Git存储库(请参阅 创建存储库)。
为多个项目创建一个Git存储库
您可以先在一个公共目录下创建多个项目,然后一次为所有项目创建一个公共存储库:
- 在共同目录下创建Eclipse项目,例如a,b,c例如 / repos / examples /
- 选择所有项目a,b,c - 从上下文菜单中单击 团队>共享项目> Git
- 按 下一步
- 选择所有项目a,b,c
- 该向导自动将默认存储库位置上移到父文件夹 / repos / examples /, 因为已选择多个项目
- 单击 创建存储库 并 完成
从现有的Git存储库开始
为了在Eclipse工作台中处理Git存储库的内容,必须将所包含的文件和文件夹作为项目导入。原则上,可以使用通用的“新建项目”或“导入...”向导来完成此导入,因为Git存储库的工作目录只是本地文件系统中的普通目录。但是,新创建的项目仍然必须与Git手动共享。“从Git导入项目”向导集成了项目导入和共享,并且还提供了一些额外的便利。
启动导入向导
要启动该向导,请单击 导入> Git> Git项目
如果您是在干净的工作区中开始的,则第一页将显示一个空列表:
在继续之前,您需要将一个或多个Git存储库添加到列表中。如果列表中已有存储库,则此步骤是可选的。
克隆或添加存储库
有两种方法可以将Git存储库添加到列表中:
- 克隆远程存储库
- 从本地文件系统添加一个现有的存储库
克隆存储库
如果您从远程存储库开始,则会使用第一个选项。克隆操作会将该存储库复制到本地文件系统。要启动克隆向导点击 克隆...。Cloning Remote Repositories中详细描述了克隆向导 。成功完成克隆操作后,新克隆的存储库会自动出现在列表中。
添加一个存储库
如果您的本地文件系统中已经有一个存储库,则第二个选项非常有用,例如,因为您之前已经克隆了它,您是从头开始创建它的,或者是从其他位置复制它的。点击 添加... ; 并在本地文件系统中选择一个目录。按 搜索 触发对此目录中包含的Git存储库的扫描。如果找到Git存储库,它们将被列出,您可以选择存储库来添加:
成功完成后,存储库列表应包含一些存储库:
从列表中选择一个存储库
您现在可以选择一个存储库并单击 下一步。在以下向导页面中,您将决定如何导入项目。
导入项目
此页面提供了一个带有单选按钮的组,允许您选择一个向导和一个目录树,该目录树可以选择允许您在工作目录中选择一个文件夹。
项目导入向导
导入现有项目
如果选择此单选按钮,向导将扫描本地文件系统中的 .project 文件并显示为导入而找到的项目。这是最舒适的解决方案,如果将.project 文件签入存储库,应该使用它 。
限制项目导入的范围
在这种情况下,底部的目录树处于活动状态。您可以 通过在此树中选择一个文件夹来限制.project文件的搜索 ,否则将扫描存储库的完整工作目录。在下一页中,将显示找到的项目列表(如果有的话)。这与通用导入现有项目 向导非常相似 ,但具有一些额外的过滤功能:
使用新建项目向导
选择此选项时,通用“新建项目”向导将打开。完成“新建项目”向导后,“从Git导入项目”向导将恢复并协助共享刚刚创建的项目。
在这种情况下,底部的目录树处于非活动状态,因为选择与“新建项目”向导无关。
导入为一般项目
当有没有这个选项可以帮助 的.project 可用的文件,也没有合适的“新建项目”向导适用于Git仓库的内容。如果选择,向导将生成一个 .project 文件并将该项目指向存储库工作目录的文件夹。结果是一个“总体项目”。
默认情况下,新生成的项目将指向Repository的工作目录。通过从底部目录树中选择一个文件夹,可以为该文件夹生成项目。
点击 Next 打开一个简单的对话框,输入新项目的名称和目录:
默认情况下,建议的项目名称与目录的名称相匹配。
使用远程存储库
克隆远程仓库
使用Git克隆向导,您可以使用不同的传输协议克隆远程存储库。
该向导可以从“从Git导入项目”向导启动,使用
导入...> Git> Git项目>下一步>克隆...
或者使用“ 克隆Git存储库” 工具栏按钮或视图菜单从“Git存储库视图”(在“ 管理存储库 ”中进行了介绍 ) 。
存储库选择
在向导的第一页上输入远程存储库的位置:
-
URI - 远程存储库的完整URI或文件系统上的路径。该字段会自动与其他字段同步。
请注意,您可以使用 本地文件... 按钮浏览本地目录,并且URI字段通过提供以前使用的值来提供内容帮助 - 主机 - 远程主机的名称,如果从文件系统克隆则为空。
- 存储库路径 - 远程存储库或文件系统的路径。
- 协议 - 下面描述的协议之一。
- 端口 - 端口号。
- 用户 - 用于认证的用户名。
- 密码 用于验证的密码。
- 存储在安全存储 中密码是否保存在Eclipse安全存储中。
支持以下协议:
- 文件 - 文件系统对存储库的访问。
- ftp - 文件传输协议
- git - 最高效的内置git协议(默认端口9418)。该协议不提供认证。通常用于对存储库进行匿名读取访问。
- http - 超文本传输协议 可以通过防火墙隧道传输。
- https - 超文本传输协议安全 可以通过防火墙隧道传输。
- sftp - SSH文件传输协议
- ssh - 通过安全shell(SSH) 协议的Git 。通常用于对存储库进行身份验证的写入访问。
注意: 如果您位于防火墙后面,则可能需要配置您的代理设置(首选项>常规>网络连接)。许多HTTP代理配置为阻止包含用户名(和/或密码)的URL,例如 http:// fred:[email protected]/egit.git, 因此建议使用 用户名和 密码 字段向导页面中,凭据将作为HTTP标头传输。
分支选择
在下一页选择哪些分支应从远程存储库中克隆:
如果您不确定您需要哪些分支,只需点击“全选”。
您可以通过使用列表上方的文本控件进行输入来按名称过滤分支。但是,请注意,已检查的分支将始终显示在列表中,即它们不会被过滤。
本地目的地
在下一页定义您想要在本地文件系统上存储存储库的位置并定义一些初始设置。
- 目录 - 将包含Git存储库的目录。如果它尚不存在,它将由向导创建。
- 初始分支 - 选择在哪里创建本地分支并初始签出。
- 远程名称 - 为远程存储库定义一个名称。默认值是“原点”。
可以在首选项Team> Git> Default Repository Folder中配置用于存储Git存储库的默认根路径
您可以按此 页面上的完成,或者 如果您正在使用 Gerrit Code Review 并且您想相应地配置您的存储库,请按 Next。
从特定位置克隆
EGit的Clone向导可以通过其他插件进行扩展,以便在托管git存储库的特定后端上搜索存储库。目前这种扩展可用于Github,很快将可用于Gerrit。对于您需要安装各自的Mylyn连接器。Gerrit Mylyn连接器扩展然后还将配置Gerrit工作的远程存储库。这也可以在Git存储库视图中完成或更改,请参阅 Gerrit配置。
当您安装了这样的扩展程序时,克隆向导打开并显示一个选择页面,您可以在该页面中选择要克隆的不同资源库源:
推送到其他仓库
推向上游
如果您正在使用具有所谓“ 上游配置 ” 的本地分支,则最便捷的推送方式依赖于此上游配置。
通常,本地分支机构是基于远程跟踪分支创建的。由于远程跟踪分支与远程关联,并且远程包含访问相应远程存储库所需的信息,因此可以在创建本地分支时自动创建此上游配置(请参阅 分支 以获取更多信息)。
从本地分支向上游推送时,推送不需要其他参数,因此可以在不显示基于存储的上游配置的另一个对话框的情况下执行。
为了推送上游,右键单击项目并选择 Team> Push to upstream 或右键单击存储库视图中的存储库,然后单击 推送到上游。Git Command Group也有一个可用的操作 。
然后在选择操作后立即执行推送。完成后,将显示一个确认对话框,显示有关推送的数据和/或错误消息的信息:
配置上游推送
可以使用确认对话框中的“Configure ...”(配置...)按钮(见上文)或通过右键单击项目并选择Team> Remote> Configure push to upstream ...来配置上游推送。
将显示一个配置对话框,用于配置推送URI和相应的分支映射(RefSpecs):
该对话框分为三个主要部分。在上部分中,显示了关于当前存储库和当前检出的分支的信息。外部组显示与当前分支关联的远程的推送配置(在我们的例子中,“组”文本中显示的“原点”)。
在这个特定的例子中,有一个警告消息,指出有几个分支使用名为“origin”的远程设备。这意味着推送配置中的更改将影响所有这些分支,而不仅仅是分支字段中显示的分支。
URI组包含两个控件,一个URI字段和一个Push URIs列表。如果列表为空,则URI字段中的URI将用于Push,如果至少有一个条目位于Push URIs列表中,则将使用列表中的URI。应该注意的是,如果Push URI列表为空,并且在此对话框中更改了URI,则新的URI也将用于Pull,因此在执行此操作时应小心。
RefMapping Group允许指定一个或多个RefSpecs(请参阅 Refspecs)推送。
“添加”将打开一个小向导,帮助创建RefSpecs。您也可以将剪贴板中的RefSpec粘贴到列表中。
点击“高级”控件将显示/隐藏“编辑(高级...)”按钮,允许更复杂的RefSpec编辑,类似于 下面的 推送向导。
下部按钮栏中的按钮允许您保存所做的更改并立即进行推送,保存更改而不提取,干运行(推送而不保存配置),恢复更改并取消。
直接推送
或者,您可以 在远程的推送规范上使用 直接推送支持。
推送向导
最强大(但也是最复杂的)方法是使用推送向导
团队>远程>推送...
推送URI
- 如果您已经在存储库视图中配置了推送规范,则也可以使用配置的远程存储库下的下拉列表在此处选择它 。 如果这个远程的Push Specification配置正确(即至少有一个URI和一个引用规范), Finish按钮将被启用。
- 否则,请单击 自定义URI 并输入要推送到的上游存储库的URI。
推参考规格
有关 更多解释,另请参阅 参考资料。
单击 Next
如果这是您第一次通过ssh连接到此存储库,则必须接受远程存储库的主机**
如果您的ssh**受密码保护(建议使用),您必须在此处输入密码
点击 添加所有分支规范
这是一种方便的方式,用于声明您想要将本地分支名称映射到要推送更改的上游存储库上的相同分支名称。
点击 添加所有标签规范 将本地标签1:1映射到您要推送到的存储库中的标签。
如果您想以不同的方式将本地分支映射到上游存储库中的分支,您可以按照以下方式定义更详细的映射规范
- 输入源和目的地ref或从下拉列表中选择已存在的分支
- 点击 添加规范
这会将新定义的映射转移到列表 规格中进行推送
其他常见推式规格:
- 根据你的昵称 joe,你可以将refs / heads / *映射 到 refs / heads / joe / *。如果多个用户想要在共同使用的公共存储库中的个人分支上发布他们的本地分支,这是非常有用的。
- 另一个通常的映射是将源头部头部映射到 目的地 头部/头部/头部。这意味着您想要将当前的HEAD (可能当前指向任何本地主题分支)映射 到上游主分支。
删除参考规格
要删除目的地信息库中的裁判选择从下拉列表中删除裁判 远程裁判删除 ,然后单击 添加规格。这将在推送 列表的规范中创建相应的条目 。或者,您可以键入要删除的参考文件的规格,也可以使用通配符。推送删除参考规格将删除目标存储库中的匹配Refs。
冲压推力参考规格
如果您添加多个冲突推式参考规格,它们将被标记为红色,通过删除或编辑冲突规格来解决此问题。也可以在列表规格中就地编辑规格
推确认
点击 下一步
这将打开“推送确认”对话框,显示预览哪些更改将被推送到目标存储库。如果这与您的期望不符,请单击“上 一步” 并相应地更正您的推式规格。
- 对于ref更新,要提交的提交范围将以<SHA1-from> .. <SHA1-to>格式显示, 例如 d97f5a2e..adfdbfd2 表示将推送d97f5a2e 和 adfdbfd2之间的所有提交 。
- 对于尚未存在于目标存储库[新分支] 或 [新标签]中的引用将 显示。
- 显示将被删除[删除]的参考 。
- 如果要确保在预览中看到的内容也是您推送这些更改时获得的内容,请选中仅在远程引用未在平均时间内更改的情况下 按下复选框。
- 选择 显示最终报告对话框,只有当它从这个确认报告不同 复选框,如果你只是想执行后推得到一个报告,如果结果从该预览不同。
推送结果报告
点击 完成
根据您选择的选项,显示推送结果报告对话框
在底部的框中显示来自远程服务器的推送确认消息。如果有任何错误,您可以在这里找到来自远程服务器的错误消息。要查看给定列表条目的消息,只需在列表中选择它。
点击 确定 关闭对话框。
从其他存储库获取
从上游获取
如果您正在使用具有所谓“ 上游配置 ” 的本地分支,则最方便的取回依赖于此上游配置。
本地分支通常基于远程跟踪分支创建。由于远程跟踪分支与远程关联,并且此远程程序包含访问远程存储库所需的信息,因此可以在创建本地分支时自动创建此上游配置(请参阅 分支 以获取更多信息)。
从上游获取时,此持久配置可用于自动提取,而无需在对话框中提供更多参数。
为了从上游获取数据,请单击 项目上游的团队>获取,或单击 存储库视图中存储库上的从上游获取。Git Command Group也有一个可用的操作 。
选择操作后,将立即执行提取。一旦完成,将显示一个确认对话框,显示有关获取数据和/或错误消息的信息:
配置上游获取
可以使用确认对话框中的“Configure ...”(配置...)按钮(参见上文)或通过单击项目上的 Team> Remote> Configure fetch from fetch ... 来配置上游获取。
将显示一个配置对话框,用于配置获取URI和分支映射(RefSpecs):
该对话框分为三个主要部分。在上部分中,显示了关于当前存储库和当前检出的分支的信息。外部组显示与当前分支关联的远程的抓取配置(在我们的例子中,组的文本中显示“起源”)。
URI字段可用于添加/更改提取URI。
RefMapping组允许指定一个或多个RefSpecs(请参阅 Refspecs)进行提取。
“添加”按钮将打开一个小向导,帮助创建RefSpecs。您也可以将剪贴板中的RefSpec粘贴到列表中。
点击“高级”控件将显示/隐藏“编辑(高级...)”按钮,允许更复杂的RefSpec编辑,类似于 获取向导。
下部按钮栏中的按钮允许您保存更改并立即执行提取,保存更改而不提取,干运行(取出而不保存配置),恢复更改并取消。
直接抓取
另一种获取方式是 在远程的获取规范上使用 直接获取支持。
抓取向导
最强大(但也是最复杂的)方法是使用抓取向导
团队>抓取...
- 如果您已经在存储库视图中配置了提取规范,则也可以使用配置的远程存储库下的下拉列表在此处选择它 。 如果这个远程的获取规范配置正确(即至少有一个URI和一个引用规范),则 完成按钮将被启用。
- 否则,请单击 自定义URI 并输入要从中提取更改的上游存储库的URI。
获取参考规格
有关 更多解释,另请参阅 参考资料。
单击 下一步
单击 添加所有分支规范
这是一种方便的方法,用于声明要将要从1:1提取更改的上游存储库中的分支名称映射到相同的本地分支名称。
- 单击编辑字段 Destination Ref ,并将路径段choose_remote_name替换 为要从中提取的上游存储库的符号名称。
- 您的存储库已克隆的存储库的默认远程名称是 origin。此远程的主设备默认从refs / heads / master映射 到 refs / remotes / origin / master。
- 如果您想另外追踪Joe本地仓库中的Joe仓库的分支机构,您可以将分支机构的仓库中的refs / heads / *映射 到以下跟踪分支 refs / remotes / joe / *。
- 如果您只允许快进更新,请取消选择 强制更新,如果您还想允许非快进更改,请选择此选项。
- 单击 强制更新所有参考 以在所有规格上设置强制更新选项
- 点击 删除所有规格 ,从列表规格中删除所有规格
- 点击 添加所有标签规格 ,将您想要从1:1获取的存储库中的标签标签映射到本地标签。
如果您想以不同的方式将上游存储库中的分支机构或标签映射到本地分支机构,则可以通过以下方式定义更详细的映射规范
- 输入源(在源代码库中引用)和目标引用(在本地存储库中跟踪分支或标记)或从下拉列表中选择已存在的分支
- 点击 添加规范
这会将新定义的映射传输到列表 提取规格
获取结果报告
点击 完成
显示提取结果对话框。
- 对于ref更新,已提取的提交范围将以<SHA1-from> .. <SHA1-to>格式显示, 例如 d97f5a2e..adfdbfd2表示 已提取d97f5a2e 和 adfdbfd2之间的所有提交 。
- 对于在本地存储库[新分支] 或 [新标签]之前不存在的参考资料 显示。
- 显示已被删除[删除]的参考文献 。
从上游分支拉动新变化
- 右键单击Package Explorer中的项目,然后选择 Team> Pull 或右键单击Git存储库视图中的存储库,然后选择 Pull从本地分支正在跟踪的上游分支中提取新更改。这也适用于从多个存储库中选择资源的情况。
- 无论何时创建基于远程跟踪分支的本地分支,EGit都可以配置跟踪关系,以便后续的提取将获取并合并或重新绑定(取决于此跟踪关系的配置)来自所跟踪的上游分支的更改; 详情请参阅分支。
EGit还不支持临时选择上游分支来提取。
可用的选择包括:
- 从外部eclipse 运行 git pull(但 要注意Windows)
- 如果您没有进行本地更改或想要放弃本地更改,请使用 团队>重置...
与Gerrit合作
如果您正在使用Gerrit(http://code.google.com/p/gerrit/),EGit允许您方便地向Gerrit服务器推送和从Gerrit服务器提取更改。
将更改推送到Gerrit Code Review Server
右键单击项目并选择 Team> Remote> Push to Gerrit ... 或右键单击存储库视图中的存储库节点,然后选择 Push to Gerrit ...
将出现一个对话框,让您选择或输入URI和分支名称:
- 在URI组合中,选择或输入指向您的Gerrit实例的URI; 该组合将被预填充当前存储库的任何远程中定义的所有URI; 另外你可以在这个字段中输入任何URI
- 在Gerrit分支字段中,输入要推送到的Gerrit分支的名称
该对话框还为Gerrit分支提供内容帮助。只需按下“Ctrl + Space”即可**此功能(请参阅在Gerrit分支字段附近悬停在小灯泡装饰器上时出现的工具提示)。将显示当前存储库的远程跟踪分支。请注意,此内容帮助已过滤,因此为了查看所有提案,您需要确保在请求内容帮助之前将Gerrit分支字段留空。
点击 完成后,当前签出的提交将被推送到指定的Gerrit分支。另外,当对话框稍后再次打开时,URI和Gerrit分支值将被记住并再次建议。
这允许在并行处理不同Gerrit分支时具有更大的灵活性(例如,频繁地在开发和修补之间切换)。
从Gerrit Code Review Server获取更改
右键单击项目并选择 团队>远程>从Gerrit获取... 或右键单击存储库视图中的存储库节点,然后选择从Gerrit获取...
会出现一个对话框,让您选择或输入URI和更改以及一些其他选项:
- 在URI组合中,选择或输入指向您的Gerrit实例的URI; 该组合将被预填充当前存储库的任何远程中定义的所有URI; 另外你可以在这个字段中输入任何URI
-
在更改字段中,您必须输入更改的完整名称; 您可以从Gerrit Web UI获取该值,使用下面描述的内容帮助,或者使用以下模式构建名称:
“refs / changes /”+(更改编号的后两位数字)+ / +(更改编号) + / +(修订版号) -
在“获取后执行的动作”中,您可以决定在获取更改后要执行的操作; 您可以创建并签出指向更改的分支,创建并签出指向更改的标签,或者只需签出更改(从而使HEAD分离); 最后一个选项在获取后不做任何处理,但是您可以在FETCH_HEAD中找到与更改有关的提交(转至存储库视图并在存储库的引用节点下找到FETCH_HEAD,请参阅 检查引用 )。
分支或标签的名称由对话框建议,但可根据需要进行覆盖。
由于EGIT目前不支持删除标签,因此我们建议暂时使用本地分支而不是标签。由于存储库视图允许使用“/”作为层次结构分隔符对分支进行分层分组,因此建议的名称在处理大量更改时可能非常方便。
除了繁琐的复制粘贴或手动输入更改ID之外,该对话框还提供了有关更改的内容帮助。只需按下“Ctrl + Space”即可**此功能(请参阅将鼠标悬停在“更改”字段旁边的小灯泡修饰器上时出现的工具提示)。Gerrit服务器将被联系,所有可用的更改将被提取并显示在内容辅助对话框中:
该列表将在更改字段中用您的输入进行过滤。选择内容帮助中的更改后,“更改”字段将填充正确的信息。
检查Repository的状态
标签装饰
标签装饰将显示Git版本控制下的Git特定信息。它们出现在显示模型对象的所有视图中,如包资源管理器,项目资源管理器,导航器,层次结构视图。
Git标签装饰可以在General> Appearance> Label Decorations下的Preference Menu(Window> Preferences)中 全局打开。
更详细的设置可以在Team> Git> Label Decorations下的首选项中完成 。
有两种不同类型的标签装饰:文字装饰和图标装饰。
文本装饰
文字装饰出现在文字标签的左侧或右侧。它们可以在选项对话框 的文字装饰标签上的 Team> Git> Label Decorations下进行配置 。例如,肮脏资源的默认值是a > ,位于其名称的左侧。
这些是默认设置:
对于文件和文件夹,有变量 “名称”, “脏” 和 “上演”。 “肮脏” 和 “上演” 是旗帜; 如果它们为真,则显示冒号后面的文本。
对于项目,还有额外的变量 “存储库” 和 “分支”。在 “库” 变量显示存储库的名称。
在 “分支” 变量显示当前签出分支的名称。如果未检出分支,装饰将显示提交的缩写名称(前七个字符,后跟省略号)。如果标签和/或远程分支指向此提交,则应用“最佳猜测”启发式也会显示以下信息:标签优先于远程分支,如果应用了多个标签,则会显示最新标签; 如果有多个远程分支或标签没有修改日期,则应用字母排序,并显示最后一个。例如:签出的承诺e49f576 ... 是指标签 v.0.7.1 库的 例如:It:
图标装饰
图标装饰出现在标签前面显示的图标的右下角。他们可以在选项对话框中 的图标装饰上的 Team> Git> Label Decorations下进行配置。
这些是默认装饰:
- 脏(文件夹) - 文件夹下至少有一个文件脏了; 这意味着它在工作树中的变化既不在索引中也不在存储库中。
- 跟踪 - 资源是Git知识库,因此在版本控制下。
- 未跟踪 - 资源未被Git存储库所知,并且在明确添加之前不会受版本控制。
- 忽略 - 资源被Git团队提供者忽略。团队>忽略资源下的首选项设置 ,.gitignore 文件中的“派生”标志和设置都会 被考虑在内。
- 脏 - 资源在工作树中发生更改,既不在索引中,也不在存储库中。
- staged - 资源已经添加到索引中的更改。请注意,只能在提交对话框中通过资源的上下文菜单添加对索引的更改。
- 部分阶段化 - 资源包含已添加到索引中的更改以及工作树中既没有到达索引也没有提交到存储库的其他更改。请参阅 Git Staging视图中的部分分段 以了解如何执行此操作。
- 添加 - 资源尚未达到存储库中的任何提交,但已被新添加到Git存储库以便将来进行跟踪。
- 已删除 - 资源将从Git存储库中移除。
- 冲突 - 文件存在合并冲突。
- 假定有效 - 资源具有“假定不变”标志。这意味着Git会停止检查工作树文件以进行可能的修改,所以当您更改工作树文件时,您需要手动取消设置该位以告诉Git。另请参阅 假设不变的操作。
提交对话框
提交对话框中显示所有修改的跟踪文件的状态摘要。通过双击文件,要提交的更改将显示在比较对话框中。由于EGit当前总是提交工作树的内容(对应于命令行中的git commit -a),比较对话框将比较工作树和上次提交。
比较内容
在日常工作中,您经常希望看到上次提交,索引和当前工作树之间的更改。为此,请在项目资源管理器或导航器中选择资源(项目,文件夹或文件),然后右键单击“ 比较”下的操作 。
要分析特定提交的内容,应该使用 支持此任务的 历史视图更好,请参阅检查提交任务 。
比较编辑器和Git树比较视图
如果您 在单个文件中使用Compare With的任何子菜单操作, 将显示一个比较编辑器,否则 将打开Git树比较视图以浏览更改; 通过在该视图中双击已更改的文件,将为该文件打开一个比较编辑器。子菜单操作“ 历史记录... ”例外 ,它将打开“历史记录视图”。
将工作树与上次提交进行比较
当前工作目录中的资源和当前分支中上次提交的资源之间的差异可以从上下文菜单Compare With> HEAD revision中查看。此功能也可在提交对话框中找到。在提交对话框中双击一个条目将打开一个比较对话框。
比较工作树和索引
当前工作树和索引(基于当前选定的资源)之间的差异可以从上下文菜单Compare With> Git Index查看。
将工作树与分支,标记或引用进行比较
- 选择一个资源
- 右键单击 Compare With> Branch,Tag或Reference ...
- 选择一个分支,标记或引用
比较工作树和任何提交
从项目浏览器:
- 选择一个资源
- 右键单击 Compare With> Commit ...
- 从提交图中选择一个提交
从历史视图(仅限文件):
- 在包资源管理器中选择一个文件
- 右键单击 Team> History in History 或 Compare With> History ...
- 在提交图中选择一个提交
- 从上下文菜单中选择 与工作树进行比较
- 这将打开一个比较对话框,显示所选提交和当前工作树之间的变化
比较两个承诺
- 在Package Explorer中选择一个资源
- 单击“ 团队”>“在历史记录中显示” 或“ 与历史记录比较...” (后者仅用于文件)
- 在提交图中选择两个提交
- 右键单击“相互 比较”
- 这将打开一个比较对话框,显示两个选定提交之间的变化
- 您也可以通过右键单击树中的“彼此比较”来打开“Git树比较”视图
比较索引与HEAD或任何其他提交
该功能尚未实现。
与分支(同步)比较
工作树(包括未提交的更改)与分支或标记之间的区别可以通过单击项目上的动态菜单 Team> Synchronize 并选择 要同步工作树的 Ref来查看。如果Git存储库包含多个Eclipse项目,则只需选择一个项目即可, 同步视图 也将包含所有其他项目。
如果你想在动态菜单中点击未列出的参考同步 团队>同步>其他...。然后在“同步向导”中单击要同步的存储库的目标列,然后选择要与之比较的Ref。
点击“包括本地未提交的比较变更”也是本地的,尚未分阶段的变更和已经分阶段的变更将显示在比较中。
也可以一次比较多个存储库。在这种情况下,在同步向导中,为每个存储库选择要与之比较的参考。
Quickdiff
不使用比较编辑器,您可以启用快速差异支持并查看文本编辑器中的更改。
此功能可通过常规>编辑器>文本编辑器>快速差异 首选项页面启用 :
然后差异注释将显示在编辑器的左侧:
如果将鼠标移动到注释上,则会看到您正在比较的版本的内容:
默认情况下,比较是针对HEAD的。您可以从历史视图中的提交的上下文菜单(Show in> History)中确定您正在比较的版本,即所谓的quickdiff基准。有三个菜单条目:
- 快速差异 - >将基线重置为HEAD的第一个父级 - 与HEAD之前的第一个提交进行比较。
- 快速差异 - >将基线重置为HEAD - 与HEAD进行比较。
- 快速差异 - >设置为基线 - 与所选提交进行比较
检查提交
检查给定的提交
- 从Package Explorer中的上下文菜单中选择 Team> Show in History
- 选择你想要检查的提交
查看提交的差异
历史视图在左下方的窗格中显示diff。选择右下方窗格中的文件会滚动到diff的相应文件部分。
显示提交的内容
双击右下方窗格中文件的行为取决于比较模式切换按钮的状态。如果它打开,将打开一个比较编辑器,它将当前提交中的文件内容与祖先提交中的内容进行比较; 如果关闭,将会打开一个编辑器,显示当前提交中的文件内容。
提交更改
git版本控制下的项目修改通过提交保存在git历史记录中。从从git存储库检出的状态开始,修改您的项目,直到您达到您满意的状态,然后将所有这些更改作为单个提交提交到存储库中。每次提交都代表存储库中存储的所有文件的定义良好的快照。
修改内容
修改已经与Git共享的项目在Eclipse中或直接在文件系统中修改或删除文件。没有必要提前告诉Git这些操作。应该受版本控制的新文件必须明确置于Git版本控制之下:
- 在文件的上下文菜单中单击 Team> Add
或者,您可以在提交对话框中显示未跟踪的文件,并选中 显示未跟踪文件 复选框以选择它们以包含在提交中。
标签装饰器例如在Package Explorer View中显示
- 尚未在git版本控制下的未跟踪文件(标有“?”)
- 已添加的文件(标有“+”)
- 修改过的文件(在文件名前用“>”标记)
有关详情,请参阅 标签装饰。
以下是包资源管理器中的一个示例
- 一个承诺的文件
- 在工作树中修改但尚未为下一次提交分配的文件
- 一个修改过的文件,已经为下一次提交进行了修改
- 一个已经新下载的文件,用于下一次提交
- 一个不在git版本控制下的文件
提交
要提交更改,请单击 项目中资源的上下文菜单中的Team> Commit ...。
Git跟踪对整个存储库进行的所有更改,以捕获该存储库中所有版本控制文件的修改,而不考虑这些文件是否驻留在同一个Eclipse项目中。
一旦你触发了提交, 提交对话框 就会弹出
选择要提交的更改,输入提交消息并创建提交, 在提交消息文本字段中按 Ctrl + Enter (Mac OS X上的Command + Enter),或单击 提交。
提交消息
在“提交”对话框中,指定描述更改的提交消息。
用短的第一行开始消息是一个好习惯,总结变化,然后是空白行,然后是消息正文。为了确保git命令行工具可以很好地格式化这些消息,行不应格式化得太宽(用灰色垂直线表示)。
Eclipse拼写检查器检查提交消息文本是否有错误。拼写检查器可以通过Eclipse Preferences> General> Editors> Text Editors> Spelling进行配置。按 Ctrl + 1 打开快速修复,这可能有助于修复拼写错误。
提交消息编辑器支持提交对话框的文件部分中显示的文件名的内容帮助,可以按Ctrl-Space**该文件部分。
页脚标签
在提交消息的最后一段中,可选的页脚标签可以如下所示:
错误:3176 更改ID:I267b97ecccb5251cec54cec90207e075ab50503e 报道者:Joe Developer <[email protected]> 签名:William Shakespeare <[email protected]>
这些标签的语义是项目或工具特定的
- 如果在错误跟踪系统中有条目要求提交更改,则最好在此将其添加为错误标记
- Gerrit Code Review 使用 Change-Id: footer将审核过程中发生变化的不同补丁集与最终接受的补丁相关联。要生成Gerrit Change-Id,请点击 Gerrit Code Review的Compute Change-Id ; 该ID将在提交时生成,直到此时空的Change-Id显示为占位符。如果将egit配置参数 gerrit.createchangeid 设置为true,则始终预先选择“提交”对话框中的相应复选框。此参数可以在存储库级别,系统级别或用户级别上进行设置。有关 更多信息,请参阅存储库配置。
- 在 参团的off-by: 页脚被许多项目来创建签名笔者贡献下,该项目的许可和知识产权规则的改变声明的正式记录。通过这种方式,可以在技术层面捕获项目不断发展的代码库的知识产权出处。请参阅 Linux内核项目使用的 开发人员证书源代码。如果偏好例如:It 插入签名断,通过 在 团队>的Git>提交对话框 设置相应的复选框在提交对话框总是会预先选定。
此外,此对话框控制将在提交中包含哪些更改。如果清除文件前面的复选框,则对该文件的更改将不会包含在提交中。您的eclipse工作区中的本地文件仍将包含修改,使您有机会使用后续提交来提交这些更改。此功能通常用于将对一组文件所做的修改分离为不同的提交。
一个例子: 想象一下,自从上次提交以来,您已经修复了A.java中的一个错误,并且您已经为B.java添加了一个新方法。这两个修改在逻辑上相互独立,因此您可能希望在两个独立的提交中提交它们。在这种情况下,您启动提交,从提交的文件集中取消选择B.java,并指定仅描述A.java中的错误修正的提交消息。在成功完成第一次提交后,您只需再次调用commit,即将出现的对话框将向您展示B.java中的其余更改。现在您指定一个提交消息来描述添加方法并完成第二次提交。
如果选中“显示未跟踪文件”复选框,则在提交对话框中将列出添加到项目中尚未明确添加到版本控制中的新文件(请参阅“修改内容”)。如果您选中列表中这些文件前面的复选框,则会将其添加到存储库并在您按下提交按钮后进行提交。团队忽略列表或 .gitignore 文件或衍生的文件(例如,java项目中的bin文件夹)将不会显示在此处。如果您的存储库中没有其他更改比未跟踪文件更多 ,默认情况下会选中Show untracks Files复选框 。
修改提交
如果您在提交更改时意识到错过了某些内容,则可以解决此问题:再次打开提交对话框并指定当前提交将“修改”当前分支中的上一个提交。新的提交将会取代之前的提交。此功能通常用于在发布到其他存储库之前纠正不正确的提交。
注意: 如果它们已经发布到共享存储库,则不要修改提交,因为如果它们已经根据已发布的更改进行了修改,则可能会打扰其他提交。
修改示例:
想象一下,您对包含错字的文件进行了更改
提交更改后,您会发现一个错字。为了纠正这个错字和相应的提交,您只需修复源文件中的错字
然后再次打开提交对话框并选择选项 修改上一个提交。
您之前提交(您想要替换的提交)的提交消息被填充到“提交消息”字段中。这不仅可以更正版本控制文件内容中的错误,还可以更正描述更改的提交消息中的错误(例如,拼写错误)。
作为修改的替代方法,您可以将更正后的版本作为后续提交提交。但是第一个包含错字的提交对任何人都没有用,为了不用不必要的提交来混淆项目的历史,你应该修改提交。
请注意,修改已发布到其他存储库的提交可能会造成麻烦。一旦将提交推送到远程存储库或您的本地存储库被其他人克隆,您应该非常小心地修改提交。在这种情况下,发布更正第一个提交的第二个提交可能是更好的解决方案。否则,通知所有其他人您已修改已发布的提交,以便他们能够做出相应的反应
恢复更改
恢复工作树中的更改
在Git索引中替换为文件
尚未提交和尚未分阶段的更改可以恢复为一组选定的文件。在包资源管理器或类似视图中选择文件,然后在Git索引中单击 替换为>文件。
替换为HEAD
此功能目前在单个文件级别上不可用。您可以使用 Reset to with hard 来强制重置存储库的整个工作树回到HEAD提交状态(请参阅下面的“重置当前的HEAD”)。该操作将恢复工作树和索引中的所有更改。您无法使用EGit在选定的一组文件上执行此操作。
替换为以前的版本
已经执行或甚至提交的更改可以通过将它们替换为之前提交的版本来“恢复”。在Package Explorer或类似视图中选择一个资源,然后单击 Replace With> Previous Revision。存储库将确定最后一次提交,该提交修改了所选资源,并提供用此提交的内容替换工作区资源。
这主要是为了从提交中“删除”单个文件(当提交已恢复的工作空间资源时,它们被有效地从当前提交中移除)。即使这也适用于文件夹和项目,用“之前的修订”替换文件夹或项目的结果可能是意外的。
使用quickdiff恢复
quickdiff功能可用于恢复对文件的单个更改。您可以按行,块(se范围更改行)或选择进行恢复。选择所有文本,然后 选择还原选择 以还原整个文件。
恢复由特定提交引入的更改
由给定提交引入的更改可以通过在当前检出的提交之上自动创建的新提交来恢复。要恢复的提交不必为此检出。
在历史视图中选择提交,打开上下文菜单并选择 恢复提交。这通过在当前签出的提交之上创建新的提交来还原所选提交引入的更改。
重置当前的HEAD
Git提供了将当前分支的HEAD重置为任何其他提交的可能性。它可以选择重置索引和工作树以匹配该提交。请注意,此操作会影响整个存储库中的所有文件和文件夹。
您可以选择进行硬重置,混合重置和软重置。
- 软 - HEAD现在指向新提交,索引和工作树不变
- 混合 - HEAD现在指向新的提交,索引被更新,工作树不变
- 很难 - HEAD现在指向新的提交,索引和工作树被更新
重置为特定分支或标签
在项目上选择 Team - > Reset ...。这将打开一个对话框,您可以在其中选择分支或标签。
重置为特定的提交
在历史视图中选择一个提交并打开上下文菜单。在这里您可以找到条目 硬重置, 混合重置 和 软重置。
恢复所有本地和分阶段的更改
这可以作为重置的特殊情况来完成。如果您重置为当前HEAD(通常是最后一次提交您的分支)的选项 硬 您覆盖工作树,并与头部的内容索引。你可以通过三种方式做到这一点:
- 在项目上选择 团队>重置...。在该对话框中选择HEAD或当前分支并切换的单选按钮 硬。
- 右键单击并 在存储库视图中的任意分支或标签上选择 重置...。这会打开一个对话框,让您决定重置类型。选择难 在这里。
- 打开历史视图HEAD提交中的上下文菜单,然后选择 硬重置。
分枝
关于分支机构的一般评论
在不使用本地分支的情况下提交对本地存储库的更改是不切实际的(参见上面的概念部分)。此外,通过使用几个不同的分支,可以通过在这些分支之间进行切换来并行处理不同的更改。
因此,在开始更改本地存储库之前,第一步通常是创建一个本地分支。本地分支机构“基于”提交或远程跟踪分支。
在使用远程存储库时,推荐使用第二个选项,因为它通过向新的本地分支添加所谓的“上游配置”来简化将本地更改与远程更改同步的任务。
请参阅 分支创建对话框 了解更多详情
上游配置
每个基于本地跟踪分支的本地分支都可以有一些额外的配置,指示远程存储库,远程分支和所谓的拉动策略。请参阅 分支创建对话框 了解更多详情
通常,根据远程跟踪分支创建本地分支时,会自动创建此配置。但是,可以在存储库配置中显示和编辑它,也可以 单击 “存储库视图”中某个分支上的“ 显示”>“属性 ”。
检出现有分支
从项目节点上的团队菜单中:
- 选择 团队>切换到... 并从列表中选择一个分支名称
如果分支太多,则列表中不会显示所有分支。在这种情况下
- 选择 团队>切换到...>其他...
- 在对话框中,选择一个分支,一个标签或一个参考
- 点击 确定
从Git存储库视图
- 在分支节点上选择 Checkout
要么
- 双击分支节点
从历史视图
- 在具有分支标签的提交上选择 签出
- 如果多个分支指向提交对话框,将允许您决定检出哪个分支。
创建新的本地分支
这总是通过“ 分支创建”对话框完成。新创建的分支可以通过选择对话框上的复选框来检出。
从团队菜单中
- 选择 团队>切换到...>新科...。
- 在对话框中,选择分支,标签或参考。
- 点击 创建分公司...。
- 该 科创建对话框 将被打开。
从存储库视图
- 在“分支”节点或任何“分支”,“标记”或“参考”节点上选择 创建分支...。
- 该 科创建对话框 将被打开。
从历史视图
- 选择 创建分支...
- 该 科创建对话框 将被打开
重命名现有分支
从项目节点的团队菜单中
- 选择 团队>高级>重命名分支...
- 在分支选择对话框中,选择要重命名的分支
- 输入新的分支名称,然后单击 确定
从存储库视图
- 打开Git存储库视图
- 选择 重命名分支... 或在您要重命名的分支上按F2
- 输入新的分支名称,然后单击 确定
从历史视图
- 使用分支标签提交时选择 重命名分支...
- 输入新的分行名称并点击 确定
删除分支
以下所有操作都表现出与以下相同的行为:
- 当前签出的分支不能被删除
-
如果删除分支可能导致数据丢失,则会显示必须确认的警告
- 如果分支指向从当前检出的提交无法访问的提交,EGit会承担潜在的数据丢失
从项目节点上的团队菜单
- 选择 团队>高级>删除分支...
- 从正显示的对话框中选择要删除的分支,然后按 确定
从存储库视图
- 打开Git存储库视图
- 在要删除的分支上选择 删除分支
从历史视图
- 使用分支标签提交时选择 删除分支
- 如果多个分支指向提交,将显示一个选择对话框,您可以在其中选择要删除的分支
分支创建对话框
有几种可用于创建本地分支的操作。所有这些操作都使用分支创建对话框:
上半部分的组合允许选择分支或提交新的分支应基于。通常,这是一个远程跟踪分支,但它可以是存储库中的任何分支或提交(不推荐选择本地分支)。
只有在组合中选择了一个分支并允许覆盖“上游配置”的默认设置时,“拉动策略”组才可见,这在提取和推送时很有帮助,特别是在拉取时。根据所选选项,可以选择以下配置:
- Rebase:拉动时,将从上游获取新的更改,并且远程跟踪分支将被更新。然后,当前的本地分支将重新贴装到更新的远程跟踪分支上
- 合并:拉动时,将从上游获取更改,远程跟踪分支将更新。然后,当前的本地分支将与新的更改合并。如果新分支基于远程跟踪分支,则这是默认设置(但此默认设置可能会被特定存储库配置覆盖)
- 无:拉动时,新的分支将不会执行特定的上游配置; 但是,如果存在默认远程设备(名称为“origin”的远程设备,则pull将尝试使用此远程设备的配置;如果新分支不是基于远程跟踪分支,则这是默认设置
您可以查看和编辑存储库配置中的上游配置, 或通过 在存储库视图中的分支上选择 Show In> Properties。
EGit还支持git配置参数 branch.autosetuprebase
,always
如果您想默认使用rebase pull策略,则将其设置为 。如果您在存储库配置中设置了此选项,则用于根据此存储库中的远程跟踪分支创建的所有本地分支,如果将其设置为用户配置,则将用于所有存储库。
在下面,您可以决定是否立即检查新分支。
合并
合并包含从命名提交(从他们的历史与当前分支分离的时间)到当前分支的更改。
将分支或标签合并到当前分支中
你有两个地方可以触发合并:
- 从团队菜单
- 从Git存储库视图
从团队菜单开始合并
在包资源管理器或导航器中,打开项目节点上的上下文菜单。选择 团队>合并...
现在合并对话框打开:
在对话框中,选择要与当前分支合并的分支或标签。
从Git存储库视图开始合并
如果您已签出本地分支,则可以从任何分支和标记节点以及从存储库节点触发合并。有关 更多详细信息,请参阅 合并分支或标记。
可能的合并结果
按下“合并”按钮后,可能会出现以下情况:
- 已经是最新的:你当前的分支指向一个具有选定分支或标签作为前任的提交。在这种情况下,没有什么改变。
- 快进:您当前的分支指向作为所选分支或标记的前任的提交。在这种情况下,您的分支会移动并指向选定的分支或标签; 这个新的HEAD被检出到工作树上。使用远程存储库时,快进是非常常见的:当远程跟踪分支更新时,与相应分支的合并通常是快进。您可以通过获取远程分支(例如起源/主控)并将其合并到相应的本地分支(例如主控)来执行拉动操作。
- 真正的合并:当以上条件都不适用时,触发合并提交。有两种可能的结果:如果不发生冲突,当前分支将指向新创建的合并提交; 如果发生冲突,冲突文件将标记为标签修饰符(请参阅解决合并冲突 以防合并冲突时的进一步操作)。
合并结果对话框
对话框中汇总了合并的结果:
在第一行你会看到合并的结果。可能的结果是“已更新”,“快进”,“合并”,“冲突”或“失败”。“失败”的可能原因可能是工作目录中存在冲突的更改。
在第二行中,如果成功合并(已完成最新,快进或合并),您将看到新的HEAD提交。
在表格中您可以看到合并的提交。
解决合并冲突
合并可能导致需要用户操作的冲突。当文件的内容不能自动合并时就是这种情况。这些冲突在导航树中标有标签修饰。文件内容中的合并冲突会显示文本冲突标记( 有关更多详细信息,请参阅http://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_how_conflicts_are_present)。
使用合并工具
- 选择显示红色冲突标签修饰器的*资源
- 单击 团队>合并工具
- 选择合并模式 使用冲突文件的HEAD(最新本地版本), 然后单击 确定
- 合并编辑器打开,显示左侧窗格中的工作树版本以及右侧窗格中要合并的版本
- 编辑工作树版本,直到你满意为止
- 团队>添加 合并资源以将冲突标记为已解决
- 通过Team> Commit提交合并 提交
手动冲突解决
要解决冲突,您必须执行以下步骤:
- 导航到冲突的资源
- 编辑冲突资源的内容
- 通过Team> Add告诉EGit冲突已解决
- 通过Team> Commit提交冲突解决方案
查找冲突的文件
包含冲突文件的存储库具有附加到存储库名称的文本标签装饰器“|冲突”。包含这些冲突资源的资源和文件夹冲突会得到冲突标签装饰。
编辑冲突的文件
在文件内容中,发生一对冲突变化的区域用标记<<<<<<<,=======和>>>>>>>标记。=======之前的部分通常是你的一面,而之后的部分通常是他们的一面(见 http://www.kernel.org/pub/software/scm/git/docs/git-merge。 html#_how_conflicts_are_presented 了解更多详情)。
在编辑器中打开文件,编辑内容并保存编辑器。
请注意,这一步不是强制性的。EGit不会检查内容以决定冲突是否已解决。下一步是相关的一步。
将冲突解决添加到git索引
编辑文件完成后,选择 Team> Add 将冲突解决添加到git索引。您可以在文件夹或整个项目上执行以一次解决所有冲突。
解决所有冲突后,文本存储库标签装饰将更改为“已合并”。没有冲突标记了。
提交合并
当存储库处于“合并”状态时(如使用文本标签修饰符“|冲突”附加到存储库名称所示),最终可以合并合并。
在导航树的任意位置选择“ 团队”>“提交...”。提交对话框以与正常提交相比稍微不同的外观打开:
- 提交消息区域预填充了标准合并提交消息。
- 不可能修改以前的提交。
- 无法添加未跟踪的文件。
- 不可能取消选中复选框。这保证所有已解决的冲突均已落实。
按下“提交”按钮后,合并完成。
中止合并
如果合并导致冲突,您可以通过对当前分支进行硬重置来中止合并。这可以在“冲突”状态和“合并”状态下完成,即在解决冲突之前和之后。
硬重置可以从团队菜单,Git存储库视图或历史视图中完成。请参阅 恢复所有本地和分阶段更改 以获取更多详细信息。
垫底
Rebase简介
Rebase将一组提交应用于给定的提交。一个典型的场景是在某个时间点从“主”分支创建的“主题”分支上开发某些功能。当“主”更新时,例如来自其他开发者的变更,而“主题”仍在开发中时,可能有必要将这些更改合并到“主题”中。
让我们假设我们通过从master创建“主题”分支来开始“主题”开发。此时,“主”和“主题”都指向提交“E”。当第一次提交(“A”)被添加到“主题”时,资源库的提交历史记录如下所示:
一个话题 / D --- E主
现在,我们假设在“主题”上有更多的提交,并且还有一些对“主”的提交(例如,“master”可能会跟踪某个远程存储库,并且该远程存储库中的一些更改已经被引入“主”):
A --- B --- C话题 / D --- E --- F --- G主
现在,为了将“主”的变化结合到“主题”中,“主”的“主题”的再版将产生
A' - B' - C'主题 / D --- E --- F --- G主
从技术上讲,“主题”中包含但不包含在“主”中的提交顺序在“主”之上逐一应用(即,挑选)。
请注意,提交A,B,C既不会丢失也不会发生更改,而是会创建与原始提交(但不同的提交ID)相同的更改和提交消息的新提交链A',B',C'。旧提交A,B,C仍在对象数据库中,但不再可见,因为它们不再可从任何分支中访问。A',B',C'与旧的不同,因为它们现在也包含变化F和G.
重建,一个简单的例子
让我们来看一个简单的例子:我们有一个文本文件“FamousWords.txt”,它最初可能有一些内容
第1章 很久以前... 第2章 生存还是毁灭
现在,在“主题”中,创建了两个提交,第一个将法语翻译添加到第2章,另一个添加德语翻译:
在“主题”中首次更改后:
第1章 很久以前... 第2章 生存还是毁灭 是或不是
在“主题”中进行第二次更改后:
第1章 很久以前... 第2章 生存还是毁灭 是或不是 是或不是
同时,通过在第1章中添加两个提交法文和德文翻译的“主文件”更改了该文件:
第1章 很久以前... 曾几何时 曾几何时 第2章 生存还是毁灭
提交历史记录如下所示:
现在,如果将“主题”重新设置为“主”,则主题中的两个更改按照与“主题”演变过程中应用的顺序相同的顺序应用。
结果是“FamousWords.txt”的合并版本:
第1章 很久以前... 曾几何时 曾几何时 第2章 生存还是毁灭 是或不是 是或不是
以及在当前“主”之上提交“主题”提交历史的提交历史记录:
现实世界:重建冲突
到目前为止,我们假设“主题”中的更改可以自动合并到“主”中。然而,在现实世界中,可能会发生在重新绑定期间遇到冲突。现在,如果挑选的提交中包含与“主”更改相冲突的更改,则在应用冲突更改后,重置操作会中断; 以通常的方式(冲突标记)将冲突可视化,并且用户有机会决定是否要
- 手动解决这些冲突,
- 跳过当前的提交,或者
- 完全放弃rebase
如果 选择了“ 解决冲突”,并且冲突已经手动解决,那么更改必须是“已添加”,然后可以重新进行重新分配,即将应用链中的下一个提交。
如果 选择跳过,冲突的更改将被还原,链中的下一个提交将被应用。
如果 选择Abort,rebase操作将完全回滚,在rebase开始之前将Repository恢复到原始状态。重复此过程直到最后一次提交成功或跳过应用。最后,“主题”分支将更改为指向最后的提交。
为了更好地理解“跳过”,让我们回顾上面的介绍。如果我们假设提交“B”导致与当前“主”的冲突,用户可能会决定跳过“B”; rebase之后的新提交历史将如下所示:
'C'主题 / D --- E --- F --- G主
启动Rebase
Rebase在Git存储库视图中可用。在Repository节点上, Rebase ... 打开一个对话框,要求用户选择未检出的分支; 当前签出的分支将被重新分配到所选分支上。在“分支”节点(包括本地和远程跟踪分支,但不在当前签出的分支上), 重置 立即将当前签出的分支重新绑定到所选分支上:
重新确认对话框
如果Rebase成功,将显示一个确认对话框; 这个对话框可以通过勾选一个复选框来抑制; Git首选项页面上的首选项允许再次出现对话框。如果该对话框被禁止,则会将“信息”消息写入Eclipse日志中。
冲突冲突
如果在重新绑定期间发生冲突,将显示一个对话框,提供有关导致冲突的提交的一些信息。通过选择一个单选按钮,您可以决定是否
- 启动合并工具以手动解决冲突
- 跳过当前提交
- 完全放弃rebase
- 什么都不做(返回工作台),这相当于击中了“Escape”:
除非在对话框中选择“跳过”或“中止”,否则必须通过编辑冲突文件手动解决冲突。编辑完成后,文件必须声明为通过将它们“添加”到索引来解析。
在所有冲突解决后,Rebase可以通过右键单击Git存储库视图中的Repository节点并选择Rebase> Continue来恢复。
通过右键单击Repository节点并分别选择Rebase> Skip and Rebase> Abort,可从Git存储库视图中获得“跳过”和“中止”选项。
合并工具也可以从团队菜单中的相应条目开始。
中止Rebase
只要存储库处于“重新启动”状态,用户就可以使用Repository节点上可用的菜单操作“Rebase> Abort”在Git存储库视图中始终放弃重新绑定。
再利用限制
目前的EGit rebase实现还不能处理所有可能的版本图。如果图表过于复杂,rebase将会以错误消息中止。作为一种解决方法,直到EGit的rebase支持这些更复杂的图表,您可以改用命令行中的native git。
采摘樱桃
樱桃挑选介绍
分支stable-1.0上 的给定提交 C 包含一组您希望集成到当前分支主机开发中的更改 。
A - B - C - D稳定 - 1.0 / D --- E --- F --- G主头
Cherry选择提交 C在当前签出的分支主机的头提交之上 创建新的提交 C' 。 C” 然后将包含在执行的更改 Ç 施加到当前签出分支的HEAD 主。
A - B - C - D稳定 - 1.0 / D --- E --- F --- G-C'master HEAD
樱桃挑选示例
您目前正在分支“feature2”(HEAD)上工作。在另一个分支中有一个提交“功能1”。
您希望将提交“功能1”执行的更改集成到当前分支“功能2”的开发中。
- 在历史视图中选择提交“功能1”并单击 Cherry-pick:
- 因此,您在当前分支“功能”的顶部获得了一个新的提交“功能1”,其中包含“功能1”的更改:
- 樱桃采摘可能会遇到冲突。在这种情况下,冲突标记将呈现到受影响的源中:
标记
创建一个标签
- 从项目上下文菜单中选择 Team> Advanced> Tag ...。
- 输入标签名称
- 输入标签消息
- 可以选择你想要标记的提交(默认是HEAD)
- 单击 确定 以创建注释标签
也可以在历史记录视图中创建标签:选择提交并 在上下文菜单中执行 创建标签...。该标签将在选定的提交上创建:
替换现有标签
如果您标记了错误的提交或最终出现了某种错误,该怎么办?
- 如果你还没有推出这个只需更换标签,你就完成了。
- 如果它已经发布,你不应该替换标签, 而是使用一个新名称,否则你必须告诉每个获得旧标签的人用你的新标签手动替换它。这是因为,Git没有(也不应该)改变用户背后的标签。所以如果有人已经拿到了旧标签,那么在树上做一个git pull不应该让它们覆盖旧标签。
因此,如果您的旧标签尚未推送,您可以通过以下方式进行更正:
- 从项目上下文菜单中选择 Team> Tag ...。
- 从现有标签列表中选择要替换的标签
- 或者开始在“标签名称”字段中输入要查找的标签的任何部分,这会将现有标签的列表过滤到包含您正在输入的字符串的那些标签,然后选择要替换的标签
- 标记复选框 强制替换现有标记
- 更改标签并按 确定
删除标签
为了删除标签,选择要删除的标签并点击 删除标签。
注意: 删除已在公共服务器上发布的标签是一种不好的做法,一些Git服务器甚至不允许删除标签以确保通常标记的发布的可追溯性。另请参阅 标记命令的Git参考文档中的“重新标记”部分。
轻量级和签名标签
轻量级标签显示在“存储库视图”和“创建标签”对话框中,但无法编辑。标签在存储库视图中显示为蓝色图标,注释标签用黄色人物装饰。
在历史视图中,标签显示为黄色标签。
EGit还不支持签名标签,而是使用命令行 git标签 或 git标签-s 。
补丁
创建修补程序
“补丁是一种旨在解决问题或更新计算机程序或其支持数据的软件”(wikipedia)。补丁文件包含一组可以自动应用到另一个eclipse工作区或git存储库的资源更改的描述。
eclipse(Team> Apply Patch)和git(git apply 或 git am 在命令行上)使用的补丁格式不同。在EGit中可以创建两种类型的补丁。
从提交创建一个补丁
这是分布式版本控制系统最常见的用例。开发人员对本地功能或错误修复分支提交更改,并希望将此更改导出到修补程序文件中。
它可以从历史视图完成:
补丁文件将包含历史视图中提交与其父代之间的区别。请注意,历史视图的过滤器也适用于修补程序创建。
补丁向导
向导由两页组成。第一页可以让你选择补丁的位置:
补丁文件的名称是从提交消息的第一行创建的。
在第二页上,您可以更改补丁格式。
目前有一个复选框: 以git补丁格式导出。
- 如果你没有检查它(这是默认设置),可以使用eclipse Apply Patch ... 向导来应用这个 补丁。路径与eclipse项目相关,不包含前缀(比如 git命令行上的git format-patch --no-prefix)。
- 如果你检查它,补丁将看起来像 git命令行上的git format-patch --no-stat的结果 。
目前没有生成二进制差异。
应用修补程序
目前EGit无法以git格式应用补丁。使用Team> Apply Patch ...可以使用标准Eclipse(统一差异)格式 应用修补程序。Git补丁可能包含用于重命名和二进制比较的非标准扩展。EGit的当前版本不会生成这些扩展名。
管理存储库
“Git存储库视图”是便于同时处理多个存储库(即在一个Eclipse工作区内)的主要UI元素。
此视图可以使用菜单路径Windows> Show View> Other ...> Git> Git Repositories打开
它也是“Git Repository Exploring”透视图的一部分,使用菜单路径
Window> Open Perspective> Other ...> Git Repository Exploring
如果您的工作空间中已有与Git存储库共享的项目,则可以使用
团队>在存储库视图中显示
在任何资源上打开视图。
将存储库添加到Git存储库视图
最初,Git存储库视图是空的。为了向其添加存储库,有以下几种选择:
- 手动从本地文件系统添加存储库
- 克隆存储库并将克隆的存储库自动添加到视图中
- 在本地文件系统上创建存储库
- 通过将Git存储库路径粘贴到视图来添加存储库
手动添加存储库
您可以将本地文件系统中的存储库添加到Git存储库视图中,而不用克隆它。如果您正在设置新的Eclipse工作区并希望重新使用您的Git存储库,这会很有帮助。使用 视图工具栏中的 添加现有的Git存储库按钮:
将出现一个对话框,提示您输入本地文件系统的目录。选择正确的目录后,您可以点击 搜索 按钮来查看该目录中的Git存储库列表。然后,您可以选择一些或全部找到的存储库,并使用OK将其添加到视图中 :
克隆存储库
为了克隆存储库,请参阅 克隆远程存储库。克隆操作成功后,新克隆的存储库应自动出现在Git存储库视图中。
您也可以使用 视图工具栏中的 克隆Git存储库按钮来启动克隆向导:
请参阅 克隆远程存储库 关于如何使用向导。
创建一个存储库
您可以在本地文件系统上创建一个新的空存储库。如果稍后想要在此存储库下创建一个或多个新项目,这很有用。另一个用例是创建一个新的裸仓库,您可以在其中推送。使用 视图工具栏中的 创建新的Git存储库按钮:
会出现一个对话框让您选择一个目录:
如果您选中创建为Bare Repository复选框 , 则新存储库将不会有工作目录。然后您只能通过推送来自另一个存储库的更改来添加内容。
使用复制和粘贴添加存储库
作为快捷方式,也可以将Git存储库的本地文件系统路径从剪贴板粘贴到此视图中。为此,请将Git存储库的路径(其.git
文件夹的完整路径 )复制到剪贴板,然后在视图面板上打开上下文菜单:
或者 从主菜单(或相应的键盘快捷键)单击 编辑>粘贴。如果剪贴板内容不合适,将显示错误弹出窗口,否则添加的存储库应自动出现。
在视图填充了一些存储库后,它应该如下所示:
删除存储库
从存储库视图中删除存储库
为了从存储库视图中删除存储库,选择一个存储库并单击“删除存储库”
删除存储库
为了删除存储库,请在存储库视图中选择它并单击“删除存储库”。
然后确认您要删除存储库
并决定是否要从Eclipse工作区删除存储库中包含的项目。
Git存储库视图的结构
以下屏幕截图显示了Git存储库视图的最上面两个级别:
根节点表示存储库本身。节点文本指示存储库的名称及其在本地文件系统中的位置。“分支”和“标签”节点允许浏览和操作标签和分支。“References”节点列出了其他不是分支或标签的引用,最显着的是“HEAD”和“FETCH_HEAD”符号引用(请参阅 Git引用)。
“工作目录”节点显示本地文件系统上工作目录的位置和结构(仅在开发情况下为裸露存储库,或者非裸露存储库,此节点始终为叶)。
最后,“远程”节点允许浏览和操作用于提取和推送的远程配置。
Git存储库视图的功能
项目导入
为了使用Git Repository的内容,它的文件和文件夹必须以项目的形式导入Eclipse工作区。虽然Git Clone向导允许在克隆后直接执行此类导入,但Git存储库视图允许独立于克隆操作触发项目导入。
“存储库”节点以及“工作目录”节点和“工作目录”节点本身内的任何“文件夹”节点上均提供“导入项目...”上下文菜单:
在几个节点上提供Import Projects ...操作的基本原理 是,用于导入项目的一些向导可以考虑文件系统目录,例如 Import Existing Projects 向导。如果从“存储库”或“工作目录”节点开始导入,则将存储库的工作目录设置为上下文,否则将设置与当前选定的“文件夹”节点相对应的目录。
有关项目导入的详细信息, 请参阅使用新项目向导。
分支和标签支持
“分支”节点允许创建,浏览,结账和删除本地和远程分支机构。“标签”节点允许浏览和签出标签。“分支”节点和“标签”节点都允许将分支或标签合并到当前签出的分支中,并且还与当前签出的分支同步。
为了更好的可读性,分支分别组织在本地和远程分支的两个子节点中,并且只显示缩写名称,例如,代替 “refs / heads / master”, 您会 在“本地”下找到条目 “主” 在“远程分支”节点下显示“分支”节点,而不是“参考/远程/源/主” 缩写名称 “起源/主站”。同样,通过省略“refs / tags /” 前缀缩短标签名称 :
检查分支和标签
可以通过双击各个节点或选择相应的上下文菜单条目检出分支和标签。
分支的创建和删除
可以使用分支创建对话框创建本地分支 。通过右键单击任何“分支”和“标记”节点上的“分支”,“本地分支”来打开该向导。
分支删除使用相应的上下文菜单条目完成。
垫底
您可以通过右键单击触发当前签出分支的垫底到另一个分支 再次基于 任何(本地或远程跟踪)分支节点上。
合并分支或标签
如果您已签出本地分支,则可以从任何分支和标记节点以及从存储库节点触发合并。有关合并 功能的更多详细信息,请参阅 合并。
- 当您选择除当前检出分支或任何标签节点以外的任何分支节点时,使用 合并 直接触发合并到当前检出分支。
- 当您选择存储库节点或当前检出的分支时,使用 合并... 打开合并对话框。在将分支或标签合并到当前分支中描述了合并对话框。
与分支或标签同步
您可以将HEAD中的更改与任何其他分支或标签中所做的更改进行比较。右键单击并选择 同步...在任何分支或标记上。然后打开eclipse同步视图,其中包含HEAD中包含的更改的表示,但不包含在另一个分支或标记(传出更改)中,反之亦然(传入更改)。有关更多详细信息,请参阅同步功能的文档。
确定检出分支
有两种方法可以确定当前检出哪个分支或标签:检出的分支/标签节点装饰有一个小勾号,“符号参考”节点下的“HEAD”条目显示退房分行:
重置为分支或标签
右键单击并 在任何分支或标签上选择 重置...。这会打开一个对话框,让您决定重置类型。有关 更多详细信息,请参阅 重置您当前的HEAD。
“分离”头部
如果HEAD是“分离的”,即不是指向本地分支的尖端,而是指向提交或标记,则树中可能没有或几个“签出”标记,因为任何数目的远程分支或标记可能指向当前签出的提交。当你的HEAD被分离时你所处的状态不会被任何分支记录(这是很自然的 - 你不在任何分支上)。
检查参考文献
“引用”节点显示除分支和标记以外的一些引用(该列表是动态的,取决于存储库的当前状态):
如果引用是符号的,即指向另一个引用,则显示目标引用的名称,后跟引用的目标的对象ID。如果引用不是符号,则只显示对象ID。
在上面的例子中,HEAD是指向分支“refs / heads / master”的符号引用(即分支“master”被检出),而FETCH_HEAD直接指向提交226a7f ...。
右键单击Reference: Checkout (除非Reference已经签出)并 创建分支' ...',可以执行以下操作。
浏览工作目录
“工作目录”节点可视化Git存储库的本地文件系统结构。也可以在文件上打开文本编辑器:
或者,可以通过将文件从工作目录拖到编辑区域来打开文件。
另外,在所有文件和文件夹节点以及“存储库”节点上,都提供了一个用于将(文件系统特定)路径复制到剪贴板的选项。这在需要路径时有时很有用,例如,使用文件浏览器打开目录或在视图实例之间复制和粘贴存储库(请参阅上述关于如何将存储库添加到视图中)。“ 复制到剪贴板” 操作也可以使用 编辑>复制 (或相应的键盘快捷键)。
存储库配置
与Eclipse中的通用“属性”视图集成允许查看和编辑Git配置(全局和特定于存储库的配置)。如果“属性”视图处于打开状态,则在选择“存储库”节点时会自动更新。使用下拉框(屏幕截图中的左侧红色框),您可以在存储库配置的显示,全局配置和聚合两者的视图之间切换。如果视图显示存储库配置或全局配置,则可以使用编辑 按钮(屏幕截图中的右侧红色框)打开编辑器对话框 。编辑器对话框具有与首选项页面Team> Git> Configuration相同的功能 。
在Git Repositories视图中, 上下文菜单中有一个 Properties操作,该操作将打开一个允许编辑Repository Configuration的配置对话框。在这里,可以添加,更改或删除键值对。在 打开 按钮可以在文本编辑器打开库配置文件。
远程存储库
“远程”节点允许浏览和编辑远程配置。每个远程配置都有一个名称和一个推送规范,一个提取规范或两者。如果选择“远程配置”节点或其任何子节点,则 属性 视图将显示远程配置的摘要。在这个例子中:有一个名为“origin”的远程配置,它只有一个提取规范,但没有推规范:
菜单操作用于添加,配置和删除远程配置以及提取和推送规范。
直接读取和推送支持
可以在远程节点以及相应的“提取”和“推送”节点上直接执行提取和推送(即无需向导):
请注意,取或推操作将立即在异步作业中执行; 完成后,您将看到一个确认弹出窗口,显示获取结果。
“Fetch”节点包含所谓的提取规范,“Push”节点包含所谓的推式规范。
克隆存储库时创建默认的提取规范。您可以使用菜单项Configure Fetch ...编辑提取规范 。这将打开一个向导。在第一页上,您可以编辑提取URI。Ob第二页,您可以确定提取参数规格,请参阅 提取参考规格。
您可以使用菜单项“ 配置推送...”创建或编辑推送规范 。这将打开一个向导。在第一页上,您可以编辑推送URI。如果指定了提取,则提取URI将自动包含在推送规范中,并且不需要其他推式URI。在第二页上,您可以确定推送参数规格,请参阅 推送参考规格。
添加远程配置
这是使用“远程”节点上的上下文菜单操作完成的。启动向导询问新配置的名称以及是否配置Fetch,Push或两者:
如果选择 配置提取 复选框,则下一个向导页面将要求从以下位置获取存储库的URI:
点击 更改... 打开一个对话框,允许您选择一个URI。下一步是为获取URI定义远程规范。有关详情,请参阅 提取参考规格 。
如果选择 配置推送 复选框,则下一个向导页面将要求存储库的URI推送到。这实际上是一个列表,因为您可以一次推送到多个存储库。单击 添加.... 使用与上面相同的对话框将URI添加到列表中。您可以在列表中标记他们,打删除的URI 删除。如果已经定义了一个提取URI,则此步骤是完全可选的。在这种情况下,获取URI也将用于推送。如果在这个步骤中至少定义了一个推送URI,它将覆盖提取URI。在这个例子中,已经有一个获取URI,所以 即使列表中没有Push URI,也会启用Next按钮:
下一步是为推送URI定义远程规范。有关详情,请参阅 推送参考规格 。
完成后,新的远程配置将可见:
更改远程配置
也可以使用上下文菜单为现有的远程配置添加,删除或更改提取/推送规范。
Gerrit配置
如果您可以使用 Gerrit Code Review 作为远程存储库服务器
- 指定用于将更改推送到代码审阅的推送配置
- 指定提取配置以从Gerrit获取审阅笔记
- 配置您的存储库以 在缺省情况下在“提交”对话框中选择“ Gerrit代码审阅的 计算更改ID”选项
从Remote的上下文菜单中选择 Gerrit Configuration ...。这将打开一个带有一个页面的向导:
- 当您单击 完成时 ,向导会将存储库配置参数 gerrit.createchangeid设置 为 true。这确保 默认情况下选中提交对话框中Gerrit代码审查的复选框Compute Change-Id。详情请参阅 提交 信息。
- 如果要在稍后的时间点配置自动Change-Id插入,可以使用存储库配置编辑器(首选项>团队> Git>配置)将配置参数gerrit.createchangeid设置 为true。如果你想为你所有的仓库配置这个配置,你可以把它放到〜/ .gitconfig中,那么你不需要重复这个配置来处理你正在使用的每个新仓库。
- 另外,向导在您的获取规范中添加了一个refspec“refs / notes / *:refs / notes / *”。Gerrit在git笔记中存储有关该评论的数据。有了这个refspec,这些评论数据将在您从这个远程获取时自动获取,并且它们将显示在提交查看器中。
- 在Push URI部分, 您可以配置用于默认推送配置的URI。它根据您从中克隆的URI进行预填充。如果使用git协议进行克隆,协议会自动更改为ssh,并自动添加默认的Gerrit ssh端口29418。对于需要用户的协议,为了方便,有一个用户字段。
- “ Push Configuration ”部分 有一个字段“ Destination Branch”。在这里您应该输入Gerrit代码审查工作流程中接受更改的目标分支的名称。这会 在克隆向导中指定的远程的推送配置中产生一个条目 HEAD:refs / for / <branchname>。
刷新
该视图会定期自动刷新。 工具栏中的 刷新按钮允许立即刷新:
与选择链接
如果 启用了带选择的 链接,则将自动显示与当前工作台选择对应的文件或文件夹:
与编辑链接
如果 启用了带编辑器的 链接,则会自动显示与当前活动编辑器对应的文件或文件夹:
分层分支布局
如果 启用了“ 分层分支布局”切换,分支将以分层布局显示,并使用斜杠(/)作为分层结构分隔符:
这对组织大量分支机构可能有帮助。
裸库
“Bare”Git存储库(与“开发”或“标准”存储库相反)根据定义没有工作目录,因此与工作目录相关的所有操作(检出,项目导入,浏览工作目录)都不可用于这样的存储库。仓库的“裸机”在“工作目录”节点上可视化,该节点总是一片叶子:
裸存储库只能通过对其进行更改来更改。
从Git存储库视图中删除存储库
这是作为“Repository”节点上的菜单操作提供的。请注意,这不会删除存储库,而只是从视图中删除该节点。如果工作区中的项目位于存储库的工作目录中,则会提示用户确认从Eclipse工作区删除这些项目。
在相关视图中显示存储库
在历史中显示
Show in> History命令 将打开 历史视图, 显示所选储存库中的所有更改。
在Reflog中显示
Show in> Reflog命令 将打开 Git Reflog视图, 显示所选存储库的Git reflog。
在属性中显示
命令 Show in> Properties 将打开 显示所选存储库属性的 Properties视图。
使用任务
由于EGit 0.11与Mylyn的第一次集成可用于支持使用任务存储库。
安装
您需要安装功能“EGit Mylyn”才能使用EGit Mylyn集成。这还需要安装Mylyn。
提交消息模板
- 在首选项>任务>团队下配置Mylyn提交消息模板, 然后编辑 提交评论模板。
-
使用以下变量以及任何文本来更改提交消息。
- repository.url,task.assignee,task.cc,task.description,task.id,task.key,task.keywords,task.lastmodified,task.notes,task.priority, task.product,task.reporter,task.resolution,task.status,task.summary,task.type,task.url,task.completiondate,task.creationdate,task.reminderdate
- 在提交更改之前,使用Mylyn UI**相应的任务。
- 当启动提交对话框时,EGit将使用提交消息模板预填充提交消息。
有关 如何使用任务的更多信息,请参阅 Mylyn用户指南。
查看提交
Egit commit查看器允许在Eclipse编辑器区域中打开提交。
EGit commit查看器显示以下提交信息:
-
提交选项卡
- 链接到打开父提交
- 作者
- 修订者
- 信息
- 指向这个提交的标签列表
- 提交存在的分支列表
-
Diff选项卡
- 文本查看器与文件差异的输出
- 查看器中使用的颜色可以通过 首选项 > 常规 > 外观 > 颜色和字体 > Git 文件夹进行配置
-
Notes标签
- 所有Git的提交注释
标记提交
-
从提交查看器工具栏中选择创建标签图标
- 标签对话框将打开,允许您从提交中创建标签。
从提交创建分支
-
从提交查看器工具栏中选择创建分支图标。
- 分支对话框将打开,允许您从提交中创建新的分支
检出一个提交
这会检查提交查看器中显示的提交。提交将被检出并且 HEAD将被分离。
樱桃采摘承诺
在当前签出的提交或分支上应用由提交查看器中显示的提交引入的更改。
打开提交查看器
提交查看器可以从以下位置打开:
搜索提交
EGit支持搜索提交。
Git搜索页面
提交可以从 标准的Eclipse搜索对话框中的 Git Search选项卡搜索。
此对话框支持搜索Git提交的不同字段中存在的文本或模式,例如消息,作者行,提交者行和提交的SHA-1 ID,其父代以及与其关联的树。
浏览搜索结果
提交搜索结果显示在标准的Eclipse搜索视图中。在树状模式下,结果按存储库分组。双击搜索视图中的提交将在提交查看器中打开它 。
启动Git搜索
Git Search页面可以通过从Eclipse工具栏上的Search下拉菜单中选择Git Search选项来打开。
打开提交对话框
EGit 1.0有一个 类似于Mylyn Open Task 和 Open Resource核心对话框的 Open Git Commit对话框 。该对话框会搜索每个已配置的Git存储库,以查找输入到过滤器框中的分支,标记或提交SHA-1,并显示匹配的提交。
该对话框可以通过选择 Eclipse导航工具栏上的Open Git Commit按钮来 打开。
查找文件中每行的作者
EGit 1.0支持 在编辑器标尺内显示 git blame信息。
选择 Team > Show Annotations 对文件选择操作将打开编辑器并显示注释标尺,其中包含文件中每行的提交和作者信息。将鼠标悬停在标尺上将显示一个弹出窗口,其中显示提交ID,作者,提交者和提交消息。
责备注释编辑器标尺的外观和感觉 可以从标尺上下文菜单中的修订子菜单中配置 。
从弹出窗口中选择SHA-1超链接将在提交查看器中打开 提交。
使用子模块
EGit / JGit中的子模块支持在2011年2月发布的1.3版本中添加,该版本是Indigo SR2的一部分。
你可以阅读更多关于Git子模块是什么以及它们如何在此 Git社区书籍章节中工作的内容。
使用子模块克隆存储库
子模块是嵌套在父存储库内的存储库。因此,在对父存储库进行克隆时,需要克隆子模块存储库,以便文件/文件夹在父存储库的工作目录中可用。
克隆父库的完成后, 从Git Clone向导中检查 克隆子模块按钮 将克隆所有子模块库。
浏览子模块
在 包含子模块的存储库的Git存储库视图中 显示了一个 Submodules节点 。
给定父存储库中的所有子模块都显示在此节点下以及有关当前检出哪些提交的信息。
添加一个子模块
您可以通过在Git存储库 视图中选择一个存储库并选择 添加子模块 上下文菜单选项来将新的子模块添加到存储库 。
该向导将提示输入要添加的子模块的路径和URL。输入的路径将相对于父存储库的工作目录,并且URL将用于本地克隆存储库。
一旦向导完成,子模块将被克隆,添加到索引,子模块将被注册到 .gitmodules 文件以及父库中的 .git / config 文件中。
更新子模块
有两个操作可用于更新子模块,即 更新子模块 和 同步子模块。
在子模块 上选择 Update Submodule操作将检出在该子模块的父存储库索引中引用的提交。如果 在父存储库的.git / config 文件中所选子模块的配置部分的更新字段中 配置了该命令,则此命令也将执行合并或重新绑定 。
在子模块 上选择 Sync子模块操作将从父存储库工作目录根目录下的.gitmodules文件中的当前值更新子模块使用的远程URL 。
团队项目集
团队项目集(.psf 文件)由Git团队提供商支持。
进口
要导入现有项目集,请使用 导入... 向导,然后 从 团队中选择 团队项目集。
然后,您可以选择一个包含导入定义的文件,并可以选择将导入的项目添加到工作集。
在下一步中,存储库被克隆,项目被导入并连接。这可能需要一段时间,取决于存储库的大小。
出口
要为现有Git项目创建项目集文件,请选择已连接到Git团队提供者的项目/工作集。
然后打开 导出... 向导并 从 团队中选择 团队项目集。您可以选择仅导出工作集或项目,并可以优化您的选择。在下一步中,选择一个输出路径并完成向导。
格式
您也可以手动编辑 .psf 文件。每个项目都有一个如下所示的条目:
<project reference =“1.0,git://egit.eclipse.org/egit.git,master,org.eclipse.egit”/>
这些值由逗号分隔,并具有以下含义:
- 格式版本
- Git存储库URL
- 最初退房的分店名称
- 导入项目的路径(包含.project的文件夹 ),相对于存储库
每个项目都有一个条目。因此,对于同一个存储库中的多个项目,使用相同的存储库URL为每个项目创建一个条目。导入足够聪明,只能克隆每个存储库一次。
如果存储库包含根目录中的项目,请使用 。 作为项目路径。
参考
菜单
项目上下文菜单
在导航视图(导航器,包资源管理器等)中的项目节点上,以下Git操作可用于与Git团队提供者共享的项目:
主项目菜单
“远程”子菜单
“切换到”子菜单
“高级”子菜单
资源上下文菜单
在导航视图中的资源节点(文件和文件夹)上,以下Git操作可用于与Git团队提供者共享的项目:
存储库查看菜单
历史视图菜单
Git Workbench工具栏和Git Workbench菜单
为了方便使用最常用的Git动作, 可以**Git Command Group以显示Git Workbench工具栏和/或菜单
- 右键单击工作台工具栏区域,然后单击 自定义透视图...
- 在选项卡 命令组可用性中 单击 Git,这将启用Git工作台工具栏和菜单
- 在标签 工具栏可见性 和 菜单可见性中, 您可以配置哪些操作应该出现在Git Workbench工具栏和菜单中
菜单操作
-
加
- 将工作树中存在的更改添加到git索引,也称为分段更改。
- 将新创建的资源放在git版本控制下(Git不会自动开始跟踪资源)。
- 解决冲突。
- 应用修补程序 - 应用修补程序。
- 假定不变 - 资源可以被标记为“假定不变”。这意味着Git会停止检查工作树文件以进行可能的修改,所以当您更改工作树文件时,您需要手动取消设置该位以告诉Git。此设置可以通过菜单操作 Team> Assume保持不变 并切换回菜单操作 Team> No Assume不变。
- 分支, 创建分支 - 签出分支或创建分支。
- 更改凭证 - 更改提取或推式规范的登录凭证,凭证按照URL安全存储库中的每个URL进行存储。
- 结帐 - 签出 分支,标签, 提交 或参考。
- 樱桃选择 - 樱桃选择一个提交到当前签出的分支的提示。
- 清除凭证 - 清除提取或推送规范的登录凭证,凭证按照URL安全存储库中的URL存储。
- 提交 - 提交更改。
- 删除提取 - 删除提取规范。
- 删除推送 - 删除推送规范。
- 配置提取 - 配置提取规范。
- 配置推送 - 配置推送规范。
- 删除分支 - 删除分支。
- 删除存储库 - 删除存储库。
- 断开连接 - 断开所连接的Git Team Provider与该项目的连接。git存储库仍然存在,但不再与Eclipse集成。
- 忽略 - 将文件添加到.gitignore,以便git忽略它们。
- 导入项目 - 将项目导入Eclipse工作台。
- 合并 - 合并分支。
- 合并工具 - 使用合并工具解决冲突。
- 打开属性视图 - 查看和编辑存储库配置。
- Pull - 从当前检出的本地分支跟踪的远程分支上拉更改。
- 远程> 取自 - 从远程存储库获取更改
- 远程> 从Gerrit 获取 - 从Gerrit代码审阅服务器更改获取
-
远程> 推送 - 将更改推送到其他存储库
- 远程> 配置从上游获取 - 配置上游自动获取
-
远程> 配置推送到上游 - 配置上游自动推送
- 重建 - 将分支重新分配到另一个分支。
- 删除存储库 - 从存储库视图中删除存储库。
- 重命名分支 - 重命名分支。
- 重置 - 重置当前的HEAD,索引或工作树。
- 在历史记录中 显示 - 在历史记录视图中显示选定的资源。
- 在存储库视图中 显示 - 在存储库视图中显示选定的资源。
- 切换到... - 切换到(也称为结账)另一个分支或标签。
- 同步 - 同步本地和远程分支。
- 标签 - 创建,删除标签。
- Untrack - 从git版本控制中移除资源。如果要从工作树中删除资源,请 在资源的上下文菜单中单击“ 删除 ”。
Git透视和观点
Git透视
Window> Open Perspective> Git Repository Exploring 打开Git Repository Exploring透视图
Git存储库视图
窗口>打开视图> Git> Git Repositories 打开Git Repositories视图,这里详细解释 。
历史视图
概观
Git版本控制下的资源历史视图是给定存储库中资源的以提交为中心的视图。它可以用来执行以下任务:
- 在Git版本控制下检查给定文件的更改历史记录(查看和比较存储库中此类文件的版本)
- 使用不同的搜索条件搜索特定的提交
- 退出某个提交
- 基于某个提交创建分支和标签
- 根据某个提交中的更改创建补丁
- 将整个存储库重置为某个提交
- 设置quickdiff基线并将其重置为某个提交
打开历史视图
历史视图可以通过打开
- 在 资源管理器中的Git版本控制下的任何资源上右键单击 Show In> History View(在所有Perspective中都不可用)
- 在资源管理器中的Git版本控制下,右键单击 Team> History in History中的任何资源
- 单击 窗口>显示视图>其他...,然后选择 团队>历史记录
视图打开后,您可以**带选择的 链接 按钮,以使视图的输入与浏览器中的选择自动保持同步。
历史观的组织
历史视图被组织在几个窗格中:
上面的窗格是提交图表,以反向时间顺序显示提交日志(或提交历史记录)(最新的提交)。在提交图下方,默认有两个窗格:左侧是修订注释区域,其中显示提交消息和提交中文件或文件的文本差异,右侧是修订详细信息区域,它显示了提交所改变的文件的表格。
该表的第一列描述了每个文件的变化性质:
- 添加 该文件是由提交添加的
- 修改 该文件已被提交修改
- 删除 文件被提交删除
下部窗格的内容取决于上部窗格中的选择,并在此选择更改时自动更新。
通过右键单击上部窗格中的任意位置,并分别选择“ 显示修订注释” 和“ 显示修订详细信息”,可以分别打开和关闭两个较低的窗格 。
在提交图上方,当前输入可视化。输入始终是工作区资源,可以是项目,文件夹或文件。在输入的类型之后,将显示路径,后面跟着包含方括号中的资源的存储库名称。
使用历史视图
检查提交图
提交图区域是历史视图的主要部分。默认情况下,它显示当前签出的提交及其所有祖先,即列表中的第一个条目是签出的提交。以下图片用于解释历史视图的一些功能:
提交图中的每一行对应于一个提交。分支,标签和HEAD可视化如下:
- 本地分支的提示显示为绿色矩形
- 远程分支的提示显示为灰色矩形
- 本地HEAD显示为白色矩形
- 标签显示为黄色矩形
(我们的例子没有远程分支)。
左侧的行是实际的提交图,它显示了列表中提交的父子关系(每个提交至少有一个父级,除了存储库中的第一次提交)。可以有对应于分支操作的分叉和对应于合并操作的连接。在我们的例子中,在分支“beforeSplit”提交之后创建了一个“实验”分支,并且在“主”和“实验”分支中都更改了相同的文件。最后一次提交是合并提交,其中“实验”分支的内容与“主”分支合并。
可以通过标记提交并查看修订注释区域来检查确切的更改。在“修订注释”区域向下滚动时,可以看到更改的文本差异,在我们的示例中,它表示Project1 / f1 / file1.txt的内容已从“修改”更改为“主修改”。当选择下一个提交(对应于“实验”分支)时,会显示一个类似的差异,表示该文件的内容已从“已修改”更改为“已修改实验”。最新的提交是将“实验”合并为“主”的结果。因此,新承诺有两个祖先,“主”和“实验”线再次合并。
显示和比较文件的版本
如果当前输入已经是一个文件, 在提交上右键单击 打开将打开一个编辑器,其文件内容对应于当前选定的提交。如果该文件在选定的提交中不存在,则会显示一条错误消息。点击 比较工作树 将打开一个比较编辑器,比较当前选定提交的文件内容与工作区中的文件内容。
在 开放 和 与工作树进行比较 的动作也可以通过双击来执行的承诺:如果“比较模式”工具栏按钮(见下文)已关闭, 比较与工作树 会被执行,否则 打开。
通过选择两个提交并右键单击比较,可以比较由当前输入过滤的两个提交的内容 。如果当前输入不是文件,则在Tree中有一个额外的菜单操作相互 比较。第一个动作打开Eclipse比较编辑器,第二个动作打开 Git树比较视图。
此外,可以选择任意数量的提交并右键单击 打开 以查看与所选提交相对应的文件的所有版本(每个版本将打开一个编辑器)。
如果当前输入不是文件,则不会有打开的菜单操作 。但是,可以双击“修订详细信息”区域的条目。如果比较模式处于活动状态,将打开一个比较编辑器,显示当前所选提交中双击文件的更改(即,当前选定提交中的文件内容与此提交的祖先的文件内容的差异)。如果比较模式未处于活动状态,则会显示一个文件内容对应于当前所选提交的编辑器。
使用过滤器设置
可以使用相应的工具栏操作更改过滤器设置(请参见下文)。默认情况下,“资源”设置处于活动状态,即只有列表中显示包含当前输入更改的提交。如果当前输入不是文件,则显示所有提交,其中包含当前输入的任何子项的更改。
如果过滤器设置为“资源”,并且当前输入是文件,则提交列表仅包含那些包含该文件更改的提交。分析该文件的历史记录时,这非常有用。但是,在某些情况下,还可以看到其他不改变实际文件的提交。例如,查看文件中的某个给定更改是否在某个不会更改该文件本身的其他提交之前或之后可能很有趣。在我们的示例中,我们可能想知道给定的更改是否在标记为“Project1”的提交之前“之前”或“之后”。通过将过滤器设置从“资源”更改为“存储库”,这很容易完成:
其他两个设置(“文件夹”和“项目”)的行为类似之处在于它们分别包含更改当前输入的父文件夹中的任何资源或当前输入的项目中的任何资源的提交。在我们上面的示例中,如果使用过滤器设置“Project”,则不会显示提交“将Project2添加到存储库”,是否不会更改当前输入项目中的任何内容(Project1 / f1 / file1.txt )。
或者,为了查看与特定项目有关的所有提交,可以更改该项目的历史视图输入。但是,文件特定的菜单操作将不可用。
工具栏操作
历史视图工具栏中的前四个按钮是刷新,选择链接,固定和导航历史记录的标准按钮。
找
如果“查找”工具栏按钮处于关闭状态,则视图的下部会显示一个搜索栏,允许在提交日志中搜索提交。根据搜索栏下拉列表中的设置,搜索提交的标题,评论,作者或提交者。
找到的搜索结果高亮显示,“Next”和“Previous”按钮允许跳转到符合搜索条件的下一个或上一个提交:
过滤器设置
视图工具栏中的下一个四个切换按钮控制显示的提交相对于当前输入的过滤方式: 按钮用作单选按钮,即四个按钮之一必须始终处于关闭状态。
- 如果“Repository”按钮处于关闭状态,则不会过滤提交日志,并显示从当前签出的分支可达到的所有提交(或所有提交,请参阅下面有关“所有分支”操作的提交)
- 如果“项目”按钮关闭,则提交日志将被过滤以显示影响包含当前输入的项目中的任何资源的所有提交
- 如果“文件夹”开关处于关闭状态,则会过滤提交日志以显示影响当前输入的父文件夹中的任何资源的所有提交
- 如果“资源”按钮关闭,则提交日志将被过滤以仅显示影响当前输入的提交; 视图菜单项“ 显示”>“跟随重命名” 允许切换是否选择资源的重命名应该由此过滤器跟随
请注意,并非所有滤波器设置和电流输入的组合都是有意义的; 例如,如果当前输入是项目,则“项目”选项实际上与“资源”选项相同。
比较模式
下一个按钮又是一个切换,**“比较模式”。如果它停机,某些双击操作(见上文)将打开比较编辑器而不是普通的编辑器。
所有分支机构
该切换**“所有分支”模式。默认情况下,只有那些提交日志中显示的提交可以从当前签出的提交中获得,即,提交图以当前签出的提交结束,而较新的提交不会显示。如果此按钮处于关闭状态,则所有提交都将显示在提交日志中。这在我们的例子的下面的图片中说明。“分裂之前”的分支目前已被检出; 通过**切换,新的分支将变为可见:
查看菜单操作
配置视图
大多数工具栏操作也可以在查看菜单中找到。另外,可以使用以下切换:
“附加参考”切换在获取,重定位,合并等操作期间创建的某些Ref的可见性,例如FETCH_HEAD,ORIGIN_HEAD ...这可以有助于消除历史视图中的混乱。
“注释历史记录”在“修订注释”区域切换Gerrit评论注释的显示。
如果使用“资源”过滤器,“跟随重命名”切换是否应在历史视图中遵循所选资源的重命名。此首选项还可以在首选项向导 首选项>团队> Git>历史记录>关注重命名中进行配置。
“修订注释”切换修订注释区域的可见性。
“修订细节”切换“修订细节”区域的可见性。
如果选中“相对日期”,则提交日期将显示为相对日期而不是绝对日期。
“电子邮件地址”切换提交者电子邮件的显示。
子菜单“In Revision Comment”打开一个子菜单,其中有更多的切换来管理修订注释区域的外观:
“标签序列”允许显示/隐藏指示给定提交的祖先列表中的最后一个标签和给定提交的后续列表中的下一个标签,即给定提交之前/之后的标签。
“包装注释”和“填充段落”切换修订注释区域内的格式。
“修订详细信息”和“修订注释”也可通过右键单击“提交图表”区域中的任意位置获得。
通过右键单击修订注释区域中的任意位置,也可以使用“标签序列”,“包装注释”和“填充段落”。
上下文菜单操作
“提交图表”区域中的上下文菜单略有不同,具体取决于当前是文件还是文件夹/项目。以下菜单条目始终可用:
如果当前输入是文件,则还有其他一些可用的操作; 如果只选择一个提交,则有三个附加选项:
如果选择了两个提交,菜单将如下所示:
如果选择了两个以上的提交,只有“打开”操作和“Quickdiff”菜单可用。
与工作树比较
只有当前输入是文件并且选择了单个提交时,此操作才可用。它将打开一个比较编辑器,将所选提交的文件内容与工作树中的文件内容进行比较。
相互比较
此操作仅在当前输入是文件并且选择了两个提交时才可用。它将打开一个比较编辑器,比较所选提交的文件内容。
打开
此操作仅在当前输入是文件时才可用。它将为每个选定的提交打开一个编辑器,显示给定提交的文件内容。
查看
这将检出当前选定的提交。如果此提交存在分支,则会检出分支,如果此提交存在多个分支,则会显示一个对话框,询问应检出哪个分支。如果不存在提交的分支,则提交将被检出并且HEAD将被分离。
创建分支...
在当前选定的提交上创建一个分支。将显示一个对话框询问分支名称以及是否应检出新创建的分支。
删除分支
如果当前选定的提交没有检出,则该操作将被启用。如果此提交中有一个分支未被签出,则此操作将立即删除该分支。如果存在多个这样的分支,将显示一个对话框,询问哪些分支应该被删除。如果提交在“删除分支”上无法访问,将显示一个确认对话框以防意外提交的意外不可达。
创建标签...
在当前选定的提交上创建一个标签。将显示一个对话框,询问标签名称和标签消息。
创建补丁...
此操作在存储库的第一次提交中不可用。它将创建一个包含当前所选提交与该提交的前任相比所做更改的修补程序。将显示一个对话框,询问是否应该将补丁创建为文件或剪贴板,以及是否使用通用补丁格式的Git补丁格式。
樱桃采摘
在当前签出的提交之上应用所选提交引入的更改。
恢复提交
通过在当前签出的提交之上创建一个新的提交来还原所选提交引入的更改。
去
将选定的提交合并到当前签出的分支中。
在最重要的基础上
在选定的提交之上重新绑定当前签出的分支。
重置>软/混合/硬
此操作将包含当前输入的存储库重置为当前选定的提交。根据子菜单的选择,将执行软重置,混合重设或硬重置。
Quickdiff>将Quickdiff Basline重置为HEAD
Quickdiff>将Quickdiff Basline重置为HEAD的第一个父级
这两个操作将存储库的quickdiff基线设置为HEAD或HEAD的父级。即使选择了多个提交,这些操作也始终可用。
Quickdiff>设置为基线
此操作仅在选择单个提交时可用; 它会将存储库的quickdiff基线设置为选定的提交。
复制
将当前选定的提交或提交的ID复制到剪贴板中。
显示修订评论
切换“修订注释”区域的可见性。
显示修订详情
切换“修订细节”区域的可见性。
包装评论
仅当右键单击修订注释区域时才可用。如果**,则注释将被自动包装以填充显示区域,否则将使用提交消息的包装。
填写段落
仅当右键单击修订注释区域时才可用。如果处于活动状态,则会显示提交消息而不会有不必要的换行符
拖放支持
您可以将提交图上的提交拖放到Mylyn Task上或拖放到 硬盘上的文件夹中。在这两种情况下,EGit都会自动创建一个可能附加到磁盘上的错误或存储的补丁。
使用修订细节区域
版本详细信息区域显示了所选提交更改的文件的表格。选择上下文菜单操作 在选定文件上显示注释将在(只读)编辑器中打开该文件,并显示包含文件中每行的提交和作者信息的注释标尺。请参阅 本节。
同步视图
菜单命令“ 团队”>“同步工作区” 将启动“同步视图”。此视图允许您检查本地工作区和本地或远程跟踪分支中的资源之间的差异。或者,您可以比较本地和远程跟踪分支。比较两个远程跟踪分支以及同步视图上的菜单命令在此EGit版本中尚不可用,并将在未来版本中提供。
以下是Git Synchronize View的内容:
同步状态
Synchronize View显示工作空间或本地分支中资源的同步状态,与另一个本地或远程跟踪分支中代表远程资源库分支状态的资源同步状态。此状态通过使用图标显示,也可以配置为将状态显示为附加到资源名称的文本。
下表显示了这些图标的说明:
模式
同步视图可以使用工具栏操作或视图下拉菜单中的菜单项进行过滤。模式可用于仅显示传入,传出或冲突的更改。
楷模
同步视图能够显示资源的不同模型表示。每个产品可能包含自己的产品特定表示。Eclipse SDK带有三种模型:
- 工作区模型
- 显示基于资源的模型。此模型的布局选项可以通过下拉菜单中的“首选项”对话框进行控制。Workspace模型的布局选项为
- 平面布局
- 将所有不同步的资源显示为其项目的直接子项。
- 树布局
- 显示项目资源管理器中显示的资源层次结构。
- 压缩文件夹
- 显示按项目分组,然后按文件夹分组的更改。这导致层次结构最多为三层,文件夹路径被压缩到单个层次(类似于Java包)。
- Java模型
- 显示一个基于Java的模型(类似于Package Explorer中显示的模型)。
- Git提交
- 显示一个基于Git Commit的模型。此模型显示按提交分组的传入更改,这对于查看谁释放内容和原因很方便。对于传出更改,您可以通过创建提交来 创建提交。Git提交描述的显示格式可以 在标签Other中的 Team> Git> Label Decorations下的首选项中配置 。
除了模型之外,还有一个 平面演示 ,它将所有不同步的元素显示为顶层元素。
导航
“同步”视图提供了用于浏览视图中的更改的工具栏操作。这些操作不仅可以在文件之间导航,还可以从文件中的更改更改。
同步视图中的树可以很容易地从工具栏展开和折叠。
Git树比较视图
该视图将通过一些Compare With 操作打开 (请参阅 比较内容)。从资源(例如项目或文件夹)启动时,它将看起来类似于工作区中的资源。但是,文件上的通常图标将被替换为显示更改状态的图标(添加,删除,更改或未更改)。
可以浏览更改并双击文件将打开该文件的比较编辑器(这只对“已更改”文件有意义,如果添加或删除文件,比较编辑器的一侧将为空,而未更改的文件将在编辑器的两侧显示相同的内容):
可以通过单击工具栏中的“隐藏等同内容的文件”按钮来隐藏未更改的文件。
Git树比较视图也可以在没有工作区资源作为起点的情况下启动(例如,当历史视图的输入是存储库而不是工作区资源时,通过比较历史视图中的两个提交)。在这种情况下,将显示存储库的完整内容,并且项目和文件夹都显示为简单的“文件夹”图标:
Git Staging View
该视图提供了用于git status
显示工作树中所做更改的等效项 。尚未转移到git索引的未暂停更改显示在“ 未更改更改” 窗格中,已在“ 暂存更改”窗格中显示 已被“添加”(暂存)到Git索引的更改 。默认情况下,这些窗格显示在行布局中,可以通过列布局选项将其更改为列布局 。默认情况下,Staged窗格和Unstaged Changes窗格显示文件的完整路径。可以通过“ 显示文件名优先”选项来配置它们,以 首先显示文件名,然后显示文件所在的目录。
双击已修改的文件以打开比较视图。如果从“未冻结”窗格触发,比较视图将显示尚未分阶段的更改。从“分段”窗格触发时,它将显示已经分阶段进行的更改。要在编辑器中打开 文件,请在文件的上下文菜单中使用“ 打开工作区版本”操作。
要演示文件,请将其从“未分级更改” 窗格拖到 “ 分段页面” 窗格中。或者, 对“ Unstaged Changes” 窗格中文件的上下文菜单使用 Add to Git Index操作 。在 与Git的索引文件替换 操作将替换选定的文件在工作树。如果该文件未冻结,它将被重置。如果它被暂存,工作树版本将被Git索引中的暂存版本替换。
要unstage文件,从拖动它 暂存的变更 窗格的 不分级的变化 窗格。或者, 在文件的上下文菜单中使用 从Git索引删除操作。
提交操作只会提交阶段性更改 - 与git commit
原生git中的操作类似 。集成的提交消息编辑器允许编辑提交的提交消息。与提交对话框不同,分段视图可以在进行更改时保持打开状态。这允许递增地写入提交消息以及更改。正在编辑的提交消息与存储库相关联,分段视图与链接。它不会被持久存储,并且如果分段视图或Eclipse被关闭,它将会丢失。
要提交,请 在提交消息文本字段中按 Ctrl + Enter (Mac OS X上的 ' Command + Enter ),或者单击 提交 或 提交并按下按钮。
部分分期
有时只提交文件的一些更改很有用。例如,在处理某个功能时注意到与该功能无关的错字或小错误。
为了只提交某些更改,这些更改必须首先进行。为此,请双击Unstaged Changes 窗格中的文件 。这将打开比较编辑器。左侧是工作区版本,右侧是索引(分段)版本。
比较编辑器的两侧都是可编辑的。当更改右侧(索引)中的某些内容并保存时,该文件将在“ 分阶段更改” 窗格中显示,并在提交时正好提交该内容。
要 放置一组更改的线条, 可以使用“ 从左到右复制当前更改”工具栏按钮(箭头图标)。
Git Reflog视图
Reflog视图显示选定存储库的Git reflog。它支持通过选择视图右上方的超链接ref名称来显示特定分支的reflog。双击或选择上下文菜单操作 在提交查看器中 打开reflog条目,在提交查看器中打开相应的提交。上下文菜单操作 Checkout 将签出选定的提交,并且 HEAD将分离。
Git网址
通常,Git URL由传输协议方案,远程服务器的地址和远程服务器中的存储库路径以及一些认证协议(也包括用户标识)组成。
EGit支持以下协议
- 文件 - 直接访问存储库的文件系统。
- git - 最高效的内置git协议(默认端口9418)。该协议不提供认证。通常用于对存储库进行匿名读取访问。
- ssh - 通过安全shell(SSH) 协议的Git 。通常用于对存储库进行身份验证的写入访问。
- http - 超文本传输协议 可以通过防火墙隧道传输。
- https - 超文本传输协议安全 可以通过防火墙隧道传输。
- ftp - 文件传输协议
- sftp - SSH文件传输协议
Git URL在使用时使用
Git参考
Git引用也很快就被称为 Refs。
它们包括
- 分支机构
- 远程跟踪分支
- 标签
它们全部用路径命名,使用'/'作为路径分隔符,并以“refs”开头。
- 本地分行以“refs / heads /”开头
- 远程跟踪分支以“refs / remotes /”开头。远程跟踪分支位于远程存储库中的代理分支,以便当没有与存储库的连接可用(脱机)时,也可以查询它们在上次传输操作时的状态。
- 标签以“refs / tags /”开头
只要缩写形式是唯一的,参考名称可以缩写。
例如
- “master”是“refs / heads / master”的简称
- “origin / master”是“refs / remotes / origin / master”的简称
- “v1.0.1”是“refs / tags / v1.0.1”的简称
Refs中还有一些“保留”名称,可用于某些场景:
参考名称 | 备注 |
头 | 指向当前结帐提交 |
FETCH_HEAD | 指向最后一次读取操作的结果 |
ORIG_HEAD | 指向在合并或重建操作启动之前签出的提交 |
有关Ref名称的完整列表以及优先顺序,如果多个引用具有相同的缩写形式,请参阅git rev-parse的 “指定修订”部分 。
Refspecs
提取和推送操作使用“refspec”来描述远程Ref 和本地 Ref之间的映射 。在语义上,它们定义了本地分支或标签如何映射到远程存储库中的分支或标签。在本地git中,它们以<src>:<dst>格式与冒号组合,前面带有可选的加号,+表示强制更新。在EGit中,它们可以在“ 推式参考规格” 和“ 取回参考规格” 和其他对话框中以表格形式显示和编辑 。
RefSpec的“左侧”称为源,“右侧”称为目的地。根据RefSpec是用于读取还是用于推送,源和目标的语义不同:对于Push RefSpec,源表示源存储库中的Ref,目标表示目标存储库中的Ref。
推送Refspecs
Push RefSpec的一个典型例子可能是
HEAD:参考文献/头/主
这意味着当前签出的分支(如HEAD引用所表示的,参见 Git引用)将被推送到远程仓库的主分支中。
获取Refspecs
Fetch RefSpec的典型示例可能是
裁判/头/ *:参/遥控器/产地/ *
这意味着远程存储库中的所有分支都将被提取到本地存储库的相应远程跟踪分支中。
遥控器
远程用于管理从您的存储库跟踪其分支的存储库(“远程”)。
在EGit中,Remotes是在什么时候定义的
- 按照惯例,从另一个存储库克隆一个存储库,这个新创建的存储库名为“origin”。如果您更喜欢不同的名称,克隆向导允许指定该名称。
- 在存储库视图中定义远程
远程首先为 你的分支机构定义一个 名字,这很重要,因为你可能想跟踪不同存储库中的分支,因此这个名字有助于理解某个操作正在处理的存储库。此外 ,为给定Remote指定的Refspecs定义了 本地存储库中分支和标记到远程存储库中分支和标记的 映射。您可能希望为入站或出站传输操作使用不同的映射,因此 编辑人员 可以定义EGit中提供的提取和推送配置。
Git忽略
.gitignore
位于工作树中的文件指定有意不应该被git跟踪的文件。他们只关注那些还没有被git跟踪的文件。为了忽略已跟踪文件中的未提交更改,请参阅 假定不变的操作。
.gitignore
文件中的每一行 定义了一个模式。Git检查忽略工作树层次结构中从高到低的模式。较高级别.gitignore
文件中定义的模式被较低级别中定义的模式 覆盖。项目所有工作中应忽略的文件通常包含在项目的存储库中,以便在团队中轻松共享。
模式格式定义:
- 空白行被忽略
- 以#开始的行 作为注释
- 可选的前缀 ! 否定该模式。再次包括由匹配的先前模式排除的文件。以斜线结尾的模式只匹配目录,但不匹配文件或符号链接。
- 不包含斜杠的模式被视为与相对于.gitignore文件位置的路径匹配的外壳全局模式
- git将模式视为fnmatch(3)中定义的shell球体,
- 在模式中通配符不匹配 / 路径名
- 一个前导斜杠匹配一个路径名的开头
EGit Ignore 菜单操作 将选定资源添加到 .gitignore
资源父目录中的文件。要输入其他忽略模式,请使用文本编辑器。
注意: EGit还没有尊重 .gitignore
Eclipse项目之外的文件,所以如果您有一个包含多个项目的存储库,则应.gitignore
为每个项目添加一个文件,而不是在根目录中添加一个文件。
用于PDE构建的Git Fetch Factory
作为EGit的PDE工具的一部分,org.eclipse.egit.fetchfactory 插件中包含一个用于Git的PDE Build fetch工厂 。
映射文件的文件格式: type @ id,[version] = GIT,args
其中, args 是键值对的逗号分隔列表。
接受的 参数 包括:
- 标记* - 必需的Git标记
- 回购* - 强制回购地点
- 路径 - 相对于指向元素的repo的可选路径(否则,假定元素位于存储库根目录)
- prebuilt - 可选布尔值,指示路径指向存储库中的预先构建的包
提取是通过三个步骤来实现的:
- 存储库被克隆到本地光盘。如果它已经存在,则认为它以前被克隆过,并且只提取新的提交
- 指定的标签将在本地克隆中签出
- 路径的内容将被复制到最终的构建位置
例如:It /用户指南
入门
概观
如果您通常不熟悉Git或分布式版本控制系统,那么您可能首先需要阅读 Git for Eclipse用户 。更多的背景和细节可以在Pro Git的在线图书中找到 。
如果您来自CVS,那么您可以找到适用于Git Platform-releng / Git Workflows的常用CVS工作 流程。
基础教程:将项目添加到版本控制
组态
识别你自己
无论何时更改存储库的历史记录(技术上,每当创建提交时),Git都会跟踪创建该提交的用户。身份证包含一个姓名(通常是一个人的姓名)和一个电子邮件地址。这些信息存储在~/.gitconfig
专用**下的文件中 。
EGit会在您创建第一次提交时询问您的信息。默认情况下,这个对话框只显示一次,直到你创建一个新的工作区或在Git首选项页面勾选“显示初始配置对话框”复选框:
如果您想稍后再查看,也可以取消选中“不要再次显示此对话框”。
您可以随时使用Git配置更改此信息,而不是使用此对话框:
- 点击 首选项>团队> Git>配置
-
单击 新建条目 并输入键值对
user.email
和user.name
在Windows上设置主目录
将环境变量添加 HOME
到您的环境变量中。
- 在Windows 7中,在开始菜单中输入“environment”
- 选择“编辑您的帐户的环境变量”
- 点击“新建”按钮。
- 在名称字段中输入“HOME”
- 在值字段中输入“%USERPROFILE%”或其他路径。
-
单击确定,然后再次确定。您刚刚在Windows上添加了主目录。
EGit需要这个路径来查找用户配置(.gitconfig)。 HOME
应该指向你的主目录,例如 C:\Users\Tom
。 确保正确的情况! 例如, C:\users
而不是 C:\Users
可能会导致问题!
如果 HOME
变量未定义,则主目录将通过连接HOMEDRIVE
和 来计算 HOMEPATH
。
如果两个 HOME
和 HOMEDRIVE
没有定义 HOMESHARE
将被使用。
如果HOME
未明确定义,EGit会显示警告 。请记住,如果您在Eclipse运行时设置HOME环境变量,则仍会看到以下警告。您必须重新启动Eclipse才能识别HOME值。
指出系统范围的配置
如果您使用Git for Windows作为EGit的伴侣,请确保EGit知道Git的安装位置,以便找到“系统范围设置”,例如core.autocrlf的设置。转到设置并查看Team> Git> Configuration,然后点击System Settings标签。
如果您在安装Git for Windows时从命令行提示中选择了其中一个选项来使用Git,则系统范围设置的位置将填充一个路径,并且一切正常。如果没有,使用浏览按钮找到Git的安装位置,例如C:\ Program Files(x86)\ Git。
此建议也适用于其他Git包装的用户,例如Cygwin或TortoiseGit下的Git。
非Windows用户理论上应检查此设置,但系统范围设置通常不在非Windows平台上使用。
创建存储库
-
创建一个新的Java项目
HelloWorld
。(在这种情况下,该项目是在Eclipse Workspace之外构建的。)
- 选择该项目,然后单击 文件>团队>共享项目
- 选择存储库类型 Git 并单击 下一步
-
要配置Git存储库,请选择新项目
HelloWorld
-
点击 Create Repository 为项目初始化一个新的Git仓库
HelloWorld
。如果您的项目已经驻留在现有Git存储库的工作树中,则会自动选择该存储库。
- 单击 完成 关闭向导。
-
项目后面的装饰器文本“[master]”显示该项目在主 分支上的存储库中被跟踪, 并且问号装饰器显示
.classpath
and.project
和.settings
文件尚未受版本控制
跟踪变化
- 在项目节点上单击 团队>添加。(这个菜单项可能会读取 最近版本的Egit的Add to Index)
- 在 + 装饰显示,目前该项目的文件添加到版本控制
-
将“bin”文件夹标记为“Git忽略”,方法是右键单击 该文件 夹并选择 Team> Ignore或通过
.gitignore
在项目文件夹中创建 具有以下内容的文件
/箱
-
这
bin
将从Git的被跟踪文件列表中排除该 文件夹。 -
添加
.gitignore
到版本控制(团队>添加):
-
您可能必须设置包资源管理器筛选器才能看到包资源管理器中
.gitignore
显示的内容。要访问过滤器,请选择Package Explorer选项卡右侧的向下箭头以显示View Menu。
-
从视图菜单中选择 Filters ...,将出现Java Element Filters对话框。取消选择顶部条目以显示以开头的文件。(期)如
.gitignore
。
- 在项目上下文菜单中单击 团队>提交
-
输入提交消息来解释您的更改,第一行(后跟一个空行)将成为此提交的简短日志。默认情况下,作者和提交者来自
.gitconfig
主目录中的 文件。 - 您可以点击 Add Signed-off-by 添加 Signed-off-by: 标签。
- 如果您正在提交其他作者的更改,则可以更改作者字段以提供作者的姓名和电子邮件地址。
- 点击 确认 提交您的第一个更改。
- 请注意,提交文件的修饰器已更改。
检查历史
- 从上下文菜单中单击 团队>历史显示以检查资源的历史记录
-
创建一个新的Java类
Hello.java
并实现它 - 将它添加到版本控制并提交您的更改
- 改进你的实现并提交改进的类
- 现在资源历史记录应该显示2个提交此类的提交
- 点击 历史视图中的 比较模式切换按钮
-
双击
src/Hello.java
历史视图的资源列表以在比较视图中打开上次提交的更改
恭喜,您刚刚掌握了使用Git的第一个项目!
GitHub教程
创建本地存储库
- 按照 EGit / User Guide / Getting Started 创建一个新的本地存储库(使用您的内容而不是演示项目)
在GitHub创建存储库
- 在GitHub上创建一个新的存储库
在下一个屏幕上,您可以看到您可能用来访问新的新存储库的URL:
- 单击 SSH 以选择 SSH协议。它可以用于读写访问
- 点击 HTTP 选择 HTTP协议。它也可以用于读写访问。
- 点击 Git Read-Only 来选择 用于克隆的匿名 git协议。这是git支持的最有效的协议。由于 git协议 不支持身份验证,因此通常用于提供对公共存储库的有效只读访问。
Eclipse SSH配置
- 打开Eclipse 首选项 并确保您的SSH2主页配置正确(通常是 〜/ .ssh)并包含您的SSH2**
- 如果您还没有SSH**,您可以在第二个对话框的Key Management (**管理)对话框中生成它们 ,请使用一个好的密码短语来保护您的私钥,更多详细信息请参阅 “使用**密码短语”
- 将您的公共SSH**上传到您的 GitHub帐户设置
推上游
- 点击 团队>远程>推送... 并复制并粘贴新的GitHub存储库的SSH URL
- 如果您位于不允许SSH通信的防火墙后面,请改用GitHub HTTPS URL,并提供您的GitHub用户和密码,而不要使用上传的公用SSH**。要将您的凭证存储在Eclipse安全商店中,请点击 安全商店中的商店。
- 注意: 许多HTTP代理被配置为阻止包含用户名的HTTP URL,因为在HTTP URL中公开用户名被认为是安全风险。在这种情况下,请从HTTP URL中删除用户名,并仅在用户字段中提供该用户名。它将作为HTTP标头发送。
- 点击 下一步 ,在第一个连接上接受GitHub的主机**。
- 输入您的SSH**的密码,然后单击 确定。
- 在下一个向导页面上,单击 添加所有分支规范 以将本地分支名称1:1映射到目标存储库中相同的分支名称。
- 点击 下一步。推送确认对话框将显示将推送到目标存储库的更改的预览。
- 单击 完成 确认您要推送这些更改。
- 下一个对话框报告推送操作的结果。
- 将您的浏览器指向您的GitHub存储库以查看您的新存储库内容已经到达
EclipseCon 2012 Git教程
在这里找到所有练习和幻灯片 。
按照 练习#1 准备Git教程。
概念
Git建立在一些简单而强大的想法之上。了解它们有助于更轻松地了解git如何工作。
知识库
存储库或对象数据库存储构成项目历史的所有对象。此数据库中的所有对象都通过 对象内容的安全20字节SHA-1散列标识 。这有几个好处:
- 比较两个对象归结为比较两个SHA-1哈希值
- 由于对象名称是在每个git存储库中以相同的方式从对象内容中计算出来的,所以相同的对象将以相同的名称存储在恰好包含此对象的所有存储库中
- 一旦创建对象就不会改变(显而易见,因为改变内容意味着必须计算新的散列并分配新名称)
- 通过检查SHA-1对象名称是否仍然是对象内容的安全散列,可以轻松检测到存储库损坏
Git有四种对象类型:
- 一个 Blob对象 存储文件内容
- 一个 树对象 存储的目录结构和包含 的Blob对象 和其他 树对象 与自己的文件系统名称和模式一起
- 甲 提交对象 表示的目录结构的快照的提交时间,并具有连接到它的前身 提交对象,其形成在所述储存库历史库修订一个非循环图。
- 一个 标签对象 是一个符号命名的链接到包含对象名称和关于谁创造了标签和签名信息的一个被引用的对象和可选信息的类型另一个仓库对象。
对象数据库存储在 .git/objects
目录中。对象既可以作为松散对象存储,也可以以包格式存储,将多个对象有效地封装到一个文件中,以便高效地存储和传输对象。
相信
Git通过安全的SHA-1哈希提供了一个内置的信任链,它允许它验证从(可能不受信任的)源获得的对象是否正确并且自创建以来未被修改过。
如果您获得签名标签,例如您可以验证的项目版本,例如标签(例如项目负责人)的公共签名**git可确保信任链覆盖以下内容:
- 签名标签标识一个提交对象
- 提交对象恰好表示一个项目修订,包括其内容和历史记录
- 提交对象包含blob对象树和其他表示项目修订目录结构的树对象
- blob对象包含此项目修订的文件内容
可以使用SHA-1算法检查所有涉及的对象名称的一致性,以确保项目修订的正确性,并以此方式确保可以信任整个历史记录。
指数
在 GIT中索引 是存储在一个二进制文件 .git/index
包含文件名,文件模式的排序列表目录,文件用于有效地检测文件的修改和斑点对象的SHA-1的对象名称的元数据。
它具有以下重要属性:
- 该索引包含生成单个唯一定义的树对象所需的全部信息。例如,提交操作会生成此树,将其存储在对象数据库中并将其与提交相关联。
- 该索引可以快速比较其定义的树与当前工作目录。这是通过在索引数据中存储关于涉及文件的附加元数据来实现的。
- 索引可以高效地存储合并涉及的树之间的合并冲突信息,以便为每个路径名提供有关所涉及树的足够信息以启用三向合并。
分行
Git中的分支是对提交的命名引用。有两种类型的分支,即“本地”和“远程跟踪”分支,用于不同目的。
当地分支机构
无论何时提交对(本地)存储库的更改,都会创建一个新的提交对象。如果没有其他任何方式,要记录存储库中的更改非常困难,特别是当其他提交已添加到存储库时,例如由于远程存储库的更新或检出另一个提交时。
本地分支通过提供可以找到“当前”提交的(本地)名称来帮助完成此任务。当更改提交到本地存储库时,分支会自动更新为指向新创建的提交。
另外,可以将一个所谓的上游配置添加到本地分支,这在与远程存储库同步时会很有帮助。
远程追踪分支
从远程存储库进行克隆和提取时会自动创建远程跟踪分支。本地存储库中的远程跟踪分支总是对应于远程存储库中的(本地)分支,并且这样的分支的名称遵循特定的约定。
远程跟踪分支指向与远程存储库中对应分支相同的提交(在克隆/提取时)。
远程跟踪分支可用于自动创建本地分支的上游配置。
工作目录
工作目录是用于修改下一次提交的文件的目录。默认情况下,它位于.git目录的上一级。进行新的提交通常涉及以下步骤:
- 检出新提交应基于的分支,这将更改工作目录,以便它反映 分支的 HEAD修订。
- 在工作目录中进行修改
- 告诉git这些修改(添加修改后的文件)。这将修改后的文件内容传输到对象数据库中,并准备要在索引中提交的树。
- 将索引中准备的树提交到对象数据库中。
- 结果是一个新的提交对象, 当前分支的 HEAD移动到新的提交。
记录存储库中的更改
您从全新的本地存储库分支结帐开始。每当您想要记录更改的状态时,您都希望进行一些更改并在存储库中记录这些更改的快照。
工作目录中的每个文件都可以 跟踪 或不 跟踪。
- 跟踪的文件是最近一次快照中的文件或新近进入 索引的文件。它们可以是 未经修改, 修改或上演的。
- 未追踪的文件是不在最后一个快照中的所有其他文件,并且尚未添加到 索引中。
当您第一次克隆存储库时,工作目录中的所有文件都将被跟踪 并且 不会被 修改, 因为它们已被新签出,并且您尚未开始编辑它们。
当你编辑文件时,git会识别出自 上次提交以来修改过的文件,所以它们会被 修改。您 阶段 修改后的文件到索引,然后提交阶段性变化和周期重复。
这里说明这个生命周期
任务
创建存储库
在Eclipse中使用Git存储库的注意事项
短篇小说
使用EGit设置Git存储库时,有两个建议可用于创建“生产性”(而不是“操场”)存储库:
-
不要在Eclipse工作区内创建存储库
- 克隆或创建存储库时要小心
- 确保正确使用Git共享向导
-
不要以root身份创建Eclipse项目的Repository
- 确保正确使用Git共享向导
第一种情况是在克隆或创建存储库期间指定工作区文件夹时发生。
当您在工作区中手动创建的Eclipse项目中使用Git共享向导时,如果不采取预防措施(该向导已在最新版本中修复),上述两种情况都会发生。
下面你会发现这些建议的一些动机。
更长的故事
Eclipse工作区和存储库工作目录
可以通过不同的方式创建Git存储库,例如通过从现有存储库进行克隆,从头创建一个或使用EGit共享向导。
在任何情况下(除非你创建一个“裸”存储库,但这里没有讨论),新的存储库本质上是一个本地硬盘上的文件夹,它包含“工作目录”和元数据文件夹。元数据文件夹是一个名为“.git”的专用子文件夹,通常称为“.git-folder”。它包含实际的存储库(即提交,参考,日志等)。
元数据文件夹对于Git客户端是完全透明的,而工作目录用于将当前签出的存储库内容公开为工具和编辑器的文件。
通常,如果这些文件将在Eclipse中使用,则必须以某种方式将它们导入到Eclipse工作区中。为了做到这一点,最简单的方法是检入。“导入现有项目”向导可以从中轻松创建项目的项目文件。因此在大多数情况下,包含Eclipse项目的Repository结构看起来类似于这样的东西:
启示
以上含义如下:
- 将项目设置为Repository的根文件夹可能不是一个好主意
- 原因是你将永远无法将另一个项目添加到此存储库,因为.project文件将占据根文件夹; 您仍然可以将项目添加为子文件夹,但是这种项目嵌套已知会导致遍布各处的许多问题。为了添加另一个项目,您必须将项目移动到存储库中的子文件夹,并将第二个项目添加为另一个子文件夹,然后才能提交此更改。
- 将您的Repository放在Eclipse Workspace之外是一个好主意
- 有几个原因:
- 新的存储库将把Eclipse工作区的完整文件夹结构视为(潜在的)内容。这会导致性能问题,例如在提交前计算更改(例如,将扫描完整的.metadata文件夹); 通常情况下,工作空间将包含死文件夹(例如删除的项目),这些文件夹在语义上与EGit无关,但不能轻易排除。
- 元数据(.git-)文件夹将是Eclipse工作区的一个子元素。目前还不清楚这是否会导致Eclipse进行不需要的文件夹遍历。
- 通过销毁Eclipse工作区,您可以轻松销毁您的Repository
创建一个新的空的Git仓库
您可以先创建一个项目并在之后分享。共享项目向导支持创建Git存储库(请参阅 将项目添加到版本控制)。
您也可以从Git存储库视图创建一个新的空的Git存储库(请参阅 创建存储库)。
为多个项目创建一个Git存储库
您可以先在一个公共目录下创建多个项目,然后一次为所有项目创建一个公共存储库:
- 在共同目录下创建Eclipse项目,例如a,b,c例如 / repos / examples /
- 选择所有项目a,b,c - 从上下文菜单中单击 团队>共享项目> Git
- 按 下一步
- 选择所有项目a,b,c
- 该向导自动将默认存储库位置上移到父文件夹 / repos / examples /, 因为已选择多个项目
- 单击 创建存储库 并 完成
从现有的Git存储库开始
为了在Eclipse工作台中处理Git存储库的内容,必须将所包含的文件和文件夹作为项目导入。原则上,可以使用通用的“新建项目”或“导入...”向导来完成此导入,因为Git存储库的工作目录只是本地文件系统中的普通目录。但是,新创建的项目仍然必须与Git手动共享。“从Git导入项目”向导集成了项目导入和共享,并且还提供了一些额外的便利。
启动导入向导
要启动该向导,请单击 导入> Git> Git项目
如果您是在干净的工作区中开始的,则第一页将显示一个空列表:
在继续之前,您需要将一个或多个Git存储库添加到列表中。如果列表中已有存储库,则此步骤是可选的。
克隆或添加存储库
有两种方法可以将Git存储库添加到列表中:
- 克隆远程存储库
- 从本地文件系统添加一个现有的存储库
克隆存储库
如果您从远程存储库开始,则会使用第一个选项。克隆操作会将该存储库复制到本地文件系统。要启动克隆向导点击 克隆...。Cloning Remote Repositories中详细描述了克隆向导 。成功完成克隆操作后,新克隆的存储库会自动出现在列表中。
添加一个存储库
如果您的本地文件系统中已经有一个存储库,则第二个选项非常有用,例如,因为您之前已经克隆了它,您是从头开始创建它的,或者是从其他位置复制它的。点击 添加... ; 并在本地文件系统中选择一个目录。按 搜索 触发对此目录中包含的Git存储库的扫描。如果找到Git存储库,它们将被列出,您可以选择存储库来添加:
成功完成后,存储库列表应包含一些存储库:
从列表中选择一个存储库
您现在可以选择一个存储库并单击 下一步。在以下向导页面中,您将决定如何导入项目。
导入项目
此页面提供了一个带有单选按钮的组,允许您选择一个向导和一个目录树,该目录树可以选择允许您在工作目录中选择一个文件夹。
项目导入向导
导入现有项目
如果选择此单选按钮,向导将扫描本地文件系统中的 .project 文件并显示为导入而找到的项目。这是最舒适的解决方案,如果将.project 文件签入存储库,应该使用它 。
限制项目导入的范围
在这种情况下,底部的目录树处于活动状态。您可以 通过在此树中选择一个文件夹来限制.project文件的搜索 ,否则将扫描存储库的完整工作目录。在下一页中,将显示找到的项目列表(如果有的话)。这与通用导入现有项目 向导非常相似 ,但具有一些额外的过滤功能:
使用新建项目向导
选择此选项时,通用“新建项目”向导将打开。完成“新建项目”向导后,“从Git导入项目”向导将恢复并协助共享刚刚创建的项目。
在这种情况下,底部的目录树处于非活动状态,因为选择与“新建项目”向导无关。
导入为一般项目
当有没有这个选项可以帮助 的.project 可用的文件,也没有合适的“新建项目”向导适用于Git仓库的内容。如果选择,向导将生成一个 .project 文件并将该项目指向存储库工作目录的文件夹。结果是一个“总体项目”。
默认情况下,新生成的项目将指向Repository的工作目录。通过从底部目录树中选择一个文件夹,可以为该文件夹生成项目。
点击 Next 打开一个简单的对话框,输入新项目的名称和目录:
默认情况下,建议的项目名称与目录的名称相匹配。
使用远程存储库
克隆远程仓库
使用Git克隆向导,您可以使用不同的传输协议克隆远程存储库。
该向导可以从“从Git导入项目”向导启动,使用
导入...> Git> Git项目>下一步>克隆...
或者使用“ 克隆Git存储库” 工具栏按钮或视图菜单从“Git存储库视图”(在“ 管理存储库 ”中进行了介绍 ) 。
存储库选择
在向导的第一页上输入远程存储库的位置:
-
URI - 远程存储库的完整URI或文件系统上的路径。该字段会自动与其他字段同步。
请注意,您可以使用 本地文件... 按钮浏览本地目录,并且URI字段通过提供以前使用的值来提供内容帮助 - 主机 - 远程主机的名称,如果从文件系统克隆则为空。
- 存储库路径 - 远程存储库或文件系统的路径。
- 协议 - 下面描述的协议之一。
- 端口 - 端口号。
- 用户 - 用于认证的用户名。
- 密码 用于验证的密码。
- 存储在安全存储 中密码是否保存在Eclipse安全存储中。
支持以下协议:
- 文件 - 文件系统对存储库的访问。
- ftp - 文件传输协议
- git - 最高效的内置git协议(默认端口9418)。该协议不提供认证。通常用于对存储库进行匿名读取访问。
- http - 超文本传输协议 可以通过防火墙隧道传输。
- https - 超文本传输协议安全 可以通过防火墙隧道传输。
- sftp - SSH文件传输协议
- ssh - 通过安全shell(SSH) 协议的Git 。通常用于对存储库进行身份验证的写入访问。
注意: 如果您位于防火墙后面,则可能需要配置您的代理设置(首选项>常规>网络连接)。许多HTTP代理配置为阻止包含用户名(和/或密码)的URL,例如 http:// fred:[email protected]/egit.git, 因此建议使用 用户名和 密码 字段向导页面中,凭据将作为HTTP标头传输。
分支选择
在下一页选择哪些分支应从远程存储库中克隆:
如果您不确定您需要哪些分支,只需点击“全选”。
您可以通过使用列表上方的文本控件进行输入来按名称过滤分支。但是,请注意,已检查的分支将始终显示在列表中,即它们不会被过滤。
本地目的地
在下一页定义您想要在本地文件系统上存储存储库的位置并定义一些初始设置。
- 目录 - 将包含Git存储库的目录。如果它尚不存在,它将由向导创建。
- 初始分支 - 选择在哪里创建本地分支并初始签出。
- 远程名称 - 为远程存储库定义一个名称。默认值是“原点”。
可以在首选项Team> Git> Default Repository Folder中配置用于存储Git存储库的默认根路径
您可以按此 页面上的完成,或者 如果您正在使用 Gerrit Code Review 并且您想相应地配置您的存储库,请按 Next。
从特定位置克隆
EGit的Clone向导可以通过其他插件进行扩展,以便在托管git存储库的特定后端上搜索存储库。目前这种扩展可用于Github,很快将可用于Gerrit。对于您需要安装各自的Mylyn连接器。Gerrit Mylyn连接器扩展然后还将配置Gerrit工作的远程存储库。这也可以在Git存储库视图中完成或更改,请参阅 Gerrit配置。
当您安装了这样的扩展程序时,克隆向导打开并显示一个选择页面,您可以在该页面中选择要克隆的不同资源库源:
推送到其他仓库
推向上游
如果您正在使用具有所谓“ 上游配置 ” 的本地分支,则最便捷的推送方式依赖于此上游配置。
通常,本地分支机构是基于远程跟踪分支创建的。由于远程跟踪分支与远程关联,并且远程包含访问相应远程存储库所需的信息,因此可以在创建本地分支时自动创建此上游配置(请参阅 分支 以获取更多信息)。
从本地分支向上游推送时,推送不需要其他参数,因此可以在不显示基于存储的上游配置的另一个对话框的情况下执行。
为了推送上游,右键单击项目并选择 Team> Push to upstream 或右键单击存储库视图中的存储库,然后单击 推送到上游。Git Command Group也有一个可用的操作 。
然后在选择操作后立即执行推送。完成后,将显示一个确认对话框,显示有关推送的数据和/或错误消息的信息:
配置上游推送
可以使用确认对话框中的“Configure ...”(配置...)按钮(见上文)或通过右键单击项目并选择Team> Remote> Configure push to upstream ...来配置上游推送。
将显示一个配置对话框,用于配置推送URI和相应的分支映射(RefSpecs):
该对话框分为三个主要部分。在上部分中,显示了关于当前存储库和当前检出的分支的信息。外部组显示与当前分支关联的远程的推送配置(在我们的例子中,“组”文本中显示的“原点”)。
在这个特定的例子中,有一个警告消息,指出有几个分支使用名为“origin”的远程设备。这意味着推送配置中的更改将影响所有这些分支,而不仅仅是分支字段中显示的分支。
URI组包含两个控件,一个URI字段和一个Push URIs列表。如果列表为空,则URI字段中的URI将用于Push,如果至少有一个条目位于Push URIs列表中,则将使用列表中的URI。应该注意的是,如果Push URI列表为空,并且在此对话框中更改了URI,则新的URI也将用于Pull,因此在执行此操作时应小心。
RefMapping Group允许指定一个或多个RefSpecs(请参阅 Refspecs)推送。
“添加”将打开一个小向导,帮助创建RefSpecs。您也可以将剪贴板中的RefSpec粘贴到列表中。
点击“高级”控件将显示/隐藏“编辑(高级...)”按钮,允许更复杂的RefSpec编辑,类似于 下面的 推送向导。
下部按钮栏中的按钮允许您保存所做的更改并立即进行推送,保存更改而不提取,干运行(推送而不保存配置),恢复更改并取消。
直接推送
或者,您可以 在远程的推送规范上使用 直接推送支持。
推送向导
最强大(但也是最复杂的)方法是使用推送向导
团队>远程>推送...
推送URI
- 如果您已经在存储库视图中配置了推送规范,则也可以使用配置的远程存储库下的下拉列表在此处选择它 。 如果这个远程的Push Specification配置正确(即至少有一个URI和一个引用规范), Finish按钮将被启用。
- 否则,请单击 自定义URI 并输入要推送到的上游存储库的URI。
推参考规格
有关 更多解释,另请参阅 参考资料。
单击 Next
如果这是您第一次通过ssh连接到此存储库,则必须接受远程存储库的主机**
如果您的ssh**受密码保护(建议使用),您必须在此处输入密码
点击 添加所有分支规范
这是一种方便的方式,用于声明您想要将本地分支名称映射到要推送更改的上游存储库上的相同分支名称。
点击 添加所有标签规范 将本地标签1:1映射到您要推送到的存储库中的标签。
如果您想以不同的方式将本地分支映射到上游存储库中的分支,您可以按照以下方式定义更详细的映射规范
- 输入源和目的地ref或从下拉列表中选择已存在的分支
- 点击 添加规范
这会将新定义的映射转移到列表 规格中进行推送
其他常见推式规格:
- 根据你的昵称 joe,你可以将refs / heads / *映射 到 refs / heads / joe / *。如果多个用户想要在共同使用的公共存储库中的个人分支上发布他们的本地分支,这是非常有用的。
- 另一个通常的映射是将源头部头部映射到 目的地 头部/头部/头部。这意味着您想要将当前的HEAD (可能当前指向任何本地主题分支)映射 到上游主分支。
删除参考规格
要删除目的地信息库中的裁判选择从下拉列表中删除裁判 远程裁判删除 ,然后单击 添加规格。这将在推送 列表的规范中创建相应的条目 。或者,您可以键入要删除的参考文件的规格,也可以使用通配符。推送删除参考规格将删除目标存储库中的匹配Refs。
冲压推力参考规格
如果您添加多个冲突推式参考规格,它们将被标记为红色,通过删除或编辑冲突规格来解决此问题。也可以在列表规格中就地编辑规格
推确认
点击 下一步
这将打开“推送确认”对话框,显示预览哪些更改将被推送到目标存储库。如果这与您的期望不符,请单击“上 一步” 并相应地更正您的推式规格。
- 对于ref更新,要提交的提交范围将以<SHA1-from> .. <SHA1-to>格式显示, 例如 d97f5a2e..adfdbfd2 表示将推送d97f5a2e 和 adfdbfd2之间的所有提交 。
- 对于尚未存在于目标存储库[新分支] 或 [新标签]中的引用将 显示。
- 显示将被删除[删除]的参考 。
- 如果要确保在预览中看到的内容也是您推送这些更改时获得的内容,请选中仅在远程引用未在平均时间内更改的情况下 按下复选框。
- 选择 显示最终报告对话框,只有当它从这个确认报告不同 复选框,如果你只是想执行后推得到一个报告,如果结果从该预览不同。
推送结果报告
点击 完成
根据您选择的选项,显示推送结果报告对话框
在底部的框中显示来自远程服务器的推送确认消息。如果有任何错误,您可以在这里找到来自远程服务器的错误消息。要查看给定列表条目的消息,只需在列表中选择它。
点击 确定 关闭对话框。
从其他存储库获取
从上游获取
如果您正在使用具有所谓“ 上游配置 ” 的本地分支,则最方便的取回依赖于此上游配置。
本地分支通常基于远程跟踪分支创建。由于远程跟踪分支与远程关联,并且此远程程序包含访问远程存储库所需的信息,因此可以在创建本地分支时自动创建此上游配置(请参阅 分支 以获取更多信息)。
从上游获取时,此持久配置可用于自动提取,而无需在对话框中提供更多参数。
为了从上游获取数据,请单击 项目上游的团队>获取,或单击 存储库视图中存储库上的从上游获取。Git Command Group也有一个可用的操作 。
选择操作后,将立即执行提取。一旦完成,将显示一个确认对话框,显示有关获取数据和/或错误消息的信息:
配置上游获取
可以使用确认对话框中的“Configure ...”(配置...)按钮(参见上文)或通过单击项目上的 Team> Remote> Configure fetch from fetch ... 来配置上游获取。
将显示一个配置对话框,用于配置获取URI和分支映射(RefSpecs):
该对话框分为三个主要部分。在上部分中,显示了关于当前存储库和当前检出的分支的信息。外部组显示与当前分支关联的远程的抓取配置(在我们的例子中,组的文本中显示“起源”)。
URI字段可用于添加/更改提取URI。
RefMapping组允许指定一个或多个RefSpecs(请参阅 Refspecs)进行提取。
“添加”按钮将打开一个小向导,帮助创建RefSpecs。您也可以将剪贴板中的RefSpec粘贴到列表中。
点击“高级”控件将显示/隐藏“编辑(高级...)”按钮,允许更复杂的RefSpec编辑,类似于 获取向导。
下部按钮栏中的按钮允许您保存更改并立即执行提取,保存更改而不提取,干运行(取出而不保存配置),恢复更改并取消。
直接抓取
另一种获取方式是 在远程的获取规范上使用 直接获取支持。
抓取向导
最强大(但也是最复杂的)方法是使用抓取向导
团队>抓取...
- 如果您已经在存储库视图中配置了提取规范,则也可以使用配置的远程存储库下的下拉列表在此处选择它 。 如果这个远程的获取规范配置正确(即至少有一个URI和一个引用规范),则 完成按钮将被启用。
- 否则,请单击 自定义URI 并输入要从中提取更改的上游存储库的URI。
获取参考规格
有关 更多解释,另请参阅 参考资料。
单击 下一步
单击 添加所有分支规范
这是一种方便的方法,用于声明要将要从1:1提取更改的上游存储库中的分支名称映射到相同的本地分支名称。
- 单击编辑字段 Destination Ref ,并将路径段choose_remote_name替换 为要从中提取的上游存储库的符号名称。
- 您的存储库已克隆的存储库的默认远程名称是 origin。此远程的主设备默认从refs / heads / master映射 到 refs / remotes / origin / master。
- 如果您想另外追踪Joe本地仓库中的Joe仓库的分支机构,您可以将分支机构的仓库中的refs / heads / *映射 到以下跟踪分支 refs / remotes / joe / *。
- 如果您只允许快进更新,请取消选择 强制更新,如果您还想允许非快进更改,请选择此选项。
- 单击 强制更新所有参考 以在所有规格上设置强制更新选项
- 点击 删除所有规格 ,从列表规格中删除所有规格
- 点击 添加所有标签规格 ,将您想要从1:1获取的存储库中的标签标签映射到本地标签。
如果您想以不同的方式将上游存储库中的分支机构或标签映射到本地分支机构,则可以通过以下方式定义更详细的映射规范
- 输入源(在源代码库中引用)和目标引用(在本地存储库中跟踪分支或标记)或从下拉列表中选择已存在的分支
- 点击 添加规范
这会将新定义的映射传输到列表 提取规格
获取结果报告
点击 完成
显示提取结果对话框。
- 对于ref更新,已提取的提交范围将以<SHA1-from> .. <SHA1-to>格式显示, 例如 d97f5a2e..adfdbfd2表示 已提取d97f5a2e 和 adfdbfd2之间的所有提交 。
- 对于在本地存储库[新分支] 或 [新标签]之前不存在的参考资料 显示。
- 显示已被删除[删除]的参考文献 。
从上游分支拉动新变化
- 右键单击Package Explorer中的项目,然后选择 Team> Pull 或右键单击Git存储库视图中的存储库,然后选择 Pull从本地分支正在跟踪的上游分支中提取新更改。这也适用于从多个存储库中选择资源的情况。
- 无论何时创建基于远程跟踪分支的本地分支,EGit都可以配置跟踪关系,以便后续的提取将获取并合并或重新绑定(取决于此跟踪关系的配置)来自所跟踪的上游分支的更改; 详情请参阅分支。
EGit还不支持临时选择上游分支来提取。
可用的选择包括:
- 从外部eclipse 运行 git pull(但 要注意Windows)
- 如果您没有进行本地更改或想要放弃本地更改,请使用 团队>重置...
与Gerrit合作
如果您正在使用Gerrit(http://code.google.com/p/gerrit/),EGit允许您方便地向Gerrit服务器推送和从Gerrit服务器提取更改。
将更改推送到Gerrit Code Review Server
右键单击项目并选择 Team> Remote> Push to Gerrit ... 或右键单击存储库视图中的存储库节点,然后选择 Push to Gerrit ...
将出现一个对话框,让您选择或输入URI和分支名称:
- 在URI组合中,选择或输入指向您的Gerrit实例的URI; 该组合将被预填充当前存储库的任何远程中定义的所有URI; 另外你可以在这个字段中输入任何URI
- 在Gerrit分支字段中,输入要推送到的Gerrit分支的名称
该对话框还为Gerrit分支提供内容帮助。只需按下“Ctrl + Space”即可**此功能(请参阅在Gerrit分支字段附近悬停在小灯泡装饰器上时出现的工具提示)。将显示当前存储库的远程跟踪分支。请注意,此内容帮助已过滤,因此为了查看所有提案,您需要确保在请求内容帮助之前将Gerrit分支字段留空。
点击 完成后,当前签出的提交将被推送到指定的Gerrit分支。另外,当对话框稍后再次打开时,URI和Gerrit分支值将被记住并再次建议。
这允许在并行处理不同Gerrit分支时具有更大的灵活性(例如,频繁地在开发和修补之间切换)。
从Gerrit Code Review Server获取更改
右键单击项目并选择 团队>远程>从Gerrit获取... 或右键单击存储库视图中的存储库节点,然后选择从Gerrit获取...
会出现一个对话框,让您选择或输入URI和更改以及一些其他选项:
- 在URI组合中,选择或输入指向您的Gerrit实例的URI; 该组合将被预填充当前存储库的任何远程中定义的所有URI; 另外你可以在这个字段中输入任何URI
-
在更改字段中,您必须输入更改的完整名称; 您可以从Gerrit Web UI获取该值,使用下面描述的内容帮助,或者使用以下模式构建名称:
“refs / changes /”+(更改编号的后两位数字)+ / +(更改编号) + / +(修订版号) -
在“获取后执行的动作”中,您可以决定在获取更改后要执行的操作; 您可以创建并签出指向更改的分支,创建并签出指向更改的标签,或者只需签出更改(从而使HEAD分离); 最后一个选项在获取后不做任何处理,但是您可以在FETCH_HEAD中找到与更改有关的提交(转至存储库视图并在存储库的引用节点下找到FETCH_HEAD,请参阅 检查引用 )。
分支或标签的名称由对话框建议,但可根据需要进行覆盖。
由于EGIT目前不支持删除标签,因此我们建议暂时使用本地分支而不是标签。由于存储库视图允许使用“/”作为层次结构分隔符对分支进行分层分组,因此建议的名称在处理大量更改时可能非常方便。
除了繁琐的复制粘贴或手动输入更改ID之外,该对话框还提供了有关更改的内容帮助。只需按下“Ctrl + Space”即可**此功能(请参阅将鼠标悬停在“更改”字段旁边的小灯泡修饰器上时出现的工具提示)。Gerrit服务器将被联系,所有可用的更改将被提取并显示在内容辅助对话框中:
该列表将在更改字段中用您的输入进行过滤。选择内容帮助中的更改后,“更改”字段将填充正确的信息。
检查Repository的状态
标签装饰
标签装饰将显示Git版本控制下的Git特定信息。它们出现在显示模型对象的所有视图中,如包资源管理器,项目资源管理器,导航器,层次结构视图。
Git标签装饰可以在General> Appearance> Label Decorations下的Preference Menu(Window> Preferences)中 全局打开。
更详细的设置可以在Team> Git> Label Decorations下的首选项中完成 。
有两种不同类型的标签装饰:文字装饰和图标装饰。
文本装饰
文字装饰出现在文字标签的左侧或右侧。它们可以在选项对话框 的文字装饰标签上的 Team> Git> Label Decorations下进行配置 。例如,肮脏资源的默认值是a > ,位于其名称的左侧。
这些是默认设置:
对于文件和文件夹,有变量 “名称”, “脏” 和 “上演”。 “肮脏” 和 “上演” 是旗帜; 如果它们为真,则显示冒号后面的文本。
对于项目,还有额外的变量 “存储库” 和 “分支”。在 “库” 变量显示存储库的名称。
在 “分支” 变量显示当前签出分支的名称。如果未检出分支,装饰将显示提交的缩写名称(前七个字符,后跟省略号)。如果标签和/或远程分支指向此提交,则应用“最佳猜测”启发式也会显示以下信息:标签优先于远程分支,如果应用了多个标签,则会显示最新标签; 如果有多个远程分支或标签没有修改日期,则应用字母排序,并显示最后一个。例如:签出的承诺e49f576 ... 是指标签 v.0.7.1 库的 例如:It:
图标装饰
图标装饰出现在标签前面显示的图标的右下角。他们可以在选项对话框中 的图标装饰上的 Team> Git> Label Decorations下进行配置。
这些是默认装饰:
- 脏(文件夹) - 文件夹下至少有一个文件脏了; 这意味着它在工作树中的变化既不在索引中也不在存储库中。
- 跟踪 - 资源是Git知识库,因此在版本控制下。
- 未跟踪 - 资源未被Git存储库所知,并且在明确添加之前不会受版本控制。
- 忽略 - 资源被Git团队提供者忽略。团队>忽略资源下的首选项设置 ,.gitignore 文件中的“派生”标志和设置都会 被考虑在内。
- 脏 - 资源在工作树中发生更改,既不在索引中,也不在存储库中。
- staged - 资源已经添加到索引中的更改。请注意,只能在提交对话框中通过资源的上下文菜单添加对索引的更改。
- 部分阶段化 - 资源包含已添加到索引中的更改以及工作树中既没有到达索引也没有提交到存储库的其他更改。请参阅 Git Staging视图中的部分分段 以了解如何执行此操作。
- 添加 - 资源尚未达到存储库中的任何提交,但已被新添加到Git存储库以便将来进行跟踪。
- 已删除 - 资源将从Git存储库中移除。
- 冲突 - 文件存在合并冲突。
- 假定有效 - 资源具有“假定不变”标志。这意味着Git会停止检查工作树文件以进行可能的修改,所以当您更改工作树文件时,您需要手动取消设置该位以告诉Git。另请参阅 假设不变的操作。
提交对话框
提交对话框中显示所有修改的跟踪文件的状态摘要。通过双击文件,要提交的更改将显示在比较对话框中。由于EGit当前总是提交工作树的内容(对应于命令行中的git commit -a),比较对话框将比较工作树和上次提交。
比较内容
在日常工作中,您经常希望看到上次提交,索引和当前工作树之间的更改。为此,请在项目资源管理器或导航器中选择资源(项目,文件夹或文件),然后右键单击“ 比较”下的操作 。
要分析特定提交的内容,应该使用 支持此任务的 历史视图更好,请参阅检查提交任务 。
比较编辑器和Git树比较视图
如果您 在单个文件中使用Compare With的任何子菜单操作, 将显示一个比较编辑器,否则 将打开Git树比较视图以浏览更改; 通过在该视图中双击已更改的文件,将为该文件打开一个比较编辑器。子菜单操作“ 历史记录... ”例外 ,它将打开“历史记录视图”。
将工作树与上次提交进行比较
当前工作目录中的资源和当前分支中上次提交的资源之间的差异可以从上下文菜单Compare With> HEAD revision中查看。此功能也可在提交对话框中找到。在提交对话框中双击一个条目将打开一个比较对话框。
比较工作树和索引
当前工作树和索引(基于当前选定的资源)之间的差异可以从上下文菜单Compare With> Git Index查看。
将工作树与分支,标记或引用进行比较
- 选择一个资源
- 右键单击 Compare With> Branch,Tag或Reference ...
- 选择一个分支,标记或引用
比较工作树和任何提交
从项目浏览器:
- 选择一个资源
- 右键单击 Compare With> Commit ...
- 从提交图中选择一个提交
从历史视图(仅限文件):
- 在包资源管理器中选择一个文件
- 右键单击 Team> History in History 或 Compare With> History ...
- 在提交图中选择一个提交
- 从上下文菜单中选择 与工作树进行比较
- 这将打开一个比较对话框,显示所选提交和当前工作树之间的变化
比较两个承诺
- 在Package Explorer中选择一个资源
- 单击“ 团队”>“在历史记录中显示” 或“ 与历史记录比较...” (后者仅用于文件)
- 在提交图中选择两个提交
- 右键单击“相互 比较”
- 这将打开一个比较对话框,显示两个选定提交之间的变化
- 您也可以通过右键单击树中的“彼此比较”来打开“Git树比较”视图
比较索引与HEAD或任何其他提交
该功能尚未实现。
与分支(同步)比较
工作树(包括未提交的更改)与分支或标记之间的区别可以通过单击项目上的动态菜单 Team> Synchronize 并选择 要同步工作树的 Ref来查看。如果Git存储库包含多个Eclipse项目,则只需选择一个项目即可, 同步视图 也将包含所有其他项目。
如果你想在动态菜单中点击未列出的参考同步 团队>同步>其他...。然后在“同步向导”中单击要同步的存储库的目标列,然后选择要与之比较的Ref。
点击“包括本地未提交的比较变更”也是本地的,尚未分阶段的变更和已经分阶段的变更将显示在比较中。
也可以一次比较多个存储库。在这种情况下,在同步向导中,为每个存储库选择要与之比较的参考。
Quickdiff
不使用比较编辑器,您可以启用快速差异支持并查看文本编辑器中的更改。
此功能可通过常规>编辑器>文本编辑器>快速差异 首选项页面启用 :
然后差异注释将显示在编辑器的左侧:
如果将鼠标移动到注释上,则会看到您正在比较的版本的内容:
默认情况下,比较是针对HEAD的。您可以从历史视图中的提交的上下文菜单(Show in> History)中确定您正在比较的版本,即所谓的quickdiff基准。有三个菜单条目:
- 快速差异 - >将基线重置为HEAD的第一个父级 - 与HEAD之前的第一个提交进行比较。
- 快速差异 - >将基线重置为HEAD - 与HEAD进行比较。
- 快速差异 - >设置为基线 - 与所选提交进行比较
检查提交
检查给定的提交
- 从Package Explorer中的上下文菜单中选择 Team> Show in History
- 选择你想要检查的提交
查看提交的差异
历史视图在左下方的窗格中显示diff。选择右下方窗格中的文件会滚动到diff的相应文件部分。
显示提交的内容
双击右下方窗格中文件的行为取决于比较模式切换按钮的状态。如果它打开,将打开一个比较编辑器,它将当前提交中的文件内容与祖先提交中的内容进行比较; 如果关闭,将会打开一个编辑器,显示当前提交中的文件内容。
提交更改
git版本控制下的项目修改通过提交保存在git历史记录中。从从git存储库检出的状态开始,修改您的项目,直到您达到您满意的状态,然后将所有这些更改作为单个提交提交到存储库中。每次提交都代表存储库中存储的所有文件的定义良好的快照。
修改内容
修改已经与Git共享的项目在Eclipse中或直接在文件系统中修改或删除文件。没有必要提前告诉Git这些操作。应该受版本控制的新文件必须明确置于Git版本控制之下:
- 在文件的上下文菜单中单击 Team> Add
或者,您可以在提交对话框中显示未跟踪的文件,并选中 显示未跟踪文件 复选框以选择它们以包含在提交中。
标签装饰器例如在Package Explorer View中显示
- 尚未在git版本控制下的未跟踪文件(标有“?”)
- 已添加的文件(标有“+”)
- 修改过的文件(在文件名前用“>”标记)
有关详情,请参阅 标签装饰。
以下是包资源管理器中的一个示例
- 一个承诺的文件
- 在工作树中修改但尚未为下一次提交分配的文件
- 一个修改过的文件,已经为下一次提交进行了修改
- 一个已经新下载的文件,用于下一次提交
- 一个不在git版本控制下的文件
提交
要提交更改,请单击 项目中资源的上下文菜单中的Team> Commit ...。
Git跟踪对整个存储库进行的所有更改,以捕获该存储库中所有版本控制文件的修改,而不考虑这些文件是否驻留在同一个Eclipse项目中。
一旦你触发了提交, 提交对话框 就会弹出
选择要提交的更改,输入提交消息并创建提交, 在提交消息文本字段中按 Ctrl + Enter (Mac OS X上的Command + Enter),或单击 提交。
提交消息
在“提交”对话框中,指定描述更改的提交消息。
用短的第一行开始消息是一个好习惯,总结变化,然后是空白行,然后是消息正文。为了确保git命令行工具可以很好地格式化这些消息,行不应格式化得太宽(用灰色垂直线表示)。
Eclipse拼写检查器检查提交消息文本是否有错误。拼写检查器可以通过Eclipse Preferences> General> Editors> Text Editors> Spelling进行配置。按 Ctrl + 1 打开快速修复,这可能有助于修复拼写错误。
提交消息编辑器支持提交对话框的文件部分中显示的文件名的内容帮助,可以按Ctrl-Space**该文件部分。
页脚标签
在提交消息的最后一段中,可选的页脚标签可以如下所示:
错误:3176 更改ID:I267b97ecccb5251cec54cec90207e075ab50503e 报道者:Joe Developer <[email protected]> 签名:William Shakespeare <[email protected]>
这些标签的语义是项目或工具特定的
- 如果在错误跟踪系统中有条目要求提交更改,则最好在此将其添加为错误标记
- Gerrit Code Review 使用 Change-Id: footer将审核过程中发生变化的不同补丁集与最终接受的补丁相关联。要生成Gerrit Change-Id,请点击 Gerrit Code Review的Compute Change-Id ; 该ID将在提交时生成,直到此时空的Change-Id显示为占位符。如果将egit配置参数 gerrit.createchangeid 设置为true,则始终预先选择“提交”对话框中的相应复选框。此参数可以在存储库级别,系统级别或用户级别上进行设置。有关 更多信息,请参阅存储库配置。
- 在 参团的off-by: 页脚被许多项目来创建签名笔者贡献下,该项目的许可和知识产权规则的改变声明的正式记录。通过这种方式,可以在技术层面捕获项目不断发展的代码库的知识产权出处。请参阅 Linux内核项目使用的 开发人员证书源代码。如果偏好例如:It 插入签名断,通过 在 团队>的Git>提交对话框 设置相应的复选框在提交对话框总是会预先选定。
此外,此对话框控制将在提交中包含哪些更改。如果清除文件前面的复选框,则对该文件的更改将不会包含在提交中。您的eclipse工作区中的本地文件仍将包含修改,使您有机会使用后续提交来提交这些更改。此功能通常用于将对一组文件所做的修改分离为不同的提交。
一个例子: 想象一下,自从上次提交以来,您已经修复了A.java中的一个错误,并且您已经为B.java添加了一个新方法。这两个修改在逻辑上相互独立,因此您可能希望在两个独立的提交中提交它们。在这种情况下,您启动提交,从提交的文件集中取消选择B.java,并指定仅描述A.java中的错误修正的提交消息。在成功完成第一次提交后,您只需再次调用commit,即将出现的对话框将向您展示B.java中的其余更改。现在您指定一个提交消息来描述添加方法并完成第二次提交。
如果选中“显示未跟踪文件”复选框,则在提交对话框中将列出添加到项目中尚未明确添加到版本控制中的新文件(请参阅“修改内容”)。如果您选中列表中这些文件前面的复选框,则会将其添加到存储库并在您按下提交按钮后进行提交。团队忽略列表或 .gitignore 文件或衍生的文件(例如,java项目中的bin文件夹)将不会显示在此处。如果您的存储库中没有其他更改比未跟踪文件更多 ,默认情况下会选中Show untracks Files复选框 。
修改提交
如果您在提交更改时意识到错过了某些内容,则可以解决此问题:再次打开提交对话框并指定当前提交将“修改”当前分支中的上一个提交。新的提交将会取代之前的提交。此功能通常用于在发布到其他存储库之前纠正不正确的提交。
注意: 如果它们已经发布到共享存储库,则不要修改提交,因为如果它们已经根据已发布的更改进行了修改,则可能会打扰其他提交。
修改示例:
想象一下,您对包含错字的文件进行了更改
提交更改后,您会发现一个错字。为了纠正这个错字和相应的提交,您只需修复源文件中的错字
然后再次打开提交对话框并选择选项 修改上一个提交。
您之前提交(您想要替换的提交)的提交消息被填充到“提交消息”字段中。这不仅可以更正版本控制文件内容中的错误,还可以更正描述更改的提交消息中的错误(例如,拼写错误)。
作为修改的替代方法,您可以将更正后的版本作为后续提交提交。但是第一个包含错字的提交对任何人都没有用,为了不用不必要的提交来混淆项目的历史,你应该修改提交。
请注意,修改已发布到其他存储库的提交可能会造成麻烦。一旦将提交推送到远程存储库或您的本地存储库被其他人克隆,您应该非常小心地修改提交。在这种情况下,发布更正第一个提交的第二个提交可能是更好的解决方案。否则,通知所有其他人您已修改已发布的提交,以便他们能够做出相应的反应
恢复更改
恢复工作树中的更改
在Git索引中替换为文件
尚未提交和尚未分阶段的更改可以恢复为一组选定的文件。在包资源管理器或类似视图中选择文件,然后在Git索引中单击 替换为>文件。
替换为HEAD
此功能目前在单个文件级别上不可用。您可以使用 Reset to with hard 来强制重置存储库的整个工作树回到HEAD提交状态(请参阅下面的“重置当前的HEAD”)。该操作将恢复工作树和索引中的所有更改。您无法使用EGit在选定的一组文件上执行此操作。
替换为以前的版本
已经执行或甚至提交的更改可以通过将它们替换为之前提交的版本来“恢复”。在Package Explorer或类似视图中选择一个资源,然后单击 Replace With> Previous Revision。存储库将确定最后一次提交,该提交修改了所选资源,并提供用此提交的内容替换工作区资源。
这主要是为了从提交中“删除”单个文件(当提交已恢复的工作空间资源时,它们被有效地从当前提交中移除)。即使这也适用于文件夹和项目,用“之前的修订”替换文件夹或项目的结果可能是意外的。
使用quickdiff恢复
quickdiff功能可用于恢复对文件的单个更改。您可以按行,块(se范围更改行)或选择进行恢复。选择所有文本,然后 选择还原选择 以还原整个文件。
恢复由特定提交引入的更改
由给定提交引入的更改可以通过在当前检出的提交之上自动创建的新提交来恢复。要恢复的提交不必为此检出。
在历史视图中选择提交,打开上下文菜单并选择 恢复提交。这通过在当前签出的提交之上创建新的提交来还原所选提交引入的更改。
重置当前的HEAD
Git提供了将当前分支的HEAD重置为任何其他提交的可能性。它可以选择重置索引和工作树以匹配该提交。请注意,此操作会影响整个存储库中的所有文件和文件夹。
您可以选择进行硬重置,混合重置和软重置。
- 软 - HEAD现在指向新提交,索引和工作树不变
- 混合 - HEAD现在指向新的提交,索引被更新,工作树不变
- 很难 - HEAD现在指向新的提交,索引和工作树被更新
重置为特定分支或标签
在项目上选择 Team - > Reset ...。这将打开一个对话框,您可以在其中选择分支或标签。
重置为特定的提交
在历史视图中选择一个提交并打开上下文菜单。在这里您可以找到条目 硬重置, 混合重置 和 软重置。
恢复所有本地和分阶段的更改
这可以作为重置的特殊情况来完成。如果您重置为当前HEAD(通常是最后一次提交您的分支)的选项 硬 您覆盖工作树,并与头部的内容索引。你可以通过三种方式做到这一点:
- 在项目上选择 团队>重置...。在该对话框中选择HEAD或当前分支并切换的单选按钮 硬。
- 右键单击并 在存储库视图中的任意分支或标签上选择 重置...。这会打开一个对话框,让您决定重置类型。选择难 在这里。
- 打开历史视图HEAD提交中的上下文菜单,然后选择 硬重置。
分枝
关于分支机构的一般评论
在不使用本地分支的情况下提交对本地存储库的更改是不切实际的(参见上面的概念部分)。此外,通过使用几个不同的分支,可以通过在这些分支之间进行切换来并行处理不同的更改。
因此,在开始更改本地存储库之前,第一步通常是创建一个本地分支。本地分支机构“基于”提交或远程跟踪分支。
在使用远程存储库时,推荐使用第二个选项,因为它通过向新的本地分支添加所谓的“上游配置”来简化将本地更改与远程更改同步的任务。
请参阅 分支创建对话框 了解更多详情
上游配置
每个基于本地跟踪分支的本地分支都可以有一些额外的配置,指示远程存储库,远程分支和所谓的拉动策略。请参阅 分支创建对话框 了解更多详情
通常,根据远程跟踪分支创建本地分支时,会自动创建此配置。但是,可以在存储库配置中显示和编辑它,也可以 单击 “存储库视图”中某个分支上的“ 显示”>“属性 ”。
检出现有分支
从项目节点上的团队菜单中:
- 选择 团队>切换到... 并从列表中选择一个分支名称
如果分支太多,则列表中不会显示所有分支。在这种情况下
- 选择 团队>切换到...>其他...
- 在对话框中,选择一个分支,一个标签或一个参考
- 点击 确定
从Git存储库视图
- 在分支节点上选择 Checkout
要么
- 双击分支节点
从历史视图
- 在具有分支标签的提交上选择 签出
- 如果多个分支指向提交对话框,将允许您决定检出哪个分支。
创建新的本地分支
这总是通过“ 分支创建”对话框完成。新创建的分支可以通过选择对话框上的复选框来检出。
从团队菜单中
- 选择 团队>切换到...>新科...。
- 在对话框中,选择分支,标签或参考。
- 点击 创建分公司...。
- 该 科创建对话框 将被打开。
从存储库视图
- 在“分支”节点或任何“分支”,“标记”或“参考”节点上选择 创建分支...。
- 该 科创建对话框 将被打开。
从历史视图
- 选择 创建分支...
- 该 科创建对话框 将被打开
重命名现有分支
从项目节点的团队菜单中
- 选择 团队>高级>重命名分支...
- 在分支选择对话框中,选择要重命名的分支
- 输入新的分支名称,然后单击 确定
从存储库视图
- 打开Git存储库视图
- 选择 重命名分支... 或在您要重命名的分支上按F2
- 输入新的分支名称,然后单击 确定
从历史视图
- 使用分支标签提交时选择 重命名分支...
- 输入新的分行名称并点击 确定
删除分支
以下所有操作都表现出与以下相同的行为:
- 当前签出的分支不能被删除
-
如果删除分支可能导致数据丢失,则会显示必须确认的警告
- 如果分支指向从当前检出的提交无法访问的提交,EGit会承担潜在的数据丢失
从项目节点上的团队菜单
- 选择 团队>高级>删除分支...
- 从正显示的对话框中选择要删除的分支,然后按 确定
从存储库视图
- 打开Git存储库视图
- 在要删除的分支上选择 删除分支
从历史视图
- 使用分支标签提交时选择 删除分支
- 如果多个分支指向提交,将显示一个选择对话框,您可以在其中选择要删除的分支
分支创建对话框
有几种可用于创建本地分支的操作。所有这些操作都使用分支创建对话框:
上半部分的组合允许选择分支或提交新的分支应基于。通常,这是一个远程跟踪分支,但它可以是存储库中的任何分支或提交(不推荐选择本地分支)。
只有在组合中选择了一个分支并允许覆盖“上游配置”的默认设置时,“拉动策略”组才可见,这在提取和推送时很有帮助,特别是在拉取时。根据所选选项,可以选择以下配置:
- Rebase:拉动时,将从上游获取新的更改,并且远程跟踪分支将被更新。然后,当前的本地分支将重新贴装到更新的远程跟踪分支上
- 合并:拉动时,将从上游获取更改,远程跟踪分支将更新。然后,当前的本地分支将与新的更改合并。如果新分支基于远程跟踪分支,则这是默认设置(但此默认设置可能会被特定存储库配置覆盖)
- 无:拉动时,新的分支将不会执行特定的上游配置; 但是,如果存在默认远程设备(名称为“origin”的远程设备,则pull将尝试使用此远程设备的配置;如果新分支不是基于远程跟踪分支,则这是默认设置
您可以查看和编辑存储库配置中的上游配置, 或通过 在存储库视图中的分支上选择 Show In> Properties。
EGit还支持git配置参数 branch.autosetuprebase
,always
如果您想默认使用rebase pull策略,则将其设置为 。如果您在存储库配置中设置了此选项,则用于根据此存储库中的远程跟踪分支创建的所有本地分支,如果将其设置为用户配置,则将用于所有存储库。
在下面,您可以决定是否立即检查新分支。
合并
合并包含从命名提交(从他们的历史与当前分支分离的时间)到当前分支的更改。
将分支或标签合并到当前分支中
你有两个地方可以触发合并:
- 从团队菜单
- 从Git存储库视图
从团队菜单开始合并
在包资源管理器或导航器中,打开项目节点上的上下文菜单。选择 团队>合并...
现在合并对话框打开:
在对话框中,选择要与当前分支合并的分支或标签。
从Git存储库视图开始合并
如果您已签出本地分支,则可以从任何分支和标记节点以及从存储库节点触发合并。有关 更多详细信息,请参阅 合并分支或标记。
可能的合并结果
按下“合并”按钮后,可能会出现以下情况:
- 已经是最新的:你当前的分支指向一个具有选定分支或标签作为前任的提交。在这种情况下,没有什么改变。
- 快进:您当前的分支指向作为所选分支或标记的前任的提交。在这种情况下,您的分支会移动并指向选定的分支或标签; 这个新的HEAD被检出到工作树上。使用远程存储库时,快进是非常常见的:当远程跟踪分支更新时,与相应分支的合并通常是快进。您可以通过获取远程分支(例如起源/主控)并将其合并到相应的本地分支(例如主控)来执行拉动操作。
- 真正的合并:当以上条件都不适用时,触发合并提交。有两种可能的结果:如果不发生冲突,当前分支将指向新创建的合并提交; 如果发生冲突,冲突文件将标记为标签修饰符(请参阅解决合并冲突 以防合并冲突时的进一步操作)。
合并结果对话框
对话框中汇总了合并的结果:
在第一行你会看到合并的结果。可能的结果是“已更新”,“快进”,“合并”,“冲突”或“失败”。“失败”的可能原因可能是工作目录中存在冲突的更改。
在第二行中,如果成功合并(已完成最新,快进或合并),您将看到新的HEAD提交。
在表格中您可以看到合并的提交。
解决合并冲突
合并可能导致需要用户操作的冲突。当文件的内容不能自动合并时就是这种情况。这些冲突在导航树中标有标签修饰。文件内容中的合并冲突会显示文本冲突标记( 有关更多详细信息,请参阅http://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_how_conflicts_are_present)。
使用合并工具
- 选择显示红色冲突标签修饰器的*资源
- 单击 团队>合并工具
- 选择合并模式 使用冲突文件的HEAD(最新本地版本), 然后单击 确定
- 合并编辑器打开,显示左侧窗格中的工作树版本以及右侧窗格中要合并的版本
- 编辑工作树版本,直到你满意为止
- 团队>添加 合并资源以将冲突标记为已解决
- 通过Team> Commit提交合并 提交
手动冲突解决
要解决冲突,您必须执行以下步骤:
- 导航到冲突的资源
- 编辑冲突资源的内容
- 通过Team> Add告诉EGit冲突已解决
- 通过Team> Commit提交冲突解决方案
查找冲突的文件
包含冲突文件的存储库具有附加到存储库名称的文本标签装饰器“|冲突”。包含这些冲突资源的资源和文件夹冲突会得到冲突标签装饰。
编辑冲突的文件
在文件内容中,发生一对冲突变化的区域用标记<<<<<<<,=======和>>>>>>>标记。=======之前的部分通常是你的一面,而之后的部分通常是他们的一面(见 http://www.kernel.org/pub/software/scm/git/docs/git-merge。 html#_how_conflicts_are_presented 了解更多详情)。
在编辑器中打开文件,编辑内容并保存编辑器。
请注意,这一步不是强制性的。EGit不会检查内容以决定冲突是否已解决。下一步是相关的一步。
将冲突解决添加到git索引
编辑文件完成后,选择 Team> Add 将冲突解决添加到git索引。您可以在文件夹或整个项目上执行以一次解决所有冲突。
解决所有冲突后,文本存储库标签装饰将更改为“已合并”。没有冲突标记了。
提交合并
当存储库处于“合并”状态时(如使用文本标签修饰符“|冲突”附加到存储库名称所示),最终可以合并合并。
在导航树的任意位置选择“ 团队”>“提交...”。提交对话框以与正常提交相比稍微不同的外观打开:
- 提交消息区域预填充了标准合并提交消息。
- 不可能修改以前的提交。
- 无法添加未跟踪的文件。
- 不可能取消选中复选框。这保证所有已解决的冲突均已落实。
按下“提交”按钮后,合并完成。
中止合并
如果合并导致冲突,您可以通过对当前分支进行硬重置来中止合并。这可以在“冲突”状态和“合并”状态下完成,即在解决冲突之前和之后。
硬重置可以从团队菜单,Git存储库视图或历史视图中完成。请参阅 恢复所有本地和分阶段更改 以获取更多详细信息。
垫底
Rebase简介
Rebase将一组提交应用于给定的提交。一个典型的场景是在某个时间点从“主”分支创建的“主题”分支上开发某些功能。当“主”更新时,例如来自其他开发者的变更,而“主题”仍在开发中时,可能有必要将这些更改合并到“主题”中。
让我们假设我们通过从master创建“主题”分支来开始“主题”开发。此时,“主”和“主题”都指向提交“E”。当第一次提交(“A”)被添加到“主题”时,资源库的提交历史记录如下所示:
一个话题 / D --- E主
现在,我们假设在“主题”上有更多的提交,并且还有一些对“主”的提交(例如,“master”可能会跟踪某个远程存储库,并且该远程存储库中的一些更改已经被引入“主”):
A --- B --- C话题 / D --- E --- F --- G主
现在,为了将“主”的变化结合到“主题”中,“主”的“主题”的再版将产生
A' - B' - C'主题 / D --- E --- F --- G主
从技术上讲,“主题”中包含但不包含在“主”中的提交顺序在“主”之上逐一应用(即,挑选)。
请注意,提交A,B,C既不会丢失也不会发生更改,而是会创建与原始提交(但不同的提交ID)相同的更改和提交消息的新提交链A',B',C'。旧提交A,B,C仍在对象数据库中,但不再可见,因为它们不再可从任何分支中访问。A',B',C'与旧的不同,因为它们现在也包含变化F和G.
重建,一个简单的例子
让我们来看一个简单的例子:我们有一个文本文件“FamousWords.txt”,它最初可能有一些内容
第1章 很久以前... 第2章 生存还是毁灭
现在,在“主题”中,创建了两个提交,第一个将法语翻译添加到第2章,另一个添加德语翻译:
在“主题”中首次更改后:
第1章 很久以前... 第2章 生存还是毁灭 是或不是
在“主题”中进行第二次更改后:
第1章 很久以前... 第2章 生存还是毁灭 是或不是 是或不是
同时,通过在第1章中添加两个提交法文和德文翻译的“主文件”更改了该文件:
第1章 很久以前... 曾几何时 曾几何时 第2章 生存还是毁灭
提交历史记录如下所示:
现在,如果将“主题”重新设置为“主”,则主题中的两个更改按照与“主题”演变过程中应用的顺序相同的顺序应用。
结果是“FamousWords.txt”的合并版本:
第1章 很久以前... 曾几何时 曾几何时 第2章 生存还是毁灭 是或不是 是或不是
以及在当前“主”之上提交“主题”提交历史的提交历史记录:
现实世界:重建冲突
到目前为止,我们假设“主题”中的更改可以自动合并到“主”中。然而,在现实世界中,可能会发生在重新绑定期间遇到冲突。现在,如果挑选的提交中包含与“主”更改相冲突的更改,则在应用冲突更改后,重置操作会中断; 以通常的方式(冲突标记)将冲突可视化,并且用户有机会决定是否要
- 手动解决这些冲突,
- 跳过当前的提交,或者
- 完全放弃rebase
如果 选择了“ 解决冲突”,并且冲突已经手动解决,那么更改必须是“已添加”,然后可以重新进行重新分配,即将应用链中的下一个提交。
如果 选择跳过,冲突的更改将被还原,链中的下一个提交将被应用。
如果 选择Abort,rebase操作将完全回滚,在rebase开始之前将Repository恢复到原始状态。重复此过程直到最后一次提交成功或跳过应用。最后,“主题”分支将更改为指向最后的提交。
为了更好地理解“跳过”,让我们回顾上面的介绍。如果我们假设提交“B”导致与当前“主”的冲突,用户可能会决定跳过“B”; rebase之后的新提交历史将如下所示:
'C'主题 / D --- E --- F --- G主
启动Rebase
Rebase在Git存储库视图中可用。在Repository节点上, Rebase ... 打开一个对话框,要求用户选择未检出的分支; 当前签出的分支将被重新分配到所选分支上。在“分支”节点(包括本地和远程跟踪分支,但不在当前签出的分支上), 重置 立即将当前签出的分支重新绑定到所选分支上:
重新确认对话框
如果Rebase成功,将显示一个确认对话框; 这个对话框可以通过勾选一个复选框来抑制; Git首选项页面上的首选项允许再次出现对话框。如果该对话框被禁止,则会将“信息”消息写入Eclipse日志中。
冲突冲突
如果在重新绑定期间发生冲突,将显示一个对话框,提供有关导致冲突的提交的一些信息。通过选择一个单选按钮,您可以决定是否
- 启动合并工具以手动解决冲突
- 跳过当前提交
- 完全放弃rebase
- 什么都不做(返回工作台),这相当于击中了“Escape”:
除非在对话框中选择“跳过”或“中止”,否则必须通过编辑冲突文件手动解决冲突。编辑完成后,文件必须声明为通过将它们“添加”到索引来解析。
在所有冲突解决后,Rebase可以通过右键单击Git存储库视图中的Repository节点并选择Rebase> Continue来恢复。
通过右键单击Repository节点并分别选择Rebase> Skip and Rebase> Abort,可从Git存储库视图中获得“跳过”和“中止”选项。
合并工具也可以从团队菜单中的相应条目开始。
中止Rebase
只要存储库处于“重新启动”状态,用户就可以使用Repository节点上可用的菜单操作“Rebase> Abort”在Git存储库视图中始终放弃重新绑定。
再利用限制
目前的EGit rebase实现还不能处理所有可能的版本图。如果图表过于复杂,rebase将会以错误消息中止。作为一种解决方法,直到EGit的rebase支持这些更复杂的图表,您可以改用命令行中的native git。
采摘樱桃
樱桃挑选介绍
分支stable-1.0上 的给定提交 C 包含一组您希望集成到当前分支主机开发中的更改 。
A - B - C - D稳定 - 1.0 / D --- E --- F --- G主头
Cherry选择提交 C在当前签出的分支主机的头提交之上 创建新的提交 C' 。 C” 然后将包含在执行的更改 Ç 施加到当前签出分支的HEAD 主。
A - B - C - D稳定 - 1.0 / D --- E --- F --- G-C'master HEAD
樱桃挑选示例
您目前正在分支“feature2”(HEAD)上工作。在另一个分支中有一个提交“功能1”。
您希望将提交“功能1”执行的更改集成到当前分支“功能2”的开发中。
- 在历史视图中选择提交“功能1”并单击 Cherry-pick:
- 因此,您在当前分支“功能”的顶部获得了一个新的提交“功能1”,其中包含“功能1”的更改:
- 樱桃采摘可能会遇到冲突。在这种情况下,冲突标记将呈现到受影响的源中:
标记
创建一个标签
- 从项目上下文菜单中选择 Team> Advanced> Tag ...。
- 输入标签名称
- 输入标签消息
- 可以选择你想要标记的提交(默认是HEAD)
- 单击 确定 以创建注释标签
也可以在历史记录视图中创建标签:选择提交并 在上下文菜单中执行 创建标签...。该标签将在选定的提交上创建:
替换现有标签
如果您标记了错误的提交或最终出现了某种错误,该怎么办?
- 如果你还没有推出这个只需更换标签,你就完成了。
- 如果它已经发布,你不应该替换标签, 而是使用一个新名称,否则你必须告诉每个获得旧标签的人用你的新标签手动替换它。这是因为,Git没有(也不应该)改变用户背后的标签。所以如果有人已经拿到了旧标签,那么在树上做一个git pull不应该让它们覆盖旧标签。
因此,如果您的旧标签尚未推送,您可以通过以下方式进行更正:
- 从项目上下文菜单中选择 Team> Tag ...。
- 从现有标签列表中选择要替换的标签
- 或者开始在“标签名称”字段中输入要查找的标签的任何部分,这会将现有标签的列表过滤到包含您正在输入的字符串的那些标签,然后选择要替换的标签
- 标记复选框 强制替换现有标记
- 更改标签并按 确定
删除标签
为了删除标签,选择要删除的标签并点击 删除标签。
注意: 删除已在公共服务器上发布的标签是一种不好的做法,一些Git服务器甚至不允许删除标签以确保通常标记的发布的可追溯性。另请参阅 标记命令的Git参考文档中的“重新标记”部分。
轻量级和签名标签
轻量级标签显示在“存储库视图”和“创建标签”对话框中,但无法编辑。标签在存储库视图中显示为蓝色图标,注释标签用黄色人物装饰。
在历史视图中,标签显示为黄色标签。
EGit还不支持签名标签,而是使用命令行 git标签 或 git标签-s 。
补丁
创建修补程序
“补丁是一种旨在解决问题或更新计算机程序或其支持数据的软件”(wikipedia)。补丁文件包含一组可以自动应用到另一个eclipse工作区或git存储库的资源更改的描述。
eclipse(Team> Apply Patch)和git(git apply 或 git am 在命令行上)使用的补丁格式不同。在EGit中可以创建两种类型的补丁。
从提交创建一个补丁
这是分布式版本控制系统最常见的用例。开发人员对本地功能或错误修复分支提交更改,并希望将此更改导出到修补程序文件中。
它可以从历史视图完成:
补丁文件将包含历史视图中提交与其父代之间的区别。请注意,历史视图的过滤器也适用于修补程序创建。
补丁向导
向导由两页组成。第一页可以让你选择补丁的位置:
补丁文件的名称是从提交消息的第一行创建的。
在第二页上,您可以更改补丁格式。
目前有一个复选框: 以git补丁格式导出。
- 如果你没有检查它(这是默认设置),可以使用eclipse Apply Patch ... 向导来应用这个 补丁。路径与eclipse项目相关,不包含前缀(比如 git命令行上的git format-patch --no-prefix)。
- 如果你检查它,补丁将看起来像 git命令行上的git format-patch --no-stat的结果 。
目前没有生成二进制差异。
应用修补程序
目前EGit无法以git格式应用补丁。使用Team> Apply Patch ...可以使用标准Eclipse(统一差异)格式 应用修补程序。Git补丁可能包含用于重命名和二进制比较的非标准扩展。EGit的当前版本不会生成这些扩展名。
管理存储库
“Git存储库视图”是便于同时处理多个存储库(即在一个Eclipse工作区内)的主要UI元素。
此视图可以使用菜单路径Windows> Show View> Other ...> Git> Git Repositories打开
它也是“Git Repository Exploring”透视图的一部分,使用菜单路径
Window> Open Perspective> Other ...> Git Repository Exploring
如果您的工作空间中已有与Git存储库共享的项目,则可以使用
团队>在存储库视图中显示
在任何资源上打开视图。
将存储库添加到Git存储库视图
最初,Git存储库视图是空的。为了向其添加存储库,有以下几种选择:
- 手动从本地文件系统添加存储库
- 克隆存储库并将克隆的存储库自动添加到视图中
- 在本地文件系统上创建存储库
- 通过将Git存储库路径粘贴到视图来添加存储库
手动添加存储库
您可以将本地文件系统中的存储库添加到Git存储库视图中,而不用克隆它。如果您正在设置新的Eclipse工作区并希望重新使用您的Git存储库,这会很有帮助。使用 视图工具栏中的 添加现有的Git存储库按钮:
将出现一个对话框,提示您输入本地文件系统的目录。选择正确的目录后,您可以点击 搜索 按钮来查看该目录中的Git存储库列表。然后,您可以选择一些或全部找到的存储库,并使用OK将其添加到视图中 :
克隆存储库
为了克隆存储库,请参阅 克隆远程存储库。克隆操作成功后,新克隆的存储库应自动出现在Git存储库视图中。
您也可以使用 视图工具栏中的 克隆Git存储库按钮来启动克隆向导:
请参阅 克隆远程存储库 关于如何使用向导。
创建一个存储库
您可以在本地文件系统上创建一个新的空存储库。如果稍后想要在此存储库下创建一个或多个新项目,这很有用。另一个用例是创建一个新的裸仓库,您可以在其中推送。使用 视图工具栏中的 创建新的Git存储库按钮:
会出现一个对话框让您选择一个目录:
如果您选中创建为Bare Repository复选框 , 则新存储库将不会有工作目录。然后您只能通过推送来自另一个存储库的更改来添加内容。
使用复制和粘贴添加存储库
作为快捷方式,也可以将Git存储库的本地文件系统路径从剪贴板粘贴到此视图中。为此,请将Git存储库的路径(其.git
文件夹的完整路径 )复制到剪贴板,然后在视图面板上打开上下文菜单:
或者 从主菜单(或相应的键盘快捷键)单击 编辑>粘贴。如果剪贴板内容不合适,将显示错误弹出窗口,否则添加的存储库应自动出现。
在视图填充了一些存储库后,它应该如下所示:
删除存储库
从存储库视图中删除存储库
为了从存储库视图中删除存储库,选择一个存储库并单击“删除存储库”
删除存储库
为了删除存储库,请在存储库视图中选择它并单击“删除存储库”。
然后确认您要删除存储库
并决定是否要从Eclipse工作区删除存储库中包含的项目。
Git存储库视图的结构
以下屏幕截图显示了Git存储库视图的最上面两个级别:
根节点表示存储库本身。节点文本指示存储库的名称及其在本地文件系统中的位置。“分支”和“标签”节点允许浏览和操作标签和分支。“References”节点列出了其他不是分支或标签的引用,最显着的是“HEAD”和“FETCH_HEAD”符号引用(请参阅 Git引用)。
“工作目录”节点显示本地文件系统上工作目录的位置和结构(仅在开发情况下为裸露存储库,或者非裸露存储库,此节点始终为叶)。
最后,“远程”节点允许浏览和操作用于提取和推送的远程配置。
Git存储库视图的功能
项目导入
为了使用Git Repository的内容,它的文件和文件夹必须以项目的形式导入Eclipse工作区。虽然Git Clone向导允许在克隆后直接执行此类导入,但Git存储库视图允许独立于克隆操作触发项目导入。
“存储库”节点以及“工作目录”节点和“工作目录”节点本身内的任何“文件夹”节点上均提供“导入项目...”上下文菜单:
在几个节点上提供Import Projects ...操作的基本原理 是,用于导入项目的一些向导可以考虑文件系统目录,例如 Import Existing Projects 向导。如果从“存储库”或“工作目录”节点开始导入,则将存储库的工作目录设置为上下文,否则将设置与当前选定的“文件夹”节点相对应的目录。
有关项目导入的详细信息, 请参阅使用新项目向导。
分支和标签支持
“分支”节点允许创建,浏览,结账和删除本地和远程分支机构。“标签”节点允许浏览和签出标签。“分支”节点和“标签”节点都允许将分支或标签合并到当前签出的分支中,并且还与当前签出的分支同步。
为了更好的可读性,分支分别组织在本地和远程分支的两个子节点中,并且只显示缩写名称,例如,代替 “refs / heads / master”, 您会 在“本地”下找到条目 “主” 在“远程分支”节点下显示“分支”节点,而不是“参考/远程/源/主” 缩写名称 “起源/主站”。同样,通过省略“refs / tags /” 前缀缩短标签名称 :
检查分支和标签
可以通过双击各个节点或选择相应的上下文菜单条目检出分支和标签。
分支的创建和删除
可以使用分支创建对话框创建本地分支 。通过右键单击任何“分支”和“标记”节点上的“分支”,“本地分支”来打开该向导。
分支删除使用相应的上下文菜单条目完成。
垫底
您可以通过右键单击触发当前签出分支的垫底到另一个分支 再次基于 任何(本地或远程跟踪)分支节点上。
合并分支或标签
如果您已签出本地分支,则可以从任何分支和标记节点以及从存储库节点触发合并。有关合并 功能的更多详细信息,请参阅 合并。
- 当您选择除当前检出分支或任何标签节点以外的任何分支节点时,使用 合并 直接触发合并到当前检出分支。
- 当您选择存储库节点或当前检出的分支时,使用 合并... 打开合并对话框。在将分支或标签合并到当前分支中描述了合并对话框。
与分支或标签同步
您可以将HEAD中的更改与任何其他分支或标签中所做的更改进行比较。右键单击并选择 同步...在任何分支或标记上。然后打开eclipse同步视图,其中包含HEAD中包含的更改的表示,但不包含在另一个分支或标记(传出更改)中,反之亦然(传入更改)。有关更多详细信息,请参阅同步功能的文档。
确定检出分支
有两种方法可以确定当前检出哪个分支或标签:检出的分支/标签节点装饰有一个小勾号,“符号参考”节点下的“HEAD”条目显示退房分行:
重置为分支或标签
右键单击并 在任何分支或标签上选择 重置...。这会打开一个对话框,让您决定重置类型。有关 更多详细信息,请参阅 重置您当前的HEAD。
“分离”头部
如果HEAD是“分离的”,即不是指向本地分支的尖端,而是指向提交或标记,则树中可能没有或几个“签出”标记,因为任何数目的远程分支或标记可能指向当前签出的提交。当你的HEAD被分离时你所处的状态不会被任何分支记录(这是很自然的 - 你不在任何分支上)。
检查参考文献
“引用”节点显示除分支和标记以外的一些引用(该列表是动态的,取决于存储库的当前状态):
如果引用是符号的,即指向另一个引用,则显示目标引用的名称,后跟引用的目标的对象ID。如果引用不是符号,则只显示对象ID。
在上面的例子中,HEAD是指向分支“refs / heads / master”的符号引用(即分支“master”被检出),而FETCH_HEAD直接指向提交226a7f ...。
右键单击Reference: Checkout (除非Reference已经签出)并 创建分支' ...',可以执行以下操作。
浏览工作目录
“工作目录”节点可视化Git存储库的本地文件系统结构。也可以在文件上打开文本编辑器:
或者,可以通过将文件从工作目录拖到编辑区域来打开文件。
另外,在所有文件和文件夹节点以及“存储库”节点上,都提供了一个用于将(文件系统特定)路径复制到剪贴板的选项。这在需要路径时有时很有用,例如,使用文件浏览器打开目录或在视图实例之间复制和粘贴存储库(请参阅上述关于如何将存储库添加到视图中)。“ 复制到剪贴板” 操作也可以使用 编辑>复制 (或相应的键盘快捷键)。
存储库配置
与Eclipse中的通用“属性”视图集成允许查看和编辑Git配置(全局和特定于存储库的配置)。如果“属性”视图处于打开状态,则在选择“存储库”节点时会自动更新。使用下拉框(屏幕截图中的左侧红色框),您可以在存储库配置的显示,全局配置和聚合两者的视图之间切换。如果视图显示存储库配置或全局配置,则可以使用编辑 按钮(屏幕截图中的右侧红色框)打开编辑器对话框 。编辑器对话框具有与首选项页面Team> Git> Configuration相同的功能 。
在Git Repositories视图中, 上下文菜单中有一个 Properties操作,该操作将打开一个允许编辑Repository Configuration的配置对话框。在这里,可以添加,更改或删除键值对。在 打开 按钮可以在文本编辑器打开库配置文件。
远程存储库
“远程”节点允许浏览和编辑远程配置。每个远程配置都有一个名称和一个推送规范,一个提取规范或两者。如果选择“远程配置”节点或其任何子节点,则 属性 视图将显示远程配置的摘要。在这个例子中:有一个名为“origin”的远程配置,它只有一个提取规范,但没有推规范:
菜单操作用于添加,配置和删除远程配置以及提取和推送规范。
直接读取和推送支持
可以在远程节点以及相应的“提取”和“推送”节点上直接执行提取和推送(即无需向导):
请注意,取或推操作将立即在异步作业中执行; 完成后,您将看到一个确认弹出窗口,显示获取结果。
“Fetch”节点包含所谓的提取规范,“Push”节点包含所谓的推式规范。
克隆存储库时创建默认的提取规范。您可以使用菜单项Configure Fetch ...编辑提取规范 。这将打开一个向导。在第一页上,您可以编辑提取URI。Ob第二页,您可以确定提取参数规格,请参阅 提取参考规格。
您可以使用菜单项“ 配置推送...”创建或编辑推送规范 。这将打开一个向导。在第一页上,您可以编辑推送URI。如果指定了提取,则提取URI将自动包含在推送规范中,并且不需要其他推式URI。在第二页上,您可以确定推送参数规格,请参阅 推送参考规格。
添加远程配置
这是使用“远程”节点上的上下文菜单操作完成的。启动向导询问新配置的名称以及是否配置Fetch,Push或两者:
如果选择 配置提取 复选框,则下一个向导页面将要求从以下位置获取存储库的URI:
点击 更改... 打开一个对话框,允许您选择一个URI。下一步是为获取URI定义远程规范。有关详情,请参阅 提取参考规格 。
如果选择 配置推送 复选框,则下一个向导页面将要求存储库的URI推送到。这实际上是一个列表,因为您可以一次推送到多个存储库。单击 添加.... 使用与上面相同的对话框将URI添加到列表中。您可以在列表中标记他们,打删除的URI 删除。如果已经定义了一个提取URI,则此步骤是完全可选的。在这种情况下,获取URI也将用于推送。如果在这个步骤中至少定义了一个推送URI,它将覆盖提取URI。在这个例子中,已经有一个获取URI,所以 即使列表中没有Push URI,也会启用Next按钮:
下一步是为推送URI定义远程规范。有关详情,请参阅 推送参考规格 。
完成后,新的远程配置将可见:
更改远程配置
也可以使用上下文菜单为现有的远程配置添加,删除或更改提取/推送规范。
Gerrit配置
如果您可以使用 Gerrit Code Review 作为远程存储库服务器
- 指定用于将更改推送到代码审阅的推送配置
- 指定提取配置以从Gerrit获取审阅笔记
- 配置您的存储库以 在缺省情况下在“提交”对话框中选择“ Gerrit代码审阅的 计算更改ID”选项
从Remote的上下文菜单中选择 Gerrit Configuration ...。这将打开一个带有一个页面的向导:
- 当您单击 完成时 ,向导会将存储库配置参数 gerrit.createchangeid设置 为 true。这确保 默认情况下选中提交对话框中Gerrit代码审查的复选框Compute Change-Id。详情请参阅 提交 信息。
- 如果要在稍后的时间点配置自动Change-Id插入,可以使用存储库配置编辑器(首选项>团队> Git>配置)将配置参数gerrit.createchangeid设置 为true。如果你想为你所有的仓库配置这个配置,你可以把它放到〜/ .gitconfig中,那么你不需要重复这个配置来处理你正在使用的每个新仓库。
- 另外,向导在您的获取规范中添加了一个refspec“refs / notes / *:refs / notes / *”。Gerrit在git笔记中存储有关该评论的数据。有了这个refspec,这些评论数据将在您从这个远程获取时自动获取,并且它们将显示在提交查看器中。
- 在Push URI部分, 您可以配置用于默认推送配置的URI。它根据您从中克隆的URI进行预填充。如果使用git协议进行克隆,协议会自动更改为ssh,并自动添加默认的Gerrit ssh端口29418。对于需要用户的协议,为了方便,有一个用户字段。
- “ Push Configuration ”部分 有一个字段“ Destination Branch”。在这里您应该输入Gerrit代码审查工作流程中接受更改的目标分支的名称。这会 在克隆向导中指定的远程的推送配置中产生一个条目 HEAD:refs / for / <branchname>。
刷新
该视图会定期自动刷新。 工具栏中的 刷新按钮允许立即刷新:
与选择链接
如果 启用了带选择的 链接,则将自动显示与当前工作台选择对应的文件或文件夹:
与编辑链接
如果 启用了带编辑器的 链接,则会自动显示与当前活动编辑器对应的文件或文件夹:
分层分支布局
如果 启用了“ 分层分支布局”切换,分支将以分层布局显示,并使用斜杠(/)作为分层结构分隔符:
这对组织大量分支机构可能有帮助。
裸库
“Bare”Git存储库(与“开发”或“标准”存储库相反)根据定义没有工作目录,因此与工作目录相关的所有操作(检出,项目导入,浏览工作目录)都不可用于这样的存储库。仓库的“裸机”在“工作目录”节点上可视化,该节点总是一片叶子:
裸存储库只能通过对其进行更改来更改。
从Git存储库视图中删除存储库
这是作为“Repository”节点上的菜单操作提供的。请注意,这不会删除存储库,而只是从视图中删除该节点。如果工作区中的项目位于存储库的工作目录中,则会提示用户确认从Eclipse工作区删除这些项目。
在相关视图中显示存储库
在历史中显示
Show in> History命令 将打开 历史视图, 显示所选储存库中的所有更改。
在Reflog中显示
Show in> Reflog命令 将打开 Git Reflog视图, 显示所选存储库的Git reflog。
在属性中显示
命令 Show in> Properties 将打开 显示所选存储库属性的 Properties视图。
使用任务
由于EGit 0.11与Mylyn的第一次集成可用于支持使用任务存储库。
安装
您需要安装功能“EGit Mylyn”才能使用EGit Mylyn集成。这还需要安装Mylyn。
提交消息模板
- 在首选项>任务>团队下配置Mylyn提交消息模板, 然后编辑 提交评论模板。
-
使用以下变量以及任何文本来更改提交消息。
- repository.url,task.assignee,task.cc,task.description,task.id,task.key,task.keywords,task.lastmodified,task.notes,task.priority, task.product,task.reporter,task.resolution,task.status,task.summary,task.type,task.url,task.completiondate,task.creationdate,task.reminderdate
- 在提交更改之前,使用Mylyn UI**相应的任务。
- 当启动提交对话框时,EGit将使用提交消息模板预填充提交消息。
有关 如何使用任务的更多信息,请参阅 Mylyn用户指南。
查看提交
Egit commit查看器允许在Eclipse编辑器区域中打开提交。
EGit commit查看器显示以下提交信息:
-
提交选项卡
- 链接到打开父提交
- 作者
- 修订者
- 信息
- 指向这个提交的标签列表
- 提交存在的分支列表
-
Diff选项卡
- 文本查看器与文件差异的输出
- 查看器中使用的颜色可以通过 首选项 > 常规 > 外观 > 颜色和字体 > Git 文件夹进行配置
-
Notes标签
- 所有Git的提交注释
标记提交
-
从提交查看器工具栏中选择创建标签图标
- 标签对话框将打开,允许您从提交中创建标签。
从提交创建分支
-
从提交查看器工具栏中选择创建分支图标。
- 分支对话框将打开,允许您从提交中创建新的分支
检出一个提交
这会检查提交查看器中显示的提交。提交将被检出并且 HEAD将被分离。
樱桃采摘承诺
在当前签出的提交或分支上应用由提交查看器中显示的提交引入的更改。
打开提交查看器
提交查看器可以从以下位置打开:
搜索提交
EGit支持搜索提交。
Git搜索页面
提交可以从 标准的Eclipse搜索对话框中的 Git Search选项卡搜索。
此对话框支持搜索Git提交的不同字段中存在的文本或模式,例如消息,作者行,提交者行和提交的SHA-1 ID,其父代以及与其关联的树。
浏览搜索结果
提交搜索结果显示在标准的Eclipse搜索视图中。在树状模式下,结果按存储库分组。双击搜索视图中的提交将在提交查看器中打开它 。
启动Git搜索
Git Search页面可以通过从Eclipse工具栏上的Search下拉菜单中选择Git Search选项来打开。
打开提交对话框
EGit 1.0有一个 类似于Mylyn Open Task 和 Open Resource核心对话框的 Open Git Commit对话框 。该对话框会搜索每个已配置的Git存储库,以查找输入到过滤器框中的分支,标记或提交SHA-1,并显示匹配的提交。
该对话框可以通过选择 Eclipse导航工具栏上的Open Git Commit按钮来 打开。
查找文件中每行的作者
EGit 1.0支持 在编辑器标尺内显示 git blame信息。
选择 Team > Show Annotations 对文件选择操作将打开编辑器并显示注释标尺,其中包含文件中每行的提交和作者信息。将鼠标悬停在标尺上将显示一个弹出窗口,其中显示提交ID,作者,提交者和提交消息。
责备注释编辑器标尺的外观和感觉 可以从标尺上下文菜单中的修订子菜单中配置 。
从弹出窗口中选择SHA-1超链接将在提交查看器中打开 提交。
使用子模块
EGit / JGit中的子模块支持在2011年2月发布的1.3版本中添加,该版本是Indigo SR2的一部分。
你可以阅读更多关于Git子模块是什么以及它们如何在此 Git社区书籍章节中工作的内容。
使用子模块克隆存储库
子模块是嵌套在父存储库内的存储库。因此,在对父存储库进行克隆时,需要克隆子模块存储库,以便文件/文件夹在父存储库的工作目录中可用。
克隆父库的完成后, 从Git Clone向导中检查 克隆子模块按钮 将克隆所有子模块库。
浏览子模块
在 包含子模块的存储库的Git存储库视图中 显示了一个 Submodules节点 。
给定父存储库中的所有子模块都显示在此节点下以及有关当前检出哪些提交的信息。
添加一个子模块
您可以通过在Git存储库 视图中选择一个存储库并选择 添加子模块 上下文菜单选项来将新的子模块添加到存储库 。
该向导将提示输入要添加的子模块的路径和URL。输入的路径将相对于父存储库的工作目录,并且URL将用于本地克隆存储库。
一旦向导完成,子模块将被克隆,添加到索引,子模块将被注册到 .gitmodules 文件以及父库中的 .git / config 文件中。
更新子模块
有两个操作可用于更新子模块,即 更新子模块 和 同步子模块。
在子模块 上选择 Update Submodule操作将检出在该子模块的父存储库索引中引用的提交。如果 在父存储库的.git / config 文件中所选子模块的配置部分的更新字段中 配置了该命令,则此命令也将执行合并或重新绑定 。
在子模块 上选择 Sync子模块操作将从父存储库工作目录根目录下的.gitmodules文件中的当前值更新子模块使用的远程URL 。
团队项目集
团队项目集(.psf 文件)由Git团队提供商支持。
进口
要导入现有项目集,请使用 导入... 向导,然后 从 团队中选择 团队项目集。
然后,您可以选择一个包含导入定义的文件,并可以选择将导入的项目添加到工作集。
在下一步中,存储库被克隆,项目被导入并连接。这可能需要一段时间,取决于存储库的大小。
出口
要为现有Git项目创建项目集文件,请选择已连接到Git团队提供者的项目/工作集。
然后打开 导出... 向导并 从 团队中选择 团队项目集。您可以选择仅导出工作集或项目,并可以优化您的选择。在下一步中,选择一个输出路径并完成向导。
格式
您也可以手动编辑 .psf 文件。每个项目都有一个如下所示的条目:
<project reference =“1.0,git://egit.eclipse.org/egit.git,master,org.eclipse.egit”/>
这些值由逗号分隔,并具有以下含义:
- 格式版本
- Git存储库URL
- 最初退房的分店名称
- 导入项目的路径(包含.project的文件夹 ),相对于存储库
每个项目都有一个条目。因此,对于同一个存储库中的多个项目,使用相同的存储库URL为每个项目创建一个条目。导入足够聪明,只能克隆每个存储库一次。
如果存储库包含根目录中的项目,请使用 。 作为项目路径。
参考
菜单
项目上下文菜单
在导航视图(导航器,包资源管理器等)中的项目节点上,以下Git操作可用于与Git团队提供者共享的项目:
主项目菜单
“远程”子菜单
“切换到”子菜单
“高级”子菜单
资源上下文菜单
在导航视图中的资源节点(文件和文件夹)上,以下Git操作可用于与Git团队提供者共享的项目:
存储库查看菜单
历史视图菜单
Git Workbench工具栏和Git Workbench菜单
为了方便使用最常用的Git动作, 可以**Git Command Group以显示Git Workbench工具栏和/或菜单
- 右键单击工作台工具栏区域,然后单击 自定义透视图...
- 在选项卡 命令组可用性中 单击 Git,这将启用Git工作台工具栏和菜单
- 在标签 工具栏可见性 和 菜单可见性中, 您可以配置哪些操作应该出现在Git Workbench工具栏和菜单中
菜单操作
-
加
- 将工作树中存在的更改添加到git索引,也称为分段更改。
- 将新创建的资源放在git版本控制下(Git不会自动开始跟踪资源)。
- 解决冲突。
- 应用修补程序 - 应用修补程序。
- 假定不变 - 资源可以被标记为“假定不变”。这意味着Git会停止检查工作树文件以进行可能的修改,所以当您更改工作树文件时,您需要手动取消设置该位以告诉Git。此设置可以通过菜单操作 Team> Assume保持不变 并切换回菜单操作 Team> No Assume不变。
- 分支, 创建分支 - 签出分支或创建分支。
- 更改凭证 - 更改提取或推式规范的登录凭证,凭证按照URL安全存储库中的每个URL进行存储。
- 结帐 - 签出 分支,标签, 提交 或参考。
- 樱桃选择 - 樱桃选择一个提交到当前签出的分支的提示。
- 清除凭证 - 清除提取或推送规范的登录凭证,凭证按照URL安全存储库中的URL存储。
- 提交 - 提交更改。
- 删除提取 - 删除提取规范。
- 删除推送 - 删除推送规范。
- 配置提取 - 配置提取规范。
- 配置推送 - 配置推送规范。
- 删除分支 - 删除分支。
- 删除存储库 - 删除存储库。
- 断开连接 - 断开所连接的Git Team Provider与该项目的连接。git存储库仍然存在,但不再与Eclipse集成。
- 忽略 - 将文件添加到.gitignore,以便git忽略它们。
- 导入项目 - 将项目导入Eclipse工作台。
- 合并 - 合并分支。
- 合并工具 - 使用合并工具解决冲突。
- 打开属性视图 - 查看和编辑存储库配置。
- Pull - 从当前检出的本地分支跟踪的远程分支上拉更改。
- 远程> 取自 - 从远程存储库获取更改
- 远程> 从Gerrit 获取 - 从Gerrit代码审阅服务器更改获取
-
远程> 推送 - 将更改推送到其他存储库
- 远程> 配置从上游获取 - 配置上游自动获取
-
远程> 配置推送到上游 - 配置上游自动推送
- 重建 - 将分支重新分配到另一个分支。
- 删除存储库 - 从存储库视图中删除存储库。
- 重命名分支 - 重命名分支。
- 重置 - 重置当前的HEAD,索引或工作树。
- 在历史记录中 显示 - 在历史记录视图中显示选定的资源。
- 在存储库视图中 显示 - 在存储库视图中显示选定的资源。
- 切换到... - 切换到(也称为结账)另一个分支或标签。
- 同步 - 同步本地和远程分支。
- 标签 - 创建,删除标签。
- Untrack - 从git版本控制中移除资源。如果要从工作树中删除资源,请 在资源的上下文菜单中单击“ 删除 ”。
Git透视和观点
Git透视
Window> Open Perspective> Git Repository Exploring 打开Git Repository Exploring透视图
Git存储库视图
窗口>打开视图> Git> Git Repositories 打开Git Repositories视图,这里详细解释 。
历史视图
概观
Git版本控制下的资源历史视图是给定存储库中资源的以提交为中心的视图。它可以用来执行以下任务:
- 在Git版本控制下检查给定文件的更改历史记录(查看和比较存储库中此类文件的版本)
- 使用不同的搜索条件搜索特定的提交
- 退出某个提交
- 基于某个提交创建分支和标签
- 根据某个提交中的更改创建补丁
- 将整个存储库重置为某个提交
- 设置quickdiff基线并将其重置为某个提交
打开历史视图
历史视图可以通过打开
- 在 资源管理器中的Git版本控制下的任何资源上右键单击 Show In> History View(在所有Perspective中都不可用)
- 在资源管理器中的Git版本控制下,右键单击 Team> History in History中的任何资源
- 单击 窗口>显示视图>其他...,然后选择 团队>历史记录
视图打开后,您可以**带选择的 链接 按钮,以使视图的输入与浏览器中的选择自动保持同步。
历史观的组织
历史视图被组织在几个窗格中:
上面的窗格是提交图表,以反向时间顺序显示提交日志(或提交历史记录)(最新的提交)。在提交图下方,默认有两个窗格:左侧是修订注释区域,其中显示提交消息和提交中文件或文件的文本差异,右侧是修订详细信息区域,它显示了提交所改变的文件的表格。
该表的第一列描述了每个文件的变化性质:
- 添加 该文件是由提交添加的
- 修改 该文件已被提交修改
- 删除 文件被提交删除
下部窗格的内容取决于上部窗格中的选择,并在此选择更改时自动更新。
通过右键单击上部窗格中的任意位置,并分别选择“ 显示修订注释” 和“ 显示修订详细信息”,可以分别打开和关闭两个较低的窗格 。
在提交图上方,当前输入可视化。输入始终是工作区资源,可以是项目,文件夹或文件。在输入的类型之后,将显示路径,后面跟着包含方括号中的资源的存储库名称。
使用历史视图
检查提交图
提交图区域是历史视图的主要部分。默认情况下,它显示当前签出的提交及其所有祖先,即列表中的第一个条目是签出的提交。以下图片用于解释历史视图的一些功能:
提交图中的每一行对应于一个提交。分支,标签和HEAD可视化如下:
- 本地分支的提示显示为绿色矩形
- 远程分支的提示显示为灰色矩形
- 本地HEAD显示为白色矩形
- 标签显示为黄色矩形
(我们的例子没有远程分支)。
左侧的行是实际的提交图,它显示了列表中提交的父子关系(每个提交至少有一个父级,除了存储库中的第一次提交)。可以有对应于分支操作的分叉和对应于合并操作的连接。在我们的例子中,在分支“beforeSplit”提交之后创建了一个“实验”分支,并且在“主”和“实验”分支中都更改了相同的文件。最后一次提交是合并提交,其中“实验”分支的内容与“主”分支合并。
可以通过标记提交并查看修订注释区域来检查确切的更改。在“修订注释”区域向下滚动时,可以看到更改的文本差异,在我们的示例中,它表示Project1 / f1 / file1.txt的内容已从“修改”更改为“主修改”。当选择下一个提交(对应于“实验”分支)时,会显示一个类似的差异,表示该文件的内容已从“已修改”更改为“已修改实验”。最新的提交是将“实验”合并为“主”的结果。因此,新承诺有两个祖先,“主”和“实验”线再次合并。
显示和比较文件的版本
如果当前输入已经是一个文件, 在提交上右键单击 打开将打开一个编辑器,其文件内容对应于当前选定的提交。如果该文件在选定的提交中不存在,则会显示一条错误消息。点击 比较工作树 将打开一个比较编辑器,比较当前选定提交的文件内容与工作区中的文件内容。
在 开放 和 与工作树进行比较 的动作也可以通过双击来执行的承诺:如果“比较模式”工具栏按钮(见下文)已关闭, 比较与工作树 会被执行,否则 打开。
通过选择两个提交并右键单击比较,可以比较由当前输入过滤的两个提交的内容 。如果当前输入不是文件,则在Tree中有一个额外的菜单操作相互 比较。第一个动作打开Eclipse比较编辑器,第二个动作打开 Git树比较视图。
此外,可以选择任意数量的提交并右键单击 打开 以查看与所选提交相对应的文件的所有版本(每个版本将打开一个编辑器)。
如果当前输入不是文件,则不会有打开的菜单操作 。但是,可以双击“修订详细信息”区域的条目。如果比较模式处于活动状态,将打开一个比较编辑器,显示当前所选提交中双击文件的更改(即,当前选定提交中的文件内容与此提交的祖先的文件内容的差异)。如果比较模式未处于活动状态,则会显示一个文件内容对应于当前所选提交的编辑器。
使用过滤器设置
可以使用相应的工具栏操作更改过滤器设置(请参见下文)。默认情况下,“资源”设置处于活动状态,即只有列表中显示包含当前输入更改的提交。如果当前输入不是文件,则显示所有提交,其中包含当前输入的任何子项的更改。
如果过滤器设置为“资源”,并且当前输入是文件,则提交列表仅包含那些包含该文件更改的提交。分析该文件的历史记录时,这非常有用。但是,在某些情况下,还可以看到其他不改变实际文件的提交。例如,查看文件中的某个给定更改是否在某个不会更改该文件本身的其他提交之前或之后可能很有趣。在我们的示例中,我们可能想知道给定的更改是否在标记为“Project1”的提交之前“之前”或“之后”。通过将过滤器设置从“资源”更改为“存储库”,这很容易完成:
其他两个设置(“文件夹”和“项目”)的行为类似之处在于它们分别包含更改当前输入的父文件夹中的任何资源或当前输入的项目中的任何资源的提交。在我们上面的示例中,如果使用过滤器设置“Project”,则不会显示提交“将Project2添加到存储库”,是否不会更改当前输入项目中的任何内容(Project1 / f1 / file1.txt )。
或者,为了查看与特定项目有关的所有提交,可以更改该项目的历史视图输入。但是,文件特定的菜单操作将不可用。
工具栏操作
历史视图工具栏中的前四个按钮是刷新,选择链接,固定和导航历史记录的标准按钮。
找
如果“查找”工具栏按钮处于关闭状态,则视图的下部会显示一个搜索栏,允许在提交日志中搜索提交。根据搜索栏下拉列表中的设置,搜索提交的标题,评论,作者或提交者。
找到的搜索结果高亮显示,“Next”和“Previous”按钮允许跳转到符合搜索条件的下一个或上一个提交:
过滤器设置
视图工具栏中的下一个四个切换按钮控制显示的提交相对于当前输入的过滤方式: 按钮用作单选按钮,即四个按钮之一必须始终处于关闭状态。
- 如果“Repository”按钮处于关闭状态,则不会过滤提交日志,并显示从当前签出的分支可达到的所有提交(或所有提交,请参阅下面有关“所有分支”操作的提交)
- 如果“项目”按钮关闭,则提交日志将被过滤以显示影响包含当前输入的项目中的任何资源的所有提交
- 如果“文件夹”开关处于关闭状态,则会过滤提交日志以显示影响当前输入的父文件夹中的任何资源的所有提交
- 如果“资源”按钮关闭,则提交日志将被过滤以仅显示影响当前输入的提交; 视图菜单项“ 显示”>“跟随重命名” 允许切换是否选择资源的重命名应该由此过滤器跟随
请注意,并非所有滤波器设置和电流输入的组合都是有意义的; 例如,如果当前输入是项目,则“项目”选项实际上与“资源”选项相同。
比较模式
下一个按钮又是一个切换,**“比较模式”。如果它停机,某些双击操作(见上文)将打开比较编辑器而不是普通的编辑器。
所有分支机构
该切换**“所有分支”模式。默认情况下,只有那些提交日志中显示的提交可以从当前签出的提交中获得,即,提交图以当前签出的提交结束,而较新的提交不会显示。如果此按钮处于关闭状态,则所有提交都将显示在提交日志中。这在我们的例子的下面的图片中说明。“分裂之前”的分支目前已被检出; 通过**切换,新的分支将变为可见:
查看菜单操作
配置视图
大多数工具栏操作也可以在查看菜单中找到。另外,可以使用以下切换:
“附加参考”切换在获取,重定位,合并等操作期间创建的某些Ref的可见性,例如FETCH_HEAD,ORIGIN_HEAD ...这可以有助于消除历史视图中的混乱。
“注释历史记录”在“修订注释”区域切换Gerrit评论注释的显示。
如果使用“资源”过滤器,“跟随重命名”切换是否应在历史视图中遵循所选资源的重命名。此首选项还可以在首选项向导 首选项>团队> Git>历史记录>关注重命名中进行配置。
“修订注释”切换修订注释区域的可见性。
“修订细节”切换“修订细节”区域的可见性。
如果选中“相对日期”,则提交日期将显示为相对日期而不是绝对日期。
“电子邮件地址”切换提交者电子邮件的显示。
子菜单“In Revision Comment”打开一个子菜单,其中有更多的切换来管理修订注释区域的外观:
“标签序列”允许显示/隐藏指示给定提交的祖先列表中的最后一个标签和给定提交的后续列表中的下一个标签,即给定提交之前/之后的标签。
“包装注释”和“填充段落”切换修订注释区域内的格式。
“修订详细信息”和“修订注释”也可通过右键单击“提交图表”区域中的任意位置获得。
通过右键单击修订注释区域中的任意位置,也可以使用“标签序列”,“包装注释”和“填充段落”。
上下文菜单操作
“提交图表”区域中的上下文菜单略有不同,具体取决于当前是文件还是文件夹/项目。以下菜单条目始终可用:
如果当前输入是文件,则还有其他一些可用的操作; 如果只选择一个提交,则有三个附加选项:
如果选择了两个提交,菜单将如下所示:
如果选择了两个以上的提交,只有“打开”操作和“Quickdiff”菜单可用。
与工作树比较
只有当前输入是文件并且选择了单个提交时,此操作才可用。它将打开一个比较编辑器,将所选提交的文件内容与工作树中的文件内容进行比较。
相互比较
此操作仅在当前输入是文件并且选择了两个提交时才可用。它将打开一个比较编辑器,比较所选提交的文件内容。
打开
此操作仅在当前输入是文件时才可用。它将为每个选定的提交打开一个编辑器,显示给定提交的文件内容。
查看
这将检出当前选定的提交。如果此提交存在分支,则会检出分支,如果此提交存在多个分支,则会显示一个对话框,询问应检出哪个分支。如果不存在提交的分支,则提交将被检出并且HEAD将被分离。
创建分支...
在当前选定的提交上创建一个分支。将显示一个对话框询问分支名称以及是否应检出新创建的分支。
删除分支
如果当前选定的提交没有检出,则该操作将被启用。如果此提交中有一个分支未被签出,则此操作将立即删除该分支。如果存在多个这样的分支,将显示一个对话框,询问哪些分支应该被删除。如果提交在“删除分支”上无法访问,将显示一个确认对话框以防意外提交的意外不可达。
创建标签...
在当前选定的提交上创建一个标签。将显示一个对话框,询问标签名称和标签消息。
创建补丁...
此操作在存储库的第一次提交中不可用。它将创建一个包含当前所选提交与该提交的前任相比所做更改的修补程序。将显示一个对话框,询问是否应该将补丁创建为文件或剪贴板,以及是否使用通用补丁格式的Git补丁格式。
樱桃采摘
在当前签出的提交之上应用所选提交引入的更改。
恢复提交
通过在当前签出的提交之上创建一个新的提交来还原所选提交引入的更改。
去
将选定的提交合并到当前签出的分支中。
在最重要的基础上
在选定的提交之上重新绑定当前签出的分支。
重置>软/混合/硬
此操作将包含当前输入的存储库重置为当前选定的提交。根据子菜单的选择,将执行软重置,混合重设或硬重置。
Quickdiff>将Quickdiff Basline重置为HEAD
Quickdiff>将Quickdiff Basline重置为HEAD的第一个父级
这两个操作将存储库的quickdiff基线设置为HEAD或HEAD的父级。即使选择了多个提交,这些操作也始终可用。
Quickdiff>设置为基线
此操作仅在选择单个提交时可用; 它会将存储库的quickdiff基线设置为选定的提交。
复制
将当前选定的提交或提交的ID复制到剪贴板中。
显示修订评论
切换“修订注释”区域的可见性。
显示修订详情
切换“修订细节”区域的可见性。
包装评论
仅当右键单击修订注释区域时才可用。如果**,则注释将被自动包装以填充显示区域,否则将使用提交消息的包装。
填写段落
仅当右键单击修订注释区域时才可用。如果处于活动状态,则会显示提交消息而不会有不必要的换行符
拖放支持
您可以将提交图上的提交拖放到Mylyn Task上或拖放到 硬盘上的文件夹中。在这两种情况下,EGit都会自动创建一个可能附加到磁盘上的错误或存储的补丁。
使用修订细节区域
版本详细信息区域显示了所选提交更改的文件的表格。选择上下文菜单操作 在选定文件上显示注释将在(只读)编辑器中打开该文件,并显示包含文件中每行的提交和作者信息的注释标尺。请参阅 本节。
同步视图
菜单命令“ 团队”>“同步工作区” 将启动“同步视图”。此视图允许您检查本地工作区和本地或远程跟踪分支中的资源之间的差异。或者,您可以比较本地和远程跟踪分支。比较两个远程跟踪分支以及同步视图上的菜单命令在此EGit版本中尚不可用,并将在未来版本中提供。
以下是Git Synchronize View的内容:
同步状态
Synchronize View显示工作空间或本地分支中资源的同步状态,与另一个本地或远程跟踪分支中代表远程资源库分支状态的资源同步状态。此状态通过使用图标显示,也可以配置为将状态显示为附加到资源名称的文本。
下表显示了这些图标的说明:
模式
同步视图可以使用工具栏操作或视图下拉菜单中的菜单项进行过滤。模式可用于仅显示传入,传出或冲突的更改。
楷模
同步视图能够显示资源的不同模型表示。每个产品可能包含自己的产品特定表示。Eclipse SDK带有三种模型:
- 工作区模型
- 显示基于资源的模型。此模型的布局选项可以通过下拉菜单中的“首选项”对话框进行控制。Workspace模型的布局选项为
- 平面布局
- 将所有不同步的资源显示为其项目的直接子项。
- 树布局
- 显示项目资源管理器中显示的资源层次结构。
- 压缩文件夹
- 显示按项目分组,然后按文件夹分组的更改。这导致层次结构最多为三层,文件夹路径被压缩到单个层次(类似于Java包)。
- Java模型
- 显示一个基于Java的模型(类似于Package Explorer中显示的模型)。
- Git提交
- 显示一个基于Git Commit的模型。此模型显示按提交分组的传入更改,这对于查看谁释放内容和原因很方便。对于传出更改,您可以通过创建提交来 创建提交。Git提交描述的显示格式可以 在标签Other中的 Team> Git> Label Decorations下的首选项中配置 。
除了模型之外,还有一个 平面演示 ,它将所有不同步的元素显示为顶层元素。
导航
“同步”视图提供了用于浏览视图中的更改的工具栏操作。这些操作不仅可以在文件之间导航,还可以从文件中的更改更改。
同步视图中的树可以很容易地从工具栏展开和折叠。
Git树比较视图
该视图将通过一些Compare With 操作打开 (请参阅 比较内容)。从资源(例如项目或文件夹)启动时,它将看起来类似于工作区中的资源。但是,文件上的通常图标将被替换为显示更改状态的图标(添加,删除,更改或未更改)。
可以浏览更改并双击文件将打开该文件的比较编辑器(这只对“已更改”文件有意义,如果添加或删除文件,比较编辑器的一侧将为空,而未更改的文件将在编辑器的两侧显示相同的内容):
可以通过单击工具栏中的“隐藏等同内容的文件”按钮来隐藏未更改的文件。
Git树比较视图也可以在没有工作区资源作为起点的情况下启动(例如,当历史视图的输入是存储库而不是工作区资源时,通过比较历史视图中的两个提交)。在这种情况下,将显示存储库的完整内容,并且项目和文件夹都显示为简单的“文件夹”图标:
Git Staging View
该视图提供了用于git status
显示工作树中所做更改的等效项 。尚未转移到git索引的未暂停更改显示在“ 未更改更改” 窗格中,已在“ 暂存更改”窗格中显示 已被“添加”(暂存)到Git索引的更改 。默认情况下,这些窗格显示在行布局中,可以通过列布局选项将其更改为列布局 。默认情况下,Staged窗格和Unstaged Changes窗格显示文件的完整路径。可以通过“ 显示文件名优先”选项来配置它们,以 首先显示文件名,然后显示文件所在的目录。
双击已修改的文件以打开比较视图。如果从“未冻结”窗格触发,比较视图将显示尚未分阶段的更改。从“分段”窗格触发时,它将显示已经分阶段进行的更改。要在编辑器中打开 文件,请在文件的上下文菜单中使用“ 打开工作区版本”操作。
要演示文件,请将其从“未分级更改” 窗格拖到 “ 分段页面” 窗格中。或者, 对“ Unstaged Changes” 窗格中文件的上下文菜单使用 Add to Git Index操作 。在 与Git的索引文件替换 操作将替换选定的文件在工作树。如果该文件未冻结,它将被重置。如果它被暂存,工作树版本将被Git索引中的暂存版本替换。
要unstage文件,从拖动它 暂存的变更 窗格的 不分级的变化 窗格。或者, 在文件的上下文菜单中使用 从Git索引删除操作。
提交操作只会提交阶段性更改 - 与git commit
原生git中的操作类似 。集成的提交消息编辑器允许编辑提交的提交消息。与提交对话框不同,分段视图可以在进行更改时保持打开状态。这允许递增地写入提交消息以及更改。正在编辑的提交消息与存储库相关联,分段视图与链接。它不会被持久存储,并且如果分段视图或Eclipse被关闭,它将会丢失。
要提交,请 在提交消息文本字段中按 Ctrl + Enter (Mac OS X上的 ' Command + Enter ),或者单击 提交 或 提交并按下按钮。
部分分期
有时只提交文件的一些更改很有用。例如,在处理某个功能时注意到与该功能无关的错字或小错误。
为了只提交某些更改,这些更改必须首先进行。为此,请双击Unstaged Changes 窗格中的文件 。这将打开比较编辑器。左侧是工作区版本,右侧是索引(分段)版本。
比较编辑器的两侧都是可编辑的。当更改右侧(索引)中的某些内容并保存时,该文件将在“ 分阶段更改” 窗格中显示,并在提交时正好提交该内容。
要 放置一组更改的线条, 可以使用“ 从左到右复制当前更改”工具栏按钮(箭头图标)。
Git Reflog视图
Reflog视图显示选定存储库的Git reflog。它支持通过选择视图右上方的超链接ref名称来显示特定分支的reflog。双击或选择上下文菜单操作 在提交查看器中 打开reflog条目,在提交查看器中打开相应的提交。上下文菜单操作 Checkout 将签出选定的提交,并且 HEAD将分离。
Git网址
通常,Git URL由传输协议方案,远程服务器的地址和远程服务器中的存储库路径以及一些认证协议(也包括用户标识)组成。
EGit支持以下协议
- 文件 - 直接访问存储库的文件系统。
- git - 最高效的内置git协议(默认端口9418)。该协议不提供认证。通常用于对存储库进行匿名读取访问。
- ssh - 通过安全shell(SSH) 协议的Git 。通常用于对存储库进行身份验证的写入访问。
- http - 超文本传输协议 可以通过防火墙隧道传输。
- https - 超文本传输协议安全 可以通过防火墙隧道传输。
- ftp - 文件传输协议
- sftp - SSH文件传输协议
Git URL在使用时使用
Git参考
Git引用也很快就被称为 Refs。
它们包括
- 分支机构
- 远程跟踪分支
- 标签
它们全部用路径命名,使用'/'作为路径分隔符,并以“refs”开头。
- 本地分行以“refs / heads /”开头
- 远程跟踪分支以“refs / remotes /”开头。远程跟踪分支位于远程存储库中的代理分支,以便当没有与存储库的连接可用(脱机)时,也可以查询它们在上次传输操作时的状态。
- 标签以“refs / tags /”开头
只要缩写形式是唯一的,参考名称可以缩写。
例如
- “master”是“refs / heads / master”的简称
- “origin / master”是“refs / remotes / origin / master”的简称
- “v1.0.1”是“refs / tags / v1.0.1”的简称
Refs中还有一些“保留”名称,可用于某些场景:
参考名称 | 备注 |
头 | 指向当前结帐提交 |
FETCH_HEAD | 指向最后一次读取操作的结果 |
ORIG_HEAD | 指向在合并或重建操作启动之前签出的提交 |
有关Ref名称的完整列表以及优先顺序,如果多个引用具有相同的缩写形式,请参阅git rev-parse的 “指定修订”部分 。
Refspecs
提取和推送操作使用“refspec”来描述远程Ref 和本地 Ref之间的映射 。在语义上,它们定义了本地分支或标签如何映射到远程存储库中的分支或标签。在本地git中,它们以<src>:<dst>格式与冒号组合,前面带有可选的加号,+表示强制更新。在EGit中,它们可以在“ 推式参考规格” 和“ 取回参考规格” 和其他对话框中以表格形式显示和编辑 。
RefSpec的“左侧”称为源,“右侧”称为目的地。根据RefSpec是用于读取还是用于推送,源和目标的语义不同:对于Push RefSpec,源表示源存储库中的Ref,目标表示目标存储库中的Ref。
推送Refspecs
Push RefSpec的一个典型例子可能是
HEAD:参考文献/头/主
这意味着当前签出的分支(如HEAD引用所表示的,参见 Git引用)将被推送到远程仓库的主分支中。
获取Refspecs
Fetch RefSpec的典型示例可能是
裁判/头/ *:参/遥控器/产地/ *
这意味着远程存储库中的所有分支都将被提取到本地存储库的相应远程跟踪分支中。
遥控器
远程用于管理从您的存储库跟踪其分支的存储库(“远程”)。
在EGit中,Remotes是在什么时候定义的
- 按照惯例,从另一个存储库克隆一个存储库,这个新创建的存储库名为“origin”。如果您更喜欢不同的名称,克隆向导允许指定该名称。
- 在存储库视图中定义远程
远程首先为 你的分支机构定义一个 名字,这很重要,因为你可能想跟踪不同存储库中的分支,因此这个名字有助于理解某个操作正在处理的存储库。此外 ,为给定Remote指定的Refspecs定义了 本地存储库中分支和标记到远程存储库中分支和标记的 映射。您可能希望为入站或出站传输操作使用不同的映射,因此 编辑人员 可以定义EGit中提供的提取和推送配置。
Git忽略
.gitignore
位于工作树中的文件指定有意不应该被git跟踪的文件。他们只关注那些还没有被git跟踪的文件。为了忽略已跟踪文件中的未提交更改,请参阅 假定不变的操作。
.gitignore
文件中的每一行 定义了一个模式。Git检查忽略工作树层次结构中从高到低的模式。较高级别.gitignore
文件中定义的模式被较低级别中定义的模式 覆盖。项目所有工作中应忽略的文件通常包含在项目的存储库中,以便在团队中轻松共享。
模式格式定义:
- 空白行被忽略
- 以#开始的行 作为注释
- 可选的前缀 ! 否定该模式。再次包括由匹配的先前模式排除的文件。以斜线结尾的模式只匹配目录,但不匹配文件或符号链接。
- 不包含斜杠的模式被视为与相对于.gitignore文件位置的路径匹配的外壳全局模式
- git将模式视为fnmatch(3)中定义的shell球体,
- 在模式中通配符不匹配 / 路径名
- 一个前导斜杠匹配一个路径名的开头
EGit Ignore 菜单操作 将选定资源添加到 .gitignore
资源父目录中的文件。要输入其他忽略模式,请使用文本编辑器。
注意: EGit还没有尊重 .gitignore
Eclipse项目之外的文件,所以如果您有一个包含多个项目的存储库,则应.gitignore
为每个项目添加一个文件,而不是在根目录中添加一个文件。
用于PDE构建的Git Fetch Factory
作为EGit的PDE工具的一部分,org.eclipse.egit.fetchfactory 插件中包含一个用于Git的PDE Build fetch工厂 。
映射文件的文件格式: type @ id,[version] = GIT,args
其中, args 是键值对的逗号分隔列表。
接受的 参数 包括:
- 标记* - 必需的Git标记
- 回购* - 强制回购地点
- 路径 - 相对于指向元素的repo的可选路径(否则,假定元素位于存储库根目录)
- prebuilt - 可选布尔值,指示路径指向存储库中的预先构建的包
提取是通过三个步骤来实现的:
- 存储库被克隆到本地光盘。如果它已经存在,则认为它以前被克隆过,并且只提取新的提交
- 指定的标签将在本地克隆中签出
- 路径的内容将被复制到最终的构建位置
例如:It /用户指南
入门
概观
如果您通常不熟悉Git或分布式版本控制系统,那么您可能首先需要阅读 Git for Eclipse用户 。更多的背景和细节可以在Pro Git的在线图书中找到 。
如果您来自CVS,那么您可以找到适用于Git Platform-releng / Git Workflows的常用CVS工作 流程。
基础教程:将项目添加到版本控制
组态
识别你自己
无论何时更改存储库的历史记录(技术上,每当创建提交时),Git都会跟踪创建该提交的用户。身份证包含一个姓名(通常是一个人的姓名)和一个电子邮件地址。这些信息存储在~/.gitconfig
专用**下的文件中 。
EGit会在您创建第一次提交时询问您的信息。默认情况下,这个对话框只显示一次,直到你创建一个新的工作区或在Git首选项页面勾选“显示初始配置对话框”复选框:
如果您想稍后再查看,也可以取消选中“不要再次显示此对话框”。
您可以随时使用Git配置更改此信息,而不是使用此对话框:
- 点击 首选项>团队> Git>配置
-
单击 新建条目 并输入键值对
user.email
和user.name
在Windows上设置主目录
将环境变量添加 HOME
到您的环境变量中。
- 在Windows 7中,在开始菜单中输入“environment”
- 选择“编辑您的帐户的环境变量”
- 点击“新建”按钮。
- 在名称字段中输入“HOME”
- 在值字段中输入“%USERPROFILE%”或其他路径。
-
单击确定,然后再次确定。您刚刚在Windows上添加了主目录。
EGit需要这个路径来查找用户配置(.gitconfig)。 HOME
应该指向你的主目录,例如 C:\Users\Tom
。 确保正确的情况! 例如, C:\users
而不是 C:\Users
可能会导致问题!
如果 HOME
变量未定义,则主目录将通过连接HOMEDRIVE
和 来计算 HOMEPATH
。
如果两个 HOME
和 HOMEDRIVE
没有定义 HOMESHARE
将被使用。
如果HOME
未明确定义,EGit会显示警告 。请记住,如果您在Eclipse运行时设置HOME环境变量,则仍会看到以下警告。您必须重新启动Eclipse才能识别HOME值。
指出系统范围的配置
如果您使用Git for Windows作为EGit的伴侣,请确保EGit知道Git的安装位置,以便找到“系统范围设置”,例如core.autocrlf的设置。转到设置并查看Team> Git> Configuration,然后点击System Settings标签。
如果您在安装Git for Windows时从命令行提示中选择了其中一个选项来使用Git,则系统范围设置的位置将填充一个路径,并且一切正常。如果没有,使用浏览按钮找到Git的安装位置,例如C:\ Program Files(x86)\ Git。
此建议也适用于其他Git包装的用户,例如Cygwin或TortoiseGit下的Git。
非Windows用户理论上应检查此设置,但系统范围设置通常不在非Windows平台上使用。
创建存储库
-
创建一个新的Java项目
HelloWorld
。(在这种情况下,该项目是在Eclipse Workspace之外构建的。)
- 选择该项目,然后单击 文件>团队>共享项目
- 选择存储库类型 Git 并单击 下一步
-
要配置Git存储库,请选择新项目
HelloWorld
-
点击 Create Repository 为项目初始化一个新的Git仓库
HelloWorld
。如果您的项目已经驻留在现有Git存储库的工作树中,则会自动选择该存储库。
- 单击 完成 关闭向导。
-
项目后面的装饰器文本“[master]”显示该项目在主 分支上的存储库中被跟踪, 并且问号装饰器显示
.classpath
and.project
和.settings
文件尚未受版本控制
跟踪变化
- 在项目节点上单击 团队>添加。(这个菜单项可能会读取 最近版本的Egit的Add to Index)
- 在 + 装饰显示,目前该项目的文件添加到版本控制
-
将“bin”文件夹标记为“Git忽略”,方法是右键单击 该文件 夹并选择 Team> Ignore或通过
.gitignore
在项目文件夹中创建 具有以下内容的文件
/箱
-
这
bin
将从Git的被跟踪文件列表中排除该 文件夹。 -
添加
.gitignore
到版本控制(团队>添加):
-
您可能必须设置包资源管理器筛选器才能看到包资源管理器中
.gitignore
显示的内容。要访问过滤器,请选择Package Explorer选项卡右侧的向下箭头以显示View Menu。
-
从视图菜单中选择 Filters ...,将出现Java Element Filters对话框。取消选择顶部条目以显示以开头的文件。(期)如
.gitignore
。
- 在项目上下文菜单中单击 团队>提交
-
输入提交消息来解释您的更改,第一行(后跟一个空行)将成为此提交的简短日志。默认情况下,作者和提交者来自
.gitconfig
主目录中的 文件。 - 您可以点击 Add Signed-off-by 添加 Signed-off-by: 标签。
- 如果您正在提交其他作者的更改,则可以更改作者字段以提供作者的姓名和电子邮件地址。
- 点击 确认 提交您的第一个更改。
- 请注意,提交文件的修饰器已更改。
检查历史
- 从上下文菜单中单击 团队>历史显示以检查资源的历史记录
-
创建一个新的Java类
Hello.java
并实现它 - 将它添加到版本控制并提交您的更改
- 改进你的实现并提交改进的类
- 现在资源历史记录应该显示2个提交此类的提交
- 点击 历史视图中的 比较模式切换按钮
-
双击
src/Hello.java
历史视图的资源列表以在比较视图中打开上次提交的更改
恭喜,您刚刚掌握了使用Git的第一个项目!
GitHub教程
创建本地存储库
- 按照 EGit / User Guide / Getting Started 创建一个新的本地存储库(使用您的内容而不是演示项目)
在GitHub创建存储库
- 在GitHub上创建一个新的存储库
在下一个屏幕上,您可以看到您可能用来访问新的新存储库的URL:
- 单击 SSH 以选择 SSH协议。它可以用于读写访问
- 点击 HTTP 选择 HTTP协议。它也可以用于读写访问。
- 点击 Git Read-Only 来选择 用于克隆的匿名 git协议。这是git支持的最有效的协议。由于 git协议 不支持身份验证,因此通常用于提供对公共存储库的有效只读访问。
Eclipse SSH配置
- 打开Eclipse 首选项 并确保您的SSH2主页配置正确(通常是 〜/ .ssh)并包含您的SSH2**
- 如果您还没有SSH**,您可以在第二个对话框的Key Management (**管理)对话框中生成它们 ,请使用一个好的密码短语来保护您的私钥,更多详细信息请参阅 “使用**密码短语”
- 将您的公共SSH**上传到您的 GitHub帐户设置
推上游
- 点击 团队>远程>推送... 并复制并粘贴新的GitHub存储库的SSH URL
- 如果您位于不允许SSH通信的防火墙后面,请改用GitHub HTTPS URL,并提供您的GitHub用户和密码,而不要使用上传的公用SSH**。要将您的凭证存储在Eclipse安全商店中,请点击 安全商店中的商店。
- 注意: 许多HTTP代理被配置为阻止包含用户名的HTTP URL,因为在HTTP URL中公开用户名被认为是安全风险。在这种情况下,请从HTTP URL中删除用户名,并仅在用户字段中提供该用户名。它将作为HTTP标头发送。
- 点击 下一步 ,在第一个连接上接受GitHub的主机**。
- 输入您的SSH**的密码,然后单击 确定。
- 在下一个向导页面上,单击 添加所有分支规范 以将本地分支名称1:1映射到目标存储库中相同的分支名称。
- 点击 下一步。推送确认对话框将显示将推送到目标存储库的更改的预览。
- 单击 完成 确认您要推送这些更改。
- 下一个对话框报告推送操作的结果。
- 将您的浏览器指向您的GitHub存储库以查看您的新存储库内容已经到达
EclipseCon 2012 Git教程
在这里找到所有练习和幻灯片 。
按照 练习#1 准备Git教程。
概念
Git建立在一些简单而强大的想法之上。了解它们有助于更轻松地了解git如何工作。
知识库
存储库或对象数据库存储构成项目历史的所有对象。此数据库中的所有对象都通过 对象内容的安全20字节SHA-1散列标识 。这有几个好处:
- 比较两个对象归结为比较两个SHA-1哈希值
- 由于对象名称是在每个git存储库中以相同的方式从对象内容中计算出来的,所以相同的对象将以相同的名称存储在恰好包含此对象的所有存储库中
- 一旦创建对象就不会改变(显而易见,因为改变内容意味着必须计算新的散列并分配新名称)
- 通过检查SHA-1对象名称是否仍然是对象内容的安全散列,可以轻松检测到存储库损坏
Git有四种对象类型:
- 一个 Blob对象 存储文件内容
- 一个 树对象 存储的目录结构和包含 的Blob对象 和其他 树对象 与自己的文件系统名称和模式一起
- 甲 提交对象 表示的目录结构的快照的提交时间,并具有连接到它的前身 提交对象,其形成在所述储存库历史库修订一个非循环图。
- 一个 标签对象 是一个符号命名的链接到包含对象名称和关于谁创造了标签和签名信息的一个被引用的对象和可选信息的类型另一个仓库对象。
对象数据库存储在 .git/objects
目录中。对象既可以作为松散对象存储,也可以以包格式存储,将多个对象有效地封装到一个文件中,以便高效地存储和传输对象。
相信
Git通过安全的SHA-1哈希提供了一个内置的信任链,它允许它验证从(可能不受信任的)源获得的对象是否正确并且自创建以来未被修改过。
如果您获得签名标签,例如您可以验证的项目版本,例如标签(例如项目负责人)的公共签名**git可确保信任链覆盖以下内容:
- 签名标签标识一个提交对象
- 提交对象恰好表示一个项目修订,包括其内容和历史记录
- 提交对象包含blob对象树和其他表示项目修订目录结构的树对象
- blob对象包含此项目修订的文件内容
可以使用SHA-1算法检查所有涉及的对象名称的一致性,以确保项目修订的正确性,并以此方式确保可以信任整个历史记录。
指数
在 GIT中索引 是存储在一个二进制文件 .git/index
包含文件名,文件模式的排序列表目录,文件用于有效地检测文件的修改和斑点对象的SHA-1的对象名称的元数据。
它具有以下重要属性:
- 该索引包含生成单个唯一定义的树对象所需的全部信息。例如,提交操作会生成此树,将其存储在对象数据库中并将其与提交相关联。
- 该索引可以快速比较其定义的树与当前工作目录。这是通过在索引数据中存储关于涉及文件的附加元数据来实现的。
- 索引可以高效地存储合并涉及的树之间的合并冲突信息,以便为每个路径名提供有关所涉及树的足够信息以启用三向合并。
分行
Git中的分支是对提交的命名引用。有两种类型的分支,即“本地”和“远程跟踪”分支,用于不同目的。
当地分支机构
无论何时提交对(本地)存储库的更改,都会创建一个新的提交对象。如果没有其他任何方式,要记录存储库中的更改非常困难,特别是当其他提交已添加到存储库时,例如由于远程存储库的更新或检出另一个提交时。
本地分支通过提供可以找到“当前”提交的(本地)名称来帮助完成此任务。当更改提交到本地存储库时,分支会自动更新为指向新创建的提交。
另外,可以将一个所谓的上游配置添加到本地分支,这在与远程存储库同步时会很有帮助。
远程追踪分支
从远程存储库进行克隆和提取时会自动创建远程跟踪分支。本地存储库中的远程跟踪分支总是对应于远程存储库中的(本地)分支,并且这样的分支的名称遵循特定的约定。
远程跟踪分支指向与远程存储库中对应分支相同的提交(在克隆/提取时)。
远程跟踪分支可用于自动创建本地分支的上游配置。
工作目录
工作目录是用于修改下一次提交的文件的目录。默认情况下,它位于.git目录的上一级。进行新的提交通常涉及以下步骤:
- 检出新提交应基于的分支,这将更改工作目录,以便它反映 分支的 HEAD修订。
- 在工作目录中进行修改
- 告诉git这些修改(添加修改后的文件)。这将修改后的文件内容传输到对象数据库中,并准备要在索引中提交的树。
- 将索引中准备的树提交到对象数据库中。
- 结果是一个新的提交对象, 当前分支的 HEAD移动到新的提交。
记录存储库中的更改
您从全新的本地存储库分支结帐开始。每当您想要记录更改的状态时,您都希望进行一些更改并在存储库中记录这些更改的快照。
工作目录中的每个文件都可以 跟踪 或不 跟踪。
- 跟踪的文件是最近一次快照中的文件或新近进入 索引的文件。它们可以是 未经修改, 修改或上演的。
- 未追踪的文件是不在最后一个快照中的所有其他文件,并且尚未添加到 索引中。
当您第一次克隆存储库时,工作目录中的所有文件都将被跟踪 并且 不会被 修改, 因为它们已被新签出,并且您尚未开始编辑它们。
当你编辑文件时,git会识别出自 上次提交以来修改过的文件,所以它们会被 修改。您 阶段 修改后的文件到索引,然后提交阶段性变化和周期重复。
这里说明这个生命周期
任务
创建存储库
在Eclipse中使用Git存储库的注意事项
短篇小说
使用EGit设置Git存储库时,有两个建议可用于创建“生产性”(而不是“操场”)存储库:
-
不要在Eclipse工作区内创建存储库
- 克隆或创建存储库时要小心
- 确保正确使用Git共享向导
-
不要以root身份创建Eclipse项目的Repository
- 确保正确使用Git共享向导
第一种情况是在克隆或创建存储库期间指定工作区文件夹时发生。
当您在工作区中手动创建的Eclipse项目中使用Git共享向导时,如果不采取预防措施(该向导已在最新版本中修复),上述两种情况都会发生。
下面你会发现这些建议的一些动机。
更长的故事
Eclipse工作区和存储库工作目录
可以通过不同的方式创建Git存储库,例如通过从现有存储库进行克隆,从头创建一个或使用EGit共享向导。
在任何情况下(除非你创建一个“裸”存储库,但这里没有讨论),新的存储库本质上是一个本地硬盘上的文件夹,它包含“工作目录”和元数据文件夹。元数据文件夹是一个名为“.git”的专用子文件夹,通常称为“.git-folder”。它包含实际的存储库(即提交,参考,日志等)。
元数据文件夹对于Git客户端是完全透明的,而工作目录用于将当前签出的存储库内容公开为工具和编辑器的文件。
通常,如果这些文件将在Eclipse中使用,则必须以某种方式将它们导入到Eclipse工作区中。为了做到这一点,最简单的方法是检入。“导入现有项目”向导可以从中轻松创建项目的项目文件。因此在大多数情况下,包含Eclipse项目的Repository结构看起来类似于这样的东西:
启示
以上含义如下:
- 将项目设置为Repository的根文件夹可能不是一个好主意
- 原因是你将永远无法将另一个项目添加到此存储库,因为.project文件将占据根文件夹; 您仍然可以将项目添加为子文件夹,但是这种项目嵌套已知会导致遍布各处的许多问题。为了添加另一个项目,您必须将项目移动到存储库中的子文件夹,并将第二个项目添加为另一个子文件夹,然后才能提交此更改。
- 将您的Repository放在Eclipse Workspace之外是一个好主意
- 有几个原因:
- 新的存储库将把Eclipse工作区的完整文件夹结构视为(潜在的)内容。这会导致性能问题,例如在提交前计算更改(例如,将扫描完整的.metadata文件夹); 通常情况下,工作空间将包含死文件夹(例如删除的项目),这些文件夹在语义上与EGit无关,但不能轻易排除。
- 元数据(.git-)文件夹将是Eclipse工作区的一个子元素。目前还不清楚这是否会导致Eclipse进行不需要的文件夹遍历。
- 通过销毁Eclipse工作区,您可以轻松销毁您的Repository
创建一个新的空的Git仓库
您可以先创建一个项目并在之后分享。共享项目向导支持创建Git存储库(请参阅 将项目添加到版本控制)。
您也可以从Git存储库视图创建一个新的空的Git存储库(请参阅 创建存储库)。
为多个项目创建一个Git存储库
您可以先在一个公共目录下创建多个项目,然后一次为所有项目创建一个公共存储库:
- 在共同目录下创建Eclipse项目,例如a,b,c例如 / repos / examples /
- 选择所有项目a,b,c - 从上下文菜单中单击 团队>共享项目> Git
- 按 下一步
- 选择所有项目a,b,c
- 该向导自动将默认存储库位置上移到父文件夹 / repos / examples /, 因为已选择多个项目
- 单击 创建存储库 并 完成
从现有的Git存储库开始
为了在Eclipse工作台中处理Git存储库的内容,必须将所包含的文件和文件夹作为项目导入。原则上,可以使用通用的“新建项目”或“导入...”向导来完成此导入,因为Git存储库的工作目录只是本地文件系统中的普通目录。但是,新创建的项目仍然必须与Git手动共享。“从Git导入项目”向导集成了项目导入和共享,并且还提供了一些额外的便利。
启动导入向导
要启动该向导,请单击 导入> Git> Git项目
如果您是在干净的工作区中开始的,则第一页将显示一个空列表:
在继续之前,您需要将一个或多个Git存储库添加到列表中。如果列表中已有存储库,则此步骤是可选的。
克隆或添加存储库
有两种方法可以将Git存储库添加到列表中:
- 克隆远程存储库
- 从本地文件系统添加一个现有的存储库
克隆存储库
如果您从远程存储库开始,则会使用第一个选项。克隆操作会将该存储库复制到本地文件系统。要启动克隆向导点击 克隆...。Cloning Remote Repositories中详细描述了克隆向导 。成功完成克隆操作后,新克隆的存储库会自动出现在列表中。
添加一个存储库
如果您的本地文件系统中已经有一个存储库,则第二个选项非常有用,例如,因为您之前已经克隆了它,您是从头开始创建它的,或者是从其他位置复制它的。点击 添加... ; 并在本地文件系统中选择一个目录。按 搜索 触发对此目录中包含的Git存储库的扫描。如果找到Git存储库,它们将被列出,您可以选择存储库来添加:
成功完成后,存储库列表应包含一些存储库:
从列表中选择一个存储库
您现在可以选择一个存储库并单击 下一步。在以下向导页面中,您将决定如何导入项目。
导入项目
此页面提供了一个带有单选按钮的组,允许您选择一个向导和一个目录树,该目录树可以选择允许您在工作目录中选择一个文件夹。
项目导入向导
导入现有项目
如果选择此单选按钮,向导将扫描本地文件系统中的 .project 文件并显示为导入而找到的项目。这是最舒适的解决方案,如果将.project 文件签入存储库,应该使用它 。
限制项目导入的范围
在这种情况下,底部的目录树处于活动状态。您可以 通过在此树中选择一个文件夹来限制.project文件的搜索 ,否则将扫描存储库的完整工作目录。在下一页中,将显示找到的项目列表(如果有的话)。这与通用导入现有项目 向导非常相似 ,但具有一些额外的过滤功能:
使用新建项目向导
选择此选项时,通用“新建项目”向导将打开。完成“新建项目”向导后,“从Git导入项目”向导将恢复并协助共享刚刚创建的项目。
在这种情况下,底部的目录树处于非活动状态,因为选择与“新建项目”向导无关。
导入为一般项目
当有没有这个选项可以帮助 的.project 可用的文件,也没有合适的“新建项目”向导适用于Git仓库的内容。如果选择,向导将生成一个 .project 文件并将该项目指向存储库工作目录的文件夹。结果是一个“总体项目”。
默认情况下,新生成的项目将指向Repository的工作目录。通过从底部目录树中选择一个文件夹,可以为该文件夹生成项目。
点击 Next 打开一个简单的对话框,输入新项目的名称和目录:
默认情况下,建议的项目名称与目录的名称相匹配。
使用远程存储库
克隆远程仓库
使用Git克隆向导,您可以使用不同的传输协议克隆远程存储库。
该向导可以从“从Git导入项目”向导启动,使用
导入...> Git> Git项目>下一步>克隆...
或者使用“ 克隆Git存储库” 工具栏按钮或视图菜单从“Git存储库视图”(在“ 管理存储库 ”中进行了介绍 ) 。
存储库选择
在向导的第一页上输入远程存储库的位置:
-
URI - 远程存储库的完整URI或文件系统上的路径。该字段会自动与其他字段同步。
请注意,您可以使用 本地文件... 按钮浏览本地目录,并且URI字段通过提供以前使用的值来提供内容帮助 - 主机 - 远程主机的名称,如果从文件系统克隆则为空。
- 存储库路径 - 远程存储库或文件系统的路径。
- 协议 - 下面描述的协议之一。
- 端口 - 端口号。
- 用户 - 用于认证的用户名。
- 密码 用于验证的密码。
- 存储在安全存储 中密码是否保存在Eclipse安全存储中。
支持以下协议:
- 文件 - 文件系统对存储库的访问。
- ftp - 文件传输协议
- git - 最高效的内置git协议(默认端口9418)。该协议不提供认证。通常用于对存储库进行匿名读取访问。
- http - 超文本传输协议 可以通过防火墙隧道传输。
- https - 超文本传输协议安全 可以通过防火墙隧道传输。
- sftp - SSH文件传输协议
- ssh - 通过安全shell(SSH) 协议的Git 。通常用于对存储库进行身份验证的写入访问。
注意: 如果您位于防火墙后面,则可能需要配置您的代理设置(首选项>常规>网络连接)。许多HTTP代理配置为阻止包含用户名(和/或密码)的URL,例如 http:// fred:[email protected]/egit.git, 因此建议使用 用户名和 密码 字段向导页面中,凭据将作为HTTP标头传输。
分支选择
在下一页选择哪些分支应从远程存储库中克隆:
如果您不确定您需要哪些分支,只需点击“全选”。
您可以通过使用列表上方的文本控件进行输入来按名称过滤分支。但是,请注意,已检查的分支将始终显示在列表中,即它们不会被过滤。
本地目的地
在下一页定义您想要在本地文件系统上存储存储库的位置并定义一些初始设置。
- 目录 - 将包含Git存储库的目录。如果它尚不存在,它将由向导创建。
- 初始分支 - 选择在哪里创建本地分支并初始签出。
- 远程名称 - 为远程存储库定义一个名称。默认值是“原点”。
可以在首选项Team> Git> Default Repository Folder中配置用于存储Git存储库的默认根路径
您可以按此 页面上的完成,或者 如果您正在使用 Gerrit Code Review 并且您想相应地配置您的存储库,请按 Next。
从特定位置克隆
EGit的Clone向导可以通过其他插件进行扩展,以便在托管git存储库的特定后端上搜索存储库。目前这种扩展可用于Github,很快将可用于Gerrit。对于您需要安装各自的Mylyn连接器。Gerrit Mylyn连接器扩展然后还将配置Gerrit工作的远程存储库。这也可以在Git存储库视图中完成或更改,请参阅 Gerrit配置。
当您安装了这样的扩展程序时,克隆向导打开并显示一个选择页面,您可以在该页面中选择要克隆的不同资源库源:
推送到其他仓库
推向上游
如果您正在使用具有所谓“ 上游配置 ” 的本地分支,则最便捷的推送方式依赖于此上游配置。
通常,本地分支机构是基于远程跟踪分支创建的。由于远程跟踪分支与远程关联,并且远程包含访问相应远程存储库所需的信息,因此可以在创建本地分支时自动创建此上游配置(请参阅 分支 以获取更多信息)。
从本地分支向上游推送时,推送不需要其他参数,因此可以在不显示基于存储的上游配置的另一个对话框的情况下执行。
为了推送上游,右键单击项目并选择 Team> Push to upstream 或右键单击存储库视图中的存储库,然后单击 推送到上游。Git Command Group也有一个可用的操作 。
然后在选择操作后立即执行推送。完成后,将显示一个确认对话框,显示有关推送的数据和/或错误消息的信息:
配置上游推送
可以使用确认对话框中的“Configure ...”(配置...)按钮(见上文)或通过右键单击项目并选择Team> Remote> Configure push to upstream ...来配置上游推送。
将显示一个配置对话框,用于配置推送URI和相应的分支映射(RefSpecs):
该对话框分为三个主要部分。在上部分中,显示了关于当前存储库和当前检出的分支的信息。外部组显示与当前分支关联的远程的推送配置(在我们的例子中,“组”文本中显示的“原点”)。
在这个特定的例子中,有一个警告消息,指出有几个分支使用名为“origin”的远程设备。这意味着推送配置中的更改将影响所有这些分支,而不仅仅是分支字段中显示的分支。
URI组包含两个控件,一个URI字段和一个Push URIs列表。如果列表为空,则URI字段中的URI将用于Push,如果至少有一个条目位于Push URIs列表中,则将使用列表中的URI。应该注意的是,如果Push URI列表为空,并且在此对话框中更改了URI,则新的URI也将用于Pull,因此在执行此操作时应小心。
RefMapping Group允许指定一个或多个RefSpecs(请参阅 Refspecs)推送。
“添加”将打开一个小向导,帮助创建RefSpecs。您也可以将剪贴板中的RefSpec粘贴到列表中。
点击“高级”控件将显示/隐藏“编辑(高级...)”按钮,允许更复杂的RefSpec编辑,类似于 下面的 推送向导。
下部按钮栏中的按钮允许您保存所做的更改并立即进行推送,保存更改而不提取,干运行(推送而不保存配置),恢复更改并取消。
直接推送
或者,您可以 在远程的推送规范上使用 直接推送支持。
推送向导
最强大(但也是最复杂的)方法是使用推送向导
团队>远程>推送...
推送URI
- 如果您已经在存储库视图中配置了推送规范,则也可以使用配置的远程存储库下的下拉列表在此处选择它 。 如果这个远程的Push Specification配置正确(即至少有一个URI和一个引用规范), Finish按钮将被启用。
- 否则,请单击 自定义URI 并输入要推送到的上游存储库的URI。
推参考规格
有关 更多解释,另请参阅 参考资料。
单击 Next
如果这是您第一次通过ssh连接到此存储库,则必须接受远程存储库的主机**
如果您的ssh**受密码保护(建议使用),您必须在此处输入密码
点击 添加所有分支规范
这是一种方便的方式,用于声明您想要将本地分支名称映射到要推送更改的上游存储库上的相同分支名称。
点击 添加所有标签规范 将本地标签1:1映射到您要推送到的存储库中的标签。
如果您想以不同的方式将本地分支映射到上游存储库中的分支,您可以按照以下方式定义更详细的映射规范
- 输入源和目的地ref或从下拉列表中选择已存在的分支
- 点击 添加规范
这会将新定义的映射转移到列表 规格中进行推送
其他常见推式规格:
- 根据你的昵称 joe,你可以将refs / heads / *映射 到 refs / heads / joe / *。如果多个用户想要在共同使用的公共存储库中的个人分支上发布他们的本地分支,这是非常有用的。
- 另一个通常的映射是将源头部头部映射到 目的地 头部/头部/头部。这意味着您想要将当前的HEAD (可能当前指向任何本地主题分支)映射 到上游主分支。
删除参考规格
要删除目的地信息库中的裁判选择从下拉列表中删除裁判 远程裁判删除 ,然后单击 添加规格。这将在推送 列表的规范中创建相应的条目 。或者,您可以键入要删除的参考文件的规格,也可以使用通配符。推送删除参考规格将删除目标存储库中的匹配Refs。
冲压推力参考规格
如果您添加多个冲突推式参考规格,它们将被标记为红色,通过删除或编辑冲突规格来解决此问题。也可以在列表规格中就地编辑规格
推确认
点击 下一步
这将打开“推送确认”对话框,显示预览哪些更改将被推送到目标存储库。如果这与您的期望不符,请单击“上 一步” 并相应地更正您的推式规格。
- 对于ref更新,要提交的提交范围将以<SHA1-from> .. <SHA1-to>格式显示, 例如 d97f5a2e..adfdbfd2 表示将推送d97f5a2e 和 adfdbfd2之间的所有提交 。
- 对于尚未存在于目标存储库[新分支] 或 [新标签]中的引用将 显示。
- 显示将被删除[删除]的参考 。
- 如果要确保在预览中看到的内容也是您推送这些更改时获得的内容,请选中仅在远程引用未在平均时间内更改的情况下 按下复选框。
- 选择 显示最终报告对话框,只有当它从这个确认报告不同 复选框,如果你只是想执行后推得到一个报告,如果结果从该预览不同。
推送结果报告
点击 完成
根据您选择的选项,显示推送结果报告对话框
在底部的框中显示来自远程服务器的推送确认消息。如果有任何错误,您可以在这里找到来自远程服务器的错误消息。要查看给定列表条目的消息,只需在列表中选择它。
点击 确定 关闭对话框。
从其他存储库获取
从上游获取
如果您正在使用具有所谓“ 上游配置 ” 的本地分支,则最方便的取回依赖于此上游配置。
本地分支通常基于远程跟踪分支创建。由于远程跟踪分支与远程关联,并且此远程程序包含访问远程存储库所需的信息,因此可以在创建本地分支时自动创建此上游配置(请参阅 分支 以获取更多信息)。
从上游获取时,此持久配置可用于自动提取,而无需在对话框中提供更多参数。
为了从上游获取数据,请单击 项目上游的团队>获取,或单击 存储库视图中存储库上的从上游获取。Git Command Group也有一个可用的操作 。
选择操作后,将立即执行提取。一旦完成,将显示一个确认对话框,显示有关获取数据和/或错误消息的信息:
配置上游获取
可以使用确认对话框中的“Configure ...”(配置...)按钮(参见上文)或通过单击项目上的 Team> Remote> Configure fetch from fetch ... 来配置上游获取。
将显示一个配置对话框,用于配置获取URI和分支映射(RefSpecs):
该对话框分为三个主要部分。在上部分中,显示了关于当前存储库和当前检出的分支的信息。外部组显示与当前分支关联的远程的抓取配置(在我们的例子中,组的文本中显示“起源”)。
URI字段可用于添加/更改提取URI。
RefMapping组允许指定一个或多个RefSpecs(请参阅 Refspecs)进行提取。
“添加”按钮将打开一个小向导,帮助创建RefSpecs。您也可以将剪贴板中的RefSpec粘贴到列表中。
点击“高级”控件将显示/隐藏“编辑(高级...)”按钮,允许更复杂的RefSpec编辑,类似于 获取向导。
下部按钮栏中的按钮允许您保存更改并立即执行提取,保存更改而不提取,干运行(取出而不保存配置),恢复更改并取消。
直接抓取
另一种获取方式是 在远程的获取规范上使用 直接获取支持。
抓取向导
最强大(但也是最复杂的)方法是使用抓取向导
团队>抓取...
- 如果您已经在存储库视图中配置了提取规范,则也可以使用配置的远程存储库下的下拉列表在此处选择它 。 如果这个远程的获取规范配置正确(即至少有一个URI和一个引用规范),则 完成按钮将被启用。
- 否则,请单击 自定义URI 并输入要从中提取更改的上游存储库的URI。
获取参考规格
有关 更多解释,另请参阅 参考资料。
单击 下一步
单击 添加所有分支规范
这是一种方便的方法,用于声明要将要从1:1提取更改的上游存储库中的分支名称映射到相同的本地分支名称。
- 单击编辑字段 Destination Ref ,并将路径段choose_remote_name替换 为要从中提取的上游存储库的符号名称。
- 您的存储库已克隆的存储库的默认远程名称是 origin。此远程的主设备默认从refs / heads / master映射 到 refs / remotes / origin / master。
- 如果您想另外追踪Joe本地仓库中的Joe仓库的分支机构,您可以将分支机构的仓库中的refs / heads / *映射 到以下跟踪分支 refs / remotes / joe / *。
- 如果您只允许快进更新,请取消选择 强制更新,如果您还想允许非快进更改,请选择此选项。
- 单击 强制更新所有参考 以在所有规格上设置强制更新选项
- 点击 删除所有规格 ,从列表规格中删除所有规格
- 点击 添加所有标签规格 ,将您想要从1:1获取的存储库中的标签标签映射到本地标签。
如果您想以不同的方式将上游存储库中的分支机构或标签映射到本地分支机构,则可以通过以下方式定义更详细的映射规范
- 输入源(在源代码库中引用)和目标引用(在本地存储库中跟踪分支或标记)或从下拉列表中选择已存在的分支
- 点击 添加规范
这会将新定义的映射传输到列表 提取规格
获取结果报告
点击 完成
显示提取结果对话框。
- 对于ref更新,已提取的提交范围将以<SHA1-from> .. <SHA1-to>格式显示, 例如 d97f5a2e..adfdbfd2表示 已提取d97f5a2e 和 adfdbfd2之间的所有提交 。
- 对于在本地存储库[新分支] 或 [新标签]之前不存在的参考资料 显示。
- 显示已被删除[删除]的参考文献 。
从上游分支拉动新变化
- 右键单击Package Explorer中的项目,然后选择 Team> Pull 或右键单击Git存储库视图中的存储库,然后选择 Pull从本地分支正在跟踪的上游分支中提取新更改。这也适用于从多个存储库中选择资源的情况。
- 无论何时创建基于远程跟踪分支的本地分支,EGit都可以配置跟踪关系,以便后续的提取将获取并合并或重新绑定(取决于此跟踪关系的配置)来自所跟踪的上游分支的更改; 详情请参阅分支。
EGit还不支持临时选择上游分支来提取。
可用的选择包括:
- 从外部eclipse 运行 git pull(但 要注意Windows)
- 如果您没有进行本地更改或想要放弃本地更改,请使用 团队>重置...
与Gerrit合作
如果您正在使用Gerrit(http://code.google.com/p/gerrit/),EGit允许您方便地向Gerrit服务器推送和从Gerrit服务器提取更改。
将更改推送到Gerrit Code Review Server
右键单击项目并选择 Team> Remote> Push to Gerrit ... 或右键单击存储库视图中的存储库节点,然后选择 Push to Gerrit ...
将出现一个对话框,让您选择或输入URI和分支名称:
- 在URI组合中,选择或输入指向您的Gerrit实例的URI; 该组合将被预填充当前存储库的任何远程中定义的所有URI; 另外你可以在这个字段中输入任何URI
- 在Gerrit分支字段中,输入要推送到的Gerrit分支的名称
该对话框还为Gerrit分支提供内容帮助。只需按下“Ctrl + Space”即可**此功能(请参阅在Gerrit分支字段附近悬停在小灯泡装饰器上时出现的工具提示)。将显示当前存储库的远程跟踪分支。请注意,此内容帮助已过滤,因此为了查看所有提案,您需要确保在请求内容帮助之前将Gerrit分支字段留空。
点击 完成后,当前签出的提交将被推送到指定的Gerrit分支。另外,当对话框稍后再次打开时,URI和Gerrit分支值将被记住并再次建议。
这允许在并行处理不同Gerrit分支时具有更大的灵活性(例如,频繁地在开发和修补之间切换)。
从Gerrit Code Review Server获取更改
右键单击项目并选择 团队>远程>从Gerrit获取... 或右键单击存储库视图中的存储库节点,然后选择从Gerrit获取...
会出现一个对话框,让您选择或输入URI和更改以及一些其他选项:
- 在URI组合中,选择或输入指向您的Gerrit实例的URI; 该组合将被预填充当前存储库的任何远程中定义的所有URI; 另外你可以在这个字段中输入任何URI
-
在更改字段中,您必须输入更改的完整名称; 您可以从Gerrit Web UI获取该值,使用下面描述的内容帮助,或者使用以下模式构建名称:
“refs / changes /”+(更改编号的后两位数字)+ / +(更改编号) + / +(修订版号) -
在“获取后执行的动作”中,您可以决定在获取更改后要执行的操作; 您可以创建并签出指向更改的分支,创建并签出指向更改的标签,或者只需签出更改(从而使HEAD分离); 最后一个选项在获取后不做任何处理,但是您可以在FETCH_HEAD中找到与更改有关的提交(转至存储库视图并在存储库的引用节点下找到FETCH_HEAD,请参阅 检查引用 )。
分支或标签的名称由对话框建议,但可根据需要进行覆盖。
由于EGIT目前不支持删除标签,因此我们建议暂时使用本地分支而不是标签。由于存储库视图允许使用“/”作为层次结构分隔符对分支进行分层分组,因此建议的名称在处理大量更改时可能非常方便。
除了繁琐的复制粘贴或手动输入更改ID之外,该对话框还提供了有关更改的内容帮助。只需按下“Ctrl + Space”即可**此功能(请参阅将鼠标悬停在“更改”字段旁边的小灯泡修饰器上时出现的工具提示)。Gerrit服务器将被联系,所有可用的更改将被提取并显示在内容辅助对话框中:
该列表将在更改字段中用您的输入进行过滤。选择内容帮助中的更改后,“更改”字段将填充正确的信息。
检查Repository的状态
标签装饰
标签装饰将显示Git版本控制下的Git特定信息。它们出现在显示模型对象的所有视图中,如包资源管理器,项目资源管理器,导航器,层次结构视图。
Git标签装饰可以在General> Appearance> Label Decorations下的Preference Menu(Window> Preferences)中 全局打开。
更详细的设置可以在Team> Git> Label Decorations下的首选项中完成 。
有两种不同类型的标签装饰:文字装饰和图标装饰。
文本装饰
文字装饰出现在文字标签的左侧或右侧。它们可以在选项对话框 的文字装饰标签上的 Team> Git> Label Decorations下进行配置 。例如,肮脏资源的默认值是a > ,位于其名称的左侧。
这些是默认设置:
对于文件和文件夹,有变量 “名称”, “脏” 和 “上演”。 “肮脏” 和 “上演” 是旗帜; 如果它们为真,则显示冒号后面的文本。
对于项目,还有额外的变量 “存储库” 和 “分支”。在 “库” 变量显示存储库的名称。
在 “分支” 变量显示当前签出分支的名称。如果未检出分支,装饰将显示提交的缩写名称(前七个字符,后跟省略号)。如果标签和/或远程分支指向此提交,则应用“最佳猜测”启发式也会显示以下信息:标签优先于远程分支,如果应用了多个标签,则会显示最新标签; 如果有多个远程分支或标签没有修改日期,则应用字母排序,并显示最后一个。例如:签出的承诺e49f576 ... 是指标签 v.0.7.1 库的 例如:It:
图标装饰
图标装饰出现在标签前面显示的图标的右下角。他们可以在选项对话框中 的图标装饰上的 Team> Git> Label Decorations下进行配置。
这些是默认装饰:
- 脏(文件夹) - 文件夹下至少有一个文件脏了; 这意味着它在工作树中的变化既不在索引中也不在存储库中。
- 跟踪 - 资源是Git知识库,因此在版本控制下。
- 未跟踪 - 资源未被Git存储库所知,并且在明确添加之前不会受版本控制。
- 忽略 - 资源被Git团队提供者忽略。团队>忽略资源下的首选项设置 ,.gitignore 文件中的“派生”标志和设置都会 被考虑在内。
- 脏 - 资源在工作树中发生更改,既不在索引中,也不在存储库中。
- staged - 资源已经添加到索引中的更改。请注意,只能在提交对话框中通过资源的上下文菜单添加对索引的更改。
- 部分阶段化 - 资源包含已添加到索引中的更改以及工作树中既没有到达索引也没有提交到存储库的其他更改。请参阅 Git Staging视图中的部分分段 以了解如何执行此操作。
- 添加 - 资源尚未达到存储库中的任何提交,但已被新添加到Git存储库以便将来进行跟踪。
- 已删除 - 资源将从Git存储库中移除。
- 冲突 - 文件存在合并冲突。
- 假定有效 - 资源具有“假定不变”标志。这意味着Git会停止检查工作树文件以进行可能的修改,所以当您更改工作树文件时,您需要手动取消设置该位以告诉Git。另请参阅 假设不变的操作。
提交对话框
提交对话框中显示所有修改的跟踪文件的状态摘要。通过双击文件,要提交的更改将显示在比较对话框中。由于EGit当前总是提交工作树的内容(对应于命令行中的git commit -a),比较对话框将比较工作树和上次提交。
比较内容
在日常工作中,您经常希望看到上次提交,索引和当前工作树之间的更改。为此,请在项目资源管理器或导航器中选择资源(项目,文件夹或文件),然后右键单击“ 比较”下的操作 。
要分析特定提交的内容,应该使用 支持此任务的 历史视图更好,请参阅检查提交任务 。
比较编辑器和Git树比较视图
如果您 在单个文件中使用Compare With的任何子菜单操作, 将显示一个比较编辑器,否则 将打开Git树比较视图以浏览更改; 通过在该视图中双击已更改的文件,将为该文件打开一个比较编辑器。子菜单操作“ 历史记录... ”例外 ,它将打开“历史记录视图”。
将工作树与上次提交进行比较
当前工作目录中的资源和当前分支中上次提交的资源之间的差异可以从上下文菜单Compare With> HEAD revision中查看。此功能也可在提交对话框中找到。在提交对话框中双击一个条目将打开一个比较对话框。
比较工作树和索引
当前工作树和索引(基于当前选定的资源)之间的差异可以从上下文菜单Compare With> Git Index查看。
将工作树与分支,标记或引用进行比较
- 选择一个资源
- 右键单击 Compare With> Branch,Tag或Reference ...
- 选择一个分支,标记或引用
比较工作树和任何提交
从项目浏览器:
- 选择一个资源
- 右键单击 Compare With> Commit ...
- 从提交图中选择一个提交
从历史视图(仅限文件):
- 在包资源管理器中选择一个文件
- 右键单击 Team> History in History 或 Compare With> History ...
- 在提交图中选择一个提交
- 从上下文菜单中选择 与工作树进行比较
- 这将打开一个比较对话框,显示所选提交和当前工作树之间的变化
比较两个承诺
- 在Package Explorer中选择一个资源
- 单击“ 团队”>“在历史记录中显示” 或“ 与历史记录比较...” (后者仅用于文件)
- 在提交图中选择两个提交
- 右键单击“相互 比较”
- 这将打开一个比较对话框,显示两个选定提交之间的变化
- 您也可以通过右键单击树中的“彼此比较”来打开“Git树比较”视图
比较索引与HEAD或任何其他提交
该功能尚未实现。
与分支(同步)比较
工作树(包括未提交的更改)与分支或标记之间的区别可以通过单击项目上的动态菜单 Team> Synchronize 并选择 要同步工作树的 Ref来查看。如果Git存储库包含多个Eclipse项目,则只需选择一个项目即可, 同步视图 也将包含所有其他项目。
如果你想在动态菜单中点击未列出的参考同步 团队>同步>其他...。然后在“同步向导”中单击要同步的存储库的目标列,然后选择要与之比较的Ref。
点击“包括本地未提交的比较变更”也是本地的,尚未分阶段的变更和已经分阶段的变更将显示在比较中。
也可以一次比较多个存储库。在这种情况下,在同步向导中,为每个存储库选择要与之比较的参考。
Quickdiff
不使用比较编辑器,您可以启用快速差异支持并查看文本编辑器中的更改。
此功能可通过常规>编辑器>文本编辑器>快速差异 首选项页面启用 :
然后差异注释将显示在编辑器的左侧:
如果将鼠标移动到注释上,则会看到您正在比较的版本的内容:
默认情况下,比较是针对HEAD的。您可以从历史视图中的提交的上下文菜单(Show in> History)中确定您正在比较的版本,即所谓的quickdiff基准。有三个菜单条目:
- 快速差异 - >将基线重置为HEAD的第一个父级 - 与HEAD之前的第一个提交进行比较。
- 快速差异 - >将基线重置为HEAD - 与HEAD进行比较。
- 快速差异 - >设置为基线 - 与所选提交进行比较
检查提交
检查给定的提交
- 从Package Explorer中的上下文菜单中选择 Team> Show in History
- 选择你想要检查的提交
查看提交的差异
历史视图在左下方的窗格中显示diff。选择右下方窗格中的文件会滚动到diff的相应文件部分。
显示提交的内容
双击右下方窗格中文件的行为取决于比较模式切换按钮的状态。如果它打开,将打开一个比较编辑器,它将当前提交中的文件内容与祖先提交中的内容进行比较; 如果关闭,将会打开一个编辑器,显示当前提交中的文件内容。
提交更改
git版本控制下的项目修改通过提交保存在git历史记录中。从从git存储库检出的状态开始,修改您的项目,直到您达到您满意的状态,然后将所有这些更改作为单个提交提交到存储库中。每次提交都代表存储库中存储的所有文件的定义良好的快照。
修改内容
修改已经与Git共享的项目在Eclipse中或直接在文件系统中修改或删除文件。没有必要提前告诉Git这些操作。应该受版本控制的新文件必须明确置于Git版本控制之下:
- 在文件的上下文菜单中单击 Team> Add
或者,您可以在提交对话框中显示未跟踪的文件,并选中 显示未跟踪文件 复选框以选择它们以包含在提交中。
标签装饰器例如在Package Explorer View中显示
- 尚未在git版本控制下的未跟踪文件(标有“?”)
- 已添加的文件(标有“+”)
- 修改过的文件(在文件名前用“>”标记)
有关详情,请参阅 标签装饰。
以下是包资源管理器中的一个示例
- 一个承诺的文件
- 在工作树中修改但尚未为下一次提交分配的文件
- 一个修改过的文件,已经为下一次提交进行了修改
- 一个已经新下载的文件,用于下一次提交
- 一个不在git版本控制下的文件
提交
要提交更改,请单击 项目中资源的上下文菜单中的Team> Commit ...。
Git跟踪对整个存储库进行的所有更改,以捕获该存储库中所有版本控制文件的修改,而不考虑这些文件是否驻留在同一个Eclipse项目中。
一旦你触发了提交, 提交对话框 就会弹出
选择要提交的更改,输入提交消息并创建提交, 在提交消息文本字段中按 Ctrl + Enter (Mac OS X上的Command + Enter),或单击 提交。
提交消息
在“提交”对话框中,指定描述更改的提交消息。
用短的第一行开始消息是一个好习惯,总结变化,然后是空白行,然后是消息正文。为了确保git命令行工具可以很好地格式化这些消息,行不应格式化得太宽(用灰色垂直线表示)。
Eclipse拼写检查器检查提交消息文本是否有错误。拼写检查器可以通过Eclipse Preferences> General> Editors> Text Editors> Spelling进行配置。按 Ctrl + 1 打开快速修复,这可能有助于修复拼写错误。
提交消息编辑器支持提交对话框的文件部分中显示的文件名的内容帮助,可以按Ctrl-Space**该文件部分。
页脚标签
在提交消息的最后一段中,可选的页脚标签可以如下所示:
错误:3176 更改ID:I267b97ecccb5251cec54cec90207e075ab50503e 报道者:Joe Developer <[email protected]> 签名:William Shakespeare <[email protected]>
这些标签的语义是项目或工具特定的
- 如果在错误跟踪系统中有条目要求提交更改,则最好在此将其添加为错误标记
- Gerrit Code Review 使用 Change-Id: footer将审核过程中发生变化的不同补丁集与最终接受的补丁相关联。要生成Gerrit Change-Id,请点击 Gerrit Code Review的Compute Change-Id ; 该ID将在提交时生成,直到此时空的Change-Id显示为占位符。如果将egit配置参数 gerrit.createchangeid 设置为true,则始终预先选择“提交”对话框中的相应复选框。此参数可以在存储库级别,系统级别或用户级别上进行设置。有关 更多信息,请参阅存储库配置。
- 在 参团的off-by: 页脚被许多项目来创建签名笔者贡献下,该项目的许可和知识产权规则的改变声明的正式记录。通过这种方式,可以在技术层面捕获项目不断发展的代码库的知识产权出处。请参阅 Linux内核项目使用的 开发人员证书源代码。如果偏好例如:It 插入签名断,通过 在 团队>的Git>提交对话框 设置相应的复选框在提交对话框总是会预先选定。
此外,此对话框控制将在提交中包含哪些更改。如果清除文件前面的复选框,则对该文件的更改将不会包含在提交中。您的eclipse工作区中的本地文件仍将包含修改,使您有机会使用后续提交来提交这些更改。此功能通常用于将对一组文件所做的修改分离为不同的提交。
一个例子: 想象一下,自从上次提交以来,您已经修复了A.java中的一个错误,并且您已经为B.java添加了一个新方法。这两个修改在逻辑上相互独立,因此您可能希望在两个独立的提交中提交它们。在这种情况下,您启动提交,从提交的文件集中取消选择B.java,并指定仅描述A.java中的错误修正的提交消息。在成功完成第一次提交后,您只需再次调用commit,即将出现的对话框将向您展示B.java中的其余更改。现在您指定一个提交消息来描述添加方法并完成第二次提交。
如果选中“显示未跟踪文件”复选框,则在提交对话框中将列出添加到项目中尚未明确添加到版本控制中的新文件(请参阅“修改内容”)。如果您选中列表中这些文件前面的复选框,则会将其添加到存储库并在您按下提交按钮后进行提交。团队忽略列表或 .gitignore 文件或衍生的文件(例如,java项目中的bin文件夹)将不会显示在此处。如果您的存储库中没有其他更改比未跟踪文件更多 ,默认情况下会选中Show untracks Files复选框 。
修改提交
如果您在提交更改时意识到错过了某些内容,则可以解决此问题:再次打开提交对话框并指定当前提交将“修改”当前分支中的上一个提交。新的提交将会取代之前的提交。此功能通常用于在发布到其他存储库之前纠正不正确的提交。
注意: 如果它们已经发布到共享存储库,则不要修改提交,因为如果它们已经根据已发布的更改进行了修改,则可能会打扰其他提交。
修改示例:
想象一下,您对包含错字的文件进行了更改
提交更改后,您会发现一个错字。为了纠正这个错字和相应的提交,您只需修复源文件中的错字
然后再次打开提交对话框并选择选项 修改上一个提交。
您之前提交(您想要替换的提交)的提交消息被填充到“提交消息”字段中。这不仅可以更正版本控制文件内容中的错误,还可以更正描述更改的提交消息中的错误(例如,拼写错误)。
作为修改的替代方法,您可以将更正后的版本作为后续提交提交。但是第一个包含错字的提交对任何人都没有用,为了不用不必要的提交来混淆项目的历史,你应该修改提交。
请注意,修改已发布到其他存储库的提交可能会造成麻烦。一旦将提交推送到远程存储库或您的本地存储库被其他人克隆,您应该非常小心地修改提交。在这种情况下,发布更正第一个提交的第二个提交可能是更好的解决方案。否则,通知所有其他人您已修改已发布的提交,以便他们能够做出相应的反应
恢复更改
恢复工作树中的更改
在Git索引中替换为文件
尚未提交和尚未分阶段的更改可以恢复为一组选定的文件。在包资源管理器或类似视图中选择文件,然后在Git索引中单击 替换为>文件。
替换为HEAD
此功能目前在单个文件级别上不可用。您可以使用 Reset to with hard 来强制重置存储库的整个工作树回到HEAD提交状态(请参阅下面的“重置当前的HEAD”)。该操作将恢复工作树和索引中的所有更改。您无法使用EGit在选定的一组文件上执行此操作。
替换为以前的版本
已经执行或甚至提交的更改可以通过将它们替换为之前提交的版本来“恢复”。在Package Explorer或类似视图中选择一个资源,然后单击 Replace With> Previous Revision。存储库将确定最后一次提交,该提交修改了所选资源,并提供用此提交的内容替换工作区资源。
这主要是为了从提交中“删除”单个文件(当提交已恢复的工作空间资源时,它们被有效地从当前提交中移除)。即使这也适用于文件夹和项目,用“之前的修订”替换文件夹或项目的结果可能是意外的。
使用quickdiff恢复
quickdiff功能可用于恢复对文件的单个更改。您可以按行,块(se范围更改行)或选择进行恢复。选择所有文本,然后 选择还原选择 以还原整个文件。
恢复由特定提交引入的更改
由给定提交引入的更改可以通过在当前检出的提交之上自动创建的新提交来恢复。要恢复的提交不必为此检出。
在历史视图中选择提交,打开上下文菜单并选择 恢复提交。这通过在当前签出的提交之上创建新的提交来还原所选提交引入的更改。
重置当前的HEAD
Git提供了将当前分支的HEAD重置为任何其他提交的可能性。它可以选择重置索引和工作树以匹配该提交。请注意,此操作会影响整个存储库中的所有文件和文件夹。
您可以选择进行硬重置,混合重置和软重置。
- 软 - HEAD现在指向新提交,索引和工作树不变
- 混合 - HEAD现在指向新的提交,索引被更新,工作树不变
- 很难 - HEAD现在指向新的提交,索引和工作树被更新
重置为特定分支或标签
在项目上选择 Team - > Reset ...。这将打开一个对话框,您可以在其中选择分支或标签。
重置为特定的提交
在历史视图中选择一个提交并打开上下文菜单。在这里您可以找到条目 硬重置, 混合重置 和 软重置。
恢复所有本地和分阶段的更改
这可以作为重置的特殊情况来完成。如果您重置为当前HEAD(通常是最后一次提交您的分支)的选项 硬 您覆盖工作树,并与头部的内容索引。你可以通过三种方式做到这一点:
- 在项目上选择 团队>重置...。在该对话框中选择HEAD或当前分支并切换的单选按钮 硬。
- 右键单击并 在存储库视图中的任意分支或标签上选择 重置...。这会打开一个对话框,让您决定重置类型。选择难 在这里。
- 打开历史视图HEAD提交中的上下文菜单,然后选择 硬重置。
分枝
关于分支机构的一般评论
在不使用本地分支的情况下提交对本地存储库的更改是不切实际的(参见上面的概念部分)。此外,通过使用几个不同的分支,可以通过在这些分支之间进行切换来并行处理不同的更改。
因此,在开始更改本地存储库之前,第一步通常是创建一个本地分支。本地分支机构“基于”提交或远程跟踪分支。
在使用远程存储库时,推荐使用第二个选项,因为它通过向新的本地分支添加所谓的“上游配置”来简化将本地更改与远程更改同步的任务。
请参阅 分支创建对话框 了解更多详情
上游配置
每个基于本地跟踪分支的本地分支都可以有一些额外的配置,指示远程存储库,远程分支和所谓的拉动策略。请参阅 分支创建对话框 了解更多详情
通常,根据远程跟踪分支创建本地分支时,会自动创建此配置。但是,可以在存储库配置中显示和编辑它,也可以 单击 “存储库视图”中某个分支上的“ 显示”>“属性 ”。
检出现有分支
从项目节点上的团队菜单中:
- 选择 团队>切换到... 并从列表中选择一个分支名称
如果分支太多,则列表中不会显示所有分支。在这种情况下
- 选择 团队>切换到...>其他...
- 在对话框中,选择一个分支,一个标签或一个参考
- 点击 确定
从Git存储库视图
- 在分支节点上选择 Checkout
要么
- 双击分支节点
从历史视图
- 在具有分支标签的提交上选择 签出
- 如果多个分支指向提交对话框,将允许您决定检出哪个分支。
创建新的本地分支
这总是通过“ 分支创建”对话框完成。新创建的分支可以通过选择对话框上的复选框来检出。
从团队菜单中
- 选择 团队>切换到...>新科...。
- 在对话框中,选择分支,标签或参考。
- 点击 创建分公司...。
- 该 科创建对话框 将被打开。
从存储库视图
- 在“分支”节点或任何“分支”,“标记”或“参考”节点上选择 创建分支...。
- 该 科创建对话框 将被打开。
从历史视图
- 选择 创建分支...
- 该 科创建对话框 将被打开
重命名现有分支
从项目节点的团队菜单中
- 选择 团队>高级>重命名分支...
- 在分支选择对话框中,选择要重命名的分支
- 输入新的分支名称,然后单击 确定
从存储库视图
- 打开Git存储库视图
- 选择 重命名分支... 或在您要重命名的分支上按F2
- 输入新的分支名称,然后单击 确定
从历史视图
- 使用分支标签提交时选择 重命名分支...
- 输入新的分行名称并点击 确定
删除分支
以下所有操作都表现出与以下相同的行为:
- 当前签出的分支不能被删除
-
如果删除分支可能导致数据丢失,则会显示必须确认的警告
- 如果分支指向从当前检出的提交无法访问的提交,EGit会承担潜在的数据丢失
从项目节点上的团队菜单
- 选择 团队>高级>删除分支...
- 从正显示的对话框中选择要删除的分支,然后按 确定
从存储库视图
- 打开Git存储库视图
- 在要删除的分支上选择 删除分支
从历史视图
- 使用分支标签提交时选择 删除分支
- 如果多个分支指向提交,将显示一个选择对话框,您可以在其中选择要删除的分支
分支创建对话框
有几种可用于创建本地分支的操作。所有这些操作都使用分支创建对话框:
上半部分的组合允许选择分支或提交新的分支应基于。通常,这是一个远程跟踪分支,但它可以是存储库中的任何分支或提交(不推荐选择本地分支)。
只有在组合中选择了一个分支并允许覆盖“上游配置”的默认设置时,“拉动策略”组才可见,这在提取和推送时很有帮助,特别是在拉取时。根据所选选项,可以选择以下配置:
- Rebase:拉动时,将从上游获取新的更改,并且远程跟踪分支将被更新。然后,当前的本地分支将重新贴装到更新的远程跟踪分支上
- 合并:拉动时,将从上游获取更改,远程跟踪分支将更新。然后,当前的本地分支将与新的更改合并。如果新分支基于远程跟踪分支,则这是默认设置(但此默认设置可能会被特定存储库配置覆盖)
- 无:拉动时,新的分支将不会执行特定的上游配置; 但是,如果存在默认远程设备(名称为“origin”的远程设备,则pull将尝试使用此远程设备的配置;如果新分支不是基于远程跟踪分支,则这是默认设置
您可以查看和编辑存储库配置中的上游配置, 或通过 在存储库视图中的分支上选择 Show In> Properties。
EGit还支持git配置参数 branch.autosetuprebase
,always
如果您想默认使用rebase pull策略,则将其设置为 。如果您在存储库配置中设置了此选项,则用于根据此存储库中的远程跟踪分支创建的所有本地分支,如果将其设置为用户配置,则将用于所有存储库。
在下面,您可以决定是否立即检查新分支。
合并
合并包含从命名提交(从他们的历史与当前分支分离的时间)到当前分支的更改。
将分支或标签合并到当前分支中
你有两个地方可以触发合并:
- 从团队菜单
- 从Git存储库视图
从团队菜单开始合并
在包资源管理器或导航器中,打开项目节点上的上下文菜单。选择 团队>合并...
现在合并对话框打开:
在对话框中,选择要与当前分支合并的分支或标签。
从Git存储库视图开始合并
如果您已签出本地分支,则可以从任何分支和标记节点以及从存储库节点触发合并。有关 更多详细信息,请参阅 合并分支或标记。
可能的合并结果
按下“合并”按钮后,可能会出现以下情况:
- 已经是最新的:你当前的分支指向一个具有选定分支或标签作为前任的提交。在这种情况下,没有什么改变。
- 快进:您当前的分支指向作为所选分支或标记的前任的提交。在这种情况下,您的分支会移动并指向选定的分支或标签; 这个新的HEAD被检出到工作树上。使用远程存储库时,快进是非常常见的:当远程跟踪分支更新时,与相应分支的合并通常是快进。您可以通过获取远程分支(例如起源/主控)并将其合并到相应的本地分支(例如主控)来执行拉动操作。
- 真正的合并:当以上条件都不适用时,触发合并提交。有两种可能的结果:如果不发生冲突,当前分支将指向新创建的合并提交; 如果发生冲突,冲突文件将标记为标签修饰符(请参阅解决合并冲突 以防合并冲突时的进一步操作)。
合并结果对话框
对话框中汇总了合并的结果:
在第一行你会看到合并的结果。可能的结果是“已更新”,“快进”,“合并”,“冲突”或“失败”。“失败”的可能原因可能是工作目录中存在冲突的更改。
在第二行中,如果成功合并(已完成最新,快进或合并),您将看到新的HEAD提交。
在表格中您可以看到合并的提交。
解决合并冲突
合并可能导致需要用户操作的冲突。当文件的内容不能自动合并时就是这种情况。这些冲突在导航树中标有标签修饰。文件内容中的合并冲突会显示文本冲突标记( 有关更多详细信息,请参阅http://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_how_conflicts_are_present)。
使用合并工具
- 选择显示红色冲突标签修饰器的*资源
- 单击 团队>合并工具
- 选择合并模式 使用冲突文件的HEAD(最新本地版本), 然后单击 确定
- 合并编辑器打开,显示左侧窗格中的工作树版本以及右侧窗格中要合并的版本
- 编辑工作树版本,直到你满意为止
- 团队>添加 合并资源以将冲突标记为已解决
- 通过Team> Commit提交合并 提交
手动冲突解决
要解决冲突,您必须执行以下步骤:
- 导航到冲突的资源
- 编辑冲突资源的内容
- 通过Team> Add告诉EGit冲突已解决
- 通过Team> Commit提交冲突解决方案
查找冲突的文件
包含冲突文件的存储库具有附加到存储库名称的文本标签装饰器“|冲突”。包含这些冲突资源的资源和文件夹冲突会得到冲突标签装饰。
编辑冲突的文件
在文件内容中,发生一对冲突变化的区域用标记<<<<<<<,=======和>>>>>>>标记。=======之前的部分通常是你的一面,而之后的部分通常是他们的一面(见 http://www.kernel.org/pub/software/scm/git/docs/git-merge。 html#_how_conflicts_are_presented 了解更多详情)。
在编辑器中打开文件,编辑内容并保存编辑器。
请注意,这一步不是强制性的。EGit不会检查内容以决定冲突是否已解决。下一步是相关的一步。
将冲突解决添加到git索引
编辑文件完成后,选择 Team> Add 将冲突解决添加到git索引。您可以在文件夹或整个项目上执行以一次解决所有冲突。
解决所有冲突后,文本存储库标签装饰将更改为“已合并”。没有冲突标记了。
提交合并
当存储库处于“合并”状态时(如使用文本标签修饰符“|冲突”附加到存储库名称所示),最终可以合并合并。
在导航树的任意位置选择“ 团队”>“提交...”。提交对话框以与正常提交相比稍微不同的外观打开:
- 提交消息区域预填充了标准合并提交消息。
- 不可能修改以前的提交。
- 无法添加未跟踪的文件。
- 不可能取消选中复选框。这保证所有已解决的冲突均已落实。
按下“提交”按钮后,合并完成。
中止合并
如果合并导致冲突,您可以通过对当前分支进行硬重置来中止合并。这可以在“冲突”状态和“合并”状态下完成,即在解决冲突之前和之后。
硬重置可以从团队菜单,Git存储库视图或历史视图中完成。请参阅 恢复所有本地和分阶段更改 以获取更多详细信息。
垫底
Rebase简介
Rebase将一组提交应用于给定的提交。一个典型的场景是在某个时间点从“主”分支创建的“主题”分支上开发某些功能。当“主”更新时,例如来自其他开发者的变更,而“主题”仍在开发中时,可能有必要将这些更改合并到“主题”中。
让我们假设我们通过从master创建“主题”分支来开始“主题”开发。此时,“主”和“主题”都指向提交“E”。当第一次提交(“A”)被添加到“主题”时,资源库的提交历史记录如下所示:
一个话题 / D --- E主
现在,我们假设在“主题”上有更多的提交,并且还有一些对“主”的提交(例如,“master”可能会跟踪某个远程存储库,并且该远程存储库中的一些更改已经被引入“主”):
A --- B --- C话题 / D --- E --- F --- G主
现在,为了将“主”的变化结合到“主题”中,“主”的“主题”的再版将产生
A' - B' - C'主题 / D --- E --- F --- G主
从技术上讲,“主题”中包含但不包含在“主”中的提交顺序在“主”之上逐一应用(即,挑选)。
请注意,提交A,B,C既不会丢失也不会发生更改,而是会创建与原始提交(但不同的提交ID)相同的更改和提交消息的新提交链A',B',C'。旧提交A,B,C仍在对象数据库中,但不再可见,因为它们不再可从任何分支中访问。A',B',C'与旧的不同,因为它们现在也包含变化F和G.
重建,一个简单的例子
让我们来看一个简单的例子:我们有一个文本文件“FamousWords.txt”,它最初可能有一些内容
第1章 很久以前... 第2章 生存还是毁灭
现在,在“主题”中,创建了两个提交,第一个将法语翻译添加到第2章,另一个添加德语翻译:
在“主题”中首次更改后:
第1章 很久以前... 第2章 生存还是毁灭 是或不是
在“主题”中进行第二次更改后:
第1章 很久以前... 第2章 生存还是毁灭 是或不是 是或不是
同时,通过在第1章中添加两个提交法文和德文翻译的“主文件”更改了该文件:
第1章 很久以前... 曾几何时 曾几何时 第2章 生存还是毁灭
提交历史记录如下所示:
现在,如果将“主题”重新设置为“主”,则主题中的两个更改按照与“主题”演变过程中应用的顺序相同的顺序应用。
结果是“FamousWords.txt”的合并版本:
第1章 很久以前... 曾几何时 曾几何时 第2章 生存还是毁灭 是或不是 是或不是
以及在当前“主”之上提交“主题”提交历史的提交历史记录:
现实世界:重建冲突
到目前为止,我们假设“主题”中的更改可以自动合并到“主”中。然而,在现实世界中,可能会发生在重新绑定期间遇到冲突。现在,如果挑选的提交中包含与“主”更改相冲突的更改,则在应用冲突更改后,重置操作会中断; 以通常的方式(冲突标记)将冲突可视化,并且用户有机会决定是否要
- 手动解决这些冲突,
- 跳过当前的提交,或者
- 完全放弃rebase
如果 选择了“ 解决冲突”,并且冲突已经手动解决,那么更改必须是“已添加”,然后可以重新进行重新分配,即将应用链中的下一个提交。
如果 选择跳过,冲突的更改将被还原,链中的下一个提交将被应用。
如果 选择Abort,rebase操作将完全回滚,在rebase开始之前将Repository恢复到原始状态。重复此过程直到最后一次提交成功或跳过应用。最后,“主题”分支将更改为指向最后的提交。
为了更好地理解“跳过”,让我们回顾上面的介绍。如果我们假设提交“B”导致与当前“主”的冲突,用户可能会决定跳过“B”; rebase之后的新提交历史将如下所示:
'C'主题 / D --- E --- F --- G主
启动Rebase
Rebase在Git存储库视图中可用。在Repository节点上, Rebase ... 打开一个对话框,要求用户选择未检出的分支; 当前签出的分支将被重新分配到所选分支上。在“分支”节点(包括本地和远程跟踪分支,但不在当前签出的分支上), 重置 立即将当前签出的分支重新绑定到所选分支上:
重新确认对话框
如果Rebase成功,将显示一个确认对话框; 这个对话框可以通过勾选一个复选框来抑制; Git首选项页面上的首选项允许再次出现对话框。如果该对话框被禁止,则会将“信息”消息写入Eclipse日志中。
冲突冲突
如果在重新绑定期间发生冲突,将显示一个对话框,提供有关导致冲突的提交的一些信息。通过选择一个单选按钮,您可以决定是否
- 启动合并工具以手动解决冲突
- 跳过当前提交
- 完全放弃rebase
- 什么都不做(返回工作台),这相当于击中了“Escape”:
除非在对话框中选择“跳过”或“中止”,否则必须通过编辑冲突文件手动解决冲突。编辑完成后,文件必须声明为通过将它们“添加”到索引来解析。
在所有冲突解决后,Rebase可以通过右键单击Git存储库视图中的Repository节点并选择Rebase> Continue来恢复。
通过右键单击Repository节点并分别选择Rebase> Skip and Rebase> Abort,可从Git存储库视图中获得“跳过”和“中止”选项。
合并工具也可以从团队菜单中的相应条目开始。
中止Rebase
只要存储库处于“重新启动”状态,用户就可以使用Repository节点上可用的菜单操作“Rebase> Abort”在Git存储库视图中始终放弃重新绑定。
再利用限制
目前的EGit rebase实现还不能处理所有可能的版本图。如果图表过于复杂,rebase将会以错误消息中止。作为一种解决方法,直到EGit的rebase支持这些更复杂的图表,您可以改用命令行中的native git。
采摘樱桃
樱桃挑选介绍
分支stable-1.0上 的给定提交 C 包含一组您希望集成到当前分支主机开发中的更改 。
A - B - C - D稳定 - 1.0 / D --- E --- F --- G主头
Cherry选择提交 C在当前签出的分支主机的头提交之上 创建新的提交 C' 。 C” 然后将包含在执行的更改 Ç 施加到当前签出分支的HEAD 主。
A - B - C - D稳定 - 1.0 / D --- E --- F --- G-C'master HEAD
樱桃挑选示例
您目前正在分支“feature2”(HEAD)上工作。在另一个分支中有一个提交“功能1”。
您希望将提交“功能1”执行的更改集成到当前分支“功能2”的开发中。
- 在历史视图中选择提交“功能1”并单击 Cherry-pick:
- 因此,您在当前分支“功能”的顶部获得了一个新的提交“功能1”,其中包含“功能1”的更改:
- 樱桃采摘可能会遇到冲突。在这种情况下,冲突标记将呈现到受影响的源中:
标记
创建一个标签
- 从项目上下文菜单中选择 Team> Advanced> Tag ...。
- 输入标签名称
- 输入标签消息
- 可以选择你想要标记的提交(默认是HEAD)
- 单击 确定 以创建注释标签
也可以在历史记录视图中创建标签:选择提交并 在上下文菜单中执行 创建标签...。该标签将在选定的提交上创建:
替换现有标签
如果您标记了错误的提交或最终出现了某种错误,该怎么办?
- 如果你还没有推出这个只需更换标签,你就完成了。
- 如果它已经发布,你不应该替换标签, 而是使用一个新名称,否则你必须告诉每个获得旧标签的人用你的新标签手动替换它。这是因为,Git没有(也不应该)改变用户背后的标签。所以如果有人已经拿到了旧标签,那么在树上做一个git pull不应该让它们覆盖旧标签。
因此,如果您的旧标签尚未推送,您可以通过以下方式进行更正:
- 从项目上下文菜单中选择 Team> Tag ...。
- 从现有标签列表中选择要替换的标签
- 或者开始在“标签名称”字段中输入要查找的标签的任何部分,这会将现有标签的列表过滤到包含您正在输入的字符串的那些标签,然后选择要替换的标签
- 标记复选框 强制替换现有标记
- 更改标签并按 确定
删除标签
为了删除标签,选择要删除的标签并点击 删除标签。
注意: 删除已在公共服务器上发布的标签是一种不好的做法,一些Git服务器甚至不允许删除标签以确保通常标记的发布的可追溯性。另请参阅 标记命令的Git参考文档中的“重新标记”部分。
轻量级和签名标签
轻量级标签显示在“存储库视图”和“创建标签”对话框中,但无法编辑。标签在存储库视图中显示为蓝色图标,注释标签用黄色人物装饰。
在历史视图中,标签显示为黄色标签。
EGit还不支持签名标签,而是使用命令行 git标签 或 git标签-s 。
补丁
创建修补程序
“补丁是一种旨在解决问题或更新计算机程序或其支持数据的软件”(wikipedia)。补丁文件包含一组可以自动应用到另一个eclipse工作区或git存储库的资源更改的描述。
eclipse(Team> Apply Patch)和git(git apply 或 git am 在命令行上)使用的补丁格式不同。在EGit中可以创建两种类型的补丁。
从提交创建一个补丁
这是分布式版本控制系统最常见的用例。开发人员对本地功能或错误修复分支提交更改,并希望将此更改导出到修补程序文件中。
它可以从历史视图完成:
补丁文件将包含历史视图中提交与其父代之间的区别。请注意,历史视图的过滤器也适用于修补程序创建。
补丁向导
向导由两页组成。第一页可以让你选择补丁的位置:
补丁文件的名称是从提交消息的第一行创建的。
在第二页上,您可以更改补丁格式。
目前有一个复选框: 以git补丁格式导出。
- 如果你没有检查它(这是默认设置),可以使用eclipse Apply Patch ... 向导来应用这个 补丁。路径与eclipse项目相关,不包含前缀(比如 git命令行上的git format-patch --no-prefix)。
- 如果你检查它,补丁将看起来像 git命令行上的git format-patch --no-stat的结果 。
目前没有生成二进制差异。
应用修补程序
目前EGit无法以git格式应用补丁。使用Team> Apply Patch ...可以使用标准Eclipse(统一差异)格式 应用修补程序。Git补丁可能包含用于重命名和二进制比较的非标准扩展。EGit的当前版本不会生成这些扩展名。
管理存储库
“Git存储库视图”是便于同时处理多个存储库(即在一个Eclipse工作区内)的主要UI元素。
此视图可以使用菜单路径Windows> Show View> Other ...> Git> Git Repositories打开
它也是“Git Repository Exploring”透视图的一部分,使用菜单路径
Window> Open Perspective> Other ...> Git Repository Exploring
如果您的工作空间中已有与Git存储库共享的项目,则可以使用
团队>在存储库视图中显示
在任何资源上打开视图。
将存储库添加到Git存储库视图
最初,Git存储库视图是空的。为了向其添加存储库,有以下几种选择:
- 手动从本地文件系统添加存储库
- 克隆存储库并将克隆的存储库自动添加到视图中
- 在本地文件系统上创建存储库
- 通过将Git存储库路径粘贴到视图来添加存储库
手动添加存储库
您可以将本地文件系统中的存储库添加到Git存储库视图中,而不用克隆它。如果您正在设置新的Eclipse工作区并希望重新使用您的Git存储库,这会很有帮助。使用 视图工具栏中的 添加现有的Git存储库按钮:
将出现一个对话框,提示您输入本地文件系统的目录。选择正确的目录后,您可以点击 搜索 按钮来查看该目录中的Git存储库列表。然后,您可以选择一些或全部找到的存储库,并使用OK将其添加到视图中 :
克隆存储库
为了克隆存储库,请参阅 克隆远程存储库。克隆操作成功后,新克隆的存储库应自动出现在Git存储库视图中。
您也可以使用 视图工具栏中的 克隆Git存储库按钮来启动克隆向导:
请参阅 克隆远程存储库 关于如何使用向导。
创建一个存储库
您可以在本地文件系统上创建一个新的空存储库。如果稍后想要在此存储库下创建一个或多个新项目,这很有用。另一个用例是创建一个新的裸仓库,您可以在其中推送。使用 视图工具栏中的 创建新的Git存储库按钮:
会出现一个对话框让您选择一个目录:
如果您选中创建为Bare Repository复选框 , 则新存储库将不会有工作目录。然后您只能通过推送来自另一个存储库的更改来添加内容。
使用复制和粘贴添加存储库
作为快捷方式,也可以将Git存储库的本地文件系统路径从剪贴板粘贴到此视图中。为此,请将Git存储库的路径(其.git
文件夹的完整路径 )复制到剪贴板,然后在视图面板上打开上下文菜单:
或者 从主菜单(或相应的键盘快捷键)单击 编辑>粘贴。如果剪贴板内容不合适,将显示错误弹出窗口,否则添加的存储库应自动出现。
在视图填充了一些存储库后,它应该如下所示:
删除存储库
从存储库视图中删除存储库
为了从存储库视图中删除存储库,选择一个存储库并单击“删除存储库”
删除存储库
为了删除存储库,请在存储库视图中选择它并单击“删除存储库”。
然后确认您要删除存储库
并决定是否要从Eclipse工作区删除存储库中包含的项目。
Git存储库视图的结构
以下屏幕截图显示了Git存储库视图的最上面两个级别:
根节点表示存储库本身。节点文本指示存储库的名称及其在本地文件系统中的位置。“分支”和“标签”节点允许浏览和操作标签和分支。“References”节点列出了其他不是分支或标签的引用,最显着的是“HEAD”和“FETCH_HEAD”符号引用(请参阅 Git引用)。
“工作目录”节点显示本地文件系统上工作目录的位置和结构(仅在开发情况下为裸露存储库,或者非裸露存储库,此节点始终为叶)。
最后,“远程”节点允许浏览和操作用于提取和推送的远程配置。
Git存储库视图的功能
项目导入
为了使用Git Repository的内容,它的文件和文件夹必须以项目的形式导入Eclipse工作区。虽然Git Clone向导允许在克隆后直接执行此类导入,但Git存储库视图允许独立于克隆操作触发项目导入。
“存储库”节点以及“工作目录”节点和“工作目录”节点本身内的任何“文件夹”节点上均提供“导入项目...”上下文菜单:
在几个节点上提供Import Projects ...操作的基本原理 是,用于导入项目的一些向导可以考虑文件系统目录,例如 Import Existing Projects 向导。如果从“存储库”或“工作目录”节点开始导入,则将存储库的工作目录设置为上下文,否则将设置与当前选定的“文件夹”节点相对应的目录。
有关项目导入的详细信息, 请参阅使用新项目向导。
分支和标签支持
“分支”节点允许创建,浏览,结账和删除本地和远程分支机构。“标签”节点允许浏览和签出标签。“分支”节点和“标签”节点都允许将分支或标签合并到当前签出的分支中,并且还与当前签出的分支同步。
为了更好的可读性,分支分别组织在本地和远程分支的两个子节点中,并且只显示缩写名称,例如,代替 “refs / heads / master”, 您会 在“本地”下找到条目 “主” 在“远程分支”节点下显示“分支”节点,而不是“参考/远程/源/主” 缩写名称 “起源/主站”。同样,通过省略“refs / tags /” 前缀缩短标签名称 :
检查分支和标签
可以通过双击各个节点或选择相应的上下文菜单条目检出分支和标签。
分支的创建和删除
可以使用分支创建对话框创建本地分支 。通过右键单击任何“分支”和“标记”节点上的“分支”,“本地分支”来打开该向导。
分支删除使用相应的上下文菜单条目完成。
垫底
您可以通过右键单击触发当前签出分支的垫底到另一个分支 再次基于 任何(本地或远程跟踪)分支节点上。
合并分支或标签
如果您已签出本地分支,则可以从任何分支和标记节点以及从存储库节点触发合并。有关合并 功能的更多详细信息,请参阅 合并。
- 当您选择除当前检出分支或任何标签节点以外的任何分支节点时,使用 合并 直接触发合并到当前检出分支。
- 当您选择存储库节点或当前检出的分支时,使用 合并... 打开合并对话框。在将分支或标签合并到当前分支中描述了合并对话框。
与分支或标签同步
您可以将HEAD中的更改与任何其他分支或标签中所做的更改进行比较。右键单击并选择 同步...在任何分支或标记上。然后打开eclipse同步视图,其中包含HEAD中包含的更改的表示,但不包含在另一个分支或标记(传出更改)中,反之亦然(传入更改)。有关更多详细信息,请参阅同步功能的文档。
确定检出分支
有两种方法可以确定当前检出哪个分支或标签:检出的分支/标签节点装饰有一个小勾号,“符号参考”节点下的“HEAD”条目显示退房分行:
重置为分支或标签
右键单击并 在任何分支或标签上选择 重置...。这会打开一个对话框,让您决定重置类型。有关 更多详细信息,请参阅 重置您当前的HEAD。
“分离”头部
如果HEAD是“分离的”,即不是指向本地分支的尖端,而是指向提交或标记,则树中可能没有或几个“签出”标记,因为任何数目的远程分支或标记可能指向当前签出的提交。当你的HEAD被分离时你所处的状态不会被任何分支记录(这是很自然的 - 你不在任何分支上)。
检查参考文献
“引用”节点显示除分支和标记以外的一些引用(该列表是动态的,取决于存储库的当前状态):
如果引用是符号的,即指向另一个引用,则显示目标引用的名称,后跟引用的目标的对象ID。如果引用不是符号,则只显示对象ID。
在上面的例子中,HEAD是指向分支“refs / heads / master”的符号引用(即分支“master”被检出),而FETCH_HEAD直接指向提交226a7f ...。
右键单击Reference: Checkout (除非Reference已经签出)并 创建分支' ...',可以执行以下操作。
浏览工作目录
“工作目录”节点可视化Git存储库的本地文件系统结构。也可以在文件上打开文本编辑器:
或者,可以通过将文件从工作目录拖到编辑区域来打开文件。
另外,在所有文件和文件夹节点以及“存储库”节点上,都提供了一个用于将(文件系统特定)路径复制到剪贴板的选项。这在需要路径时有时很有用,例如,使用文件浏览器打开目录或在视图实例之间复制和粘贴存储库(请参阅上述关于如何将存储库添加到视图中)。“ 复制到剪贴板” 操作也可以使用 编辑>复制 (或相应的键盘快捷键)。
存储库配置
与Eclipse中的通用“属性”视图集成允许查看和编辑Git配置(全局和特定于存储库的配置)。如果“属性”视图处于打开状态,则在选择“存储库”节点时会自动更新。使用下拉框(屏幕截图中的左侧红色框),您可以在存储库配置的显示,全局配置和聚合两者的视图之间切换。如果视图显示存储库配置或全局配置,则可以使用编辑 按钮(屏幕截图中的右侧红色框)打开编辑器对话框 。编辑器对话框具有与首选项页面Team> Git> Configuration相同的功能 。
在Git Repositories视图中, 上下文菜单中有一个 Properties操作,该操作将打开一个允许编辑Repository Configuration的配置对话框。在这里,可以添加,更改或删除键值对。在 打开 按钮可以在文本编辑器打开库配置文件。
远程存储库
“远程”节点允许浏览和编辑远程配置。每个远程配置都有一个名称和一个推送规范,一个提取规范或两者。如果选择“远程配置”节点或其任何子节点,则 属性 视图将显示远程配置的摘要。在这个例子中:有一个名为“origin”的远程配置,它只有一个提取规范,但没有推规范:
菜单操作用于添加,配置和删除远程配置以及提取和推送规范。
直接读取和推送支持
可以在远程节点以及相应的“提取”和“推送”节点上直接执行提取和推送(即无需向导):
请注意,取或推操作将立即在异步作业中执行; 完成后,您将看到一个确认弹出窗口,显示获取结果。
“Fetch”节点包含所谓的提取规范,“Push”节点包含所谓的推式规范。
克隆存储库时创建默认的提取规范。您可以使用菜单项Configure Fetch ...编辑提取规范 。这将打开一个向导。在第一页上,您可以编辑提取URI。Ob第二页,您可以确定提取参数规格,请参阅 提取参考规格。
您可以使用菜单项“ 配置推送...”创建或编辑推送规范 。这将打开一个向导。在第一页上,您可以编辑推送URI。如果指定了提取,则提取URI将自动包含在推送规范中,并且不需要其他推式URI。在第二页上,您可以确定推送参数规格,请参阅 推送参考规格。
添加远程配置
这是使用“远程”节点上的上下文菜单操作完成的。启动向导询问新配置的名称以及是否配置Fetch,Push或两者:
如果选择 配置提取 复选框,则下一个向导页面将要求从以下位置获取存储库的URI:
点击 更改... 打开一个对话框,允许您选择一个URI。下一步是为获取URI定义远程规范。有关详情,请参阅 提取参考规格 。
如果选择 配置推送 复选框,则下一个向导页面将要求存储库的URI推送到。这实际上是一个列表,因为您可以一次推送到多个存储库。单击 添加.... 使用与上面相同的对话框将URI添加到列表中。您可以在列表中标记他们,打删除的URI 删除。如果已经定义了一个提取URI,则此步骤是完全可选的。在这种情况下,获取URI也将用于推送。如果在这个步骤中至少定义了一个推送URI,它将覆盖提取URI。在这个例子中,已经有一个获取URI,所以 即使列表中没有Push URI,也会启用Next按钮:
下一步是为推送URI定义远程规范。有关详情,请参阅 推送参考规格 。
完成后,新的远程配置将可见:
更改远程配置
也可以使用上下文菜单为现有的远程配置添加,删除或更改提取/推送规范。
Gerrit配置
如果您可以使用 Gerrit Code Review 作为远程存储库服务器
- 指定用于将更改推送到代码审阅的推送配置
- 指定提取配置以从Gerrit获取审阅笔记
- 配置您的存储库以 在缺省情况下在“提交”对话框中选择“ Gerrit代码审阅的 计算更改ID”选项
从Remote的上下文菜单中选择 Gerrit Configuration ...。这将打开一个带有一个页面的向导:
- 当您单击 完成时 ,向导会将存储库配置参数 gerrit.createchangeid设置 为 true。这确保 默认情况下选中提交对话框中Gerrit代码审查的复选框Compute Change-Id。详情请参阅 提交 信息。
- 如果要在稍后的时间点配置自动Change-Id插入,可以使用存储库配置编辑器(首选项>团队> Git>配置)将配置参数gerrit.createchangeid设置 为true。如果你想为你所有的仓库配置这个配置,你可以把它放到〜/ .gitconfig中,那么你不需要重复这个配置来处理你正在使用的每个新仓库。
- 另外,向导在您的获取规范中添加了一个refspec“refs / notes / *:refs / notes / *”。Gerrit在git笔记中存储有关该评论的数据。有了这个refspec,这些评论数据将在您从这个远程获取时自动获取,并且它们将显示在提交查看器中。
- 在Push URI部分, 您可以配置用于默认推送配置的URI。它根据您从中克隆的URI进行预填充。如果使用git协议进行克隆,协议会自动更改为ssh,并自动添加默认的Gerrit ssh端口29418。对于需要用户的协议,为了方便,有一个用户字段。
- “ Push Configuration ”部分 有一个字段“ Destination Branch”。在这里您应该输入Gerrit代码审查工作流程中接受更改的目标分支的名称。这会 在克隆向导中指定的远程的推送配置中产生一个条目 HEAD:refs / for / <branchname>。
刷新
该视图会定期自动刷新。 工具栏中的 刷新按钮允许立即刷新:
与选择链接
如果 启用了带选择的 链接,则将自动显示与当前工作台选择对应的文件或文件夹:
与编辑链接
如果 启用了带编辑器的 链接,则会自动显示与当前活动编辑器对应的文件或文件夹:
分层分支布局
如果 启用了“ 分层分支布局”切换,分支将以分层布局显示,并使用斜杠(/)作为分层结构分隔符:
这对组织大量分支机构可能有帮助。
裸库
“Bare”Git存储库(与“开发”或“标准”存储库相反)根据定义没有工作目录,因此与工作目录相关的所有操作(检出,项目导入,浏览工作目录)都不可用于这样的存储库。仓库的“裸机”在“工作目录”节点上可视化,该节点总是一片叶子:
裸存储库只能通过对其进行更改来更改。
从Git存储库视图中删除存储库
这是作为“Repository”节点上的菜单操作提供的。请注意,这不会删除存储库,而只是从视图中删除该节点。如果工作区中的项目位于存储库的工作目录中,则会提示用户确认从Eclipse工作区删除这些项目。
在相关视图中显示存储库
在历史中显示
Show in> History命令 将打开 历史视图, 显示所选储存库中的所有更改。
在Reflog中显示
Show in> Reflog命令 将打开 Git Reflog视图, 显示所选存储库的Git reflog。
在属性中显示
命令 Show in> Properties 将打开 显示所选存储库属性的 Properties视图。
使用任务
由于EGit 0.11与Mylyn的第一次集成可用于支持使用任务存储库。
安装
您需要安装功能“EGit Mylyn”才能使用EGit Mylyn集成。这还需要安装Mylyn。
提交消息模板
- 在首选项>任务>团队下配置Mylyn提交消息模板, 然后编辑 提交评论模板。
-
使用以下变量以及任何文本来更改提交消息。
- repository.url,task.assignee,task.cc,task.description,task.id,task.key,task.keywords,task.lastmodified,task.notes,task.priority, task.product,task.reporter,task.resolution,task.status,task.summary,task.type,task.url,task.completiondate,task.creationdate,task.reminderdate
- 在提交更改之前,使用Mylyn UI**相应的任务。
- 当启动提交对话框时,EGit将使用提交消息模板预填充提交消息。
有关 如何使用任务的更多信息,请参阅 Mylyn用户指南。
查看提交
Egit commit查看器允许在Eclipse编辑器区域中打开提交。
EGit commit查看器显示以下提交信息:
-
提交选项卡
- 链接到打开父提交
- 作者
- 修订者
- 信息
- 指向这个提交的标签列表
- 提交存在的分支列表
-
Diff选项卡
- 文本查看器与文件差异的输出
- 查看器中使用的颜色可以通过 首选项 > 常规 > 外观 > 颜色和字体 > Git 文件夹进行配置
-
Notes标签
- 所有Git的提交注释
标记提交
-
从提交查看器工具栏中选择创建标签图标
- 标签对话框将打开,允许您从提交中创建标签。
从提交创建分支
-
从提交查看器工具栏中选择创建分支图标。
- 分支对话框将打开,允许您从提交中创建新的分支
检出一个提交
这会检查提交查看器中显示的提交。提交将被检出并且 HEAD将被分离。
樱桃采摘承诺
在当前签出的提交或分支上应用由提交查看器中显示的提交引入的更改。
打开提交查看器
提交查看器可以从以下位置打开:
搜索提交
EGit支持搜索提交。
Git搜索页面
提交可以从 标准的Eclipse搜索对话框中的 Git Search选项卡搜索。
此对话框支持搜索Git提交的不同字段中存在的文本或模式,例如消息,作者行,提交者行和提交的SHA-1 ID,其父代以及与其关联的树。
浏览搜索结果
提交搜索结果显示在标准的Eclipse搜索视图中。在树状模式下,结果按存储库分组。双击搜索视图中的提交将在提交查看器中打开它 。
启动Git搜索
Git Search页面可以通过从Eclipse工具栏上的Search下拉菜单中选择Git Search选项来打开。
打开提交对话框
EGit 1.0有一个 类似于Mylyn Open Task 和 Open Resource核心对话框的 Open Git Commit对话框 。该对话框会搜索每个已配置的Git存储库,以查找输入到过滤器框中的分支,标记或提交SHA-1,并显示匹配的提交。
该对话框可以通过选择 Eclipse导航工具栏上的Open Git Commit按钮来 打开。
查找文件中每行的作者
EGit 1.0支持 在编辑器标尺内显示 git blame信息。
选择 Team > Show Annotations 对文件选择操作将打开编辑器并显示注释标尺,其中包含文件中每行的提交和作者信息。将鼠标悬停在标尺上将显示一个弹出窗口,其中显示提交ID,作者,提交者和提交消息。
责备注释编辑器标尺的外观和感觉 可以从标尺上下文菜单中的修订子菜单中配置 。
从弹出窗口中选择SHA-1超链接将在提交查看器中打开 提交。
使用子模块
EGit / JGit中的子模块支持在2011年2月发布的1.3版本中添加,该版本是Indigo SR2的一部分。
你可以阅读更多关于Git子模块是什么以及它们如何在此 Git社区书籍章节中工作的内容。
使用子模块克隆存储库
子模块是嵌套在父存储库内的存储库。因此,在对父存储库进行克隆时,需要克隆子模块存储库,以便文件/文件夹在父存储库的工作目录中可用。
克隆父库的完成后, 从Git Clone向导中检查 克隆子模块按钮 将克隆所有子模块库。
浏览子模块
在 包含子模块的存储库的Git存储库视图中 显示了一个 Submodules节点 。
给定父存储库中的所有子模块都显示在此节点下以及有关当前检出哪些提交的信息。
添加一个子模块
您可以通过在Git存储库 视图中选择一个存储库并选择 添加子模块 上下文菜单选项来将新的子模块添加到存储库 。
该向导将提示输入要添加的子模块的路径和URL。输入的路径将相对于父存储库的工作目录,并且URL将用于本地克隆存储库。
一旦向导完成,子模块将被克隆,添加到索引,子模块将被注册到 .gitmodules 文件以及父库中的 .git / config 文件中。
更新子模块
有两个操作可用于更新子模块,即 更新子模块 和 同步子模块。
在子模块 上选择 Update Submodule操作将检出在该子模块的父存储库索引中引用的提交。如果 在父存储库的.git / config 文件中所选子模块的配置部分的更新字段中 配置了该命令,则此命令也将执行合并或重新绑定 。
在子模块 上选择 Sync子模块操作将从父存储库工作目录根目录下的.gitmodules文件中的当前值更新子模块使用的远程URL 。
团队项目集
团队项目集(.psf 文件)由Git团队提供商支持。
进口
要导入现有项目集,请使用 导入... 向导,然后 从 团队中选择 团队项目集。
然后,您可以选择一个包含导入定义的文件,并可以选择将导入的项目添加到工作集。
在下一步中,存储库被克隆,项目被导入并连接。这可能需要一段时间,取决于存储库的大小。
出口
要为现有Git项目创建项目集文件,请选择已连接到Git团队提供者的项目/工作集。
然后打开 导出... 向导并 从 团队中选择 团队项目集。您可以选择仅导出工作集或项目,并可以优化您的选择。在下一步中,选择一个输出路径并完成向导。
格式
您也可以手动编辑 .psf 文件。每个项目都有一个如下所示的条目:
<project reference =“1.0,git://egit.eclipse.org/egit.git,master,org.eclipse.egit”/>
这些值由逗号分隔,并具有以下含义:
- 格式版本
- Git存储库URL
- 最初退房的分店名称
- 导入项目的路径(包含.project的文件夹 ),相对于存储库
每个项目都有一个条目。因此,对于同一个存储库中的多个项目,使用相同的存储库URL为每个项目创建一个条目。导入足够聪明,只能克隆每个存储库一次。
如果存储库包含根目录中的项目,请使用 。 作为项目路径。
参考
菜单
项目上下文菜单
在导航视图(导航器,包资源管理器等)中的项目节点上,以下Git操作可用于与Git团队提供者共享的项目:
主项目菜单
“远程”子菜单
“切换到”子菜单
“高级”子菜单
资源上下文菜单
在导航视图中的资源节点(文件和文件夹)上,以下Git操作可用于与Git团队提供者共享的项目:
存储库查看菜单
历史视图菜单
Git Workbench工具栏和Git Workbench菜单
为了方便使用最常用的Git动作, 可以**Git Command Group以显示Git Workbench工具栏和/或菜单
- 右键单击工作台工具栏区域,然后单击 自定义透视图...
- 在选项卡 命令组可用性中 单击 Git,这将启用Git工作台工具栏和菜单
- 在标签 工具栏可见性 和 菜单可见性中, 您可以配置哪些操作应该出现在Git Workbench工具栏和菜单中
菜单操作
-
加
- 将工作树中存在的更改添加到git索引,也称为分段更改。
- 将新创建的资源放在git版本控制下(Git不会自动开始跟踪资源)。
- 解决冲突。
- 应用修补程序 - 应用修补程序。
- 假定不变 - 资源可以被标记为“假定不变”。这意味着Git会停止检查工作树文件以进行可能的修改,所以当您更改工作树文件时,您需要手动取消设置该位以告诉Git。此设置可以通过菜单操作 Team> Assume保持不变 并切换回菜单操作 Team> No Assume不变。
- 分支, 创建分支 - 签出分支或创建分支。
- 更改凭证 - 更改提取或推式规范的登录凭证,凭证按照URL安全存储库中的每个URL进行存储。
- 结帐 - 签出 分支,标签, 提交 或参考。
- 樱桃选择 - 樱桃选择一个提交到当前签出的分支的提示。
- 清除凭证 - 清除提取或推送规范的登录凭证,凭证按照URL安全存储库中的URL存储。
- 提交 - 提交更改。
- 删除提取 - 删除提取规范。
- 删除推送 - 删除推送规范。
- 配置提取 - 配置提取规范。
- 配置推送 - 配置推送规范。
- 删除分支 - 删除分支。
- 删除存储库 - 删除存储库。
- 断开连接 - 断开所连接的Git Team Provider与该项目的连接。git存储库仍然存在,但不再与Eclipse集成。
- 忽略 - 将文件添加到.gitignore,以便git忽略它们。
- 导入项目 - 将项目导入Eclipse工作台。
- 合并 - 合并分支。
- 合并工具 - 使用合并工具解决冲突。
- 打开属性视图 - 查看和编辑存储库配置。
- Pull - 从当前检出的本地分支跟踪的远程分支上拉更改。
- 远程> 取自 - 从远程存储库获取更改
- 远程> 从Gerrit 获取 - 从Gerrit代码审阅服务器更改获取
-
远程> 推送 - 将更改推送到其他存储库
- 远程> 配置从上游获取 - 配置上游自动获取
-
远程> 配置推送到上游 - 配置上游自动推送
- 重建 - 将分支重新分配到另一个分支。
- 删除存储库 - 从存储库视图中删除存储库。
- 重命名分支 - 重命名分支。
- 重置 - 重置当前的HEAD,索引或工作树。
- 在历史记录中 显示 - 在历史记录视图中显示选定的资源。
- 在存储库视图中 显示 - 在存储库视图中显示选定的资源。
- 切换到... - 切换到(也称为结账)另一个分支或标签。
- 同步 - 同步本地和远程分支。
- 标签 - 创建,删除标签。
- Untrack - 从git版本控制中移除资源。如果要从工作树中删除资源,请 在资源的上下文菜单中单击“ 删除 ”。
Git透视和观点
Git透视
Window> Open Perspective> Git Repository Exploring 打开Git Repository Exploring透视图
Git存储库视图
窗口>打开视图> Git> Git Repositories 打开Git Repositories视图,这里详细解释 。
历史视图
概观
Git版本控制下的资源历史视图是给定存储库中资源的以提交为中心的视图。它可以用来执行以下任务:
- 在Git版本控制下检查给定文件的更改历史记录(查看和比较存储库中此类文件的版本)
- 使用不同的搜索条件搜索特定的提交
- 退出某个提交
- 基于某个提交创建分支和标签
- 根据某个提交中的更改创建补丁
- 将整个存储库重置为某个提交
- 设置quickdiff基线并将其重置为某个提交
打开历史视图
历史视图可以通过打开
- 在 资源管理器中的Git版本控制下的任何资源上右键单击 Show In> History View(在所有Perspective中都不可用)
- 在资源管理器中的Git版本控制下,右键单击 Team> History in History中的任何资源
- 单击 窗口>显示视图>其他...,然后选择 团队>历史记录
视图打开后,您可以**带选择的 链接 按钮,以使视图的输入与浏览器中的选择自动保持同步。
历史观的组织
历史视图被组织在几个窗格中:
上面的窗格是提交图表,以反向时间顺序显示提交日志(或提交历史记录)(最新的提交)。在提交图下方,默认有两个窗格:左侧是修订注释区域,其中显示提交消息和提交中文件或文件的文本差异,右侧是修订详细信息区域,它显示了提交所改变的文件的表格。
该表的第一列描述了每个文件的变化性质:
- 添加 该文件是由提交添加的
- 修改 该文件已被提交修改
- 删除 文件被提交删除
下部窗格的内容取决于上部窗格中的选择,并在此选择更改时自动更新。
通过右键单击上部窗格中的任意位置,并分别选择“ 显示修订注释” 和“ 显示修订详细信息”,可以分别打开和关闭两个较低的窗格 。
在提交图上方,当前输入可视化。输入始终是工作区资源,可以是项目,文件夹或文件。在输入的类型之后,将显示路径,后面跟着包含方括号中的资源的存储库名称。
使用历史视图
检查提交图
提交图区域是历史视图的主要部分。默认情况下,它显示当前签出的提交及其所有祖先,即列表中的第一个条目是签出的提交。以下图片用于解释历史视图的一些功能:
提交图中的每一行对应于一个提交。分支,标签和HEAD可视化如下:
- 本地分支的提示显示为绿色矩形
- 远程分支的提示显示为灰色矩形
- 本地HEAD显示为白色矩形
- 标签显示为黄色矩形
(我们的例子没有远程分支)。
左侧的行是实际的提交图,它显示了列表中提交的父子关系(每个提交至少有一个父级,除了存储库中的第一次提交)。可以有对应于分支操作的分叉和对应于合并操作的连接。在我们的例子中,在分支“beforeSplit”提交之后创建了一个“实验”分支,并且在“主”和“实验”分支中都更改了相同的文件。最后一次提交是合并提交,其中“实验”分支的内容与“主”分支合并。
可以通过标记提交并查看修订注释区域来检查确切的更改。在“修订注释”区域向下滚动时,可以看到更改的文本差异,在我们的示例中,它表示Project1 / f1 / file1.txt的内容已从“修改”更改为“主修改”。当选择下一个提交(对应于“实验”分支)时,会显示一个类似的差异,表示该文件的内容已从“已修改”更改为“已修改实验”。最新的提交是将“实验”合并为“主”的结果。因此,新承诺有两个祖先,“主”和“实验”线再次合并。
显示和比较文件的版本
如果当前输入已经是一个文件, 在提交上右键单击 打开将打开一个编辑器,其文件内容对应于当前选定的提交。如果该文件在选定的提交中不存在,则会显示一条错误消息。点击 比较工作树 将打开一个比较编辑器,比较当前选定提交的文件内容与工作区中的文件内容。
在 开放 和 与工作树进行比较 的动作也可以通过双击来执行的承诺:如果“比较模式”工具栏按钮(见下文)已关闭, 比较与工作树 会被执行,否则 打开。
通过选择两个提交并右键单击比较,可以比较由当前输入过滤的两个提交的内容 。如果当前输入不是文件,则在Tree中有一个额外的菜单操作相互 比较。第一个动作打开Eclipse比较编辑器,第二个动作打开 Git树比较视图。
此外,可以选择任意数量的提交并右键单击 打开 以查看与所选提交相对应的文件的所有版本(每个版本将打开一个编辑器)。
如果当前输入不是文件,则不会有打开的菜单操作 。但是,可以双击“修订详细信息”区域的条目。如果比较模式处于活动状态,将打开一个比较编辑器,显示当前所选提交中双击文件的更改(即,当前选定提交中的文件内容与此提交的祖先的文件内容的差异)。如果比较模式未处于活动状态,则会显示一个文件内容对应于当前所选提交的编辑器。
使用过滤器设置
可以使用相应的工具栏操作更改过滤器设置(请参见下文)。默认情况下,“资源”设置处于活动状态,即只有列表中显示包含当前输入更改的提交。如果当前输入不是文件,则显示所有提交,其中包含当前输入的任何子项的更改。
如果过滤器设置为“资源”,并且当前输入是文件,则提交列表仅包含那些包含该文件更改的提交。分析该文件的历史记录时,这非常有用。但是,在某些情况下,还可以看到其他不改变实际文件的提交。例如,查看文件中的某个给定更改是否在某个不会更改该文件本身的其他提交之前或之后可能很有趣。在我们的示例中,我们可能想知道给定的更改是否在标记为“Project1”的提交之前“之前”或“之后”。通过将过滤器设置从“资源”更改为“存储库”,这很容易完成:
其他两个设置(“文件夹”和“项目”)的行为类似之处在于它们分别包含更改当前输入的父文件夹中的任何资源或当前输入的项目中的任何资源的提交。在我们上面的示例中,如果使用过滤器设置“Project”,则不会显示提交“将Project2添加到存储库”,是否不会更改当前输入项目中的任何内容(Project1 / f1 / file1.txt )。
或者,为了查看与特定项目有关的所有提交,可以更改该项目的历史视图输入。但是,文件特定的菜单操作将不可用。
工具栏操作
历史视图工具栏中的前四个按钮是刷新,选择链接,固定和导航历史记录的标准按钮。
找
如果“查找”工具栏按钮处于关闭状态,则视图的下部会显示一个搜索栏,允许在提交日志中搜索提交。根据搜索栏下拉列表中的设置,搜索提交的标题,评论,作者或提交者。
找到的搜索结果高亮显示,“Next”和“Previous”按钮允许跳转到符合搜索条件的下一个或上一个提交:
过滤器设置
视图工具栏中的下一个四个切换按钮控制显示的提交相对于当前输入的过滤方式: 按钮用作单选按钮,即四个按钮之一必须始终处于关闭状态。
- 如果“Repository”按钮处于关闭状态,则不会过滤提交日志,并显示从当前签出的分支可达到的所有提交(或所有提交,请参阅下面有关“所有分支”操作的提交)
- 如果“项目”按钮关闭,则提交日志将被过滤以显示影响包含当前输入的项目中的任何资源的所有提交
- 如果“文件夹”开关处于关闭状态,则会过滤提交日志以显示影响当前输入的父文件夹中的任何资源的所有提交
- 如果“资源”按钮关闭,则提交日志将被过滤以仅显示影响当前输入的提交; 视图菜单项“ 显示”>“跟随重命名” 允许切换是否选择资源的重命名应该由此过滤器跟随
请注意,并非所有滤波器设置和电流输入的组合都是有意义的; 例如,如果当前输入是项目,则“项目”选项实际上与“资源”选项相同。
比较模式
下一个按钮又是一个切换,**“比较模式”。如果它停机,某些双击操作(见上文)将打开比较编辑器而不是普通的编辑器。
所有分支机构
该切换**“所有分支”模式。默认情况下,只有那些提交日志中显示的提交可以从当前签出的提交中获得,即,提交图以当前签出的提交结束,而较新的提交不会显示。如果此按钮处于关闭状态,则所有提交都将显示在提交日志中。这在我们的例子的下面的图片中说明。“分裂之前”的分支目前已被检出; 通过**切换,新的分支将变为可见:
查看菜单操作
配置视图
大多数工具栏操作也可以在查看菜单中找到。另外,可以使用以下切换:
“附加参考”切换在获取,重定位,合并等操作期间创建的某些Ref的可见性,例如FETCH_HEAD,ORIGIN_HEAD ...这可以有助于消除历史视图中的混乱。
“注释历史记录”在“修订注释”区域切换Gerrit评论注释的显示。
如果使用“资源”过滤器,“跟随重命名”切换是否应在历史视图中遵循所选资源的重命名。此首选项还可以在首选项向导 首选项>团队> Git>历史记录>关注重命名中进行配置。
“修订注释”切换修订注释区域的可见性。
“修订细节”切换“修订细节”区域的可见性。
如果选中“相对日期”,则提交日期将显示为相对日期而不是绝对日期。
“电子邮件地址”切换提交者电子邮件的显示。
子菜单“In Revision Comment”打开一个子菜单,其中有更多的切换来管理修订注释区域的外观:
“标签序列”允许显示/隐藏指示给定提交的祖先列表中的最后一个标签和给定提交的后续列表中的下一个标签,即给定提交之前/之后的标签。
“包装注释”和“填充段落”切换修订注释区域内的格式。
“修订详细信息”和“修订注释”也可通过右键单击“提交图表”区域中的任意位置获得。
通过右键单击修订注释区域中的任意位置,也可以使用“标签序列”,“包装注释”和“填充段落”。
上下文菜单操作
“提交图表”区域中的上下文菜单略有不同,具体取决于当前是文件还是文件夹/项目。以下菜单条目始终可用:
如果当前输入是文件,则还有其他一些可用的操作; 如果只选择一个提交,则有三个附加选项:
如果选择了两个提交,菜单将如下所示:
如果选择了两个以上的提交,只有“打开”操作和“Quickdiff”菜单可用。
与工作树比较
只有当前输入是文件并且选择了单个提交时,此操作才可用。它将打开一个比较编辑器,将所选提交的文件内容与工作树中的文件内容进行比较。
相互比较
此操作仅在当前输入是文件并且选择了两个提交时才可用。它将打开一个比较编辑器,比较所选提交的文件内容。
打开
此操作仅在当前输入是文件时才可用。它将为每个选定的提交打开一个编辑器,显示给定提交的文件内容。
查看
这将检出当前选定的提交。如果此提交存在分支,则会检出分支,如果此提交存在多个分支,则会显示一个对话框,询问应检出哪个分支。如果不存在提交的分支,则提交将被检出并且HEAD将被分离。
创建分支...
在当前选定的提交上创建一个分支。将显示一个对话框询问分支名称以及是否应检出新创建的分支。
删除分支
如果当前选定的提交没有检出,则该操作将被启用。如果此提交中有一个分支未被签出,则此操作将立即删除该分支。如果存在多个这样的分支,将显示一个对话框,询问哪些分支应该被删除。如果提交在“删除分支”上无法访问,将显示一个确认对话框以防意外提交的意外不可达。
创建标签...
在当前选定的提交上创建一个标签。将显示一个对话框,询问标签名称和标签消息。
创建补丁...
此操作在存储库的第一次提交中不可用。它将创建一个包含当前所选提交与该提交的前任相比所做更改的修补程序。将显示一个对话框,询问是否应该将补丁创建为文件或剪贴板,以及是否使用通用补丁格式的Git补丁格式。
樱桃采摘
在当前签出的提交之上应用所选提交引入的更改。
恢复提交
通过在当前签出的提交之上创建一个新的提交来还原所选提交引入的更改。
去
将选定的提交合并到当前签出的分支中。
在最重要的基础上
在选定的提交之上重新绑定当前签出的分支。
重置>软/混合/硬
此操作将包含当前输入的存储库重置为当前选定的提交。根据子菜单的选择,将执行软重置,混合重设或硬重置。
Quickdiff>将Quickdiff Basline重置为HEAD
Quickdiff>将Quickdiff Basline重置为HEAD的第一个父级
这两个操作将存储库的quickdiff基线设置为HEAD或HEAD的父级。即使选择了多个提交,这些操作也始终可用。
Quickdiff>设置为基线
此操作仅在选择单个提交时可用; 它会将存储库的quickdiff基线设置为选定的提交。
复制
将当前选定的提交或提交的ID复制到剪贴板中。
显示修订评论
切换“修订注释”区域的可见性。
显示修订详情
切换“修订细节”区域的可见性。
包装评论
仅当右键单击修订注释区域时才可用。如果**,则注释将被自动包装以填充显示区域,否则将使用提交消息的包装。
填写段落
仅当右键单击修订注释区域时才可用。如果处于活动状态,则会显示提交消息而不会有不必要的换行符
拖放支持
您可以将提交图上的提交拖放到Mylyn Task上或拖放到 硬盘上的文件夹中。在这两种情况下,EGit都会自动创建一个可能附加到磁盘上的错误或存储的补丁。
使用修订细节区域
版本详细信息区域显示了所选提交更改的文件的表格。选择上下文菜单操作 在选定文件上显示注释将在(只读)编辑器中打开该文件,并显示包含文件中每行的提交和作者信息的注释标尺。请参阅 本节。
同步视图
菜单命令“ 团队”>“同步工作区” 将启动“同步视图”。此视图允许您检查本地工作区和本地或远程跟踪分支中的资源之间的差异。或者,您可以比较本地和远程跟踪分支。比较两个远程跟踪分支以及同步视图上的菜单命令在此EGit版本中尚不可用,并将在未来版本中提供。
以下是Git Synchronize View的内容:
同步状态
Synchronize View显示工作空间或本地分支中资源的同步状态,与另一个本地或远程跟踪分支中代表远程资源库分支状态的资源同步状态。此状态通过使用图标显示,也可以配置为将状态显示为附加到资源名称的文本。
下表显示了这些图标的说明:
模式
同步视图可以使用工具栏操作或视图下拉菜单中的菜单项进行过滤。模式可用于仅显示传入,传出或冲突的更改。
楷模
同步视图能够显示资源的不同模型表示。每个产品可能包含自己的产品特定表示。Eclipse SDK带有三种模型:
- 工作区模型
- 显示基于资源的模型。此模型的布局选项可以通过下拉菜单中的“首选项”对话框进行控制。Workspace模型的布局选项为
- 平面布局
- 将所有不同步的资源显示为其项目的直接子项。
- 树布局
- 显示项目资源管理器中显示的资源层次结构。
- 压缩文件夹
- 显示按项目分组,然后按文件夹分组的更改。这导致层次结构最多为三层,文件夹路径被压缩到单个层次(类似于Java包)。
- Java模型
- 显示一个基于Java的模型(类似于Package Explorer中显示的模型)。
- Git提交
- 显示一个基于Git Commit的模型。此模型显示按提交分组的传入更改,这对于查看谁释放内容和原因很方便。对于传出更改,您可以通过创建提交来 创建提交。Git提交描述的显示格式可以 在标签Other中的 Team> Git> Label Decorations下的首选项中配置 。
除了模型之外,还有一个 平面演示 ,它将所有不同步的元素显示为顶层元素。
导航
“同步”视图提供了用于浏览视图中的更改的工具栏操作。这些操作不仅可以在文件之间导航,还可以从文件中的更改更改。
同步视图中的树可以很容易地从工具栏展开和折叠。
Git树比较视图
该视图将通过一些Compare With 操作打开 (请参阅 比较内容)。从资源(例如项目或文件夹)启动时,它将看起来类似于工作区中的资源。但是,文件上的通常图标将被替换为显示更改状态的图标(添加,删除,更改或未更改)。
可以浏览更改并双击文件将打开该文件的比较编辑器(这只对“已更改”文件有意义,如果添加或删除文件,比较编辑器的一侧将为空,而未更改的文件将在编辑器的两侧显示相同的内容):
可以通过单击工具栏中的“隐藏等同内容的文件”按钮来隐藏未更改的文件。
Git树比较视图也可以在没有工作区资源作为起点的情况下启动(例如,当历史视图的输入是存储库而不是工作区资源时,通过比较历史视图中的两个提交)。在这种情况下,将显示存储库的完整内容,并且项目和文件夹都显示为简单的“文件夹”图标:
Git Staging View
该视图提供了用于git status
显示工作树中所做更改的等效项 。尚未转移到git索引的未暂停更改显示在“ 未更改更改” 窗格中,已在“ 暂存更改”窗格中显示 已被“添加”(暂存)到Git索引的更改 。默认情况下,这些窗格显示在行布局中,可以通过列布局选项将其更改为列布局 。默认情况下,Staged窗格和Unstaged Changes窗格显示文件的完整路径。可以通过“ 显示文件名优先”选项来配置它们,以 首先显示文件名,然后显示文件所在的目录。
双击已修改的文件以打开比较视图。如果从“未冻结”窗格触发,比较视图将显示尚未分阶段的更改。从“分段”窗格触发时,它将显示已经分阶段进行的更改。要在编辑器中打开 文件,请在文件的上下文菜单中使用“ 打开工作区版本”操作。
要演示文件,请将其从“未分级更改” 窗格拖到 “ 分段页面” 窗格中。或者, 对“ Unstaged Changes” 窗格中文件的上下文菜单使用 Add to Git Index操作 。在 与Git的索引文件替换 操作将替换选定的文件在工作树。如果该文件未冻结,它将被重置。如果它被暂存,工作树版本将被Git索引中的暂存版本替换。
要unstage文件,从拖动它 暂存的变更 窗格的 不分级的变化 窗格。或者, 在文件的上下文菜单中使用 从Git索引删除操作。
提交操作只会提交阶段性更改 - 与git commit
原生git中的操作类似 。集成的提交消息编辑器允许编辑提交的提交消息。与提交对话框不同,分段视图可以在进行更改时保持打开状态。这允许递增地写入提交消息以及更改。正在编辑的提交消息与存储库相关联,分段视图与链接。它不会被持久存储,并且如果分段视图或Eclipse被关闭,它将会丢失。
要提交,请 在提交消息文本字段中按 Ctrl + Enter (Mac OS X上的 ' Command + Enter ),或者单击 提交 或 提交并按下按钮。
部分分期
有时只提交文件的一些更改很有用。例如,在处理某个功能时注意到与该功能无关的错字或小错误。
为了只提交某些更改,这些更改必须首先进行。为此,请双击Unstaged Changes 窗格中的文件 。这将打开比较编辑器。左侧是工作区版本,右侧是索引(分段)版本。
比较编辑器的两侧都是可编辑的。当更改右侧(索引)中的某些内容并保存时,该文件将在“ 分阶段更改” 窗格中显示,并在提交时正好提交该内容。
要 放置一组更改的线条, 可以使用“ 从左到右复制当前更改”工具栏按钮(箭头图标)。
Git Reflog视图
Reflog视图显示选定存储库的Git reflog。它支持通过选择视图右上方的超链接ref名称来显示特定分支的reflog。双击或选择上下文菜单操作 在提交查看器中 打开reflog条目,在提交查看器中打开相应的提交。上下文菜单操作 Checkout 将签出选定的提交,并且 HEAD将分离。
Git网址
通常,Git URL由传输协议方案,远程服务器的地址和远程服务器中的存储库路径以及一些认证协议(也包括用户标识)组成。
EGit支持以下协议
- 文件 - 直接访问存储库的文件系统。
- git - 最高效的内置git协议(默认端口9418)。该协议不提供认证。通常用于对存储库进行匿名读取访问。
- ssh - 通过安全shell(SSH) 协议的Git 。通常用于对存储库进行身份验证的写入访问。
- http - 超文本传输协议 可以通过防火墙隧道传输。
- https - 超文本传输协议安全 可以通过防火墙隧道传输。
- ftp - 文件传输协议
- sftp - SSH文件传输协议
Git URL在使用时使用
Git参考
Git引用也很快就被称为 Refs。
它们包括
- 分支机构
- 远程跟踪分支
- 标签
它们全部用路径命名,使用'/'作为路径分隔符,并以“refs”开头。
- 本地分行以“refs / heads /”开头
- 远程跟踪分支以“refs / remotes /”开头。远程跟踪分支位于远程存储库中的代理分支,以便当没有与存储库的连接可用(脱机)时,也可以查询它们在上次传输操作时的状态。
- 标签以“refs / tags /”开头
只要缩写形式是唯一的,参考名称可以缩写。
例如
- “master”是“refs / heads / master”的简称
- “origin / master”是“refs / remotes / origin / master”的简称
- “v1.0.1”是“refs / tags / v1.0.1”的简称
Refs中还有一些“保留”名称,可用于某些场景:
参考名称 | 备注 |
头 | 指向当前结帐提交 |
FETCH_HEAD | 指向最后一次读取操作的结果 |
ORIG_HEAD | 指向在合并或重建操作启动之前签出的提交 |
有关Ref名称的完整列表以及优先顺序,如果多个引用具有相同的缩写形式,请参阅git rev-parse的 “指定修订”部分 。
Refspecs
提取和推送操作使用“refspec”来描述远程Ref 和本地 Ref之间的映射 。在语义上,它们定义了本地分支或标签如何映射到远程存储库中的分支或标签。在本地git中,它们以<src>:<dst>格式与冒号组合,前面带有可选的加号,+表示强制更新。在EGit中,它们可以在“ 推式参考规格” 和“ 取回参考规格” 和其他对话框中以表格形式显示和编辑 。
RefSpec的“左侧”称为源,“右侧”称为目的地。根据RefSpec是用于读取还是用于推送,源和目标的语义不同:对于Push RefSpec,源表示源存储库中的Ref,目标表示目标存储库中的Ref。
推送Refspecs
Push RefSpec的一个典型例子可能是
HEAD:参考文献/头/主
这意味着当前签出的分支(如HEAD引用所表示的,参见 Git引用)将被推送到远程仓库的主分支中。
获取Refspecs
Fetch RefSpec的典型示例可能是
裁判/头/ *:参/遥控器/产地/ *
这意味着远程存储库中的所有分支都将被提取到本地存储库的相应远程跟踪分支中。
遥控器
远程用于管理从您的存储库跟踪其分支的存储库(“远程”)。
在EGit中,Remotes是在什么时候定义的
- 按照惯例,从另一个存储库克隆一个存储库,这个新创建的存储库名为“origin”。如果您更喜欢不同的名称,克隆向导允许指定该名称。
- 在存储库视图中定义远程
远程首先为 你的分支机构定义一个 名字,这很重要,因为你可能想跟踪不同存储库中的分支,因此这个名字有助于理解某个操作正在处理的存储库。此外 ,为给定Remote指定的Refspecs定义了 本地存储库中分支和标记到远程存储库中分支和标记的 映射。您可能希望为入站或出站传输操作使用不同的映射,因此 编辑人员 可以定义EGit中提供的提取和推送配置。
Git忽略
.gitignore
位于工作树中的文件指定有意不应该被git跟踪的文件。他们只关注那些还没有被git跟踪的文件。为了忽略已跟踪文件中的未提交更改,请参阅 假定不变的操作。
.gitignore
文件中的每一行 定义了一个模式。Git检查忽略工作树层次结构中从高到低的模式。较高级别.gitignore
文件中定义的模式被较低级别中定义的模式 覆盖。项目所有工作中应忽略的文件通常包含在项目的存储库中,以便在团队中轻松共享。
模式格式定义:
- 空白行被忽略
- 以#开始的行 作为注释
- 可选的前缀 ! 否定该模式。再次包括由匹配的先前模式排除的文件。以斜线结尾的模式只匹配目录,但不匹配文件或符号链接。
- 不包含斜杠的模式被视为与相对于.gitignore文件位置的路径匹配的外壳全局模式
- git将模式视为fnmatch(3)中定义的shell球体,
- 在模式中通配符不匹配 / 路径名
- 一个前导斜杠匹配一个路径名的开头
EGit Ignore 菜单操作 将选定资源添加到 .gitignore
资源父目录中的文件。要输入其他忽略模式,请使用文本编辑器。
注意: EGit还没有尊重 .gitignore
Eclipse项目之外的文件,所以如果您有一个包含多个项目的存储库,则应.gitignore
为每个项目添加一个文件,而不是在根目录中添加一个文件。
用于PDE构建的Git Fetch Factory
作为EGit的PDE工具的一部分,org.eclipse.egit.fetchfactory 插件中包含一个用于Git的PDE Build fetch工厂 。
映射文件的文件格式: type @ id,[version] = GIT,args
其中, args 是键值对的逗号分隔列表。
接受的 参数 包括:
- 标记* - 必需的Git标记
- 回购* - 强制回购地点
- 路径 - 相对于指向元素的repo的可选路径(否则,假定元素位于存储库根目录)
- prebuilt - 可选布尔值,指示路径指向存储库中的预先构建的包
提取是通过三个步骤来实现的:
- 存储库被克隆到本地光盘。如果它已经存在,则认为它以前被克隆过,并且只提取新的提交
- 指定的标签将在本地克隆中签出
- 路径的内容将被复制到最终的构建位置