Почему в строке «От» в ответе «git pull» не указано имя голого репо?

Я новичок в git, и я пытаюсь понять строки

...
From /tvm
   f8322345..9837f82f  master     -> origin/master
...

в ответе git на git pull с проверенной веткой dev.

У меня есть репозиторий git bare и два репозитория, которые подталкивают/вытягивают к этому репозиторию бара; все на одном сервере. Конфигурация выглядит следующим образом:

/
|
+-- tvm.git           The bare repo
|
+-- htdocs
      |
      +-- dev         The development repo. Has both master and dev branches
      |
      +-- website     The production repo. A clone of the master branch.

Эта настройка используется для управления веб-сайтом на основе Joomla. База данных меняется по мере того, как люди пишут новые статьи и т. д., поэтому с этим меняется основная ветка в рабочем репозитории.

Мне нужно объединить ветку master с веткой dev в репозитории разработки, чтобы обновить dev. Находясь в /htdocs/website (у которого всегда есть проверенная ветка master), я сначала выгружаю БД, затем git commit и git push. Ответ Git (некоторые строки удалены для краткости):

Enumerating objects: 5, done.
...
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
To /tvm.git
   5f08eef0..9837f82f  master -> master

Я понимаю, что последние две строки означают: Git перенес изменения в голое репо (To /tvm.git), и это была ветвь master к master.

Затем я перехожу в каталог devlopment, в котором есть проверенная ветка dev.

/htdocs/website $ cd ../dev/
/htdocs/dev $ git status
On branch dev
Your branch is up to date with 'origin/dev'.

nothing to commit, working tree clean

Просто чтобы быть уверенным, я тяну с нуля с помощью git pull. Ответ (снова некоторые строки удалены):

remote: Enumerating objects: 17, done.
...
Unpacking objects: 100% (13/13), 32.46 KiB | 21.00 KiB/s, done.
From /tvm
   f8322345..9837f82f  master     -> origin/master
Already up to date.

Я не понимаю, во-первых, почему git говорит мне From /tvm, а не From /tvm.git? Это просто несоответствие? Во-вторых, почему git пишет master -> origin/master? Почему master, а не dev? И в-третьих, почему git пишет Already up to date.? Основная ветвь нет актуальна; Я только что зафиксировал и отправил изменения в основную ветку в голом репо.

Файлы конфигурации git содержат...

  • В репозитории разработки:
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        url = /tvm.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master
[branch "dev"]
        remote = origin
        merge = refs/heads/dev
  • В производственном репозитории:
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        url = /tvm.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master
  • В голом репо_:
[core]
        repositoryformatversion = 0
        filemode = true
        bare = true
Формы c голосовым вводом в React с помощью Speechly
Формы c голосовым вводом в React с помощью Speechly
Пытались ли вы когда-нибудь заполнить веб-форму в области электронной коммерции, которая требует много кликов и выбора? Вас попросят заполнить дату,...
Стилизация и валидация html-формы без использования JavaScript (только HTML/CSS)
Стилизация и валидация html-формы без использования JavaScript (только HTML/CSS)
Будучи разработчиком веб-приложений, легко впасть в заблуждение, считая, что приложение без JavaScript не имеет права на жизнь. Нам становится удобно...
Flatpickr: простой модуль календаря для вашего приложения на React
Flatpickr: простой модуль календаря для вашего приложения на React
Если вы ищете пакет для быстрой интеграции календаря с выбором даты в ваше приложения, то библиотека Flatpickr отлично справится с этой задачей....
В чем разница между Promise и Observable?
В чем разница между Promise и Observable?
Разберитесь в этом вопросе, и вы значительно повысите уровень своей компетенции.
Что такое cURL в PHP? Встроенные функции и пример GET запроса
Что такое cURL в PHP? Встроенные функции и пример GET запроса
Клиент для URL-адресов, cURL, позволяет взаимодействовать с множеством различных серверов по множеству различных протоколов с синтаксисом URL.
Четыре эффективных способа центрирования блочных элементов в CSS
Четыре эффективных способа центрирования блочных элементов в CSS
У каждого из нас бывали случаи, когда нам нужно отцентрировать блочный элемент, но мы не знаем, как это сделать. Даже если мы реализуем какой-то...
1
0
22
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

I don't understand, firstly, why does git tell me From /tvm and not From /tvm.git?

Git считывает параметр url = из origin (в данном случае) и использует его, но имеет тенденцию удалять .git из конца таких URL-адресов. Для этого нет особенно хороших или плохих причин. Git просто делает это.

Secondly, why is git writing master -> origin/master? Why master and not [the branch I am on, i.e.,] dev?

Команда git pull состоит из запуска двух других команд Git: 1

  • Сначала git pull бежит git fetch.
  • Затем он запускает другую команду, которую мы пока опустим.

(Большинство, но не все аргументы, которые вы передаете git pull, идут непосредственно к git fetch, если вы их приводите. Вы этого не сделали, поэтому мы можем обойти здесь все кровавые подробности.)

