use*_*932 1 versioning git github git-checkout gitlab
根据我对 git 的理解,每次执行时都会git checkout发生以下两种情况之一:
但是,有几次我git checkout对远程分支(本地从未存在过)执行 a 操作,并且得到了过时的内容。然后我执行 agit pull并收到新的提交。
有人也遇到过这个问题吗?你知道为什么会发生这种情况吗?
tor*_*rek 11
您可以避免使用git pull(完全或只是有时,这取决于您)。有时您确实需要运行git fetch,有时还需要运行一些其他命令。
将这一切牢记在心的方法本身有点复杂,但可以从以下开始:
\n\norigin。(甚至可以超过两个,但从两个开始,如果添加更多,它只会变得更加毛茸茸!)origin。此名称存储其他 Git 存储库的 URL。origin)几乎总是此处的方法。除此之外,这意味着您只需输入一次长 URL。如果您运行git config -l(列出所有配置),或者git config --get-regex "remote\\..*"您应该看到至少两个条目:
remote.origin.url <some url>\nremote.origin.fetch +refs/heads/*:refs/remotes/*\nRun Code Online (Sandbox Code Playgroud)\n\n第一个是保存的 URL。第二个是git fetch命令的一些指令。
由于这里涉及两个 Git 存储库,因此您必须不时地将它们相互连接。有两个主要的 Git 命令可用于执行此操作,git fetch以及git pull. 两者都指示你的Git 调用另一个 Git,所以区别在于传输方向:
git fetch让你的 Git 调用他们的 Git 并获取东西;git push让你的 Git 调用他们的 Git 并提供东西。你在这里给予或接受的是承诺。虽然提交保存文件(通过保存完整的快照),但提交本身并不是文件,因此将其视为推送或获取文件是错误的。它总是完整的提交。
\n\n但有一个巨大的问题:在 Git 中,提交必须是可找到的。
\n\n让我们画一个只有三个提交的小型存储库。提交有大而难看的哈希 ID,它们看起来是随机的(尽管它们不是);让我们使用单个大写字母,而不是发明一些字母。这将我们的伪存储库限制为仅 26 个 ASCII 提交(例如,尽管我们可以用挪威语将提交命名为 \xc3\x98,以获得更多),但它要方便得多。
\n\n提交将其父提交的哈希 ID 存储在其中,以便提交指向其父提交:
\n\nA <-B <-C\nRun Code Online (Sandbox Code Playgroud)\n\nCB是我们最近的提交,它记录了其父级的 事实。B记录A是B\ 的父级。因为A这是我们的第一次提交,所以它没有父提交( Git 术语中的根提交),我们就到此为止。但我们如何找到呢C?答案是我们使用分支名称,例如master:
A <-B <-C <--master\nRun Code Online (Sandbox Code Playgroud)\n\n为了向我们的存储库添加新的提交,我们在简化的绘图中计算其哈希 ID\xe2\x80\x94,这只是D\xe2\x80\x94 并将其写出来,将其父级设置为当前提交C。然后我们更改master ,使其指向D而不是C:
A--B--C--D <-- master\nRun Code Online (Sandbox Code Playgroud)\n\n我们从不更改任何现有的提交,并且我们实际上不需要记录它们的箭头方向:它们总是指向向后。但我们确实一直在改变分支名称,所以我们应该记下它们的箭头,因为它们会移动。
\n\n因此 Git 是向后工作的。它始终包含有关最新提交的信息。它使用这些来查找较旧的提交。Git 将名称附加HEAD到其中一个分支,以便它知道您所在的分支。当您运行时git checkout,它所做的一件事就是附加HEAD到您签出的任何分支。我将在下面开始介绍这一点。
让我们回到这里涉及到的两个 Git 存储库这一事实。其中之一就是你的。您有自己的分支名称,master例如develop和feature/short等等feature/tall。但是 at 上还有另一个 Git 存储库origin,它有自己的分支名称。
当你的 Git 调用他们的 Git 并获取他们的提交时,他们的 Git 一直在通过他们的分支名称查找他们的提交。如果他们master和你master不同意他们应该指向哪个提交怎么办?例如,您已经添加D,而他们还没有添加D,因此它们 master仍然指向。C
你的 Git通过重命名来记录它们的分支指针。你还记得他们的:origin/mastermaster
D <-- master (HEAD)\n /\nA--B--C <-- origin/master\nRun Code Online (Sandbox Code Playgroud)\n\n如果自您上次同步以来他们添加了新的提交,则该提交具有不同的(且唯一的)哈希 ID。master我们称之为E:
D <-- master (HEAD)\n /\nA--B--C\n \\\n E <-- origin/master\nRun Code Online (Sandbox Code Playgroud)\n\ngit checkout如果合适的话将创建一个分支假设您的存储库中有一些提交系列,以及一些名称:
\n\n D <-- master (HEAD)\n /\nA--B--C <-- origin/master, origin/dev\nRun Code Online (Sandbox Code Playgroud)\n\n如果您现在说git checkout dev,好吧,您没有. dev但你确实有origin/dev,指向承诺C。你的 Git 会注意到这一点并自动创建你的devnow:
D <-- master\n /\nA--B--C <-- dev (HEAD), origin/master, origin/dev\nRun Code Online (Sandbox Code Playgroud)\n\n请注意分支名称是新的,即使提交不是新的。该名称HEAD现已附加到新的分支名称中。
如果您git checkout master再次,您的dev继续存在,指向C:
D <-- master (HEAD)\n /\nA--B--C <-- dev, origin/master, origin/feature\nRun Code Online (Sandbox Code Playgroud)\n\n唯一发生的事情是你HEAD附加到现有的master(当然 Git 也会检查提交D)。
如果你现在git fetch再次origin,他们已经添加了E对 他们master和F他们 的提交dev,并E指向C和F指向E,你会得到:
D <-- master (HEAD)\n /\nA--B--C <-- dev\n \\\n E <-- origin/master\n \\\n F <-- origin/dev\nRun Code Online (Sandbox Code Playgroud)\n\n当您运行时git fetch,您的 Git 会调用他们的 Git,列出他们所有的分支名称和提交哈希值,然后您的 Git 从他们的 Git 中获取他们拥有但您没有的任何提交。您的 Git 将这些添加到您的存储库并更新您的远程跟踪名称。
当您第一次使用git clone他们的存储库时,git clone会创建一个新的空存储库(例如git init),什么都没有,甚至还没有master分支。您使用 URL 和默认线路git clone设置遥控器。然后你的 Git 调用他们的 Git ( ),询问他们的分支名称,询问他们有你没有的提交\xe2\x80\x94,当然这是每个提交,\xe2\x80\x94 并把所有仅使用远程跟踪名称将这些提交到您的空存储库中:originfetchgit fetch
A--B--C <-- origin/master\nRun Code Online (Sandbox Code Playgroud)\n\n作为最后一步,git clone实际上运行git checkout master. 这将创建您的master,也指向 commit C。
稍后每次git fetch更新您的所有远程跟踪名称\xe2\x80\x94您的origin/*名称\xe2\x80\x94,同时获取(共享)提交。因此,您的远程跟踪名称会记住它们的分支名称,而您自己的现有分支名称则保持不变。
因此,如果您git fetch在运行git checkout将创建新分支名称之前,您的新分支名称将从更新的远程跟踪名称创建。如果您太早命名,您将根据旧值 xe2x80x94(您已有的提交的旧哈希 ID)git checkout创建它。
git pull、 或git merge、 或git rebase该git pull命令只为您运行两个命令:
git fetch,它执行上述所有操作:它获取任何新的提交并更新您的远程跟踪名称,但永远不会影响您的分支。通常您运行是git fetch因为您希望从其他 Git 存储库获取新内容。如果你确实得到了新东西,你可能想用它做点什么。这意味着对您的分支机构进行一些操作。
主要有两种方法可以将您已完成和承诺的任何工作与其他人已完成和承诺的工作合并。这些是git merge和git rebase。git fetch因此,在之后,您想要使用这两个命令之一是非常典型的。
您应该使用哪一个?嗯,这是一个见仁见智的问题,对此有不同的思想流派。我喜欢根据我做了多少工作、他们做了多少工作以及这些工作之间的关系来选择使用哪一个。为此,我必须看看他们所做的工作。
\n\n使用git pull,您必须在有机会查看之前提前决定是合并还是变基。所以我回避 git pull。我跑步git fetch,然后看看,然后决定做什么。如果你使用 ,你就不能这样做git pull:你必须先弄清楚要做什么,合并或变基,然后才能看到你想要哪一个。有时你可能只是知道,在这种情况下,git pull没关系!
无论如何,如果您正在使用git pull,您可以告诉 Git 做什么:合并(默认)或--rebase变基。然后它会git fetch为您运行,并为您运行第二个命令\xe2\x80\x94git merge或git rebase\xe2\x80\x94。这就是它真正所做的一切!1 了解如何操作git merge和git rebase工作是一个好主意,我认为如果您手动运行它们,而不是为您运行它们,您会学得更快git pull,但您现在拥有制作您的应用程序所需的所有部分。自己的决定在这里。
1好吧,如果有子模块,你可以让它递归地拉入子模块。但这完全是另一回事。
\n| 归档时间: |
|
| 查看次数: |
8417 次 |
| 最近记录: |