Почему git не получает запрос на удаление, который я слил в GitHub?

Question

У меня проблемы с мерзавцем.Моя настройка выглядит следующим образом:

[репозиторий рабочей станции] -origin-> [сетевое дисковое репозиторий] -origin-> [GitHub]

Я только что принял мой первый запрос на загрузку на GitHub ( этот ) и слил его с мастером.Теперь я хочу вытащить его на свою рабочую станцию.Поэтому я делаю git fetch на сетевом диске, а затем git pull на моей рабочей станции, но на моей рабочей станции git говорит «Уже в курсе» и отказывается объединить изменения (я проверил, это не в моей рабочей области).

Вывод git branch -vv на сетевом диске включает строку:

* master                    0fe40e2 [origin/master: behind 2] Some small code improvements

Вывод git branch -vv на репозитории рабочей станции включает строку:

* master         0fe40e2 [origin/master] Some small code improvements

Фактический коммит, на который они должны указывать, это 3388641 .Похоже, что в голом репо на сетевом диске ветка master как-то отстает от origin / master.Понятия не имею, как возникла эта ситуация или как ее исправить.Я не могу использовать git pull или git reset, так как это голый репозиторий.

Кто-нибудь знает, как я могу определить, в чем проблема и как ее исправить?

Answer 1

Я не уверен, какова цель этого отдельного голого клона (голый клон - это тот, который, как вы говорите, находится на сетевом диске), но если это не клон mirror - зеркала являются конкретный тип чистого клона - у него есть собственные имена веток, независимые от всех других репозиториев Git. ¹ Следовательно, вам нужно указать обновить любой конкретной ветки, если и когда Вы хотите, чтобы он подчинял себя какому-нибудь другому хранилищу Git.

Я не могу использовать git pull или git reset, так как это голый репо ...

Это правда, что вы не можете использовать git pull, потому что это пустой репозиторий и git pull означает run git fetch, затем выполните вторую команду Git , и эта вторая команда Git всегда одна это нуждается в рабочем дереве. Однако это не случай, когда вы не можете использовать git reset. То, что вы не можете сделать, это сделать смешанный или полный сброс:

$ git reset
fatal: mixed reset is not allowed in a bare repository
$ git reset --hard
fatal: this operation must be run in a work tree

A --soft сброс, однако, разрешен:

$ git reset --soft
$ 

, поэтому один из способов перемещения локального master в соответствие origin/master:

$ git reset --soft origin/master

Однако наиболее подходящим вариантом, вероятно, является либо полное прекращение использования этого пустого хранилища, либо использование зеркального клона (см. Сноску 1).

---

¹ Технически, даже зеркальный клон имеет свои собственные имена ветвей. Ключевое различие между клоном без зеркала и клоном без зеркала состоит в том, что у клона зеркала все имена ветвей подчинены своему источнику. ² В частности, конфигурация fetch для зеркального клона: :

[remote "origin"]
    fetch = +refs/heads/*:refs/heads/*

вместо стандартных:

[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*

Стандартная настройка извлечения означает, что при запуске git fetch в таком клоне все имена refs/remotes/origin/* обновляются в соответствии с именами refs/heads/* источника. Нестандартный параметр зеркала означает, что git fetch, запущенный в зеркальном клоне, принудительно обновляет все имена refs/heads/*, немедленно забывая (и таким образом теряя любые коммиты, которые только достижимы из) его собственных имен ветвей в пользу использования вместо этого извлеченных имен. Вот что делает зеркало зеркалом: оно удаляет любые коммиты, которые были эксклюзивными для своих собственных ветвей, заменяя свои собственные хеши фиксации имени ветви на то, что он видел на удаленном компьютере.

² Приведенное выше описание предполагает стандартное имя удаленного устройства origin. Если вы использовали какое-то другое имя, все остается в силе, просто вместо origin строковый литерал будет тем именем, которое вы использовали.