Команда git fetch создает эти строки вывода. Команда извлечения:

  1. Вызывает другой репозиторий Git: любые ответы по указанному URL-адресу. Обычно URL-адрес начинается с https:// или ssh://, так что Git работает по сети, что-то вроде телефонного звонка через Интернет. Веб-сервер или ssh-сервер ответит и передаст «телефонный звонок» другому программному обеспечению Git или, по крайней мере, другому программному обеспечению, использующему протокол Git, так что теперь будут выполняться две отдельные команды Git: ваша, в вашем репозитории и их команда. , в их репозитории.

    В вашем случае URL-адрес предназначен для файла, поэтому вместо того, чтобы звонить кому-то, чтобы узнать, кто отвечает, ваше собственное программное обеспечение Git играет роль другого программного обеспечения Git. (Ваш Git может порождать или не порождать второй раунд программного обеспечения Git, в зависимости от того, какую версию всего, что вы используете. Традиционный C Git порождает или, по крайней мере, должен порождать еще один, потому что есть или, по крайней мере, были, слишком много глобальных переменных, так что только один репозиторий мог быть «в игре», будучи либо прочитанным — Git, обслуживающим выборку, либо записанным; это, по крайней мере, в основном исправлено с течением времени, поэтому детали могут различаться в зависимости от версии Git. ) Принцип одинаков в любом случае: сервер вашего Git "вызывает" читает их репозиторий, а ваш Git пишет ваш репозиторий Git.

  2. Их Git (их программное обеспечение в их репозитории) перечисляет ветки и теги их и другие подобные имена, а также идентификаторы хэшей коммитов, которые сопровождают их. Ваш Git выбирает те, которые ему «нравятся». Для По умолчаниюgit fetch вашему Git нравится все, поэтому любой хэш-идентификатор коммита, который ваш Git видит, что ваш Git еще не имеет имеют, ваш Git просит их Git отправить это. Это обязывает их предлагать родителя (ей) этого коммита; ваш Git проверяет, есть ли у вас эти коммиты, и если нет, ваш Git запрашивает их, что заставляет их Git предлагать больше родителей и так далее.

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

    Это охватывает этапы подсчета и перечисления, сжатия и получения. Теперь у вашего Git есть все необходимые коммиты и вспомогательные объекты, так что у вас есть коммит каждый. Ваш Git сохраняет их, расширяя («распаковывая» и «проверяя» и т. д.) вещи, если/по мере необходимости, используя объекты, которые у вас уже есть, о которых они узнали во время фазы разговора «есть / хочу». Все связь выполнены, и ваше программное обеспечение Git может отключиться от них.

  3. Теперь, когда у вас есть все их совершает, ваш Git берет каждое из их имен ветка и меняет их на ваши имена дистанционное отслеживание: их main становится вашим origin/main, их dev становится вашим origin/dev и так далее. Помните, в начале они перечислили все имена своих веток и все хэш-идентификаторы коммитов, которые представляли эти имена.

    Теперь ваш Git проверяет, какие из ваших origin/* имен нужно создать или обновить. Вот где:

       f8322345..9837f82f  master     -> origin/master
    

    выходят линии стиля. Это означает, что их master — ваш origin/master — раньше называли коммит f8322345, но теперь их master имена коммит 9837f82f. Поэтому ваш Git должен обновить свой собственный origin/master.

Чтобы понять это, вам нужен еще один факт: хэш-идентификатор любого коммита — универсально уникальный. Если у вас есть коммит 9837f82f, ваш Git называет это 9837f82f, их Git называет это 9837f82f, а любой другой Git во вселенной, у которого есть этот коммит, называет его 9837f82f. (Этот 9837f82f на самом деле сокращен от полного хеш-идентификатора, который должен быть огромным, чтобы могу был универсально уникальным.) Таким образом, ваш Git и их Git могут сказать, какие коммиты есть у вас обоих, просто изучив количество. (Идентификатор хеша — это представление шестнадцатеричный большой криптографической контрольной суммы по содержимому коммита.2)

Есть еще несколько вещей, на которые следует обратить внимание в отношении линии:

   f8322345..9837f82f  master     -> origin/master

Во-первых, обратите внимание на две точки и тот факт, что строка не заканчивается на (forced update). Это означает, что коммит f8322345 является предок коммита 9837f82f: родитель, или прародитель, или прапрародитель, или прапрародитель для п > 1. Если бы master был перемотан и переписан, вы бы увидели знак плюс, точки три и добавленное примечание forced update.

Если ваш собственный Git еще не сделал имеютorigin/master, так что существование их master (вашего origin/master) было новым для вашего репозитория, вы получите:

 * [new branch]            master     -> origin/master

и если вы запустите git fetch с включенной опцией обрезки, и у них есть удален какое-то имя ветки, которое они Раньше у нас, но больше не делают, вы получите:

 - [deleted]               (none)     -> origin/foo

Таким образом, эти строки многое расскажут вам о том, что произошло с тех пор, как вы в последний раз собирали обновления с данного именованного пульта, например origin.

And thirdly, why is git writing Already up to date.?

Теперь мы переходим к команде второй, которая запустится git pull. Вы можете выбрать эту команду, но она (в настоящее время или, по крайней мере, ранееn) по умолчанию равна git merge. Другой вариант — git rebase, но вы получаете git merge.

В отличие от git fetch, которая извлекает все имена других веток Git,3 команда второй Git, независимо от того, какую вы выберете, будет работать только с текущая ветвь. Ваша текущая ветка — dev, а ее вверх по течениюorigin/dev. Команды git status и git branch -vv покажут вам настройку восходящего потока:

$ git status
On branch master
Your branch is up to date with 'origin/master'.

Вот я на своем master для своего репозитория Git для Git, и он синхронизирован с origin/master. Поскольку я только что запустил git fetch, это означает, что мастер origin идентифицирует тот же коммит:

$ git rev-parse master origin/master
ab1f2765f78e75ee51dface57e1071b3b7f42b09
ab1f2765f78e75ee51dface57e1071b3b7f42b09

Здесь мы видим, что оба имени идентифицируют коммит ab1f2765f78e75ee51dface57e1071b3b7f42b09, то есть версию Git 2.36.0-rc1.

Ваш git fetch обновил ваш origin/master — это то, что вы видели в выводе git fetch из git pull — но не обновил ваш origin/dev. Верхний коммит вашей существующей ветки dev либо совпадает с вашим коммитом origin/dev, либо опережает его. Это означает, что у git merge нет работы на стороне их, которую можно было бы объединить с любой работой, которую вы могли выполнить на своей стороне. Ваш dev уже обновлен с вашим origin/dev. И это то, что Git сказал вам здесь.


4Раньше git pull был просто скриптом оболочки, который фактически запускал git fetch, а затем запускал вторую команду Git. В наши дни это большая мохнатая программа на C, которая во время компиляции включает один и тот же код в видеgit fetch и обе другие программы, так что вместо того, чтобы вызывать другие программы как команды, она вызывает их как вызовы подпрограмм. Однако принцип тот же, и чтобы сохранить «обратную» в «обратной совместимости», код C упрямо перебирает каждую последнюю глупую маленькую морщинку, которая раньше требовалась. так как это были отдельные программы.

1В настоящее время это 160-битный хэш SHA-1, но оказывается, что 160-битный SHA-1 не является криптографически стойким, и Git движется к 256-битному SHA-256. См. также Git и SHA-256.

2Это значение по умолчанию оказывается плохим/неправильным для многих, и теперь Git начинает требовать, чтобы вы использовали настроить по умолчанию. Если вы получаете жалобу на необходимость настройки pull.ff и/или pull.rebase, у вас есть версия Git, которая подталкивает вас к выбору чего-то сознательно, а не просто принимает какое-то значение по умолчанию, которое может вам не подойти.

3На самом деле это зависит от множества деталей, но по умолчанию вы получаете все ветки, если запускаете git fetch без параметров. Следите за ответами, в которых говорится об использовании git pull --all: это передает --all в git fetch, где это не означает все филиалы, поскольку это уже имеет место. Вместо этого это означает все пульты. Это не вредный, но он не делает то, что люди думают, поэтому к ответам, рекомендующим --all, следует относиться с осторожностью, чтобы у человека, который их написал, не было других недоразумений, что находятся вреден.


Вывод

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

Как только вы узнаете, что делает каждая команда, вы можете обнаружить, что git pull это удобный способ запустить git fetch, а затем сразу же — не давая вам возможности наблюдать, что git fetch извлекло — запустить вторую команду является, что вы хотите. Но на самом деле вы не будете знать этого, пока не узнаете, чего хотите, а вы не мочь знаете, пока не узнаете, что делает каждый из них. Хуже, когда одна из команд терпит неудачу, вы не будете знать, как восстановиться. Огромная часть умения работать с чем-либо (программное обеспечение, кулинария, работа с деревом, работа с ядерным реактором и т. д.) заключается в знании того, что делать, когда что-то не работает. Когда все работает, как задумано, это может сделать любой дурак; профи знают что делать когда не.

Миллион спасибо! Я рад, что задал этот вопрос, так как ваш ответ так много узнал о Git.

phunsoft 10.04.2022 11:07
... но у него есть тенденция удалять .git из конца таких URL-адресов. Но это не следует этой тенденции, следовательно: «.git» удаляется в сообщении От, но не в сообщении К. (Наверное, это и означает «тенденция».)
phunsoft 10.04.2022 11:10

Я не совсем понимаю, что вы хотели сказать этим предложением в конце 3.: Это означает, что их мастер — ваш источник/мастер — раньше называл коммит f8322345, но теперь их мастер называет коммит 9837f82f. Поэтому вашему Git необходимо обновить свой собственный источник/мастер.

phunsoft 10.04.2022 11:13

Теперь я понимаю, что (в моем случае) «мой git» извлек каждую фиксацию каждой ветки с удаленного git. Итак, я мог бы немедленно сделать git merge master, чтобы объединить ветку master с веткой dev. Не надо сначала git checkout master, git pull (ну git fetch как я только что узнал), потом git checkout dev и наконец git merge master?

phunsoft 10.04.2022 11:17

Другие вопросы по теме