git pull origin master что делает
Работа с удалёнными репозиториями
Для того, чтобы внести вклад в какой-либо 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 origin master в ветке разработки?
предположим, у меня есть частная ветвь темы под названием develop с 2 коммитами впереди master.
Что значит git pull origin master делать?
вытащить все из удаленного мастера в локальной разработке и объединить его? Вытащить все из местной главной ветви и объединить?
и есть ли способ обновить master от develop без git checkout master первый?
2 ответов
git pull origin master вытягивает главную ветвь из удаленного источника, называемого origin, в текущую ветвь. это влияет только на вашу текущую ветвь, а не на вашу локальную главную ветвь.
это даст вам историю, выглядящую примерно так:
Вашу локальную ветку master не имеет значения в этом. git pull по существу представляет собой комбинацию git fetch и git merge ; он извлекает удаленную ветвь, а затем сливает ее в текущую ветвь. Это слияние, как и любое другое; это не делает ничего волшебного.
если вы хотите обновить локальную главную ветку, у вас нет выбора, кроме как проверить ее. Невозможно объединить в ветку, которая не проверена, потому что Git нужно дерево работы для выполнения слияния. (В частности, это абсолютно необходимо для того, чтобы сообщать о конфликтах слияния и разрешать их.)
после фиксации изменений в ветке с помощью
затем вы можете сделать:
в вашу ветку, и это будет держать ваши коммиты поверх мастер-тяги. Теперь ваша ветка будет даже с master + вашими коммитами сверху. Итак, теперь вы можете сделать:
и git будет толкать ваши изменения вместе с master commits в вас ветку. Затем вы можете легко объединить это в master на Github.
Git для начинающих. Урок 6.
git push и git pull
Видеоурок
Конспект урока
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Во втором уроке мы создавали репозитории на github и научились клонировать их. После этого мы работали только с локальным репозиторием, на своей машине. Сегодня мы рассмотрим взаимодействие с удаленным репозиторием.
Что такое push (пуш)
Зачем пушить на сервер
Когда пушить на сервер
Когда сделали новый коммит или несколько коммитов
Как узнать, что есть незапушенные коммиты
В командной строке набрать git status
Ключевая фраза здесь «Your branch is ahead of ‘origin/master’ by 5 commits.». Это значит, что у нас есть 5 неотправленных на сервер коммитов. Если незапушенных коммитов нет, то картина будет такая
«is up-to-date» означает, что у нас нет незапушенных коммитов
master и origin/master
git push в терминале
Как пушить в PhpStorm
Что такое pull (пулл)
Это скачивание данных с сервера. Похоже на клонирование репозитория, но с той разницей, что скачиваются не все коммиты, а только новые.
Зачем пулиться с сервера
Чтобы получать изменения от ваших коллег. Или от себя самого, если работаете на разных машинах
git pull в терминале
Как пулить в PhpStorm
Когда что-то пошло не так.
Иногда при работе в команде git push и git pull могут вести себя не так, как пишут в учебниках. Рассмотрим примеры
git push rejected
Вы сделали новый коммит, пытаетесь запушить его, а git в ответ выдает такое
Написано много, но суть в том, что коммит отклонен, пуш не прошел. Почему?
Git устроен так, что локально мы можем коммитить сколько угодно. Но прежде чем отправить свои коммиты на сервер, то есть запушить, нужно подтянуть новые коммиты с сервера. Те самые, которые успели сделать наши коллеги. То есть сделать git pull.
Все, наши коммиты на сервере. При этом появится странный коммит «Merge branch ‘master’ of github.com:Webdevkin/site-git». Это так называемый мердж-коммит, о нем чуть ниже.
Если же при попытке пуша новых коммитов на сервере нет, то git push пройдет сразу и отправит наши коммиты на сервер.
Как избавиться от мердж-коммита
Мердж-коммит появляется, когда вы сделали локальный коммит, а после этого подтянули новые коммиты с сервера. Мердж-коммит не несет смысловой информации, кроме самого факта мерджа. Без него история коммитов выглядит чище.
При этом ваш локальный коммит окажется «поверх» нового коммита с сервера, а мердж-коммита не будет. И не забудьте после этого запушить свой коммит на сервер.
Мердж-коммит в PhpStorm
PhpStorm помогает избавиться от мердж-коммитов через меньшее количество действий. Если мы запушим локальные коммиты и получим rejected из-за того, что на сервере есть новые коммиты, то PhpStorm выдаст предупреждение, где предложит выбрать вариант: как подтянуть новые коммиты, с мерждем или ребейзом. Жмите кнопку «Rebase», мердж-коммита не будет и при этом локальный коммит сразу запушится на сервер.
Что могу посоветовать
Если мы работаем в одиночку, то удаленный репозиторий нужен только для сохранения резевной копии. Скорее всего, мы будем в него только пушить.
Но при работе в команде имеет смысл подумать над такими вещами:
Не переживайте, если иногда будете чувствовать себя, как друзья ниже. Это нормально, новый инструмент не осваивается за 5 минут. Немного практики, и мы будем понимать, почему иногда git ведет себя не так, как хочется, и главное, будем понимать, как это исправить.
В следующем уроке мы узнаем, что такое ветки и будем активно работать с ними. Там мы будем активно использовать git push и git pull, и это поможет закрепить уже пройденный материал.
Git для новичков (часть 2)
В прошлой статье, я рассказал, что такое Git, как его установить и выложить свой код на GitHub. Сегодня мы поговорим про работу в команде над одним проектом. И как это устроено в Git.
В данной статье, вся работа с Git будет через командную строку.
Совместная работа
Для того, чтобы создать новую ветку вводим:
Эти команды делают тоже самое, только второй вариант позволяет сразу переключиться в новую ветку. Вносить изменения в новую ветку можно сразу после ее создания.
При создании новой ветки, старайтесь называть ее кратким и ёмким именем. Чтобы сразу было понятно, что именно изменялось по проекту. Если вы используете, какую-нибудь систему для ведения задач, то можете в начале названия ветки указывать ID задачи, чтобы можно было легко найти, на основе какой задачи была создана ветка. Например вот так:
В каждом новом commit следует оставлять коммент и в нем описывать суть изменений.
Переключаться между ветками можно такой командой:
Для того чтобы посмотреть текущее состояние ветки, например, какие файлы добавлены или не добавлены для создания commit, можно выполнить команду:
Теперь все ваши изменения, в ветке master улетели в GitHub. Таким же образом, можно отправить любую другую ветку:
?Совет. Каждый коммит, лучше заливать сразу в удаленный репозиторий. Никто не застрахован, поломки собственного ПК. Поэтому чтобы не потерять все наработки, не забывайте сливать ваши изменения на GitHub.
Как же теперь другой человек получит все ваши изменения?
Для этого вам понадобиться GitHub или любой другой сервис для хранения кода. В прошлой статье я рассказывал как отправить код в GitHub. Сейчас я покажу, как его скопировать обратно себе на компьютер.
Если у вашего друга раньше не было проекта, то ему придется его «клонировать» себе:
? Адрес репозитория на GitHub можно получить, нажав на зеленую кнопку Code
После выполнения команды, в папке где появиться проект и ваш друг сможет с ним работать. Все ветки и их история также подтянуться.
Теперь самое главное
Перед тем, как создавать новый функционал и новую ветку, стоит обновить master на вашем устройстве. Для этого нужно находиться в этой ветке и выполнить следующую команду:
Таким же образом можно актуализировать любую другую ветку, заменив название ветки master на вашу.
Для обновления всех веток сразу, можно использовать такую, команду, но не рекомендую:
Теперь можно создавать новую ветку и кодить.
Какие проблемы могут возникнуть?
Git старается автоматически сливать изменения, однако это не всегда возможно. Иногда возникают конфликты. Например, когда в двух ветках были изменения в одной и той же строчке кода. Если такое произошло, то необходимо разрешить конфликт вручную. Для этого откройте файл там, где этого произошло. Например, вы можете увидеть что-то подобное:
После внесения нужных изменений добавьте ваш файл через git add как измененный и создайте новый commit:
Вспомогательные команды
Просмотреть изменения относительно двух веток можно командой:
Удалить ненужную ветку:
Просмотр историю ветки:
Подсказки по популярным командам:
Практика и вспомогательные инструменты
Для улучшения ваших навыков, в очередной раз оставлю ссылку на полезный тренажер с заданиями.
Так же, для удобства использования в Visual Studio Code, советую поставить это расширение, которое визуализирует ваши ветки и commit, и помогает с ними работать.