mirror of
https://github.com/fofolee/uTools-Manuals.git
synced 2025-06-08 23:14:06 +08:00
36 lines
83 KiB
HTML
36 lines
83 KiB
HTML
<div class="c-markdown doc-markdown"><div class="doc-postil"><div class="c-markdown"><h2>名称</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>gitcore-tutorial - 面向开发人员的Git核心教程</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>概要</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>git *</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>描述</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>本教程介绍了如何使用“core”Git命令来设置和使用Git存储库。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果你只需要使用Git作为修订控制系统，你可能更喜欢从“Git教程简介”（gittutorial[7]）或Git用户手册开始。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>但是，如果您想了解Git的内部组件，那么对这些低级工具的理解会很有帮助。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>核心Git通常被称为“plumbing”，其中更漂亮的用户界面称为“porcelain”。您可能不想经常直接使用管道，但可以很好地知道porcelain没有冲洗时plumbing的功能。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>本文最初编写时，很多瓷器命令都是shell脚本。为了简单起见，它仍然用它们作为例子来说明管道是如何配合在一起形成瓷器命令的。源代码树包含一些在contrib/examples/中的脚本以供参考。虽然这些不再作为shell脚本实现，但对管道层命令做什么的描述仍然有效。</p></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>注意</p></div></th><th style="text-align: left;"><div class="table-header"><p>更深入的技术细节通常被标记为Notes，您可以在第一次阅读时跳过。</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><h2>创建一个git仓库</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>创建一个新的Git仓库不是一件容易的事情：所有的Git仓库都是空的，你唯一需要做的就是找到一个你想用作工作树的子目录 - 对于一个全新的项目来说是空的，或者您想要导入到Git中的现有工作树。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>对于我们的第一个例子，我们将从头开始一个全新的存储库，没有预先存在的文件，我们将调用它<code>git-tutorial</code>。首先，为它创建一个子目录，切换到该子目录，并使用以下命令初始化Git基础结构<code>git init</code>：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ mkdir git-tutorial
|
||
|
||
$ cd git-tutorial
|
||
|
||
$ git init</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>Git会回复</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">Initialized empty Git repository in .git/</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>这只是Git说你没有做过任何奇怪事情的方式，并且它会<code>.git</code>为你的新项目创建一个本地目录设置。你现在会有一个<code>.git</code>目录，你可以用它来检查<code>ls</code>。对于您的新空项目，它应该显示三个条目，其中包括：</p></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>一个叫做<code>HEAD</code>的文件，里面有<code>ref: refs/heads/master</code>。这类似于符号链接并指向<code>refs/heads/master</code>相对于该<code>HEAD</code>文件。不要担心<code>HEAD</code>链接指向的文件甚至不存在 - 您尚未创建将启动您的<code>HEAD</code>开发分支的提交。</p></li><li><p>一个名为<code>objects</code>的子目录，其中将包含项目的所有对象。你永远不应该有任何真正的理由直接看对象，但你可能想知道这些对象是什么包含<code>data</code>你的存储库中的所有实体。</p></li><li><p>一个名为<code>refs</code>的子目录，其中包含对对象的引用。</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><p>特别是，<code>refs</code>子目录将包含另外两个子目录，分别命名<code>heads</code>和<code>tags</code>分别。他们完全按照他们的名字暗示：它们包含对任意数量不同<code>heads</code>开发（aka <code>branches</code>）的引用，以及为<code>tags</code>创建存储库中特定版本而创建的任何引用。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>注意：特殊的<code>master</code>头是默认分支，这就是为什么<code>.git/HEAD</code>文件被创建指向它，即使它尚不存在。基本上，这个<code>HEAD</code>链接应该始终指向你现在正在工作的分支，并且你总是开始期待在<code>master</code>分支上工作。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>然而，这仅仅是一个约定，你可以随意命名你的分支什么，不必连过<code>have</code>一个<code>master</code>分支。不过，许多Git工具会认为<code>.git/HEAD</code>是有效的。</p></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>注意</p></div></th><th style="text-align: left;"><div class="table-header"><p>一个对象由其160位SHA-1散列（又名对象名称）标识，而对象的引用始终是该SHA-1名称的40字节十六进制表示。预计refs子目录中的文件将包含这些十六进制引用（通常在最后有一个最后的\n），因此当您实际启动时，您应该期望在这些refs子目录中看到许多包含这些引用的41字节文件填充你的树。</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>注意</p></div></th><th style="text-align: left;"><div class="table-header"><p>完成本教程后，高级用户可能想看看gitrepository-layout5。</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><p>你现在已经创建了你的第一个Git仓库。当然，由于它是空的，这不是很有用，所以让我们开始用数据填充它。</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>填充一个git仓库</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>我们会保持这种简单和愚蠢的，所以我们将开始填充一些简单的文件，以获得它的感觉。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>首先创建你想在你的Git仓库中维护的随机文件。我们将从一些不好的例子开始，以了解它的工作原理：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ echo "Hello World" >hello
|
||
|
||
$ echo "Silly example" >example</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>你现在在你的工作树（又名<code>working directory</code>）中创建了两个文件，但要真正检查你的努力工作，你必须经历两个步骤：</p></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>用有关工作树状态的信息填写<code>index</code>文件（又名<code>cache</code>）。</p></li><li><p>将该索引文件作为对象提交。</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><p>第一步很简单：当你想告诉Git关于工作树的任何修改时，你就可以使用<code>git update-index</code>程序。该程序通常只需要一个你想更新的文件名列表，但为了避免微不足道的错误，它拒绝向索引添加新的条目（或删除现有的条目），除非你明确地告诉它你正在添加一个新的条目<code>--add</code>标志（或移除<code>--remove</code>标志）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>因此，要使用刚刚创建的两个文件填充索引，可以这样做</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git update-index --add hello example</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>你现在已经告诉Git跟踪这两个文件。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>事实上，正如你所做的那样，如果你现在查看你的对象目录，你会注意到Git会在对象数据库中添加两个新对象。如果你完成上述步骤，你现在应该可以做到</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ ls .git/objects/??/*</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>并看两个文件：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">.git/objects/55/7db03de997c86a4a028e1ebd3a1ceb225be238.git/objects/f2/4c74a2e500f5ee1332c86b94199f52b1d1d962</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>它们分别与名称为<code>557db...</code>和的对象相对应<code>f24c7...</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果你愿意，你可以用<code>git cat-file</code>来查看这些对象，但是你必须使用对象名称，而不是对象的文件名：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>当<code>-t</code>告诉<code>git cat-file</code>告诉你对象的“类型”是什么。Git会告诉你，你有一个“blob”对象（即，只是一个普通文件），你可以看到内容</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git cat-file blob 557db03</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>这将打印出“Hello World”。该对象<code>557db03</code>只不过是文件的内容<code>hello</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>注意</p></div></th><th style="text-align: left;"><div class="table-header"><p>不要将该对象与文件hello本身混淆。该对象实际上只是文件的特定内容，不管您稍后更改文件hello中的内容，我们刚刚查看的对象都不会改变。对象是不可变的。</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>注意</p></div></th><th style="text-align: left;"><div class="table-header"><p>第二个例子说明，可以在大部分地方将对象名缩写为仅前几个十六进制数字。</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><p>无论如何，正如我们前面提到的，通常你永远都不会真正看到对象本身，而输入长40个字符的十六进制名称并不是你通常想要做的事情。上面的题目只是为了表明<code>git update-index</code>做了一些神奇的事情，并且实际上将文件的内容保存到了Git对象数据库中。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>更新索引也做了其他事情：它创建了一个<code>.git/index</code>文件。这是描述您当前工作树的索引，以及您应该非常清楚的内容。同样，你通常不会担心索引文件本身，但是你应该知道这样一个事实，即到目前为止你还没有真正“检查”你的文件到Git中，你只是<strong>告诉</strong>Git。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>但是，由于Git知道它们，现在可以开始使用一些最基本的Git命令来操纵文件或查看它们的状态。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>特别是，我们甚至不会将两个文件检入到Git中，然后我们将首先添加另一行<code>hello</code>：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ echo "It's a new day for git" >>hello</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>现在你可以，因为你告诉Git关于以前的状态<code>hello</code>，请问使用下面的<code>git diff-files</code>命令Git树中的变化与旧索引相比：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git diff-files</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>噢不，这不是很可读。它只是说出它自己的内部版本<code>diff</code>，但是这个内部版本实际上只是告诉你，它已经注意到“hello”已被修改，并且它的旧对象内容已被替换为其他东西。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>为了使它可读，我们可以<code>git diff-files</code>通过使用<code>-p</code>标志来告诉输出差异作为补丁：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git diff-files -p
|
||
|
||
diff --git a/hello b/hello
|
||
|
||
index 557db03..263414f 100644--- a/hello+++ b/hello
|
||
|
||
@@ -1 +1,2 @@
|
||
|
||
Hello World+It's a new day for git</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>即我们通过添加另一条线所导致的变化的差异<code>hello</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>换句话说，<code>git diff-files</code>总是向我们显示索引中记录的内容与工作树中当前内容之间的区别。这非常有用。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>一个通用的简写<code>git diff-files -p</code>是只写<code>git diff</code>，它会做同样的事情。</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git diff
|
||
|
||
diff --git a/hello b/hello
|
||
|
||
index 557db03..263414f 100644--- a/hello+++ b/hello
|
||
|
||
@@ -1 +1,2 @@
|
||
|
||
Hello World+It's a new day for git</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><h2>提交git状态</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>现在，我们要进入Git的下一个阶段，即在索引中获取Git知道的文件，并将它们作为真正的树进行提交。我们分两个阶段来完成：创建一个<code>tree</code>对象，并将该<code>tree</code>对象作为<code>commit</code>对象提交，同时解释树的全部内容以及我们如何进入该状态的信息。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>创建一个树对象是微不足道的，并且完成<code>git write-tree</code>。没有选项或其他输入：<code>git write-tree</code>将采用当前索引状态，并编写描述整个索引的对象。换句话说，我们现在将所有不同的文件名与他们的内容（以及他们的权限）结合在一起，我们创建了一个Git“目录”对象的等价物：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git write-tree</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>并且这只会输出结果树的名称，在这种情况下（如果您完全按照我所描述的那样完成）它应该是</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">8988da15d077d4829fc51d8544c097def6644dbb</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>这是另一个难以理解的对象名称。再一次，如果你愿意的话，你可以使用<code>git cat-file -t 8988d...</code>看到这次对象不是一个“blob”对象，而是一个“树”对象（你也可以用它<code>git cat-file</code>来实际输出原始对象的内容，但你会看到主要二进制混乱，所以这不那么有趣）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>但是 - 通常你不会<code>git write-tree</code>自己使用它，因为通常你总是使用该<code>git commit-tree</code>命令将一棵树提交到一个提交对象中。事实上，根本不能实际使用<code>git write-tree</code>它，但只是将其结果作为参数传递给它<code>git commit-tree</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p><code>git commit-tree</code>通常需要几个参数 - 它想知道<code>parent</code>提交的内容是什么，但由于这是该新存储库中的第一次提交，并且没有父母，我们只需要传入树的对象名称。但是，<code>git commit-tree</code>也希望在其标准输入上获得提交消息，并将提交的结果对象名称写入其标准输出。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>这就是我们创建<code>.git/refs/heads/master</code>指向的文件的地方<code>HEAD</code>。这个文件应该包含对主分支树顶端的引用，因为这正是<code>git commit-tree</code>吐出来的东西，所以我们可以用一系列简单的shell命令来完成这一切：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ tree=$(git write-tree)$ commit=$(echo 'Initial commit' | git commit-tree $tree)$ git update-ref HEAD $commit</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>在这种情况下，这会创建一个与其他任何内容都无关的全新提交。通常情况下，你这样做只是<strong>一次</strong>为一个项目永远，其随后所有的提交将在较早提交顶部父。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>再次，通常你永远不会亲自去做这件事。有一个有用的脚本<code>git commit</code>，它会为你做所有这些。所以你可以写下来<code>git commit</code>，而且它会为你完成上面的magic脚本。</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>做出改变</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>请记住我们是如何完成<code>git update-index</code>on文件的<code>hello</code>，然后再进行更改<code>hello</code>，并且可以将新状态<code>hello</code>与我们保存在索引文件中的状态进行比较？</p></div></div><div class="doc-postil"><div class="c-markdown"><p>此外，请记住我是如何<code>git write-tree</code>将<strong>索引</strong>文件的内容写入树中的，因此我们刚刚承诺的实际上是文件的<strong>原始</strong>内容<code>hello</code>，而不是新的内容。我们这样做的目的是为了显示索引状态和工作树中的状态之间的区别，以及它们如何不匹配，即使我们犯了错误。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>和以前一样，如果我们<code>git diff-files -p</code>在我们的git-tutorial项目中做，我们仍然会看到我们上次看到的同样的区别：索引文件并没有因提交任何内容而改变。然而，现在我们已经犯了一些事件，我们也可以学习使用一个新的命令：<code>git diff-index</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>与<code>git diff-files</code>显示索引文件和工作树<code>git diff-index</code>之间的区别不同，显示了提交<strong>树</strong>与索引文件或工作树之间的区别。换句话说，我们<code>git diff-index</code>希望一棵树能够与之相抗衡，而在我们提交之前，我们不能这样做，因为我们没有任何可以相互区分的东西。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>但现在我们可以做到</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git diff-index -p HEAD</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>（这里<code>-p</code>的含义与它的意思相同<code>git diff-files</code>），它会向我们展示同样的差异，但是却出于完全不同的原因。现在我们将工作树与索引文件进行比较，但是对照我们刚刚编写的树。恰恰相反，这两个显然是相同的，所以我们得到了相同的结果。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>再次，因为这是一种常见的操作，您也可以简单地使用</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git diff HEAD</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>最终为你做上述事情。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>换句话说，<code>git diff-index</code>通常将一棵树与工作树进行比较，但是在给定该<code>--cached</code>标志时，会告诉它仅仅比较索引缓存内容，并完全忽略当前工作树状态。由于我们只是将索引文件写入HEAD，<code>git diff-index --cached -p HEAD</code>因此应该返回一组空白的差异，而这正是它所做的。</p></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>注意</p></div></th><th style="text-align: left;"><div class="table-header"><p>因此，git diff-index确实总是使用索引进行比较，并且说它将树与工作树进行比较因此不是严格准确的。特别是，无论是否使用--cached标志，要比较的文件列表（“元数据”）总是来自索引文件。--cached标志只确定要比较的文件内容是否来自工作树。这并不难理解，只要您意识到Git根本就不知道（或关心）文件，而不会明确地告知它。Git永远不会去查找要比较的文件，它希望你告诉它文件是什么，这就是索引的用途。</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><p>但是，我们下一步要承诺我们所做的<strong>改变</strong>，并且再次了解发生了什么，请牢记“工作树内容”，“索引文件”和“承诺树”之间的差异。我们在工作树中进行了更改，我们需要处理索引文件，因此我们需要做的第一件事是更新索引缓存：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git update-index hello</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>（注意<code>--add</code>这次我们不需要这个标志，因为Git已经知道这个文件了）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>注意<code>git diff-*</code>这里的不同版本会发生什么。我们更新后<code>hello</code>的指数，<code>git diff-files -p</code>现在显示无显着差异，但<code>git diff-index -p HEAD</code>仍然<strong>没有</strong>显示当前状态是我们犯下的状态不同。实际上，<code>git diff-index</code>无论我们是否使用该<code>--cached</code>标志，现在都显示出同样的差异，因为现在索引与工作树是一致的。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>现在，由于我们已经更新<code>hello</code>了索引，我们可以提交新版本。我们可以通过再次手工编写树并提交树来完成此操作（这次我们必须使用<code>-p HEAD</code>标志来告诉提交HEAD是新提交的<strong>父代</strong>，并且这不是初始提交任何更多），但你已经完成了，所以我们这次只使用有用的脚本：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git commit</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>它会启动一个编辑器来编写提交消息，并告诉你一些关于你已经完成的事情。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>写下你想要的任何消息，所有<code>#</code>以此开始的行将被删除，其余的将被用作改变的提交消息。如果您决定此时不想提交任何内容（您可以继续编辑内容并更新索引），则可以留下一条空的消息。否则<code>git commit</code>会为你做出改变。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>你现在已经做出了你的第一个真正的Git提交。如果你有兴趣研究<code>git commit</code>真正的功能，请随时调查：这是一些非常简单的shell脚本，用于生成有用的（？）提交消息头文件，以及一些实际执行提交本身的单行程序（<code>git commit</code>） 。</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>检查更改</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>虽然创建更改很有用，但如果以后可以告诉更改了哪些内容，则更有用。对此的最有用的命令是另一个<code>diff</code>家庭，即<code>git diff-tree</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p><code>git diff-tree</code>可以给两棵任意的树，它会告诉你它们之间的区别。也许更普遍的是，你可以给它一个单一的提交对象，它会找出那个提交本身的父对象，并直接显示它们之间的区别。因此，为了获得我们已经多次看到的差异，我们现在可以做</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git diff-tree -p HEAD</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>（再次，<code>-p</code>意味着将差异显示为人类可读的补丁），并且它将显示上次提交（in <code>HEAD</code>）实际上发生了什么变化。</p></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>Note</p></div></th><th style="text-align: left;"><div class="table-header"><p>Here is an ASCII art by Jon Loeliger that illustrates how various diff-* commands compare things. diff-tree +----+ | | | | V V +-----------+ | Object DB | | Backing | | Store | +-----------+ ^ ^ | | | | diff-index --cached | | diff-index | V | +-----------+ | | Index | | | "cache" | | +-----------+ | ^ | | | | diff-files | | V V +-----------+ | Working | | Directory | +-----------+</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><p>更有意思的是，你也可以给<code>git diff-tree</code>这个<code>--pretty</code>标志，告诉它也显示提交信息和作者以及提交日期，你可以告诉它显示一系列的差异。或者，你可以告诉它是“沉默”，并且根本不显示差异，但只显示实际的提交信息。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>实际上，与<code>git rev-list</code>程序（产生修订列表）一起，<code>git diff-tree</code>最终成为变化的真正来源。你可以模仿<code>git log</code>，<code>git log -p</code>等用一个简单的脚本，管道输出<code>git rev-list</code>到<code>git diff-tree --stdin</code>，这是究竟如何早期版本<code>git log</code>中实现。</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>标记一个版本</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>在Git中，有两种标签，一种是“轻”标签，另一种是“带标签的标签”。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>一个“light”标签在技术上只不过是一个分支，除了我们把它放在<code>.git/refs/tags/</code>子目录中而不是调用它<code>head</code>。所以最简单的标签形式仅仅涉及</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git tag my-first-tag</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>它只是把当前<code>HEAD</code>的<code>.git/refs/tags/my-first-tag</code>文件写入文件，然后你可以在这个特定的状态下使用这个符号名称。例如，你可以做</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git diff my-first-tag</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>将当前状态与当前显然是空白区别的标签进行比较，但如果您继续开发和提交内容，则可以使用标签作为“定位点”来查看标记后发生了哪些变化。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>一个“带注释的标签”实际上是一个真正的Git对象，它不仅包含一个指向你想要标记的状态的指针，而且还包含一个小标签名称和消息，还有一个可选的PGP签名，表示是的，你确实是这样做的标签。您可以使用<code>-a</code>或<code>-s</code>标志创建这些带注释的标签<code>git tag</code>：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git tag -s <tagname></code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>这将签署当前<code>HEAD</code>（但您也可以给它另一个参数，指定要标记的东西，例如，您可以使用标记当前<code>mybranch</code>点<code>git tag <tagname> mybranch</code>）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>通常，您只会为主要版本或类似的东西做签名标记，而轻量级标记对于您想要执行的任何标记都很有用 - 无论何时您决定要记住某个特定点，只需为其创建一个专用标记，并且在那个时候你有一个很好的符号名称。</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>复制存储库</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>Git仓库通常是完全自给自足和可重新定位的。例如，与CVS不同，“存储库”和“工作树”没有单独的概念。Git仓库通常<strong>是</strong>工作树，本地Git信息隐藏在<code>.git</code>子目录中。没有别的。你看到的是你得到的。</p></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>注意</p></div></th><th style="text-align: left;"><div class="table-header"><p>您可以告诉Git将Git内部信息从它跟踪的目录中分离出来，但现在我们将忽略它：这不是普通项目的工作方式，而只是用于特殊用途。因此，“Git信息始终与其描述的工作树直接相关”的心智模型在技术上可能不是100％准确的，但它对于所有正常使用来说都是一个很好的模型。</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><p>这有两个含义：</p></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>如果您对创建的教程库感到厌倦（或者您犯了一个错误并想要重新开始），那么您可以执行简单的$ rm -rf git-tutorial</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><p>它会消失。没有外部存储库，并且您创建的项目之外没有任何历史记录。</p></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>如果你想移动或复制一个Git仓库，你可以这样做。有<code>git clone</code>命令，但如果你想要做的只是创建一个你的仓库的副本（附带所有完整的历史记录），你可以用常规的方式来完成<code>cp -a git-tutorial new-git-tutorial</code>。请注意，当您移动或复制Git存储库时，您的Git索引文件（缓存各种信息，特别是所涉及文件的一些“统计”信息）可能需要刷新。所以在你<code>cp -a</code>创建一个新副本之后，你会想要做$ git update-index --refresh</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><p>在新的存储库中确保索引文件是最新的。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>请注意，第二点即使在机器上也是如此。您可以复制一个远程的Git仓库与<strong>任何</strong>常规复制机制，是它<code>scp</code>，<code>rsync</code>或<code>wget</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>在复制远程存储库时，您至少需要更新索引缓存，尤其是在其他人的存储库中，您通常希望确保索引缓存处于某种已知状态（您不需要知道他们做了<strong>什么</strong>，且还没有检查），所以通常你会先于<code>git update-index</code>用</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git read-tree --reset HEAD
|
||
|
||
$ git update-index --refresh</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>这将强制从指向的树中重新构建索引<code>HEAD</code>。它将索引内容重置为<code>HEAD</code>，然后<code>git update-index</code>确保将所有索引条目与检出文件进行匹配。如果原始存储库在其工作树中有未提交的更改，则<code>git update-index --refresh</code>通知它们并告诉您需要更新它们。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>以上内容也可以简单写成</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git reset</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>实际上很多常见的Git命令组合都可以通过<code>git xyz</code>接口编写脚本。您可以通过查看各种git脚本所做的工作来了解情况。例如，<code>git reset</code>用于实现在上述的两行<code>git reset</code>，但像一些<code>git status</code>和<code>git commit</code>稍微围绕基本Git命令更复杂的脚本。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>许多（大多数？）公共远程存储库不会包含任何检出的文件或甚至索引文件，并且<strong>只</strong>包含实际的核心Git文件。这样的存储库通常甚至没有该<code>.git</code>子目录，但直接在存储库中包含所有Git文件。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>要创建自己的“原始”Git存储库的本地活动副本，首先要为项目创建自己的子目录，然后将原始存储库内容复制到<code>.git</code>目录中。例如，要创建自己的Git存储库副本，您需要执行以下操作</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ mkdir my-git
|
||
|
||
$ cd my-git
|
||
|
||
$ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>其次是</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git read-tree HEAD</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>来填充索引。然而，现在你已经填充了索引，并且你拥有所有的Git内部文件，但是你会注意到你实际上没有任何工作树文件可以工作。为了得到这些，你会检查出来</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git checkout-index -u -a</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>其中<code>-u</code>标志意味着你要检出，以保持指数最高最新（这样你就不必事后刷新），<code>-a</code>标志的意思是“签出的所有文件”（如果你有一个陈旧的副本或签出树的旧版本，你可能还需要添加<code>-f</code>第一个标志，告诉<code>git checkout-index</code>来<strong>强制</strong>覆盖任何旧文件）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>再次，这可以全部简化</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git clone git://git.kernel.org/pub/scm/git/git.git/ my-git
|
||
|
||
$ cd my-git
|
||
|
||
$ git checkout</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>这将最终为你做上述所有的事情。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>您现在已经成功复制了其他人的（我的）远程存储库，并将其签出。</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>创建一个新的分支</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>Git中的分支实际上只不过是从<code>.git/refs/</code>子目录中进入Git对象数据库的指针，正如我们已经讨论的那样，<code>HEAD</code>分支只不过是这些对象指针之一的符号链接。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>您可以随时通过在项目历史记录中选择一个任意点来创建一个新分支，然后将该对象的SHA-1名称写入一个文件中<code>.git/refs/heads/</code>。你可以使用你想要的任何文件名（实际上是子目录），但是惯例是调用“普通”分支<code>master</code>。尽管如此，这只是一个惯例，没有什么可以强制它。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>举个例子，让我们回到我们之前使用的git-tutorial存储库，并在其中创建一个分支。你只需说出你想要签出一个新的分支就可以做到这一点：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git checkout -b mybranch</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>将在当前<code>HEAD</code>位置创建一个新的分支，并切换到它。</p></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>注意</p></div></th><th style="text-align: left;"><div class="table-header"><p>如果您决定在历史中的某个其他位置启动新分支，而不是当前的HEAD，那么您可以通过告诉git checkout检出结果的基础来做到这一点。换句话说，如果你有一个更早的标签或分支，你只需要做$ git checkout -b mybranch early-commit，它会在之前的提交中创建新的分支mybranch，然后检查当时的状态。</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><p>你可以随时跳回原来的<code>master</code>分支</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git checkout master</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>（或者任何其他分支名称），如果你忘记了你碰巧在哪个分支上，那么简单</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ cat .git/HEAD</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>会告诉你它指向的地方。要获得您拥有的分支名单，您可以说</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git branch</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>它曾经只是一个简单的脚本而已<code>ls .git/refs/heads</code>。目前分支前面会有一个星号。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>有时您可能希望创建一个新的分支，<code>without</code>实际检查并切换到该分支。如果是这样，只需使用该命令</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git branch <branchname> [startingpoint]</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>这将简单<code>create</code>分支，但不会做任何进一步的事情。然后，你可以稍后 - 一旦你决定要在该分支上进行实际开发，就可以<code>git checkout</code>使用branchname作为参数切换到该分支。</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>合并两个分支</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>拥有一个分支的想法之一是你做了一些（可能是实验性的）工作，并最终将它合并回主分支。因此，假设您创建了<code>mybranch</code>与原始<code>master</code>分支相同的上述内容，那么让我们确保我们在该分支中，并在那里做一些工作。</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git checkout mybranch
|
||
|
||
$ echo "Work, work, work" >>hello
|
||
|
||
$ git commit -m "Some work." -i hello</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>在这里，我们只是添加了另一行<code>hello</code>，并且我们使用了一个简写来完成这两个操作，<code>git update-index hello</code>并<code>git commit</code>通过直接给文件名直接<code>git commit</code>添加一个<code>-i</code>标志（<code>include</code>除了索引文件到目前为止您做了什么之外，它还告诉Git 该文件）提交）。该<code>-m</code>标志是从命令行提供提交日志消息。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>现在，为了让它更有趣一些，让我们假设别人在原始分支中做了一些工作，并通过回到主分支来模拟它，并在那里编辑相同的文件：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git checkout master</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>在这里，花一些时间看看内容<code>hello</code>，注意它们不包含我们刚才所做的工作<code>mybranch</code>- 因为这项工作在<code>master</code>分支中根本没有发生。然后做</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ echo "Play, play, play" >>hello
|
||
|
||
$ echo "Lots of fun" >>example
|
||
|
||
$ git commit -m "Some fun." -i hello example</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>因为主分支显然心情更好。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>现在，你有两个分支，并且你决定要合并完成的工作。在我们这样做之前，让我们介绍一个很酷的图形工具，帮助您查看正在发生的事情：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ gitk --all</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>会以图形方式向你展示你的两个分支（这<code>--all</code>就是说：通常它会向你显示你当前的<code>HEAD</code>）和他们的历史。你也可以看到他们是如何来自一个共同的来源。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>无论如何，让我们退出<code>gitk</code>（<code>^Q</code>或文件菜单），并决定我们要将我们在<code>mybranch</code>分支上所做的工作合并到<code>master</code>分支中（这也是我们的工作<code>HEAD</code>）。要做到这一点，有一个很好的脚本调用<code>git merge</code>，它想知道你想要解决哪些分支以及合并的内容：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git merge -m "Merge work in mybranch" mybranch</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>如果可以自动解析合并，则第一个参数将用作提交消息。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>现在，在这种情况下，我们故意创建了需要手动修正合并的情况，因此，Git会自动完成它的功能（在这种情况下，它只是合并<code>example</code>文件，在<code>mybranch</code>分支中没有差异），并说：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash"> Auto-merging hello CONFLICT (content): Merge conflict in hello
|
||
|
||
Automatic merge failed; fix conflicts and then commit the result.</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>它告诉你它做了一个“自动合并”，由于<code>hello</code>冲突导致失败。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>不用担心。如果你曾经使用过CVS，那么它就会以相同的形式在<code>hello</code>留下（小小的）冲突，所以让我们在我们的编辑器中打开<code>hello</code>（不管怎么说），然后以某种方式修复它。我建议让<code>hello</code>包含所有四行：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">Hello World
|
||
|
||
It's a new day for git
|
||
|
||
Play, play, play
|
||
|
||
Work, work, work</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>一旦你对你的手动合并感到满意，就执行</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git commit -i hello</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>这会非常大声地警告你，你现在正在进行合并（这是正确的，所以不要介意），并且你可以写一个关于你的冒险的小型合并信息<code>git merge</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>完成后，启动<code>gitk --all</code>以图形方式查看历史记录的样子。注意，<code>mybranch</code>仍然存在，你可以切换到它，并继续使用它，如果你想。该<code>mybranch</code>分支不包含合并，但下一次您从<code>master</code>分支中合并它时，Git会知道您如何合并它，因此您不必再次合并。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>另一个有用的工具，特别是如果你不总是在X-Window环境下工作，是<code>git show-branch</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git show-branch --topo-order --more=1 master mybranch* [master] Merge work in mybranch ! [mybranch] Some work.--- [master] Merge work in mybranch*+ [mybranch] Some work.* [master^] Some fun.</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>前两行表示它显示了两个分支，它们的树顶部提交的标题，您当前在<code>master</code>分支上（注意星号<code>*</code>字符），后面的输出行的第一列用于显示<code>master</code>分支中包含的提交以及分支的第二列<code>mybranch</code>。显示了三个提交以及他们的标题。它们都在第一列中有空白字符（<code>*</code>显示当前分支上的普通提交，<code>-</code>是合并提交），这意味着它们现在是<code>master</code>分支的一部分。只有“某些工作”提交<code>+</code>在第二列中具有加号字符，因为<code>mybranch</code>尚未合并到主分支的这些提交中。提交日志消息之前的括号内的字符串是一个短名称，可用于命名提交。在上面的例子中，<code>master</code>并且<code>mybranch</code>是分支头。<code>master^</code>是<code>master</code>分支头的第一位家长。如果您想查看更复杂的案例，请参阅gitrevisions[7]。</p></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>注意</p></div></th><th style="text-align: left;"><div class="table-header"><p>如果没有--more = 1选项，git show-branch将不会输出master ^ commit，因为mybranch提交是master和mybranch提示的共同祖先。有关详细信息，请参阅git-show-branch1。</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>注意</p></div></th><th style="text-align: left;"><div class="table-header"><p>如果合并后主分支上有更多的提交，默认情况下合并提交本身不会由git show-branch显示。在这种情况下，您需要提供--sparse选项以使合并提交可见。</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><p>现在，让我们假装你是一个完成所有工作的人<code>mybranch</code>，并且你辛勤工作的成果最终被合并到<code>master</code>分支中。让我们回到<code>mybranch</code>，并运行<code>git merge</code>以获取“上游变更”回到您的分支。</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git checkout mybranch
|
||
|
||
$ git merge -m "Merge upstream changes." master</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>这会输出这样的内容（实际的提交对象名称会有所不同）</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">Updating from ae3a2da... to a80b4aa....Fast-forward (no commit created; -m option ignored)
|
||
|
||
example | 1 +
|
||
|
||
hello | 1 + 2 files changed, 2 insertions(+)</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>因为你的分支没有包含任何已经合并到<code>master</code>分支中的东西，合并操作实际上并没有进行合并。相反，它只是将分支树的顶部更新为分支树的顶部<code>master</code>。这通常被称为<code>fast-forward</code>合并。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>您可以再次运行<code>gitk --all</code>以查看commit ancestry的外观，或者运行<code>show-branch</code>，这可以告诉您这一点。</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git show-branch master mybranch! [master] Merge work in mybranch * [mybranch] Merge work in mybranch---- [master] Merge work in mybranch</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><h2>合并外部工作</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>通常情况下，与其他人合并比合并你自己的分支要普遍得多，所以值得指出的是，Git也使得它非常简单，事实上，与做一个没有什么不同<code>git merge</code>。事实上，远程合并最终不过是“将工作从远程存储库获取到临时标记中”，然后是一个<code>git merge</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>不出所料，从远程存储库中获取<code>git fetch</code>：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git fetch <remote-repository></code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>可以使用下列其中一个传输命令来从以下位置下载存储库：</p></div></div><div class="doc-postil"><div class="c-markdown"><p>SSH</p></div></div><div class="doc-postil"><div class="c-markdown"><p><code>remote.machine:/path/to/repo.git/</code> or</p></div></div><div class="doc-postil"><div class="c-markdown"><p><code>ssh://remote.machine/path/to/repo.git/</code></p></div></div><div class="doc-postil"><div class="c-markdown"><p>此传输可用于上传和下载，并要求您拥有<code>ssh</code>远程计算机的登录权限。它通过交换两端提交的头部提交并转移（接近）最小的一组对象来找出对方缺乏的对象集合。这是在库之间交换Git对象的最有效方式。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>本地目录</p></div></div><div class="doc-postil"><div class="c-markdown"><p><code>/path/to/repo.git/</code></p></div></div><div class="doc-postil"><div class="c-markdown"><p>此传输与SSH传输相同，但用于<code>sh</code>在本地计算机上运行两端，而不是在远程计算机上运行另一端<code>ssh</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>Git Native</p></div></div><div class="doc-postil"><div class="c-markdown"><p><code>git://remote.machine/path/to/repo.git/</code></p></div></div><div class="doc-postil"><div class="c-markdown"><p>此传输设计用于匿名下载。与SSH传输一样，它可以找到下游端缺少的对象集合，并将其转移（接近）最小的一组对象。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>HTTP(S)</p></div></div><div class="doc-postil"><div class="c-markdown"><p><code>http://remote.machine/path/to/repo.git/</code></p></div></div><div class="doc-postil"><div class="c-markdown"><p>Downloader从http和https URL首先通过查看<code>repo.git/refs/</code>目录下指定的refname从远程站点获取最高的提交对象名称，然后尝试通过<code>repo.git/objects/xx/xxx...</code>使用该提交对象的对象名称进行下载来获取提交对象。然后它读取提交对象以找出其父提交和关联树对象；它会重复这个过程，直到它获得所有必需的对象。由于这种行为，他们有时也被称为<code>commit walkers</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p><code>commit walkers</code>有时也被称为<code>dumb transports</code>，因为它们不需要任何的Git知道智能服务器如Git机传输一样。任何股票甚至不支持目录索引的HTTP服务器就足够了。但是您必须准备好您的存储库<code>git update-server-info</code>来帮助传输下载者。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>一旦你从远程仓库获取，<code>merge</code>当前分支。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>然而 - <code>fetch</code>是一件很常见的事情，然后立即<code>merge</code>就被调用<code>git pull</code>，你可以简单地做</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git pull <remote-repository></code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>并且可选地给远端的分支名称作为第二个参数。</p></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>注意</p></div></th><th style="text-align: left;"><div class="table-header"><p>根本不需要使用任何分支，通过保留尽可能多的本地存储库，因为您希望拥有分支，并使用git pull合并它们，就像在分支之间合并一样。这种方法的优点是，它可以让你为每个分支保存一组文件，并且如果你同时处理多行开发，你可能会发现来回切换更容易。当然，您将支付更多磁盘使用的代价来保存多个工作树，但是现在磁盘空间很便宜。</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><p>您可能会不时从同一个远程存储库中获取数据。简而言之，您可以将远程存储库URL存储在本地存储库的配置文件中，如下所示：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>并使用“linus”关键字<code>git pull</code>而不是完整的URL。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>示例：</p></div></div><div class="doc-postil"><div class="c-markdown"><ol class="ol-level-0 list-paddingleft-2"><li><p><code>git pull linus</code></p></li><li><p><code>git pull linus tag v0.99.1</code></p></li></ol></div></div><div class="doc-postil"><div class="c-markdown"><p>以上相当于：</p></div></div><div class="doc-postil"><div class="c-markdown"><ol class="ol-level-0 list-paddingleft-2"><li><p><code>git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD</code></p></li><li><p><code>git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1</code></p></li></ol></div></div><div class="doc-postil"><div class="c-markdown"><h2>合并如何工作？</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>我们说这个教程展示了什么管道可以帮助你应对不冲水的瓷器，但我们迄今没有谈到合并的真正效果。如果您是第一次使用本教程，我会建议跳至“发布您的作品”部分，稍后再回来。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>好，还跟得上吗？为了让我们看一个示例，让我们回到先前的存储库，带有“hello”和“example”文件，并让我们回到预合并状态：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git show-branch --more=2 master mybranch! [master] Merge work in mybranch * [mybranch] Merge work in mybranch---- [master] Merge work in mybranch+* [master^2] Some work.+* [master^] Some fun.</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>请记住，在运行<code>git merge</code>之前，我们的<code>master</code>head在“享受些乐趣”。承诺，而我们的<code>mybranch</code>head在“做些工作”。commit.</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git checkout mybranch
|
||
|
||
$ git reset --hard master^2$ git checkout master
|
||
|
||
$ git reset --hard master^</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>倒回后，提交结构应如下所示：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git show-branch* [master] Some fun. ! [mybranch] Some work.--* [master] Some fun. + [mybranch] Some work.*+ [master^] Initial commit</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>现在我们已经准备好尝试手动合并了。</p></div></div><div class="doc-postil"><div class="c-markdown"><p><code>git merge</code>命令，当合并两个分支时，使用3-way合并算法。首先，它找到它们之间的共同祖先。它使用的命令是<code>git merge-base</code>：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ mb=$(git merge-base HEAD mybranch)</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>该命令将公共祖先的提交对象名称写入标准输出，因此我们将其输出捕获到一个变量中，因为我们将在下一步中使用它。顺便说一下，在这种情况下，共同的祖先提交是“初始提交”提交。你可以告诉它：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git name-rev --name-only --tags $mb
|
||
|
||
my-first-tag</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>找到一个共同的祖先提交后，第二步是这样的：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git read-tree -m -u $mb HEAD mybranch</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>这与<code>git read-tree</code>我们已经看到的命令是一样的，但是与以前的例子不同，它需要三棵树。这将每棵树的内容读入<code>stage</code>索引文件中的不同内容（第一棵树进入第一阶段，第二棵树进入第二阶段，等等）。在将三棵树读入三个阶段之后，所有三个阶段中相同的路径都<code>collapsed</code>进入阶段0.在三个阶段中的两个阶段中相同的路径折叠到阶段0，从阶段2获取SHA-1或者阶段3，与第一阶段不同（即只有一侧从共同祖先改变）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p><code>collapsing</code>操作之后，三棵树中不同的路径将保留在非零阶段。此时，您可以使用以下命令检查索引文件：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git ls-files --stage100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>在我们仅有两个文件的示例中，我们没有没有更改的文件，因此只能<code>example</code>导致崩溃。但是在现实生活中的大型项目中，当一次提交中只有少量文件发生变化时，这<code>collapsing</code>往往会使相当快速的大部分路径轻松合并，从而在非零阶段只发生少量实际变化。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>要仅查看非零阶段，请使用<code>--unmerged</code>标志：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git ls-files --unmerged100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>合并的下一步是合并这三个版本的文件，使用3-way合并。这是通过将<code>git merge-one-file</code>命令作为命令的参数之一来完成的<code>git merge-index</code>：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git merge-index git-merge-one-file hello
|
||
|
||
Auto-merging hello
|
||
|
||
ERROR: Merge conflict in hello
|
||
|
||
fatal: merge program failed</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p><code>git merge-one-file</code>用参数调用脚本来描述这三个版本，并负责将合并结果留在工作树中。这是一个相当简单的shell脚本，最终调用<code>merge</code>RCS套件中的程序执行文件级3路合并。在这种情况下，<code>merge</code>检测到冲突，并将带有冲突标记的合并结果留在工作树中。如果<code>ls-files --stage</code>在此时再次运行，可以看到这一点：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git ls-files --stage100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>这是索引文件的状态，并且工作文件<code>git merge</code>将控制权返回给您，并将冲突合并留给您解决。请注意，路径<code>hello</code>尚未被合并，此时您看到的<code>git diff</code>是自第2阶段（即您的版本）以来的差异。</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>发布你的作品</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>所以，我们可以使用别人的作品从远程仓库，但<strong>你</strong>如何能准备一个资料库，让其他人撤出？</p></div></div><div class="doc-postil"><div class="c-markdown"><p>您在工作树中执行真正的工作，并将主存储库挂在其<code>.git</code>子目录下。您<strong>可以</strong>远程访问该存储库，并要求人们从中获取信息，但实际上这并不是通常的做法。推荐的方法是拥有一个公共存储库，让其他人可以访问该存储库，并且当您在主工作树中所做的更改状态良好时，请从中更新公共存储库。这通常被称为<code>pushing</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>注意</p></div></th><th style="text-align: left;"><div class="table-header"><p>这个公共存储库可以进一步被镜像，这就是kernel.org上的Git存储库的管理方式。</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><p>将本地（专用）存储库中的更改发布到远程（公用）存储库需要在远程计算机上具有写权限。您需要有一个SSH帐户才能运行单个命令，<code>git-receive-pack</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>首先，您需要在将存放公共存储库的远程机器上创建一个空的存储库。这个空的存储库将被填充并随后推入，以保持最新状态。显然，这个存储库的创建只需要完成一次。</p></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>注意</p></div></th><th style="text-align: left;"><div class="table-header"><p>git push使用一对命令，本地机器上的git send-pack和远程机器上的git-receive-pack。两者之间的通信通过网络在内部使用SSH连接。</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><p>您的私有存储库的Git目录通常是<code>.git</code>，但您的公共存储库通常以项目名称命名，即<code><project>.git</code>。让我们为项目创建一个这样的公共存储库<code>my-git</code>。登录到远程机器后，创建一个空目录：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ mkdir my-git.git</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>然后，通过运行将该目录设置为Git存储库<code>git init</code>，但这次由于其名称<code>.git</code>并不常见，所以我们的做法略有不同：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ GIT_DIR=my-git.git git init</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>确保此目录可用于您希望通过您选择的交通工具提取您的更改的其他人。你也需要确保你在<code>$PATH</code>有这个<code>git-receive-pack</code>程序。</p></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>注意</p></div></th><th style="text-align: left;"><div class="table-header"><p>当你直接运行程序时，许多sshd安装不会将你的shell作为登录shell调用; 这意味着如果您的登录shell是bash，则只读取.bashrc而不是.bash_profile。作为一种解决方法，确保.bashrc设置$ PATH，以便您可以运行git-receive-pack程序。</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>注意</p></div></th><th style="text-align: left;"><div class="table-header"><p>如果你打算发布这个通过http访问的仓库，你应该在这个时候执行mv my-git.git/hooks/post-update.sample my-git.git/hooks/post-update。这可以确保每次你进入这个仓库时，都会运行git update-server-info。</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><p>您的“公共存储库”现在已准备好接受您的更改。回到你有你的私人存储库的机器。从那里运行这个命令：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git push <public-host>:/path/to/my-git.git master</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>这会使您的公共存储库与<code>master</code>您的当前存储库中与指定的分支头（即本例中）和它们可访问的对象相匹配。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>作为一个真实的例子，这是我更新公共Git存储库的方式。Kernel.org镜像网络负责传播给其他公开可见的机器：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git push master.kernel.org:/pub/scm/git/git.git/</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><h2>打包你的仓库</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>之前，我们看到<code>.git/objects/??/</code>为目录创建的每个Git对象都存储目录下的一个文件。这种表示对于原子级和安全地创建是有效的，但在网络上传输并不方便。由于Git对象一旦创建就不可变，因此可以通过“将它们组合在一起”来优化存储。命令</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git repack</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>会为你完成。如果你按照教程的例子，你现在已经在<code>.git/objects/??/</code>目录中累积了约17个对象。<code>git repack</code>告诉您打包了多少个对象，并将打包文件存储在<code>.git/objects/pack</code>目录中。</p></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>注意</p></div></th><th style="text-align: left;"><div class="table-header"><p>您将在.git/objects/pack目录中看到两个文件，即pack - *。pack和pack - *。idx。它们彼此密切相关，如果您出于任何原因手动将它们复制到不同的存储库，则应确保将它们复制在一起。前者保存包中对象的所有数据，后者保存随机访问的索引。</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><p>如果你偏执，运行<code>git verify-pack</code>命令会检测你是否有腐败的包装，但不要太担心。我们的项目总是完美的;-)。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>一旦你打包了对象，你就不需要保留包文件中包含的解压对象了。</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git prune-packed</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>会为你删除它们。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果您好奇，您可以在跑步<code>find .git/objects -type f</code>前后尝试跑步<code>git prune-packed</code>。此外<code>git count-objects</code>还会告诉您存储库中有多少个未打包对象以及它们占用了多少空间。</p></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>注意</p></div></th><th style="text-align: left;"><div class="table-header"><p>对于HTTP传输来说，git pull稍微麻烦，因为打包的存储库可能包含相对较少包中的相对较少的对象。如果你期望从你的公共仓库获取很多HTTP请求，你可能需要经常重新打包和修剪，或者永远不要修剪。</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><p>如果此时再次运行<code>git repack</code>，则会显示“没有新包装”。一旦继续开发并累积更改，<code>git repack</code>再次运行将创建一个新包，其中包含自上次打包存储库后创建的对象。我们建议您在初次导入后尽快打包项目（除非您从头开始项目），然后<code>git repack</code>每隔一段时间运行一次，具体取决于项目的活跃程度。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>当一个储存库是通过同步<code>git push</code>和<code>git pull</code>填充在源存储库对象通常存储在目的地解压。虽然这允许您在两端使用不同的打包策略，但这也意味着您可能需要每隔一段时间重新打包两个存储库。</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>与他人合作</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>尽管Git是一个真正的分布式系统，但通过非正式的开发人员层次来组织项目通常很方便。Linux内核开发就是这样运行的。在Randy Dunlap的演讲中有一个很好的例子（第17页，“合并到Mainline”）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>应该强调的是，这个层次纯粹是<strong>非正式的</strong>。在Git中没有任何基础强制执行这个层次结构所暗示的“补丁流程链”。您不必仅从一个远程存储库中获取数据。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>“项目领导”的推荐工作流程如下所示：</p></div></div><div class="doc-postil"><div class="c-markdown"><ol class="ol-level-0 list-paddingleft-2"><li><p>在本地计算机上准备主要存储库。你的工作在那里完成。</p></li><li><p>准备一个可供他人访问的公共存储库。如果其他人通过哑传输协议（HTTP）从您的存储库中提取数据，则需要保留此存储库<code>dumb transport friendly</code>。之后<code>git init</code>，<code>$GIT_DIR/hooks/post-update.sample</code>从标准模板复制将包含呼叫，<code>git update-server-info</code>但您需要手动启用挂钩<code>mv post-update.sample post-update</code>。这确保<code>git update-server-info</code>了必要的文件保持最新。</p></li><li><p>从主存储库推入公共存储库。</p></li><li><p><code>git repack</code>公共存储库。这会建立一个包含初始对象集合作为基准的大包，并且可能<code>git prune</code>用于从存储库中提取的传输支持打包存储库。</p></li><li><p>继续在主存储库中工作。您的更改包括修改您自己的修改，通过电子邮件收到的修补程序以及从您的“子系统维护者”的“公共”存储库中拉取合并。只要你愿意，你可以重新包装这个私人存储库。</p></li><li><p>将更改推送到公共存储库，并向公众发布。</p></li><li><p>每过一段时间，<code>git repack</code>公共存储库。返回步骤5.继续工作。</p></li></ol></div></div><div class="doc-postil"><div class="c-markdown"><p>为该项目工作并拥有自己的“公共存储库”的“子系统维护人员”推荐的工作周期如下所示：</p></div></div><div class="doc-postil"><div class="c-markdown"><ol class="ol-level-0 list-paddingleft-2"><li><p>通过<code>git clone</code>在“项目负责人”的公共存储库上运行，准备工作存储库。用于初始克隆的URL存储在remote.origin.url配置变量中。</p></li><li><p>准备一个可供他人访问的公共存储库，就像“项目负责人”一样。</p></li><li><p>将“项目负责人”公共存储库中的打包文件复制到公共存储库，除非“项目负责人”存储库与您的计算机位于同一台计算机上。在后一种情况下，您可以使用<code>objects/info/alternates</code>文件指向您从中借用的存储库。</p></li><li><p>从主存储库推入公共存储库。运行<code>git repack</code>，并且可能<code>git prune</code>用于从存储库中提取的传输支持打包的存储库。</p></li><li><p>继续在主存储库中工作。您的更改包括修改您自己的修改，通过电子邮件收到的修补程序，以及拉动“项目负责人”的“公共”存储库和可能的“子子系统维护人员”所产生的合并。只要你愿意，你可以重新包装这个私人存储库。</p></li><li><p>将更改推送到公共存储库，并请求您的“项目负责人”和可能的“子子系统维护人员”从中抽取。</p></li><li><p>每过一段时间，<code>git repack</code>公共存储库。返回步骤5.继续工作。</p></li></ol></div></div><div class="doc-postil"><div class="c-markdown"><p>没有“公共”存储库的“个人开发人员”的建议工作周期稍有不同。它是这样的：</p></div></div><div class="doc-postil"><div class="c-markdown"><ol class="ol-level-0 list-paddingleft-2"><li><p>通过<code>git clone</code>“项目负责人”（或“子系统维护人员”，如果您在子系统上工作）的公共存储库准备工作存储库。用于初始克隆的URL存储在remote.origin.url配置变量中。</p></li><li><p>在<code>master</code>分支机构的仓库中工作。</p></li><li><p><code>git fetch origin</code>每隔一段时间从上游的公共存储库运行。这只有前半部分，<code>git pull</code>但不合并。公共存储库的头部存储在<code>.git/refs/remotes/origin/master</code>。</p></li><li><p>使用<code>git cherry origin</code>查看哪些补丁那些被接受，和/或使用<code>git rebase origin</code>端口的未合并的变化着更新的上游。</p></li><li><p>使用<code>git format-patch origin</code>准备用于电子邮件提交补丁，你的上游，并发送出去。返回第2步并继续。</p></li></ol></div></div><div class="doc-postil"><div class="c-markdown"><h2>与他人合作，共享存储库风格</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>如果您来自CVS背景，上一节中提出的合作风格对您来说可能是新的。你不必担心。Git支持您可能更熟悉的“共享公共存储库”合作风格。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>有关详细信息，请参阅gitcvs-migration[7]。</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>将你的工作捆绑在一起</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>您可能一次只能处理一件以上的事情。使用Git分支来管理那些或多或少的独立任务是很容易的。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>我们已经看到了分支机构以前的工作方式，以两个分支机构的“乐趣和工作”为例。如果有两个以上的分支，这个想法是一样的。假设你从“主”头开始，并在“主”分支中有一些新代码，并在“提交 - 修复”和“差异修复”分支中有两个独立修复：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git show-branch! [commit-fix] Fix commit message normalization. ! [diff-fix] Fix rename detection. * [master] Release candidate #1--- + [diff-fix] Fix rename detection. + [diff-fix~1] Better common substring algorithm.+ [commit-fix] Fix commit message normalization. * [master] Release candidate #1++* [diff-fix~2] Pretty-print messages.</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>这两个修补程序都经过了很好的测试，在这一点上，您想要在它们两个中进行合并。你可以先合并<code>diff-fix</code>然后再合并<code>commit-fix</code>，如下所示：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git merge -m "Merge fix in diff-fix" diff-fix
|
||
|
||
$ git merge -m "Merge fix in commit-fix" commit-fix</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>这将导致：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git show-branch! [commit-fix] Fix commit message normalization. ! [diff-fix] Fix rename detection. * [master] Merge fix in commit-fix--- - [master] Merge fix in commit-fix+ * [commit-fix] Fix commit message normalization. - [master~1] Merge fix in diff-fix +* [diff-fix] Fix rename detection. +* [diff-fix~1] Better common substring algorithm. * [master~2] Release candidate #1++* [master~3] Pretty-print messages.</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>但是，没有什么特别的理由要先合并一个分支，然后再合并，当你有一系列真正独立的变化时（如果顺序重要，那么它们就不是定义上的独立）。您可以将这两个分支同时合并到当前分支中。首先让我们撤销我们刚刚做的并重新开始。我们希望在这两次合并之前将主分支重置为<code>master~2</code>：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git reset --hard master~2</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>你可以确保<code>git show-branch</code>在<code>git merge</code>你刚刚做的那两个之前匹配状态。然后，不是连续运行两个<code>git merge</code>命令，而是合并这两个分支头（这被称为<code>making an Octopus</code>）：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre><code class="language-Bash">$ git merge commit-fix diff-fix
|
||
|
||
$ git show-branch! [commit-fix] Fix commit message normalization. ! [diff-fix] Fix rename detection. * [master] Octopus merge of branches 'diff-fix' and 'commit-fix'--- - [master] Octopus merge of branches 'diff-fix' and 'commit-fix'+ * [commit-fix] Fix commit message normalization. +* [diff-fix] Fix rename detection. +* [diff-fix~1] Better common substring algorithm. * [master~1] Release candidate #1++* [master~2] Pretty-print messages.</code></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>请注意，你不应该因为你可以做Octopus。如果要同时合并两个以上的独立更改，章鱼是一件有效的事情，并且通常可以更容易地查看提交历史记录。但是，如果您与正在合并且需要手工解决的任何分支合并冲突，则表示发生在这些分支中的发展毕竟不是独立的，并且您应该一次合并两个分支，记录如何你解决了冲突，以及你偏好一方的变化。否则，它会使项目的历史难以跟上，并不容易。</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>也可以看看</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>gittutorial[7], gittutorial-2[7], gitcvs-migration[7], git-help[1], giteveryday[7], The Git User’s Manual</p></div></div></div> |