seo网站快排,网站代码编辑器,食品商务网-网站建设,网站布局设计排版Git 是常用的去中心化源代码存储库。它是由 Linux 创建者 Linus Torvalds 创建的#xff0c;用于管理 Linux 内核源代码。像 GitHub 这样的整个服务都是基于它的。因此#xff0c;如果您想在 Linux 世界中进行编程或将 IBM 的 DevOps Services 与 Git 结合使用#xff0c;那…Git 是常用的去中心化源代码存储库。它是由 Linux 创建者 Linus Torvalds 创建的用于管理 Linux 内核源代码。像 GitHub 这样的整个服务都是基于它的。因此如果您想在 Linux 世界中进行编程或将 IBM 的 DevOps Services 与 Git 结合使用那么深入了解 Git 会很有帮助。 当我开始使用 Git 时我对并发版本系统 (CVS) 和 Apache Subversion (SVN) 有一些经验因此我尝试从这些经典的源代码存储库系统的角度来理解它。这种思维方式只让我对 Git 的功能了解有限。从那时起我对 Git 有了更好的理解所以这篇文章是一种“自我笔记”文本旨在提醒自己 Git 是如何工作的并向那些刚接触 Git 的人解释它。我假设您了解其他更经典的源代码存储库如 CVS 或 SVN。 基础知识 因此让我们从经典源代码存储库中的一个基本示例开始如图 1 所示。在经典源代码存储库中包含文件和子文件夹的文件夹将作为内容进行处理CVS 和 Git 实际上不处理文件夹仅处理位于路径位置。存储库保存内容的所有版本而工作目录是您修改代码的位置。您将代码从存储库检出到工作目录并将在此工作目录中所做的更改提交回存储库中内容的新版本。 图 1. 经典源代码存储库工作区处理 每次提交都会创建一个新的内容子版本该内容派生自您修改的先前父版本如图 2 所示。内容存储为一系列版本也称为快照通过创建的父子关系链接通过提交操作。通过提交在父版本和子版本之间发生更改的信息称为更改集。 这一系列的版本称为流或分支。在SVN中主流称为trunk在 CVS 中它通常称为HEAD在 Git 中它通常被命名为master。分支在实施项目中用于分离特定功能的开发或用于旧版本的维护。 图 2. 在经典存储库中创建新版本 到目前为止Git 看起来非常像这种经典的源代码存储库不是吗不幸的是相似之处就到此为止了。 CVS 和 SVN 的一大特点是它们有一个中央存储库。 Git 是去中心化的。多个存储库可以在软件开发中协同工作事实上每个开发人员的存储库的工作和通信方式与任何基于服务器的 Git 存储库相同。 Git 的工作原理 一旦理解了 Git 的主要原理就会发现它非常简单。 首先Git 处理快照中的内容每次提交一个快照并且知道如何应用或回滚两个快照之间的更改集。这是一个重要的概念。在我看来理解应用和回滚变更集的概念会让 Git 更容易理解和使用。 这才是真正的基本原理。其他任何事情都由此而来。让我们进一步深入研究 Git。 使用 Git 首先这里列出了使用 Git 时将使用的常用命令 git init-- 初始化存储库git checkout branch-- 将存储库中的分支检出到工作目录中git add file-- 将文件中的更改添加到更改集git commit-- 将更改集从工作目录提交到存储库 要开始使用 Git您只需运行git init命令。它将当前目录转换为 Git 工作目录并在.git它创建的隐藏目录中创建存储库。然后您就可以开始使用 Git。checkout和命令commit与其他源代码存储库类似但对更改集的关注是在 Git 中拥有该命令的原因add类似于 SVN。使用此命令工作目录中的更改将添加到下一次提交的暂存区域。该暂存区通常称为索引。图 3 说明了创建从快照版本 A 到快照版本 B 的更改集的过程。 git status帮助您跟踪您所在的分支上已添加或未添加哪些更改。 图 3. 在 Git 中创建更改集 git log显示工作目录中的更改即提交的历史记录或git log path应用到给定路径的更改的历史记录。 同时git status列出了工作区中修改过的文件以及索引中的文件您可以通过命令查看文件之间的差异git diff。仅使用git diff不带参数仅显示工作目录中尚未添加到索引中的更改。您需要使用git diff --cached来查看索引中实际内容暂存的更改。git diff name或git diff name -- path分别显示当前工作目录与工作目录或给定路径的命名提交之间的差异。该名称可以是提交 ID、分支名称或其他名称。现在是讨论命名的好时机。 命名 注意 由于提交 ID 的长度我将在图中仅使用“(A)”、“(B)”等缩写。 让我们看一下 Git 中事物的命名。快照是 Git 中的主要元素。它们以提交 ID命名这是一个哈希 ID例如“c69e0cc32f3c1c8f2730cade36a8f75dc8e3d480”。它源自快照的内容由实际内容和一些元数据组成如提交时间、作者信息、父母等。快照没有像 CVS 那样的点号版本也没有交易编号和/branches 顶级目录下的路径与 SVN 中一样。因此您无法像在其他存储库中那样从 Git 快照名称确定任何类型的顺序。为了方便起见Git 可以通过从 ID 开头获取最少数量的字符将这些长哈希缩写为短名称以便短名称在存储库中仍然是唯一的。在上面的示例中简称为“c69e0cc”。 请注意术语commit既用作创建快照的动词也用作生成的快照的名称。 通常您不必使用提交 ID相反您与分支机构一起工作。在其他源代码存储库中命名的更改流称为分支。在 Git 中更改流是更改集的有序列表因为它们被一个接一个地应用以从一个快照转到下一个快照。Git 中的分支只是指向特定快照的命名指针。它指出了使用此分支时应应用新更改的位置。当更改应用于分支时分支标签也会移动到新的提交。 Git 如何知道将工作区中的更改放在哪里这就是 HEAD 所指向的地方。开发的 HEAD 是您最后一次检查工作区的位置更重要的是是提交更改的位置。它通常指向您上次签出的分支。请注意这与 CVS 将术语 HEAD 解释为默认分支的开发技巧不同。 该tag命令命名一个提交并允许您使用可读的名称来寻址单个提交。基本上标签是提交 ID 的别名但也可以使用一些快捷方式来处理提交。 HEAD 作为工作目录中的开发提示。 HEAD^1 是 HEAD 提交的第一个父级HEAD^2 是第二个依此类推。 有关更多详细信息请参阅gitrevisions主页。因为像标签或分支名称这样的名称是对提交的引用所以它们被称为refnames。引用日志显示名称生命周期内发生的更改从创建名称通常由分支到当前状态。 分枝 分支背后的概念是每个快照可以有多个子快照。将第二个更改集应用到同一个快照会创建一个新的、独立的开发流。如果命名的话就称为分支。 图 4. Git 中的示例分支结构 图 4 通过 Git 中的示例分支结构说明了这一点。当前发生一些开发的主分支指向快照 F。另一个旧分支标记了旧快照也许是一个可能的修复开发点。功能分支对特定功能有其他更改。更改集被标记为从一个版本到另一个版本例如“[B-D]”。在此示例中快照 B 有两个子级两个开发流从那里开始一个用于功能分支另一个用于其他分支。提交 B 也被标记为修复编号 123 的错误。 您需要了解的其他命令 git branch branchname-- 从当前 HEAD工作目录创建一个新分支git checkout -b branchname-- 从当前 HEAD 创建一个新分支并将工作目录切换到新分支git diff branchname - pathpath-- 显示工作目录和给定分支之间的差异git checkout branchname - path-- 将给定分支中的文件检出到工作目录中git merge branchname-- 将给定分支合并到当前分支git merge -abort-- 中止导致冲突的合并 分支是使用git branch branch name当前 HEAD 或git branch branch name commit id任何有效快照版本上的命令创建的。这会在存储库中创建一个新的分支指针。请小心以这种方式分支会将__您的工作空间保留在旧分支上。您需要先签出新分支。随着git checkout -b branch name新分支的创建您的工作空间也将移动到新分支。 另外两个命令相当有用 git diff branch -- path如上所述打印当前工作目录和指定分支之间给定路径文件或目录的差异。git checkout branch -- path将不同分支中的文件检出到工作目录中以便您可以从另一个分支中选择更改。 合并 当您实现新功能时您将其签入存储库例如在“功能”分支上。当该功能完成后您需要将其合并回 master 分支。您可以通过检查 master 分支并使用 来完成此操作git merge branch name。然后Git 将给定分支的更改合并到已签出的分支中。 Git 为实现此目的所做的是将功能分支中的所有更改集应用到主分支的尖端。 根据两个分支中的更改类型以及可能的冲突可能会发生三种可能性。 快进合并由于两个分支分歧接收分支没有得到任何更改。接收分支仍然指向另一个分支分歧之前的最后一次提交。在这种情况下Git 将接收分支的分支指针向前移动如图 5 所示。由于除了向前移动分支指针之外没有其他操作因此 Git 将其称为快进合并。 图 5. 快进合并 无冲突合并两个分支都有变化但不冲突。例如如果两个分支中的更改影响不同的文件就会发生这种情况。 Git 可以自动将其他分支的所有更改应用到接收分支并创建包含这些更改的新提交。然后接收分支向前移动到该提交如图 6 所示。 请注意生成的提交合并提交有两个父级。不过我还没有注意到这里的更改集。原则上从E到H的变更集将是自两个分支转移以来来自特征分支的所有变更集的组合但这可能使类比太过分了。 图 6. 无冲突合并 冲突合并两个分支都有更改但它们发生冲突。在这种情况下冲突的结果将保留在工作目录中供用户修复和提交或者中止与git merge –abort. 需要注意的一件有趣的事情是合并会查找两个分支中应用了相同补丁的实例。因为两个分支都有更改这通常会导致冲突但由于 Git 足够智能可以检测到这种情况因此您仍然可以进行快进合并。 回滚和重放变更集的概念进一步体现了诸如变基和挑选等高级功能。 有时您开发了一个功能但主开发也在并行进行而您还不想合并您的功能。结果将是两个分支很快彼此远离。然而可以将变更集从一个分支应用到另一分支。 Git 为此提供了 rebase 和cherry-picking 功能。 变基 想象一下您正在开发您的功能并且需要合并主分支的最新更改以跟上总体开发的步伐。这就是所谓的功能分支变基它将两个分支之间的分流点向上移动到其中一个分支上。 Git 所做的是然后它会在另一个分支的顶端重播一个分支的更改为每个原始提交创建新的提交。在图 7 所示的示例中它尝试将来自 master 分支顶部的功能分支的更改应用。 图 7. 分支变基 git 变基-- 将当前分支重新定位到给定其他分支的尖端。 git rebase -i——交互式变基。 git 樱桃挑选-- 中止导致冲突的樱桃选择。 git revert -- 恢复补丁。 如果重播导致冲突则变基会在第一次冲突时停止并将冲突状态保留在工作目录中供用户修复。然后可以继续或中止变基。 使用该--onto选项变基实际上可以将转移点“移动到”另一个分支中的任何较新的快照上。 樱桃采摘 想象一下您现在正在开发一项功能并且已经开发了一些更改应该立即将其放入您的主开发中。这可能是一个错误修复或者是一个很酷的功能但您还不想合并或变基分支。 Git 允许使用樱桃选择功能将更改集从一个分支复制到另一个分支。 在这种情况下如图 8 所示Git 仅应用导致 HEAD 上选定快照的更改集例如 master 分支。这里通常实际使用提交 ID也称为哈希值。 图 8. 择优选择提交 恢复 该revert命令回滚工作目录上的一个或多个补丁集然后在结果上创建一个新的提交。revert几乎与樱桃采摘相反。有关示例请参见图 9。 图 9. 恢复提交 该revert命令将恢复记录为新提交。如果您不希望记录下来可以将分支指针重置为较早的提交但这超出了本文的范围。 那么为什么我要如此详细地讨论这一部分呢这是因为在下一节讨论协作功能时理解这些功能至关重要。事实上一旦你理解了第一部分第二部分几乎立刻就清楚了。大多数协作功能都基于迄今为止讨论的基本功能。 合作 在经典的源代码存储库中总是有一个明确的概念什么是分支这是中央存储库上的一个。 然而在 Git 中不存在主分支这样的东西。等等我上面不是写了一般都有一个master分支吗是的我做到了。然而。该 master 分支仅存在于本地。除了您创建的关系之外一个存储库中的 master 分支与另一存储库中的 master 分支之间不存在任何关系。 图 10. 两个存储库 如果您已有存储库则可以使用该git remote add命令添加远程存储库。然后你可以使用命令在你自己的存储库中获取远程分支的镜像fetch。这称为远程跟踪分支因为它跟踪远程系统上的开发。 当您签出仅作为远程跟踪分支而不是本地分支存在的分支时Git 会自动从远程跟踪分支创建本地分支并签出该分支。 一旦完成您就可以将远程分支的内容合并到您自己的分支中。图 11 显示了签出到本地 master 分支但情况不一定如此您可以将其合并到具有公共历史记录的任何其他分支如普通合并命令。 图 11. 获取并签出远程分支 另一种方法是使用git clone例如从托管服务获取远程存储库的命令。这会自动获取所有远程分支但还没有本地引用并签出主分支。 正如您所看到的一种模式出现了。因为远程存储库分支“只是一个分支”所以上面讨论的有关分支、合并等的所有内容几乎无缝地适用于这里特别是在从远程存储库获取更改时。 图 12. 获取远程更改 克隆-- 创建远程存储库的“克隆”。 git 远程添加 -- 添加一个名为的远程存储库与给定的连接 URL。 git 获取 -- 获取对远程跟踪分支的更改从远程存储库。 git拉 -- 获取然后合并。 git 推送 -- 将更改从本地分支通过远程跟踪分支推送到远程存储库。 在图12中git fetch示出了a它更新远程跟踪分支。然后您只需在远程跟踪分支和本地分支之间执行正常的合并操作在本例中git checkout master; git merge repo1/master。提取后您可以使用FETCH_HEAD合并命令中的名称作为提取的远程分支的快捷方式例如git merge FETCH_HEAD.此外与上面的讨论类似此合并可能会导致快进合并、无冲突合并或需要手动解决的冲突。 该命令是与git pull结合使用的便捷命令。fetchmerge 当更改已提交到本地分支时必须将它们传输到远程分支。这是通过push将本地更改推送到远程分支的命令来完成的。它是相反的fetch而不是相反的pull。然而它的作用不仅仅是获取因为它更新远程分支的本地副本以及其他存储库中的远程分支如图 13 所示。push还允许您在远程存储库中创建新分支。 图 13. 推送更改 有一个保障。仅当推送会导致远程存储库中的远程分支上的快进合并时它才会成功否则会中止。如果情况并非如此则远程分支已经有来自其他存储库或提交者的一些其他更改提交。 Git 中止推送并让一切保持原样。然后您必须获取更改将它们合并到本地分支中然后再次尝试推送。 请注意在这种情况下您可以进行正常合并但也可以选择进行变基合并以将本地分支中的更改变基到远程分支的新的、更新的头。 除了 fetch 和 push 命令之外还有另一种分发补丁的方法旧式通过邮件。为此有一个命令git format-patch start-name它为从给定提交到当前分支状态的每个提交创建一个补丁文件。git am mail files将这些补丁文件应用到当前分支。 注意事项 一个警告如果您尝试推送到一个存储库其中有人实际跟踪分支并在本地对其进行处理。这可能会扰乱分支管理因此 Git 会警告您并告诉您首先将远程分支的状态与pull. 很明显您不应该对远程跟踪分支进行变基。它不再与远程分支匹配因此它不会在push.您已经破坏了存储库结构。 高级 Git 图 14. 多存储库结构示例 通常情况下即使使用 Git也存在星型结构其中有一个中央存储库作为主存储库以及每个用户的本地存储库。但情况并非一定如此。您可以像在 Web 中一样使用交叉连接添加远程存储库连接如图 14 所示。 上面我将变基描述为在原始分支的不同分支或转移点之上重放更改集。 Git 通常按照提交的顺序进行重播。作为一项高级功能git rebase -i您可以实际选择应按何种顺序进行哪些提交即使可以删除提交或可以组合两个提交“压缩”。只需确保不要对已推送的提交执行此操作 - 否则那些基于这些提交进行工作的提交可能会产生很多冲突。 我还编写了如何检查特定分支但您也可以检查任何提交快照。这让 HEAD 指针指向提交而不是分支。这称为分离 HEAD模式。当你在这种情况下做出改变时你就开始了新的发展。基本上您会进行分支但没有为这个新分支指定分支名称。开发的尖端只能通过使用提交 ID 才能到达任何引用名称都无法访问它。您可以使用通常的“”命令从此 HEAD 创建分支git branch branchname。 任何引用都无法访问的提交会发生什么情况好吧如果您不做任何特殊的事情它们就会保存在存储库中。但是您可以托管服务可能实际运行git gcGit 垃圾收集器来删除不必要的文件。任何引用名称都无法访问的提交是不必要的因此将被删除。因此始终在真实分支上工作是一种很好的做法尤其是当在 Git 中创建新分支如此快速且轻松时。 结论 Git 一方面基于简单的原则但它提供的灵活性有时可能令人难以承受。主要要点是 Git 管理快照以及快照之间的更改集。最常见的命令应用并回滚不同分支之间的这些更改集。第二个要点是处理远程分支基本上与处理本地分支相同因为甚至存在远程分支的本地镜像。 至此我已经快速浏览了 Git 的工作原理。这些命令基本上涵盖了我使用 Git 所做的所有操作。所有命令的更多详细信息可以在相应的手册页中找到通过此处提供的知识您希望能够更好地理解它们并使用它们。此外命令本身git status通常会给出下一步该做什么的宝贵提示。 另一个帮助你理解 Git 的好工具是图形化的gitk工具它显示了本地存储库的结构。用于gitk --all显示所有分支和标签等。它还提供了一个简单的界面来在 Git 上发起操作。 Git 通常已经安装在您的 Linux 系统上。您可能必须从包管理器安装开发工具。对于 Windows您可以在Git 主页上下载它。 我希望现在您对 Git 的工作原理有了更好的了解并且不再害怕使用它的灵活性。 感谢我的同事 Witold Szczeponik 对这个主题进行了一些有趣的讨论并审阅了本文他比我更了解 Git。