Будет ли обновляться рабочий каталог при обновлении текущей ветки?

Перед моими вопросами я хотел бы знать, правильно ли понято понимание некоторых концепций Git, и, пожалуйста, не стесняйтесь меня исправить:

  • имя ветки указывает на кончик (т.е. конечную фиксацию) ветки и
  • HEAD указывает на название ветки текущей ветки и
  • текущая ветвь определяется как ветвь проверена в рабочем каталоге.

Вот мои вопросы:

  • Когда новая фиксация добавляется к ветке командой Git (любая команда Git, которая может добавить фиксацию в ветку),

    Вопросы:

    команда Git всегда перемещает имя ветки вперед, указывая на новый коммит?

    Или существуют команды Git, которые добавляют новые коммиты к ветке, которая не перемещайте имя ветки и, следовательно, мне нужно запустить некоторые Дополнительная команда Git для ее перемещения?

  • Когда

    • новая команда добавляется к текущей ветке командой Git и
    • имя ветки перемещается вперед, чтобы указать на новый наконечник наконечника в текущей ветке,

    Вопросы:

    • необходимо ли дополнительно обновлять HEAD?

      Мое предположение - нет, потому что HEAD уже указал на текущее название ветки, текущее название ветки уже обновлено, чтобы указать на новое tip commit текущей ветки и перемещение текущей ветки имя не изменяет тот факт, что HEAD указывает на текущий название ветки. Таким образом, все выглядит отлично без дополнительных изменений в HEAD.

    • уже обновлен рабочий каталог, чтобы он был таким же, как новый наконечник кончика ветки?

      Или может рабочий каталог по-прежнему будет таким же, как предыдущий кончик фиксации ветки, и в чтобы проверить новый наконечник накопления текущей ветки в рабочий каталог, мне нужно запустить еще одну команду Git?

    Ниже перечислены два случая/примеры с белыми Git командами (git push и git pull), что заставило меня задуматься и задать вопросы из этих двух частей для произвольные команды Git, которые могут добавлять фиксации к ветке или к текущей ветке:

  • git push добавляет новые фиксации к ветке на пульте дистанционного управления репозиторий.

    Предположим теперь, что

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

    Вопросы:

    • в удаленном репозитории, git push переместить имя ветки, чтобы указать на новый отзыв?

      Или пользователь удаленного репозитория должен запустить некоторую дополнительную команду Git, чтобы переместить ее?

    • В удаленном репозитории git push обновить рабочий каталог так же, как новый наконечник накопления?

    • т.е. в удаленном репозитории - это обновленная версия (через git push) текущей ветки ( "current" до git push), тем не менее текущая ветвь после git push? (обратите внимание на определение текущего я дал в начале сообщения: "Текущая ветка определяется как ветвь проверена в рабочем каталоге. ")

    Мое предположение - нет, если я правильно понимаю из Control Version Git от Loeliger 2ed, который гласит:

    Напомним, что команда Git push не проверяет файлы в получающий репозиторий. Он просто переносит объекты из источника репозитория в принимающий репозиторий, а затем обновляет соответствующие ref на принимающей стороне.

    В открытом репозитории это поведение - все, что можно ожидать, потому что нет рабочего каталога, который может быть обновлен извлеченные файлы. Это хорошо. Однако в разработке репозиторий, который является получателем операции push, он может позже вызвать путаницу для всех, кто использует репозиторий разработки.

    Операция push может обновлять состояние репозитория, включая HEAD совершить. То есть, хотя разработчик на удаленном конце ничего, ветка refs и HEAD могут измениться, переставая синхронизироваться с проверенными файлами и индексом.

    Разработчик, который активно работает в репозитории, в который асинхронное нажатие не увидит толчок. Но последующий фиксация этим разработчиком произойдет на неожиданном HEAD, создав странная история. Усиленный толчок потеряет толкаемые фиксации от другого разработчик. Разработчик в этом репозитории также может оказаться неспособная согласовать свою историю с каким-либо восходящим репозиторием или нисходящий клон, потому что они более не бывают быстрыми вперед, как они должны быть. И она не знает, почему: хранилище тихо из-под нее. Кошки и собаки будут жить вместе. Itll будет плохо.

  • В команде git pull шаг слияния объединяет вновь выбранную ветвь удаленного отслеживания в текущую ветку. Если я прав, шаг слияния git pull также увеличивает имя ветки ветки, чтобы указать на новую верхнюю фиксацию на ветке.

    Вопрос:

    • В локальном репозитории git pull обновляет рабочий каталог так же, как новый захваченный отзыв?

    • т.е. В локальном репозитории находится обновленная версия (через git pull) текущей ветки ( "ток" до git pull) по-прежнему текущая ветка после git pull? (обратите внимание на определение текущей ветки, которую я дал в начале сообщения: "текущая ветвь определяется как ветвь проверена в рабочем каталоге." )

    Я задал вопрос о git pull в Запустил ли Git текущую ветку после шага слияния/переадресации?. Из моего понимания, что означает ответ Джозефа, git pull проверяет новый захваченный отзыв в рабочий каталог локального репозитория, и мне не нужно запускать дополнительные команды Git, чтобы проверить его. torek ответ велик, но это будет некоторое время, пока я не смогу его понять.

