Git: сложность становится существующей Git Репозиторий для отслеживания нового голого удаленного репозитория

Question

Резюме: У меня проблемы с получением существующего локального хранилища для отслеживания нового удаленного удаленного хранилища.

Что я пробовал: У меня есть попытался сделать локальное репо sh в новом голом репо при настройке отслеживания вверх по течению. Git сообщает, что отслеживание в восходящем направлении происходит, но я все еще не вижу отслеживаемую ветку в журнале локального репо, даже после извлечения удаленного репо.

Я также пытался создать голый клон из локальное репо, надеясь, что это будет работать аналогично клонированию другого локального репо, где отслеживание настроено автоматически, но я все еще не вижу признаков отслеживания в журнале локального репо.

Запрос: Сможет ли кто-нибудь взглянуть на справочную информацию, приведенную ниже, и подсказать мне, где я могу ошибаться, или у меня может быть неправильное понимание того, как заставить мое существующее репо отслеживать новое голое удаленное репо? Спасибо, я уже старался изо всех сил исследовать это.

Справочная информация Я работаю инженером-технологом в небольшой команде. Мы хотели бы настроить рабочий процесс, используя центральный общий удаленный репозиторий Git для команды. Я пытался настроить демонстрацию того, как это будет работать, с каталогом «centralRepo. git», расположенным ниже, являющимся нашим центральным репозиторием, а другие члены группы, работающие с другими папками, могут клонировать центральный пульт дистанционного управления. Поскольку у нас уже есть существующая работа, но нет существующего централизованного удаленного репо, мы начнем с существующего репо в «davesClones», которое будет передано на центральный пульт, а затем при необходимости будет клонировано в другие папки членов группы, например, «stevesClones» . "

Что я ожидаю увидеть, если отслеживание работает: Если я клонирую обычный локальный репо, отслеживание автоматически настраивается, и в журнале отображаются собственные ветви моих клонов вместе с веткой «origin», которую он отслеживает из каталога, из которого он был клонирован, как показано на скриншоте ниже, обведенном синим цветом:

Попытка # 1: Нажатие с / - Setstream Upstream:

Я попытался перенести мой существующий локальный репо на новый центральный ре Сделайте повторное воспроизведение, используя git push --set-upstream <remote> master, как показано ниже, и даже несмотря на то, что вывод показывает, что отслеживание настроено, я не вижу никакого отслеживания в журнале git, как это было при клонировании обычного репо, даже после использования fetch. Приведенные ниже примеры показывают, как я пропускаю ветку отслеживания происхождения в журнале после выполнения описанных выше действий:

Попытка № 2: Клонировать - bare:

Я также пытался клонировать существующее репо в новое голое репо, надеясь, что это автоматически установит отслеживание sh, но, как показано ниже, журнал не показывает никакого отслеживания, даже после извлечения:

Есть идеи, почему я не вижу отслеживания в мой журнал? (Имеется в виду, почему после клонирования стандартного локального репо я вижу отслеживание [origin / master, origin head], но не могу получить это в своем журнале, когда использую pu sh --set-upstream для pu sh local repo на удаленный сервер или при использовании git clone --bare для клонирования локального репо на чистый пульт?)

Также в локальном репо есть сделанный коммит, поэтому он не пустой при нажатии или клонирование в пульт.

Спасибо!

Answer 1

TL; DR

Вам необходимо запустить весь процесс, настроив remote в своем собственном хранилище Git:

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

, после чего вы Вы должны использовать name часть, которую вы использовали, вместо того, чтобы вводить (предположительно более длинный) URL-или-путь. То есть вы сделаете:

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

Long

Позвольте мне начать с того, что мне действительно не нравится слово tracking здесь, поскольку оно вводит всех в заблуждение. Он сделал это и с вами.

Мы должны использовать git remote для создания или иным образом манипулировать пультами . Пульт ДУ - это просто короткое имя - например, origin, которое является своего рода стандартным именем, используемым для пульта ДУ, - в котором будет храниться URL-адрес (и некоторая другая внутренняя информация для Git). .

Я заново набираю с вашего скриншота, поэтому могу ввести опечатки, но ключ здесь в этой строке:

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

Давайте сделаем быстрый обход документация Git. Синтаксис для git push описан в строках SYNOPSIS документации как (сокращенно):

<strong>git push</strong> [options] [repository [refspec...]]

Здесь ваш одиночный параметр --set-upstream (что само по себе хорошо), и ваш репозиторий задается как путь, /d/Seafile/.... Если вы перейдете к разделу ОПЦИИ, параметр хранилища будет описан слишком кратко следующим образом:

<repository>
«Удаленный» репозиторий, который является местом назначения операция пу sh. Этот параметр может быть либо URL-адресом ... либо именем удаленного ...

К сожалению, здесь опущено то, что --set-upstream, и тип отслеживания, который вы хотите, работает только в том случае, если указанный параметр является удаленным .

Имя пути, например /d/Seafile/..., которое Git внутренне преобразовано в D:/Seafile/..., как вы можете видеть в других выходных данных, считается как URL-адрес, а не «удаленный».

Пульты дистанционного управления и имена для удаленного отслеживания

Вместо того, чтобы говорить, что имя ветви отслеживает какое-то другое имя, я хотел бы использовать Фраза имеет в качестве восходящего . Эта фраза, к сожалению, немного неуклюжа (поэтому Git использует track в качестве глагола). Любое имя ветви может не иметь ни одного восходящего потока, ни одного восходящего. Когда ветвь имеет восходящий поток, это может быть либо:

• другое имя ветки, например, develop может иметь master в качестве восходящего потока, либо
• a имя удаленного отслеживания , например origin/master.

Я называю имена, такие как origin/master имена удаленного отслеживания (Git документация в основном называет эти имена веток удаленного отслеживания ). Они появляются, соединяя вместе имя remote , например origin, с именем ветви: имя ветви в Git, с которой Git обращается, когда ваш Git звонит на другой Git, используя URL , сохраненный в этом «удаленном».

Когда вы используете git fetch или git push, у вас есть Git позвоните другому Git. Есть два Гита; каждый Git имеет своих ветвей. У вашего Git есть ваши ветви, а у их Git есть их. Ваши Git предлагают запомнить их имена для вас, в качестве услуги ... но для того, чтобы ваши Git запомнили имена их филиалов, ваш Git должен придумать имя для каждого, который не мешает вашим собственным именам веток. Ваш Git делает это, вставляя что-то перед именами их ветвей. ¹

Часть, которая вставляется сюда, это имя remote , например, origin. Без пульта дистанционного управления - вместо URL-адреса - вставить нечего, поэтому вставка впереди никогда не произойдет. Параметр --set-upstream становится неработоспособным.

Так почему ваш Git напечатал:

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

? Единственный возможный ответ здесь - это то, что Git очень мерзкий. Он просто сказал, что сделал то, что физически не может сделать, и поэтому не сделал.

---

¹ Технически имена удаленного отслеживания находятся в отдельном пространстве имен : имена ветвей имеют полностью прописанные имена, которые начинаются с refs/heads/, так что master действительно refs/heads/master. Имена удаленного отслеживания начинаются с refs/remotes/ и go on, чтобы включать имя удаленного и другого sla sh. Остальная часть имени - это сокращенное имя ветви, которое видно на этом пульте по URL-адресу. Таким образом, их refs/heads/master становится вашим refs/remotes/origin/master, который сокращается до origin/master.