Getting changes from a remote repository
You can use common Git commands to access remote repositories.
Options for getting changes
These commands are very useful when interacting with a remote repository. clone and fetch download remote code from a repository’s remote URL to your local computer, merge is used to merge different people’s work together with yours, and pull is a combination of fetch and merge .
Cloning a repository
To grab a complete copy of another user’s repository, use git clone like this:
You can choose from several different URLs when cloning a repository. While logged in to GitHub, these URLs are available on the main page of the repository when you click
When you run git clone , the following actions occur:
- A new folder called repo is made
- It is initialized as a Git repository
- A remote named origin is created, pointing to the URL you cloned from
- All of the repository’s files and commits are downloaded there
- The default branch is checked out
For every branch foo in the remote repository, a corresponding remote-tracking branch refs/remotes/origin/foo is created in your local repository. You can usually abbreviate such remote-tracking branch names to origin/foo .
Fetching changes from a remote repository
Use git fetch to retrieve new work done by other people. Fetching from a repository grabs all the new remote-tracking branches and tags without merging those changes into your own branches.
If you already have a local repository with a remote URL set up for the desired project, you can grab all the new information by using git fetch *remotename* in the terminal:
Otherwise, you can always add a new remote and then fetch. For more information, see «Managing remote repositories.»
Merging changes into your local branch
Merging combines your local changes with changes made by others.
Typically, you’d merge a remote-tracking branch (i.e., a branch fetched from a remote repository) with your local branch:
Pulling changes from a remote repository
git pull is a convenient shortcut for completing both git fetch and git merge in the same command:
Because pull performs a merge on the retrieved changes, you should ensure that your local work is committed before running the pull command. If you run into a merge conflict you cannot resolve, or if you decide to quit the merge, you can use git merge —abort to take the branch back to where it was in before you pulled.
git fetch
Команда git fetch загружает коммиты, файлы и ссылки из удаленного репозитория в ваш локальный репозиторий. Извлеките данные с помощью команды fetch, если хотите увидеть, над чем работают остальные. Эта команда похожа на команду svn update и позволяет увидеть прогресс в центральном репозитории, но при этом не вынуждает вас выполнять слияние изменений с вашим репозиторием. Извлеченное содержимое в Git остается изолированным от имеющихся локальных данных и совершенно не влияет на локальную разработку. Чтобы переключиться на извлеченное содержимое, нужно отдельно запустить команду git checkout . Таким образом, применение команды fetch позволяет безопасно просмотреть коммиты, перед тем как интегрировать их в локальный репозиторий.
Загрузить содержимое из удаленного репозитория можно с помощью двух команд: git pull и git fetch . Из этих двух команд git fetch можно считать «безопасным» вариантом. Она загружает удаленное содержимое, но не обновляет рабочее состояние локального репозитория, оставляя текущую работу нетронутой. Команда git pull действует более агрессивно: она загружает удаленное содержимое для активной локальной ветки и сразу выполняет команду git merge , создавая коммит слияния для нового удаленного содержимого. Если у вас есть ожидающие изменения, то возникнут конфликты, и будет запущен процесс разрешения конфликтов слияния.
Как git fetch работает с удаленными ветками
Чтобы лучше понять, как работает git fetch , давайте рассмотрим, как Git организует и хранит коммиты. На самом деле все коммиты (локальные и удаленные) хранятся в каталоге ./.git/objects . Git хранит коммиты удаленных и локальных веток раздельно в виде ссылок на ветки. Ссылки на локальные ветки хранятся в каталоге ./.git/refs/heads/ . При выполнении команды git branch будет выведен список ссылок на локальные ветки. Ниже приведен пример вывода команды git branch с несколькими демонстрационными именами веток.
Можно проверить содержимое каталога /.git/refs/heads/ — оно будет соответствовать полученному результату.
Удаленные ветки похожи на локальные, однако они сопоставляются с коммитами из репозитория другого пользователя. Удаленные ветки имеют префикс репозитория, которому принадлежат, поэтому вы не перепутаете их с локальными. Как и для локальных веток, Git также хранит ссылки на удаленные ветки. Ссылки на удаленные ветки находятся в каталоге ./.git/refs/remotes/ . В следующем фрагменте кода показаны ветки, которые можно увидеть после извлечения удаленного репозитория с именем remote-repo:
В выводе перечислены локальные ветки, показанные ранее, но теперь они отображаются с префиксом origin/ . Кроме того, можно видеть удаленные ветки с префиксом remote-repo . Переключиться на удаленную ветку можно так же, как и на локальную, но при этом указатель HEAD окажется в открепленном состоянии (как при переключении на старый коммит). Вы можете расценивать такие ветки как доступные только для чтения. Чтобы просмотреть удаленные ветки, просто передайте команде git branch флаг -r .
Просмотреть удаленные ветки можно с помощью привычных команд git checkout и git log . Если вы согласны с изменениями, которые содержит удаленная ветка, ее можно слить с локальной веткой обычной командой git merge . Таким образом, в отличие от SVN, синхронизация локального репозитория с удаленным происходит в два этапа: сначала выполняется извлечение данных, а затем их слияние. Удобная короткая команда git pull выполняет сразу оба этих процесса.
Команды и опции git fetch
Извлечение всех веток из репозитория. При этом также загружаются все необходимые коммиты и файлы из другого репозитория.
Аналогично команде выше, но данные извлекаются только для указанной ветки.
Мощная команда, которая извлекает все зарегистрированные удаленные репозитории и их ветки.
Опция —dry-run выполняет демонстрационный прогон команды. Она выводит на экран действия, которые были бы выполнены при извлечении, не выполняя их на самом деле.
Примеры использования git fetch
Извлечение удаленной ветки
В следующем примере будет показано, как извлечь удаленную ветку и обновить состояние локального рабочего репозитория содержимым удаленной ветки. Для этого представим, что существует центральный репозиторий origin, с которого с помощью команды git clone был клонирован локальный репозиторий. Допустим также, что имеется дополнительный удаленный репозиторий с именем coworkers_repo, содержащий ветку feature_branch, которую нужно будет настроить и извлечь. Приняв данные условия, продолжим пример.
Сначала необходимо настроить удаленный репозиторий с помощью команды git remote .
Создана ссылка на репозиторий коллеги с помощью URL‑адреса этого репозитория. Теперь передадим имя удаленного репозитория команде git fetch , чтобы загрузить его содержимое.
Теперь содержимое ветки coworkers/feature_branch представлено локально, и его нужно будет интегрировать с локальной рабочей копией. Начнем процесс с команды git checkout , чтобы переключиться на только что загруженную удаленную ветку.
Данный вывод команды checkout указывает на то, что указатель HEAD находится в открепленном состоянии. Такое состояние ожидаемо и означает, что ссылка HEAD указывает на ссылку, которая не соответствует локальной истории. Поскольку ссылка HEAD указывает на ссылку coworkers/feature_branch, из этой ссылки можно создать новую локальную ветку. В выводе, сообщающем об открепленном состоянии HEAD , указано, как это можно сделать с помощью команды git checkout :
Здесь создана новая локальная ветка с именем local_feature_branch. Теперь ссылка HEAD указывает на последнюю версию удаленного содержимого, и можно продолжать разработку, начиная с этой точки.
Синхронизация с репозиторием origin командой git fetch
В следующем примере рассматривается типичный процесс синхронизации локального репозитория с главной веткой центрального репозитория.
Эта команда покажет загруженные ветки:
На рисунке ниже коммиты из новых удаленных веток показаны не в виде кругов, а в виде квадратов. Как вы можете видеть, команда git fetch предоставляет доступ ко всей структуре веток другого репозитория.
Чтобы увидеть, какие коммиты были добавлены в вышестоящую главную ветку, можно выполнить команду git log , используя origin/main в качестве фильтра:
Чтобы подтвердить изменения и выполнить их слияние с локальной веткой main, используйте следующие команды:
Затем можно воспользоваться командой git merge origin/main :
Ветка origin/main и ветка main теперь указывают на один и тот же коммит, а ваш репозиторий синхронизован с вышестоящими результатами.
Сводная информация по git fetch
Рассмотренная команда git fetch — это основная команда, которая используется для загрузки содержимого из удаленного репозитория. Чтобы обновить локальный репозиторий до состояния удаленного репозитория, команда git fetch используется в сочетании с командами git remote , git branch , git checkout и git reset . Команда git fetch представляет собой важную часть рабочих процессов, связанных с совместной работой в Git. Поведение git fetch сходно с поведением команды git pull , однако git fetch можно считать более безопасным вариантом без разрушения информации.
Перемещение по истории — Введение в Git
Git позволяет не только просматривать историю. Еще мы можем перемещаться по истории, загружая в рабочую директорию состояние кода на момент выполнения любого коммита. В этом уроке мы изучим, как перемещаться по истории с помощью команды git checkout .
Для начала воспользуемся командой git log :
Переключимся на момент, когда был выполнен коммит с сообщением add INFO.md. Для этого используем команду git checkout <хеш коммита> :
Выполните команду выше и изучите рабочую директорию. Обратите внимание, что хеш вашего коммита может отличаться. Вы увидите, что пропала часть изменений из-за возврата в прошлое. Сами изменения никуда не делись, и мы снова можем вернуться на последний коммит следующей командой:
Переключившись в нужный коммит, можно не только изучить содержимое репозитория. Еще мы можем забрать какие-то изменения, которые были удалены, но снова понадобились для работы. Для этого достаточно их скопировать, переключиться на последний коммит и вставить в нужный файл.
Команда git branch
Переключение по коммитам отражается только на содержимом рабочей директории. Больше нигде не видно, где мы находимся. Из-за этого немало программистов забывают, где они находятся. Они начинают работать и очень удивляются, когда не получается выполнить коммит.
Самый простой способ узнать место нахождения — вызвать команду git branch . В обычной ситуации, когда мы находимся на последнем коммите, Git покажет такой вывод:
Но если прямо сейчас загружен коммит из прошлого, то вывод станет таким:
Такой способ проверки текущего местоположения требует постоянного внимания. Нужно не забывать его использовать. Конечно же, все забывают это делать, поэтому гораздо надежнее и удобнее вывести текущее местоположение прямо в командной строке. Например, так:
Именно так делают большинство профессиональных разработчиков. Как добиться такого вывода? Ответ на этот вопрос зависит от используемого командного интерпретатора:
В Bash вывод местоположения происходит благодаря редактированию переменной окружения $PS1 , подробнее об этом вы можете почитать по ссылке в дополнительных материалах.
Как загрузить последнюю версию проекта с сервера с помощью git?
На локалке есть версия проекта, где что-то пошло не так. Все зашло настолько далеко, что проще загрузить с git последнюю загруженную версию, где все работало.
Как это сделать?
Версию на локалке не коммитила
- Вопрос задан более трёх лет назад
- 11934 просмотра
- Вконтакте
- Вконтакте
Артем Калачян, я правильно понимаю, что после этой команды версия на локалке и версия на сервере будут одинаковые (как на сервере)?
P.S. переспрашиваю, потому как боюсь делов натворить))
Вас интересует следующее:
Как привести рабочую директорию к состоянию, в котором всё работало.
Ответ на этот вопрос дан выше: git reset —hard <коммит>.
HEAD — последний коммит, можно написать хеш более раннего коммита (см. git log)
К слову, для этого иметь подключение к серверу не обязательно, для таких задач git исходно и создавался.
Если же необходимо получить актуальную версию с сервера, то git pull.
Git stash — сохранить изменения в заначку, и переместить голову на последний комитета;
Git pull — получить последний комит
Дальше на выбор:
Либо git stash pop — натянуть спрятанные изменения на полученную версию
Либо git stash clear — очистить заначку
Ну или ресетнуть изменения
- Вконтакте
Stash вам даст время ещё подумать, «а нужны ли мои изменения».
После reset вам все равно делать git pull, что бы получить последнюю версию с сервера