Git:难以获取现有的Git存储库以跟踪新的裸远程存储库

问题描述 投票:1回答:1

摘要:我很难让现有的本地存储库来跟踪新的裸远程存储库。

我尝试过的事情:我尝试在设置上游跟踪时将本地存储库推送到新的裸存储库。 Git告诉我正在进行上游跟踪,但是即使在获取远程存储库之后,我仍然看不到本地存储库日志中的分支被跟踪。

我还尝试了从本地存储库创建裸克隆,希望它的工作方式类似于克隆另一个自动设置跟踪的本地存储库,但是我仍然看不到本地跟踪的迹象。回购日志。

请求:任何人都可以看一下下面的背景信息,并指导我可能要去哪里了,或者对如何获取现有存储库以跟踪新的裸机远程存储库有不正确的理解吗?谢谢,我已经尽力研究了。

背景我在一个小团队中担任制造工程师。我们想为团队使用中央共享的远程Git存储库来设置工作流程。我一直在尝试建立一个演示如何运行的演示,下面的“ centralRepo.git”目录是我们的中央存储库,让其他文件夹的团队成员可以将中央远程服务器克隆到该文件夹​​。

由于我们已经有现成的工作,但是没有现有的中央远程仓库,所以我们将从“ davesClones”中的现有仓库开始,将其推送到中央远程仓库,然后根据需要克隆到其他团队成员文件夹,例如“ stevesClones”。

Folder Example

我希望看到跟踪是否正常:如果我克隆常规的本地存储库,则会自动设置跟踪,并且日志会向我显示我的克隆自身的分支,以及正在从其克隆目录中跟踪的“ origin”分支,如下面的屏幕快照所示(蓝色) :

Expected tracking outcome

尝试#1:按w /-Set-Upstream:

我尝试使用以下方法将现有的本地存储库推送到新的中央远程存储库如下所示,git push --set-upstream <remote> master,尽管输出似乎表明已设置跟踪,但即使使用fetch之后,我也看不到克隆常规回购协议时在git日志中发生的任何跟踪。下面的示例显示在尝试上述步骤后,我如何在日志中缺少起点跟踪分支:

--set-upstream didn't work

尝试#2:克隆-bare:

我还尝试将现有的存储库克隆到一个新的裸存储库,希望它会自动建立跟踪,但是如下所示,即使在获取后,日志似乎也没有显示任何跟踪发生:

Cloning daveClones to bare repo attempt

Fetching did not help

知道为什么我的日志中没有跟踪记录吗? (指的是克隆标准本地存储库后的状态,我看到了一个跟踪[来源/主设备,原始记录头,但是当使用push --set-upstream将本地存储库推送到远程时,或者使用git clone --bare可以将本地存储库克隆到裸露的远程服务器吗?]

此外,本地存储库中确实有提交,因此在推送或克隆到远程服务器时,它不是空的。

谢谢!

git git-push bare remotes
1个回答
1
投票

TL; DR

您需要通过在自己的Git存储库中设置remote来开始整个过程​​:

git remote add <name> <URL-or-path>

之后,您必须使用您使用的name部分,而不是键入(可能更长)URL或路径。也就是说,您将执行以下操作:

git remote add origin /d/Seafile/...
git push --set-upstream origin master

让我开始说,我真的不喜欢tracking这个词,因为它误导了所有人。它也对您做到了。

我们必须使用git remote创建或以其他方式操纵远程。遥控器只是一个短名称(例如origin,它是遥控器要使用的标准名字的一种),它将存储一个URL(以及其他一些更内部的Git信息)。 >

我正在从您的屏幕截图中重新键入,因此我可能会介绍错别字,但关键在此处:

git push --set-upstream /d/Seafile/Development/gitTest/centralRepo.git master

让我们快速绕过Git文档。 git push的语法在the SYNOPSIS lines of the documentation中描述为(缩写):

git push [options] [repository [refspec...]]

[这里,您的唯一选项是--set-upstream(单独使用就可以了),并且您的存储库以路径名/d/Seafile/...给出。如果您跳到“选项”部分,则存储库参数的描述将非常简单,如下所示:

<repository>

作为推送操作目标的“远程”存储库。此参数可以是URL ...或远程名称....

不幸的是,这里省略了--set-upstream以及所需的跟踪类型,仅在给定的参数是远程参数时有效

/d/Seafile/...之类的路径名-您的Git在内部将其翻译为D:/Seafile/...,如您在其他输出中看到的那样-算作URL,而不是“远程”。

远程和远程跟踪名称

而不是说分支名称tracks其他名称,我喜欢使用短语has作为上游。不幸的是,该短语有点尴尬(因此Git将track用作动词)。任何分支名称都可以完全没有上游,也可以没有一个上游。当分支does具有上游时,可以是:

  • 另一个分支名称,例如develop可能以master作为其上游,或
  • 一个远程跟踪名称
  • ,例如origin/master

    我叫origin/master之类的名称远程跟踪名称

(Git文档主要称这些远程跟踪分支名称))。它们通过将remote的名称(例如origin)与分支名称串在一起而存在:当您的Git打电话给另一个Git时,您的Git与之交谈的Git中的分支名称。使用存储在该“远程”下的URL进行Git。

[当您使用git fetchgit push时,您的Git手机已安装了另一个Git。有两个Git。每个Git都有其自己的

分支。您的Git有分支,而Git有分支。您的Git愿意为您记住their名称,作为一项服务...但是,为了让您的Git记住其分支名称,您的Git必须为每个名称都提供一个名称,且该名称不会干扰您自己的分支名称。您的Git通过在分支名称之前粘贴一些内容来实现此目的。1

此处粘贴在前面的部分是remote

名称,例如origin。如果没有远程服务器(而是URL),则无需粘贴在前面,因此永远不会粘贴在前面。 --set-upstream选项不起作用。

所以,为什么您的Git打印:

Branch 'master' set up to track remote branch 'master' from 'D:/Seafile/Development/gitTest/centrapRepo.git'.

?唯一可能的答案是,Git非常的Gitty。它只是说它做了它在物理上[[做不到

做的事情,因此没有做过。

1

从技术上讲,远程跟踪名称位于单独的namespace:分支名称中,具有以refs/heads/开头的全拼写名称,因此master实际上是refs/heads/master。远程跟踪名称以refs/remotes/开头,并继续包含远程名称和另一个斜杠。名称的其余部分是在该遥控器上URL上看到的精简分支名称。因此,他们的refs/heads/master成为您的refs/remotes/origin/master,并显示为简化为origin/master
© www.soinside.com 2019 - 2024. All rights reserved.