Работа с удалёнными репозиториями
Для того, чтобы внести вклад в какой-либо 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 pull
Использование git pull
Порядок действий
В этом сценарии команда git pull загрузит все изменения, начиная с того места, где разошлись локальная и главная ветки. В данном примере это точка E. Команда git pull получит удаленные коммиты из отходящей ветки (т. е. точки A‑B‑C). Затем в процессе запуска команды pull будет создан новый локальный коммит слияния, включающий содержимое новых удаленных коммитов из отходящей ветки.
На этой схеме видно, что при перебазировании с помощью команды pull не был создан новый коммит H. Вместо этого удаленные коммиты A‑B‑C были скопированы и добавлены в историю в локальной ветке origin/main перед локальными коммитами E–F–G с перезаписью последних.
Распространенные опции
Подобно вызову по умолчанию, извлекает удаленное содержимое, но не создает новый коммит со слитым содержимым.
Во время выполнения команды pull выдает подробный вывод о загружаемом содержимом и информацию о слиянии.
Обсуждение git pull
Сначала вы думаете, что ваш репозиторий синхронизирован, однако команда git fetch показывает, что с момента последней проверки версия origin ветки main была изменена. Затем команда git merge сразу интегрирует удаленную ветку main в локальную ветку.
Git pull и синхронизация
Команда git pull — одна из множества команд, отвечающих за синхронизацию удаленного содержимого. Команда git remote используется, чтобы указать, на каких удаленных конечных точках будут работать команды синхронизации. Команда git push используется для выгрузки содержимого в удаленный репозиторий.
Сравнение pull и rebase
Примеры использования git pull
В нижеприведенных примерах показано, как использовать команду git pull в общих сценариях.
Поведение по умолчанию
Команда git pull на удаленных ветках
Перебазирование с помощью git pull вместо слияния
В следующем примере показано, как выполнить синхронизацию с главной веткой main центрального репозитория, используя перебазирование.
В этом примере ваши локальные изменения просто помещаются поверх изменений всех остальных участников разработки.
Всем привет. Сегодня мы разберем с вами подробнее команды git pull и git push. Сначала разберем git pull. До этого мы с вами писали команду git pull и все работало. Что делает эта команда? Внутри себя на самом деле она выполняет две команды:
Команда git fetch сливает все данные с проекта, которые находятся в нашем remote репозитории. Все данные которых у нас нет она сливает, но не применяет в наши ветки. Ее можно использовать безбоязненно даже не думая, что что-то поломается. И потом git merge мерджит текущую ветку с такой же веткой из репозитория.
Здесь мы указываем в какой ремоут мы хотим запушить и на какую ветку. По умолчанию гит настроен так, что команда git push пушит в ветку с таким же именем на сервере, а если ее нет то создает ее.
Очень часто с короткой записью pull и push возникает проблема что команда вываливается с ошибкой, что она не знает с какой ремоут веткой работать.
Давайте рассмотрим на примере:
Создадим новую ветку
Ветка запушилась без проблем. Но теперь если мы напишем git pull, то получим замечательную ошибку
То есть гит не знает какой ремоут ветке соответствует эта локальная ветка. Первый вариант решения это всегда писать
Второй вариант это указать трекинг информацию для этой ветки и тогда мы всегда будем пулить правильную ветку.
После выполнения этой команды можно спокойно использовать git pull и ошибок не будет.
Git push, git pull, git fetch — в чем разница? Шпаргалка по git-командам
Git — это распределенная система контроля версий. Она позволяет хранить данные обо всех изменениях кода в конкретных папках на жестком диске и обеспечивает удобную командную работу.
Git push
Команда git push в ходе выполнения переносит все изменения, внесенные юзером, в удаленный репозиторий (например, такой как GitHub):
Вынужденная команда push при корректировке коммитов:
Git pull
Команда git pull отвечает за скачивание данных с сервера. Процесс очень похож на клонирование репозитория, но здесь скачиваются не все коммиты, а только новые.
По сути, git pull — это сочетание команд git fetch (загружает коммиты, ссылки, файлы из удаленного репозитория в локальный) и git merge (объединяет несколько коммитов в один общий).
Git pull для удаленной ветки
Git fetch
Синхронизация с командой git fetch origin
Это отобразит ветки, которые уже были загружены:
Git merge
Команда git merge связывает ряд коммитов в одно целое. В свою очередь git создает коммит слияния, где и объединяются изменения обеих последовательностей.
Конфликт в слиянии
По завершению слияния, выполните команду git add : таким образом вы проинформируете, что причина конфликта разрешена. Важно запомнить, что конфликты допустимы только в трехслойном слиянии и никогда не возникают при ускоренном.
Разница между командами git
Условно говоря, git pull – это последовательность двух команд: git fetch (прием изменений от сервера) и git merge (слияние).
В свою очередь, git push переносит ветвь разработки в удаленную исходную точку, а git merge — объединяет изменения из разработки в локальную ветку.
Шпаргалка по git-командам
git init — создание новых репозиториев;
git clone — клонирование удаленного репозитория;
git rm — удаление файла;
git log — просмотр истории коммитов;
git branch
— создание новой ветки;
git branch –d
— удаление ветки;
git merge
— слияние веток;
git push
— отправка ветки на удаленный сервер;
git push :
— удаление ветки на удаленном сервере;
git tag — просмотр меток;
git push — обмен метками;
git remote — отображение удаленных репозиториев;
git pull
— получение данных из удаленного репозитория и слияние с локальным;
git push
— отправка локальных изменений на удаленный сервер.
Команда Git Pull
Мы уже рассмотрели git merge, теперь перейдем к pull.
Команда pull забирает изменения из удаленного репозитория и интегрирует их с изменениями в локальном репозитории.
Пример использования
Чтобы забрать изменения из удаленной ветки dev репозитория origin и слить их с изменениями в текущей ветке, где мы находимся, выполним:
Это аналогично двум последовательным командам:
Обратите внимание, что перед выполнением команды pull все текущие изменения должны быть закоммичены, так же, как перед выполнением команды merge. Иначе слияние не выполнится.
Параметры по умолчанию
Если попробовать выполнить pull без параметров, находясь в ветке master:
команда выполнится. Но с какой же веткой происходит в этом случае слияние? По умолчанию это ветка master репозитория origin. (При клонировании удаленного репозитория по умолчанию ему дается имя origin). То есть команда аналогична:
Как видите, для ветки master заданы параметры по умолчанию. Можно их задать и для других веток. Связывание локальной ветки и удаленной ветки называется отслеживанием ветки.
Настройка отслеживаемой ветки
Давайте сделаем так, чтобы, когда мы находимся в локальной ветке dev, по умолчанию слияние происходило с веткой dev репозитория origin. Перейдем в ветку dev и выполним команду:
Эта команда связало локальную ветку dev с удаленной веткой origin/dev.
Теперь когда мы находимся на локальной ветке dev и выполняем pull без параметров, слияние происходит по умолчанию с удаленной веткой dev:
То есть теперь вышеприведенная команда без параметров будет аналогична команде с параметрами:
git pull vs. git fetch
git fetch просто обновляет локальную копию удаленного репозитория. То есть все копии удаленных веток (которые записываются через слеш — например, origin/master) будут содержать самый последний коммит из удаленного репозитория.
Но при этом содержимое локальных веток, в том числе той, на которой вы находитесь, не меняется. В папках остаются те же файлы. Команда fetch безвредна и ее можно делать сколько угодно раз. Иногда даже пишут скрипт, который выполняет git fetch в фоновом режиме.
Команда pull же состоит из fetch и merge. То есть помимо обновления копии удаленного репозитория на вашем компьютере, она еще и реально меняет содержимое папок, с которыми вы работаете. Вливает удаленную ветку в текущую.
git pull —rebase
Рассмотрим команду pull с параметром rebase:
На результат слияния параметр —rebase не влияет, единственное, что он делает — меняет вид истории коммитов.
До команды pull
Допустим, мы разветвились с удаленным репозиторием на коммите D:
До pull
Наши локальные коммиты с момента разветвления — это нижние E, F, G, а в удаленном репозитории с тех пор появились коммиты A, B, C. Нам надо их накатить сверху на наши коммиты E, F, G, что собственно и делает команда pull.
Обычный pull
Но тут возможны нюансы. По умолчанию делается дополнительный коммит H, который и включает все изменения из удаленной ветки:
git pull
pull —rebase
Если же мы выполним:
то история локальных коммитов будет выглядеть по другому (при том же результате слияния файлов):
git pull —rebase
При просмотре истории коммитов мы просто увидим ряд коммитов из основной ветки A, B, C, идущих за нашими локальными E, F, G. Кому-то такой вид выглядит чище, хотя разницы в итоговом содержимом файлов нет.
git pull force
Насильно выполнить git pull нельзя. Она не перезапишет локальные изменения, если есть конфликт. Конфликт все равно придется разрешать.
Если же требуется получить данные из удаленной ветки, перезаписав локальные изменения, то делается это в два этапа. Сначала обновить локальную копию удаленного репозитория:
Далее, допустим надо перезаписать содержимое текущей ветки данными из ветки master репозитория origin:
Если надо перезаписать содержимое текущей ветки данными из другой ветки dev репозитория origin:
Но будьте внимательны с опцией —hard, она действительно затирает коммиты текущей ветки безвозвратно. Если надо их сохранить, то перед выполнением команды создайте новую ветку — в нее все сохранится:
Что еще интересно: коммиты reset —hard затирает, а если в папке были просто неотслеживаемые файлы, то они не будут затронуты.
Итоги
Команда pull — на любителя, потому что не всем нравится автоматически сливать ветки. Гораздно прозрачнее делать отдельно fetch и merge.
