Info
Content

7. git pull & git push

git fetch

Позволяет скачивать объекты и ссылки с удаленного репозитория

  • --all - скачать все
  • -t/--tags - скачать все теги

git fetch origin - обновить состояние всех веток в соответствии с репозиторием origin
git fetch -t - скачать все метки


Если необходимо скачать только новые файлы с удалённого репозитория, не обновляя существующие на локальном, то подходит команда git fetch

git pull

Скачать и синхронизироваться с репозиторием

git pull [opts] [<repo> [<refspec> ..]]

Слить удаленную ветку next в текущую

git pull origin next

Пример
Локально закоммитили и запушили
После этого на сервере кто-то закоммитил
Делаем изменения у себя локально без коммита
Пытаемся спуллить
Возникнет конфликт

git push

  • <repository> - Имя или URL удалённого репозитория, на который необходимо загрузить данные
  • <refspec> - указывает, какую ссылку необходимо обновить в соответствии с каким объектом. Пример использования: "+<объект>:<ссылка>"
  • --all - Загрузить все ветки (то есть refs/heads/); не может быть использован вместе с <refspec>
  • --delete - Удалить все перечисленнык ссылки с удалённого репозитория. Имеет тот же самый эффект, что и запись ":<ссылка>"
  • -f --force - Обычно невозможно обновить ссылку на удалённом репозитории, если объект, который необходимо перезаписать, не был предком нового объекта. Для решения этой проблемы можно воспользоваться этим ключом

Загрузить изменения в конкретную ветку на удалённом репозитории

git push origin branch_name

Разрешение конфликтов

Конфликт - это ситуация, когда, в ходе слияния (pull/push/merge) система не может решить какие изменения нужно сохранить
Чаще всего такое бывает когда из одного коммита создано несколько веток и в один и тот же файл внесены изменения без синхронизации между ветками

Пример
Terminal_2021-02-14-22-50-30.png
Из мастера ответвились дважды и наделали независимых изменений
Далее смерджили первую ветку в мастер (все окей)
А когда попытаемся смерджить вторую ветку в мастер - будет конфликт

Внутри конфликтного файла будет такое

<<<<<<< HEAD
Changes from branch2
=======
Changes from branch1
>>>>>>> master
  • между <<<<<<< HEAD и ======= - изменения, которые были внесены в текущей ветке/версии
  • между ======= и >>>>>>> master - изменения, которые были в ветке master на момент слияния (может быть указан хэш коммита вместо названия ветки)

Упрощенное разрешение конфликтов

git checkout --ours README.md # оставляем изменения из текущей ветки (отвергаем изменения из ветки которую мерджим в текущую)  
git checkout --theirs README.md # наоборот  

(логика простая, либо оставляем НАШЕ, либо оставляем ИХ)

Далее git add, git commit и все становится хорошо


Ручное разрешение конфликтов

Ручное разрешение конфликтов подходит в ситуациях, когда необходимы изменения, добавленные во всех конфликтующих ветках. Например, если в branch1 были добавлены стили, а в branch2 исправлены ошибки текста. Для ручного разрешения конфликта необходимо проделать следующее во всех конфликтных файлах (причем конфликт может возникать в нескольких местах одного файла):

  • Удалить метки, которые добавил git
  • Оставить одну, наиболее подходящую версию изменений

Для всех файлов с исправленным конфликтом необходимо сделать git add, после чего закоммитить и повторить операцию слияния

В данном примере, конфликт можно было спровоцировать, проделав git pull branch2 из ветки branch1 или наоборот. Алгоритм разрешения конфликтов в подобной ситуации аналогичен

No Comments
Back to top