Что произойдет при выполнении команды git fetch
Работа с удалёнными репозиториями
Для того, чтобы внести вклад в какой-либо Git-проект, вам необходимо уметь работать с удалёнными репозиториями. Удалённые репозитории представляют собой версии вашего проекта, сохранённые в интернете или ещё где-то в сети. У вас может быть несколько удалённых репозиториев, каждый из которых может быть доступен для чтения или для чтения-записи. Взаимодействие с другими пользователями предполагает управление удалёнными репозиториями, а также отправку и получение данных из них. Управление репозиториями включает в себя как умение добавлять новые, так и умение удалять устаревшие репозитории, а также умение управлять различными удалёнными ветками, объявлять их отслеживаемыми или нет и так далее. В данном разделе мы рассмотрим некоторые из этих навыков.
Вполне возможно, что удалённый репозиторий будет находиться на том же компьютере, на котором работаете вы. Слово «удалённый» не означает, что репозиторий обязательно должен быть где-то в сети или Интернет, а значит только — где-то ещё. Работа с таким удалённым репозиторием подразумевает выполнение стандартных операций отправки и получения, как и с любым другим удалённым репозиторием.
Просмотр удалённых репозиториев
Если у вас больше одного удалённого репозитория, команда выведет их все. Например, для репозитория с несколькими настроенными удалёнными репозиториями в случае совместной работы нескольких пользователей, вывод команды может выглядеть примерно так:
Это означает, что мы можем легко получить изменения от любого из этих пользователей. Возможно, что некоторые из репозиториев доступны для записи и в них можно отправлять свои изменения, хотя вывод команды не даёт никакой информации о правах доступа.
Обратите внимание на разнообразие протоколов, используемых при указании адреса удалённого репозитория; подробнее мы рассмотрим протоколы в разделе Установка Git на сервер главы 4.
Добавление удалённых репозиториев
В предыдущих разделах мы уже упоминали и приводили примеры добавления удалённых репозиториев, сейчас рассмотрим эту операцию подробнее. Для того, чтобы добавить удалённый репозиторий и присвоить ему имя (shortname), просто выполните команду git remote add :
Получение изменений из удалённого репозитория — Fetch и Pull
Как вы только что узнали, для получения данных из удалённых проектов, следует выполнить:
Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет. После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта, которые вы можете просмотреть или слить в любой момент.
Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем «origin». Таким образом, git fetch origin извлекает все наработки, отправленные на этот сервер после того, как вы его клонировали (или получили изменения с помощью fetch). Важно отметить, что команда git fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.
Начиная с версии 2.27, команда git pull выдаёт предупреждение, если настройка pull.rebase не установлена. Git будет выводить это предупреждение каждый раз пока настройка не будет установлена.
Отправка изменений в удаленный репозиторий (Push)
Когда вы хотите поделиться своими наработками, вам необходимо отправить их в удалённый репозиторий. Команда для этого действия простая: git push
. Чтобы отправить вашу ветку master на сервер origin (повторимся, что клонирование обычно настраивает оба этих имени автоматически), вы можете выполнить следующую команду для отправки ваших коммитов:
Просмотр удаленного репозитория
Это был пример для простой ситуации и вы наверняка встречались с чем-то подобным. Однако, если вы используете Git более интенсивно, вы можете увидеть гораздо большее количество информации от git remote show :
Удаление и переименование удалённых репозиториев
Если по какой-то причине вы хотите удалить удаленный репозиторий — вы сменили сервер или больше не используете определённое зеркало, или кто-то перестал вносить изменения — вы можете использовать git remote rm :
При удалении ссылки на удалённый репозиторий все отслеживаемые ветки и настройки, связанные с этим репозиторием, так же будут удалены.
git fetch
Как git fetch работает с удаленными ветками
Можно проверить содержимое каталога /.git/refs/heads/ — оно будет соответствовать полученному результату.
Команды и опции git fetch
Извлечение всех веток из репозитория. При этом также загружаются все необходимые коммиты и файлы из другого репозитория.
Аналогично команде выше, но данные извлекаются только для указанной ветки.
Мощная команда, которая извлекает все зарегистрированные удаленные репозитории и их ветки.
Примеры использования git fetch
Извлечение удаленной ветки
В следующем примере будет показано, как извлечь удаленную ветку и обновить состояние локального рабочего репозитория содержимым удаленной ветки. Для этого представим, что существует центральный репозиторий origin, с которого с помощью команды git clone был клонирован локальный репозиторий. Допустим также, что имеется дополнительный удаленный репозиторий с именем coworkers_repo, содержащий ветку feature_branch, которую нужно будет настроить и извлечь. Приняв данные условия, продолжим пример.
Здесь создана новая локальная ветка с именем local_feature_branch. Теперь ссылка HEAD указывает на последнюю версию удаленного содержимого, и можно продолжать разработку, начиная с этой точки.
Синхронизация с репозиторием origin командой git fetch
В следующем примере рассматривается типичный процесс синхронизации локального репозитория с главной веткой центрального репозитория.
Эта команда покажет загруженные ветки:
На рисунке ниже коммиты из новых удаленных веток показаны не в виде кругов, а в виде квадратов. Как вы можете видеть, команда git fetch предоставляет доступ ко всей структуре веток другого репозитория.
Чтобы подтвердить изменения и выполнить их слияние с локальной веткой main, используйте следующие команды:
Затем можно воспользоваться командой git merge origin/main :
Ветка origin/main и ветка main теперь указывают на один и тот же коммит, а ваш репозиторий синхронизован с вышестоящими результатами.
Сводная информация по git fetch
Git Fetch и Git Merge
В одной из последних статей мы узнали о команде Git push. Команда Git push перемещает изменения, внесенные пользователями в их локальном репозитории, в удаленный репозиторий. Кроме того, передача изменений в удаленный репозиторий позволяет всей команде сотрудничать и делиться своей работой. Но это была одна сторона истории, когда пользователи перенесли свои локальные изменения в удаленный репозиторий. С другой стороны, все остальные члены команды должны синхронизировать эти изменения из удаленного репозитория в свой локальный репозиторий. Поэтому для этого члены команды должны извлечь изменения и объединить их в своем локальном репозитории. В этой статье мы рассмотрим Git Fetch и Git Merge, я покажу, как пользователи могут синхронизировать изменения из удаленного репозитория в свой локальный репозиторий.
Что такое команда Git Fetch?
Команда Git fetch помогает пользователю загружать коммиты, ссылки и файлы из удаленного репозитория в локальный репозиторий. Другими словами, выполнение этой команды поможет вам увидеть все обновления в удаленном репозитории. Вы можете подумать, а что, если вы не хотите сохранить изменения? Что ж, эта команда нисколько не повредит вашему рабочему репозиторию.
Git fetch — это отличный способ стоять в месте, откуда вы можете видеть изменения и решать, хотите ли вы сохранить их или отказаться от них.
Как использовать команду Git Fetch?
Прежде чем использовать эту команду, давайте внесем некоторые изменения в наш удаленный репозиторий, чтобы мы могли извлечь их через локальный репозиторий.
Выполните следующие действия в своей учетной записи GitHub:
Теперь, когда у нас есть некоторые изменения в удаленном репозитории, мы должны получить их в нашей локальной рабочей копии репозитория.
Последние две строки означают:
https:// : URL-адрес репозитория.
e7b37f6..47b2bf6 : первый хэш-это хэш последней объединенной фиксации в локальном репозитории, а 47b2bf6-это новый хэш-код фиксации/изменения из удаленного репозитория.
Пользователь также может проверить коммиты и недавние действия с помощью команды git log.
Если на вашем экране отображается аналогичный вывод, как показано на рисунке выше, вы успешно извлекли изменения из удаленного хранилища.
Параметры команды Git Fetch
Как и любая другая команда в Git, команда Git fetch также содержит некоторые параметры для быстрого и эффективного использования команды. Давайте обсудим их ниже:
Опция all извлекает все удаленные ссылки, файлы и т. д.
git fetch –all
Dry Run
Dry Run покажет пользователю, как команда будет выполняться без внесения каких-либо изменений.
git fetch –dry-run
Что такое команда Git Merge?
Команда Git merge — это решение включить изменения, которые вы увидели с помощью команды Git fetch. Как только пользователь будет готов принять изменения из удаленного хранилища, он сможет объединить эти изменения в локальное хранилище. Как следует из названия, вы подтверждаете merge (слияние) этих изменений.
Изображение ниже может помочь прямо описать значение Git Merge.
Извлечение изменений, выполненных на удаленном компьютере, происходит с помощью команды fetch, а затем, если пользователь одобряет их, они объединяются с локальным репозиторием.
Как использовать команду Git Merge?
Чтобы объединить изменения, полученные в предыдущем разделе, выполните следующую команду:
git merge
Если вы видите такой же результат, значит, вы успешно объединили изменения в своем локальном репозитории. На приведенном выше изображении третья строка показывает написанное Fast-forward (перемотка вперед). Это происходит потому, что это fast-forward merge (быстрое слияние), выполняемое git. Давайте посмотрим, что это такое.
Fast-Forward Merge
Fast-Forward Merge (быстрое слияние) в Git означает, что существует линейный путь от ветви, который отклоняется от ветви, к которой вы сливаетесь. Линейный путь означает, что не было никаких коммитов к главной ветви с тех пор, как ветвь объекта перешла в точку слияния.
На приведенном выше рисунке показано, что ветвь была отклонена, сделала три коммита, и за это время в главной ветви не было коммитов (зеленые точки). После трех коммитов я объединю ветвь функции в главную ветвь, что приведет к быстрой перемотке вперед.
Параметры в Git Merge
Опция –no-ff предотвращает слияние изменений git в ускоренной перемотке вперед.
git merge –no-ff
–no-commit
Опция no-commit не будет автоматически фиксировать слияние git и будет запрашивать вмешательство пользователя для завершения.
git merge –no-commit
В слиянии git есть еще много вариантов, которые вы можете изучить и опробовать в локальном репозитории. Git, будучи системой контроля версий, гарантирует, что истории коммитов этих отдельных ветвей остаются отдельными даже после завершения операции слияния. Слияние Git происходит после выборки изменений, то есть производительность выборки Git уже имеет место. Но есть способ обойти этот двухэтапный процесс и преобразовать его в один шаг. Он известен как pulling (вытягивание)в Git, и команда Git pull выполняет его. Более подробно рассмотрим эту команду в одной из следующих статей.
Частые вопросы
Что отличает git fetch и git pull?
Команда git fetch и команда git pull отличаются друг от друга по работе. Git fetch извлекает изменения, в то время как git pull объединяет их после извлечения. Таким образом, в некотором смысле git fetch является частью git pull, поскольку он сначала извлекает изменения, а затем выполняет git merge.
Могу ли я отменить изменения, внесенные git merge?
В последнем уроке мы познакомились с командой Git fetch и Read more
Мы уже знаем, как вносить изменения в локальное хранилище и Read more
Команда git push при выполнении перемещает изменения, внесенные пользователем на Read more
«Клонирование» означает создание идентичных особей естественным или искусственным путем. Клонирование Read more
Сегодня мы узнаем, как скопировать чужой репозиторий в наш аккаунт Read more
Все данные, доступные в локальном репозитории, могут быть загружены в Read more
Что произойдет при выполнении команды git fetch
Check your version of git by running
SYNOPSIS
DESCRIPTION
Fetch branches and/or tags (collectively, «refs») from one or more other repositories, along with the objects necessary to complete their histories. Remote-tracking branches are updated (see the description of below for ways to control this behavior).
git fetch can fetch from either a single named repository or URL, or from several repositories at once if is given and there is a remotes. entry in the configuration file. (See git-config[1]).
When no remote is specified, by default the origin remote will be used, unless there’s an upstream branch configured for the current branch.
OPTIONS
Use an atomic transaction to update local refs. Either all refs are updated, or on error, no refs are updated.
Deepen or shorten the history of a shallow repository to exclude commits reachable from a specified remote branch or tag. This option can be specified multiple times.
If the source repository is complete, convert a shallow repository to a complete one, removing all the limitations imposed by shallow repositories.
If the source repository is shallow, fetch as much as possible so that the current repository has the same history as the source repository.
By default, Git will report, to the server, commits reachable from all local refs to find common commits in an attempt to reduce the size of the to-be-received packfile. If specified, Git will only report commits reachable from the given tips. This is useful to speed up fetches when the user knows which local ref is likely to have commits in common with the upstream ref being fetched.
This option may be specified more than once; if so, Git will report commits reachable from any of the given commits.
The argument to this option may be a glob on ref names, a ref, or the (possibly abbreviated) SHA-1 of a commit. Specifying a glob is equivalent to specifying this option multiple times, one for each matching ref name.
Internally this is used to implement the push.negotiate option, see git-config[1].
Show what would be done, without making any changes.
When git fetch is used with : refspec it may refuse to update the local branch as discussed in the part below. This option overrides that check.
Keep downloaded pack.
Allow several and arguments to be specified. No s may be specified.
Modify the configured refspec to place all refs into the refs/prefetch/ namespace. See the prefetch task in git-maintenance[1].
See the PRUNING section below for more details.
See the PRUNING section below for more details.
This option controls if and under what conditions new commits of populated submodules should be fetched too. It can be used as a boolean option to completely disable recursion when set to no or to unconditionally recurse into all populated submodules when set to yes, which is the default when this option is used without any value. Use on-demand to only recurse into a populated submodule when the superproject retrieves a commit that updates the submodule’s reference to a commit that isn’t already in the local submodule clone. By default, on-demand is used, unless fetch.recurseSubmodules is set (see git-config[1]).
Number of parallel children to be used for all forms of fetching.
Typically, parallel recursive and multi-remote fetches will be faster. By default fetches are performed sequentially, not in parallel.
to paths printed in informative messages such as «Fetching submodule foo». This option is used internally when recursing over submodules.
By default git fetch refuses to update the head which corresponds to the current branch. This flag disables the check. This is purely for the internal use for git pull to communicate with git fetch, and unless you are implementing your own Porcelain you are not supposed to use it.
Use IPv4 addresses only, ignoring IPv6 addresses.
Use IPv6 addresses only, ignoring IPv4 addresses.
The «remote» repository that is the source of a fetch or pull operation. This parameter can be either a URL (see the section GIT URLS below) or the name of a remote (see the section REMOTES below).
A name referring to a list of repositories as the value of remotes. in the configuration file. (See git-config[1]).
tag means the same as refs/tags/ :refs/tags/ ; it requests fetching everything up to the given tag.
The remote ref that matches is fetched, and if is not an empty string, an attempt is made to update the local ref that matches it.
Unlike when pushing with git-push[1], there is no configuration which’ll amend these rules, and nothing like a pre-fetch hook analogous to the pre-receive hook.
Read refspecs, one per line, from stdin in addition to those provided as arguments. The «tag » format is not supported.
GIT URLS
In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent.
Git supports ssh, git, http, and https protocols (in addition, ftp, and ftps can be used for fetching, but this is inefficient and deprecated; do not use it).
The native transport (i.e. git:// URL) does no authentication and should be used with caution on unsecured networks.
The following syntaxes may be used with them:
Как научить людей использовать Git
По работе приходится участвовать в разных проектах, поэтому я хорошо знаю, как работают все мои коллеги. Помню, что компания начала использовать Git буквально за пару недель до моего прихода. На мониторах разработчиков кругом висели наклейки с напоминанием: сначала add, потом коммит, затем пуш.
Мне нравится составлять карту в голове. Я не говорю «ментальные карты», потому что это хорошо известный тип диаграмм. Речь о неких картинках, структурах или любом графическом представлении в уме. Например, в детстве я учила арифметику, представляя игральные кубики.
Поэтому я подготовила несколько рисунков. Не обязательно их смотреть, чтобы понять текст. Для каждого есть пояснение.
Кроме того, очень важно научить человека терминам. Иначе он не поймёт сообщения от Git. Рисунки — хороший способ.
Распределенная система контроля версий
На рисунке четыре области распределены следующим образом:
Клонирование репозитория
При клонировании данные из удалённого репозитория перемещаются в две области:
Внесение изменений в рабочий каталог
В рабочем каталоге два типа файлов:
Обновление удаленного репозитория
После подготовки изменений в рабочем каталоге их необходимо добавить в промежуточную область (staging area).
Когда там накопился ряд изменений с общей целью, самое время создать в локальном репозитории коммит с сообщением об этой цели.
Если в локальном репозитории есть один или несколько коммитов, готовых к совместному использованию всем остальным миром, они отправляются в удалённый репозиторий.
В этот момент можно говорить о различных состояниях файла в среде разработки: изменённом, промежуточном (staged) и зафиксированном (commited).
Далее вы можете объяснить:
Обновление среды разработки
Получение (fetching)
При выполнении git fetch данные из удалённого репозитория перемещаются только в локальный репозиторий.
Вытягивание (pulling)
При выполнении git pull данные из удалённого репозитория перемещаются в две области:
Дальнейшие действия
Можете добавить в среду разработки ещё одну область, чтобы проще прятать накопленные изменения: грязный рабочий каталог.
Когда люди усвоят эти понятия, вам будет легче объяснить дальнейшее: ветви, историю коммитов, перебазировку и так далее, потому что прочный фундамент уже заложен.
Дружеское напоминание
Я работала с другими системами управления версиями (Visual SourceSafe, TFS и Subversion): по моему скромному опыту, недостаток знаний вредит и со старым инструментом, и с новым. Сосредоточьтесь не только на выборе инструмента, но и на его освоении.
Дальнейшее чтение
Полученные отзывы
Мой друг Марк Виллаграса напомнил, что очень полезно решить задачки Git и делиться с коллегами решением.
И спасибо Стюарту Максвеллу, который поделился ссылкой на Hacker News, и u/cryptoz, который запостил её на Reddit!