ОТВЕТЫ

Ответ 1

Есть несколько проблем с вашим пониманием Git, которые я пытаюсь прояснить:

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

команда Git всегда перемещает имя ветки вперед, чтобы указать на новую фиксацию?

Существуют способы создания коммитов, не влияющих на какую-либо ветвь; и если вы находитесь на отдельной головке, у вас также нет ветки, обновленной после фиксации.

Если вы не находитесь на отдельной HEAD (о которой Git предупредит вас о том, что когда вы ее введете), вы не должны слишком беспокоиться о необходимости обновлять ветвь позже вручную. Обычными командами, которые вы используете для создания (или воссоздания) коммитов, являются git commit, git merge и git rebase (в дополнение к извлечению существующих коммитов из других мест, конечно), и все они влияют на текущую ветвь.

необходимо ли дополнительно обновлять HEAD?

Опять же, если вы не находитесь на отдельной голове, HEAD всегда будет относительной ссылкой на другую ветку или ссылку. Таким образом, после этих обновлений HEAD также будет неявно обновляться. И если вы находитесь на отдельной HEAD, тогда Git будет обновлять HEAD непосредственно при создании коммитов.

обновлен рабочий каталог, чтобы он был таким же, как новый наконечник наконечника ветки?

Рабочий каталог полностью отделен от коммитов или веток. Да, когда вы делаете git checkout для переключения ветки или какой-либо другой фиксации, которая напрямую влияет на рабочий каталог, тогда рабочий каталог будет обновляться, но, в частности, передача не будет изменять рабочий каталог вообще. Обычно вы добавляете изменения из рабочего каталога в индекс, а затем создаете фиксацию из индекса. Таким образом, рабочий каталог остается в любом состоянии, которое вы оставили перед его выполнением. Теоретически рабочий каталог может быть чем-то совершенно отличным от того, что вы только что совершили.

git push добавляет новые фиксации к ветке в удаленном репозитории.

Нет, git push свяжется с удаленным каталогом и затем перенесет на него существующие коммиты.

в удаленном репозитории, выполняет ли Git push перемещение имени ветки, чтобы указать на новый отзыв?

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

Лучшая практика заключается в том, чтобы нажать на голый репозиторий, и тогда у него есть крючок, который обновляет другой репозиторий с рабочим каталогом (на том же компьютере).

Если я прав, шаг слияния Git pull также увеличивает имя ветки ветки, чтобы указать на новый верхний фиксатор на ветке.

Слияние обновляет ветку, да.

В локальном репозитории Git вытащить проверку нового захваченного наконечника в рабочий каталог?

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

Ответ 2

1. Всегда ли команда git переводит имя ветки вперед, чтобы указать на новую фиксацию?

Да, когда вы совершаете фиксацию в ветки, она перемещает ее до последней фиксации.

2. Нужно ли дополнительно обновлять HEAD?

Нет, поскольку HEAD относится к фиксации на вершине текущей ветки, и если вы вносите новые изменения в эту вывешенную ветку, то снова HEAD указывает на последнюю фиксацию.

3. Обновлен ли рабочий каталог так же, как новый конкат фиксации ветки?

Да рабочая директория обновляется с момента совершения новой фиксации, и если после совершения нового изменения в branch A вы выберете более старую branch B, тогда рабочий каталог указывает на более раннюю ветвь B со своим собственным последняя фиксация.

4. В удаленном репозитории git push переместите имя ветки, чтобы указать на новый отзыв?

Да, если мы git нажмем из нашего локального репозитория branch A в удаленный репозиторий, у которого также есть рабочий каталог, указывающий на branch A, он перемещает его до последней фиксации. Пользователю не нужно выполнять какие-либо дополнительные команды.

Если вы нажмете код из branch B (локального репозитория) на branch B (удаленный репозиторий), у которого рабочий репозиторий будет branch A, он переместит branch B на последнюю фиксацию, но рабочий каталог все еще указывает на branch A в удаленном репозитории. Он обновляет только код ветки, на которую вы нажимаете новые коммиты, нет проверки.

5. В локальном репозитории git pull проверить, что новый захваченный отзыв в рабочий каталог?

Нет git pull не проверяет фиксацию нового захваченного наконечника, он объединяет удаленные ветки, связанные с текущей ветвью в рабочем каталоге. Вы можете тянуть код от branch B до branch A, который объединяет branch B совершает транзакции branch A, но не изменяет текущую ветвь на B.

6. Является ли обновленная версия (от git pull) текущей ветки ( "текущая" до git pull) все еще текущая ветка после git pull?

Да, текущая ветка остается прежней даже после git pull, как объяснялось выше, поскольку она просто объединяет коммиты.