Как сделать cherry pick
GIT Cherry-pick
Введение в GIT Cherry-pick
В этой статье мы подробно узнаем о GIT Cherry-pick. Есть много программистов, работающих над одной и той же разработкой программного обеспечения из разных уголков мира. Тогда как управлять кодами? Как они заставят других понять, какие изменения они внесли? Как зафиксировать коды и поддерживать разные версии? Как объединить коды?
Чтобы решить эти проблемы, GIT вошла в мир разработки. GIT является выдающейся системой управления исходным кодом (SCM) и распределенной системой контроля версий. GIT был создан Linux Torvald, человеком, который разработал ядро Linux. Очевидно, что это инструмент с открытым исходным кодом, где каждый программист может внести свой вклад в создание программного обеспечения из любой точки мира.
GIT имеет много функций. Может иметь несколько ветвей. Разработчик может написать коды после создания своей собственной ветки в локальной системе и объединить ее с основной веткой или другими ветками удаленного GIT-репозитория.
Что такое GIT Cherry-pick?
Представьте себе, продолжается работа над проектом сценария по истории и эволюции сотовых телефонов. Итак, над одним проектом работает много людей, и все работают отдельно. Однако, в конце концов, каждый скрипт будет скомпилирован вместе.
Теперь член А пишет о телефонах Apple и вдруг понимает, что это может быть лучше. Таким образом, он сообщил об этом другим членам команды, которые работают над тем же проектом. Другой член Х сказал ему, что он пишет сценарий на телефонах Android, и попросил члена А посмотреть.
Затем член А изучил сценарий товарища по команде и обнаружил, что некоторые части совпадают с некоторыми действительно хорошими изменениями. Поэтому он выбрал эти изменения и вставил в свой сценарий. Это то же самое, что Cherry-Pick называет в GIT в области программного обеспечения.
Используйте команду ниже (в системе Unix), чтобы узнать различные опции для git-cherry-pick,
Команда:
Синтаксис для команды cherry-pick,
Синтаксис:
git cherry-pick (–edit) (-n) (-m parent-number) (-x)
Когда мы используем GIT Cherry-pick?
Как работает GIT Cherry-pick?
Обнаружен дефект в коде в производственной среде, и необходимо внести исправление. После внесения изменений и исправления дефекта настало время вернуть это изменение кода в среду разработки, чтобы в будущем дефект не возникал снова и снова в производственной среде.
Cherry-pick приносит тот коммит, который был сделан только для исправления ошибки. Он не выбирает другие коммиты.
Рисунок 2: Теперь коммит H выбирается в ветке разработки, и в результате коммит H ‘. Изменения Commit G не включены в ветку Development.
Как использовать GIT Cherry-pick с примером?
Предположим, у нас есть две ветви (master и new_feature) (команда, используемая для просмотра ветви branch-git)
Тем не менее, он должен быть только в основной ветке. Сначала скопируйте выделенный SHA в блокноте.
Теперь мы будем использовать команду git-cherry-pick для перемещения этого коммита в основную ветку, однако перед этим нам нужно переключиться на основную ветку (команда, используемая для переключения проверки ветки-git )
(команда использовала git — cherry — pick ) (тот же SHA должен быть вставлен, который был скопирован ранее в блокнот с помощью команды git cherry-pick)
Теперь мы видим, что тот же коммит доступен в основной ветке (команда used-git log)
Более подробный пример команд git cherry-pick смотрите по ссылке ниже:
Важные вещи для запоминания
При использовании cherry-pick и работе в команде нужно помнить три вещи.
Это позволит избежать слияния конфликтов в будущем.
2. скопируйте заметки: иногда у некоторых из «вишневого кирки» есть заметки, и когда мы запускаем «вишневый кирк», они не копируются. Поэтому лучше его использовать.
3. Выберите несколько коммитов, когда они только линейные: мы хотим выбрать несколько коммитов типа G, H (рис. 1), если они линейные, тогда используйте только следующую команду:
Вывод
Предположим, что мы хотим выбрать конкретный коммит из другой ветви и применить к текущей ветви, вот рекомендуемые шаги,
1. Найдите хеш коммита, который нужно сначала выбрать из вишни.
2. Перейдите в ветку назначения.
Разрешите конфликты, если они случаются. Если в исходном коммите есть заметки, их нужно скопировать.
Рекомендуемые статьи
Хватит копировать, пора сливаться. Часть 1. Конфликт слияний
Несмотря на распространённость операции git cherry-pick (копирование коммитов) в Git, обычно это не самое лучшее решение. Иногда это меньшее из двух зол, но я ещё не видел ситуации, где оно было бы целесообразно.
Это первая часть из серии статей, которые начинаются объяснением почему копирование это плохо, продолжаются рассказом почему это ужасно, а затем описывают как получить тот же результат, применяя слияние (merge). Я покажу как применить эту технику в случае, когда вам нужно сделать слияние со старыми коммитами (retroactive merge) и когда вы хотите исправить копирование на слияние пока не случилось чего-нибудь плохого.
В копировании задействованы две ветки: донорская (откуда берётся коммит) и принимающая (куда он копируется). Давайте назовём их соответственно master и feature. Для простоты предположим, что копируемый коммит содержит изменение только в одной строке единственного файла. На данной диаграмме каждый коммит помечен содержанием этой строки, а штрихованная стрелка означает само копирование (операцию git cherry-pick ).
Внимание! Все стрелки перевёрнуты! A git cherry-pick в дереве появляются две копии одного коммита. Если хотя бы одна из его строк поменяется до слияния её копий, то возникнет невынужденная коллизия. Причём это может произойти и через неделю, и через год. Это значит, что тот, кто будет её разрешать, может попросту не иметь ресурсов для принятия правильного решения (не он копировал, команда полностью поменялась и проч).
Однако, вся эта Санта-Барбара может стать ещё хуже если конфликта не произойдёт!
Что значит Cherry Picking в тестировании
Когда это происходит: в том случае, если разработчам удалось создать большое количество новых фич, но менеджмент считает, что не стоит выкатывать сразу все.
Почему бы не выложить сразу все фичи:
git cherry-pick
В git существует команда
Прочитать спецификацию можно здесь
git cherry-pick-это мощная команда, которая позволяет выбирать произвольные коммиты Git по ссылке и добавлять их к текущей рабочей головке.
git cherry-pick может быть полезен для отмены изменений.
Например, предположим, что коммит случайно сделан не в ту ветвь.
Вы можете переключиться на правильную ветвь и выбрать фиксацию там, где она должна быть.
Когда использовать git cherry pick
git cherry-pick-полезный инструмент, но не всегда лучшая практика.
Сбор вишни может привести к дублированию коммитов, и во многих сценариях, где сбор вишни будет работать, вместо этого предпочтительны традиционные слияния.
С учетом сказанного git cherry-pick-это удобный инструмент для нескольких сценариев.
Командное сотрудничество.
Часто команда находит отдельных членов, работающих в одном и том же коде или вокруг него.
Возможно, новая функция продукта имеет бэкэнд и фронтенд-компонент.
Возможно, существует некоторый общий код между двумя секторами продукта.
Возможно, бэкэнд-разработчик создает структуру данных, которую также должен будет использовать фронтэнд.
Фронтенд-разработчик может использовать git cherry-pick для выбора коммита, в котором была создана эта гипотетическая структура данных.
Этот выбор позволит разработчику frontend продолжить работу над своей частью проекта.
Исправления ошибок
При обнаружении ошибки важно как можно быстрее доставить исправление конечным пользователям.
Например,предположим, что разработчик начал работу над новой функцией.
Во время разработки этой новой функции они выявляют уже существующую ошибку.
Разработчик создает явную фиксацию исправления этой ошибки.
Эта новая фиксация патча может быть выбрана непосредственно в главной ветви, чтобы исправить ошибку, прежде чем она повлияет на большее количество пользователей.
Отмена изменений и восстановление потерянных коммитов
Иногда ветвь функции может устареть и не слиться с мастером.
Иногда запрос на вытягивание может быть закрыт без слияния.
Git никогда не теряет эти коммиты, и с помощью таких команд, как git log и git reflog, их можно найти и вернуть к жизни.
Как использовать git cherry pick
Чтобы продемонстрировать, как использовать git cherry-pick, предположим, что у нас есть репозиторий со следующим состоянием ветви:
использование git cherry-pick является прямым и может быть выполнено следующим образом:
git cherry-pick commitSha
Нужную commit reference можно найти с помощью git log.
В этом примере мы хотим черрипикнуть commit `f` в master.
Сначала мы удостоверяемся, что работаем над master.
git checkout master
Затем мы выполняем cherry-pick следующей командой:
После выполнения наша git history будет выглядеть так:
Коммит f был успешно черрипикнут в главную ветвь
Примеры git cherry pick
git cherry pick также может выполнен с различными опциями:
В дополнение к этим полезным опциям git cherry-pick также принимает различные варианты стратегии слияния.
Подробнее об этих параметрах читайте в документации git merge strategies.
Резюме
Git. Урок 5.
Слияние изменений и продвинутая
работа с ветками.
Команды: merge, cherry-pick, rebase.
1. Что такое слияние и зачем оно нужно.
2. Слияние в Git. Команда git merge.
2.1 Явное слияние
2.2 Неявное слияние (fast-forward)
2.3 В чем разница между fast-forward и явным слиянием?
3. Разрешение конфликтов слияния.
3.1. Ручное разрешение конфликта
3.2. Выбор одного из двух файлов
3.3. Тонкости разрешения merge-конфликтов.
3.4. Инструменты для разрешения merge-конфликтов.
4. Еще один способ объединения изменений из разных веток. Команда git rebase.
5. Интерактивный git rebase. Редактирование коммитов любой давности.
6. Берем вишенку с торта. Команда git cherry-pick.
То есть общий ход нашей работы выглядит следующим образом:
1. Решили добавить новую функцию – создали отдельную ветку. Дальше работаем в новой ветке.
2. Написали функцию, протестировали ее работу, внесли все необходимые исправления, еще раз протестировали и убедились, что функция работает исправно и не привнесла ошибок в остальной код.
3. Теперь нужно как-то перенести изменения с тестовой ветки на основную – в продакшн. Тут нам на помощь и приходит слияние: мы просто сливаем (т.е. переносим) изменения с нашей тестовой ветки в основную.
Итак, дадим определения:
Команда git merge
—abort
Ключ, использующийся только при разрешении конфликтов. Позволяет прервать слияние и вернуть все к моменту начала операции.
—continue
Ключ, использующийся только при разрешении конфликтов. Позволяет продолжить слияние после разрешения всех конфликтов.
2. 1. Явное слияние
Допустим, у нас есть граф вида:
Флаг —no-ff в данной ситуации необходим, поскольку мы хотим выполнить именно явное слияние. Подробнее о смысле этого флага мы поговорим чуть позже.
2.2. Неявное слияние
Давайте рассмотрим пример. Допустим, у нас есть все тот же граф репозитория:
Очень часто во время слияния веток оказывается, что ваши изменения удаляют или переписывают информацию в уже существующих файлах. Такая ситуация называется файловым конфликтом. Git останавливает выполнение слияния, пока вы не разрешите конфликт.
По сути, Git сталкивается с проблемой: у него есть два файла с одним и тем же именем, и он не знает, какой из них взять. Поэтому обращается к нам за помощью.
Давайте сразу начнем с примера и по ходу будем учиться разрешению конфликтов. Так будет нагляднее. Итак, допустим есть следующий репозиторий:
3.1. Ручное разрешение конфликта
3.2. Выбор одного из двух файлов
Дальше все стандартно: откроется редактор сообщения коммита. В сообщении следует указать, какие ветки вы сливали, и вкратце перечислить внесенные изменения.
3.3. Тонкости разрешения merge-конфликтов.
Теперь мы имеем представление, как разрешать конфликты слияния, и пришло время углубиться в эту тему. Поговорим о тонкостях, которые помогут вам понять, как правильно разрешить конфликт. Подчеркиваем: «правильно», поскольку разрешить конфликт не составляет труда, но если сделать это неверно, можно потерять код, написанный другими разработчиками.
Видно, что файлы различаются, но из этого представления совсем непонятно, что именно должно войти в итоговый файл. Если бы это был ваш личный проект, вы бы прекрасно знали, какой из файлов выбрать, но это чужой репозиторий и цена ошибки велика. Конечно, можно потратить много времени, перебирая коммиты из обеих веток, разбираясь, как менялись файлы, чтобы понять, что должно быть в итоговом файле. Но можно поступить проще. Прежде всего, давайте изучим немного теории.
Итак, при слиянии двух веток используются четыре состояния, и три из них необходимы, чтобы разрешить конфликт правильно. Давайте разбираться, что это за состояния.
Эти состояния можно изобразить на диаграмме следующим образом.
Чтобы понять, что изображено на диаграмме, полезно будет вспомнить, что такое дельта.
Дельта – это разность каких-то двух состояний. То есть по сути это информация о том, какие изменения вы внесли в файлы с момента определенного коммита. Как мы помним из второго урока данного курса, коммиты хранят именно дельты, а не полностью файлы. Благодаря этому репозиторий Git занимает очень мало места.
На диаграмме выше Дельта-1 – это разность текущего состояния ветки main и базы слияния. Аналогично Дельта-2 – это разность текущего состояния ветки develop и базы слияния.
Результат слияния нам как раз и нужно получить. Git пытается получить его автоматически, совмещая Дельту-1 и Дельту-2, но если эти дельты задевают одни и те же части одного и того же файла, возникает конфликт. При возникновении конфликта Git просит нас сравнить Дельту-1 и Дельту-2, чтобы составить из них третье состояние – результат слияния.
3.4. Инструменты для разрешения merge-конфликтов.
Использование графических утилит особенно удобно при сравнении больших файлов: почти во всех есть подсветка внесенных изменений, что поможет вам не запутаться в файле. Тем не менее при сравнении маленьких файлов часто можно обойтись одной консолью. Кстати, большинство IDE имеет встроенную утилиту для разрешения конфликтов, что сделает вашу работу с кодом еще более удобной.
Если говорить кратко, git rebase переносит коммиты текущей ветки на вершину переданной. Но перед тем, как перейти непосредственно к команде, давайте разберем принцип ее действия на примере. Пусть у нас есть репозиторий со следующим графом.
Команда git rebase
-i
—interative
Эти ключи позволяют нам делать rebase в интерактивном режиме. Мы будем активно пользоваться ими при редактировании старых коммитов.
—abort
Ключ, использующийся только при разрешении конфликтов. Позволяет прервать ребейз и вернуть все к моменту до начала операции.
—continue
Ключ, использующийся только при разрешении конфликтов. Позволяет продолжить ребейз после разрешения всех конфликтов.
—skip
Ключ, использующийся только при разрешении конфликтов. Позволяет пропустить текущий коммит.
После выполнения всех вышеуказанных операций, граф репозитория будет выглядеть так.
В предыдущем уроке мы с вами разобрали, помимо прочего, как можно объединить несколько последовательных коммитов в один и как редактировать содержимое и сообщение последнего коммита ветки. Но что если мы хотим отредактировать более ранний коммит? Git предоставляет нам и такую возможность. Правда тут мы воспользуемся небольшой хитростью.
На самом деле git rebase можно выполнять для одной и той же ветки. В обычном режиме это нам ничего не даст, но вот в интерактивном режиме мы сможем поменять сообщения, содержимое и вообще манипулировать коммитами, как нам только вздумается, вплоть до удаления. Давайте на примере разберем, как происходит изменение коммитов. Итак, допустим у нас есть репозиторий, граф которого выглядит так:
Команда git cherry-pick
-e
—edit
С этим ключом вы сможете отредактировать сообщение коммита.
-n
—no-commit
С этим ключом команда не создаст коммит на вашей ветке, а только скопирует все изменения в вашу рабочую копию. То есть с этим ключом данная команда идентичная git checkout *
—abort
Ключ, использующийся только при разрешении конфликтов. Позволяет прервать операцию и вернуть все к моменту до начала операции.
—continue
Ключ, использующийся только при разрешении конфликтов. Позволяет продолжить операцию после разрешения всех конфликтов.
Берет переданный коммит и создает в текущей ветке его точную копию.
Также в команду можно передать первый и последний коммит последовательности, тогда та же операция будет выполнена для всех коммитов последовательности.
1. Случай первый. Работа в команде.
Этот случай был описан во введении к данной части. Часто в команде несколько разработчиков работают над одним и тем же участком кода, но каждый – в своей ветке. Соответственно могут возникать ситуации, когда одному из разработчиков для реализации своей части задачи потребуется часть кода, написанная другим разработчиком. Merge в данном случае делать нерационально, поскольку ни одна из веток не пришла к своему логическому завершению, а вот cherry-pick – то, что надо.
2. Случай второй. Быстрые исправления багов.
Если в коде был обнаружен баг, очень важно как можно быстрее донести исправления до конечного пользователя. В таком случае, разработчик, обнаруживший ошибку, срочно создает коммит, в котором исправляет ее. Этот коммит может быть перенесен в основную ветку с помощью cherry-pick, чтобы не задерживать исправление бага слияниями в различные пре-релизные ветки.
Раскладываем Git по полочкам: терминология
Что это за зверь?
Git — распределённая система управления версиями. Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки.
Ничего не понятно, давай еще раз
Какие такие версии?
Версия — это состояние файла (или нескольких файлов) в какой-то конкретный момент времени. Например, пустой файл (1), тот же файл с каким-то текстом (2) и этот же файл, в котором была исправлена опечатка (3) — три разные версии одного файла, которые были получены последовательной модификацией (изменением) файла.
Системы чего.
Система управления версиями — программа, позволяющая сохранять состояние файлов (те самые версии), возвращаться к ранее сохраненному состоянию, сохранять последовательность изменений внесенных в файлы, отменять или заново применять эти изменения, отслеживать авторство изменений.
Что там с этими версиями делают?
Разделение версий — независимые изменения одного файла.
Версионность на примере текстового файла
Например, у нас есть файл с каким-то текстом (версия этого файла). Файл отправляется на проверку, там обнаруживается и исправляется опечатка (получаем новую версию файла). Независимо от этого в старый (неисправленный) файл дописывается еще что-то (получаем еще одну версию этого файла). Т.е., на данный момент у нас есть два разных файла (две версии одного файла), которые были независимо друг от друга созданы на основе одной общей версии.
Слияние версий — объединение двух и более независимых версий. Для примера выше, слиянием будет объединение двух существующих версий нашего файла в одну — файл, в котором будет и новый текст, и исправленная опечатка.
А при чем тут история?
История разработки — совокупность всех версий файлов, над которыми ведется работа. Историей разработки в данном случае будет список изменений:
добавление изначального текста
добавление нового текста
объединение двух версий файла (при выполнении слияния)
Нелинейная история — история, в которой изменения вносятся не одно за другим последовательно, а может быть внесено несколько независимых изменений на основе одной версии файла (исправление опечатки и добавление нового текста). Т.е. мы создаем две параллельные истории изменений файла.
Немного терминологии
Репозиторий (repository) — совокупность файлов, состояние которых отслеживается, и история их изменений. По факту, репозиторий — это проект, над которым ведется работа, и все изменения в этом проекте. Для отслеживания состояния файла его необходимо добавить в репозиторий.
Коммит (commit) — сохраненное состояние (версия) файлов репозитория.
Ветка (branch) — последовательность коммитов (история изменения состояния репозитория). Каждый коммит в ветке имеет «родителя» (parent commit) — коммит, на основе которого был получен текущий. В репозитории может быть несколько веток (в случаях, когда к одной версии репозитория применяется несколько независимых изменений).
HEAD — указатель на текущий коммит (указатель на состояние, в котором репозиторий находится на данный момент).
Мастер (master, main) — основная ветка репозитория, создается автоматически при создании репозитория.
Мердж (слияние, merge) — объединение двух или более веток. В процессе мерджа изменения с указанной ветки переносятся (копируются) в текущую.
Целевая ветка мерджа — ветка, изменения с которой объединяются с текущей веткой.
База слияния (merge base) — последний общий коммит двух веток.
Мердж коммит (merge commit) — коммит, который создается автоматически по завершению процесса слияния веток. Мердж коммит содержит в себе все изменения целевой ветки мерджа, которые отсутствуют в текущей (все коммиты целевой ветки, которые начиная с базы слияния, но не включая её).
Слияние перемоткой (fast-forward merge) — слияние веток, при котором в текущей ветке отсутствуют новые коммиты (последний коммит текущей ветки является базой слияния). При таком мердже текущая ветка просто переходит в состояние целевой ветки (указатель HEAD переносится на последний коммит целевой ветки). Мердж коммит при этом не создается.
Слияние без перемотки (non fast-forward merge) — слияние, при котором новые коммиты (относительно базы слияния) присутствуют как в текущей, так и в целевой ветках.
В пустом репозитории, в основной ветке, создаем пустой файл, добавляем в репозиторий (теперь git будет отслеживать состояние файла) и коммитим (коммит А).
Добавляем в файл текст, коммитим еще раз (коммит B).
Создаем новую ветку (как бы копируя состояние репозитория), вносим изменения в файл и снова коммитим (коммит С).
Возвращаемся на предыдущую ветку (теперь репозиторий находится в состоянии, которое сохранилось при коммите B, без изменений, которые вносились в новой ветке).
Вносим новые изменения, создаем новый коммит (D).
История изменений при создании новой ветки
После этого новая ветка останется в состоянии С (со своими собственными изменениями), а в основной ветке будут изменения из обеих веток (изменения, внесенные коммитами С и D). Эта ветка перейдет в состояние Е.
Возможна и обратная ситуация, когда изменения из основной ветки вливаются в новую (мердж производится из новой ветки).
При этом мы можем вернуться в новую ветку и продолжить работу в ней (внести новые изменения и создать коммит F).
История изменений после слияния и нового коммита
Мердж конфликт (merge conflict) — ситуация, когда при слиянии веток в один или несколько файлов вносились независимые изменения. В некоторых случаях (например, если изменялись разные, не пересекающиеся части одного файла) git способен самостоятельно решить, как выполнять слияние таких файлов. Если автоматически это сделать не удалось — возникает конфликт. В таком случае необходимо самостоятельно указать, как выполнять слияние конфликтующих версий (решить конфликт, resolve merge conflict). Изменения, внесенные в процессе решения конфликта автоматически попадают в мердж коммит.
Чекаут (checkout) — переход на другое (существующее) состояние репозитория (на другой коммит или ветку). При этом все файлы в репозитории возвращаются в состояние, в котором они находились на момент указанного коммита. Если перед переходом в репозиторий были внесены изменения, которые были добавлены в репозиторий, но не попали в коммит — они будут перенесены «поверх» состояния после перехода. Как и при мердже, git попробует применить эти изменения к новому состоянию автоматически, при неудаче — возникает конфликт и изменения необходимо применить вручную.
Дифф (diff) — разница двух состояний (коммитов, веток, подготовленных или модифицированных файлов).
Трехсторонний дифф (three-way diff) — дифф, возникающий при мердже и решении конфликтов. Является разницей трех состояний: состояния репозитория в текущей ветке, состояния в целевой ветке слияния и общего состояния между этими ветками (состояния в базе слияния).
Черри-пик (cherry-pick) — процесс добавления в текущую ветку одного (или нескольких) коммитов из другой ветки, без необходимости выполнять слияние веток.
Реверт (revert) — отмена внесенных изменений (коммита или группы коммитов). В процессе реверта создается дополнительный коммит, который так же можно отменить при необходимости (вернув репозиторий в изначальное состояние). Реверт мердж коммита позволяет отменить выполненное ранее слияние веток.
Ребейз (rebase) — перенос изменений текущей ветки «поверх» другой ветки. При этом все коммиты текущей ветки, которых нет в целевой, удаляются из текущей и заново создаются в целевой ветке (последовательно применяются к состоянию в целевой ветке). Поскольку ребейз пересоздает коммиты заново и меняет существующую историю, его использование не рекомендуется при командной разработке. Ребейз в ветке, над которой работает несколько человек, может привести к потере чужих изменений и/или невозможности корректно выполнить слияние.
В данном случае коммит Е содержит изменения, которые вносились с момента последнего слияния или создания ветки (с момента коммита В). Т.е. коммит Е содержит в себе изменения из D. При выполнении ребейза git понимает, что эти изменения (E) уже присутствуют в целевой ветке (и окажутся в текущей после ребейза), потому нет необходимости копировать коммит Е, дублируя этим D.
Командная разработка
Наличие удаленного репозитория может быть полезным и при одиночной разработке: оно позволяет синхронизировать состояние проекта на разных компьютерах и просто сохранить проект на внешнем сервере.
Есть два варианта синхронизации изменений:
пулл (pull) — слияние состояния удаленного репозитория и локального (обычно — в отдельной ветке). Пулл может выполняться как для одной и той же ветки (с одинаковым именем), так и для разных. Пулл являет собою обычный мердж, но целевая ветка при этом находится не в том же репозитории, в котором выполняется пулл, а в удаленном. Как следствие, при пулле так же создается мердж коммит, пулл можно отменить (заревертить) и в его процессе может возникнуть мердж конфликт.
пуш (push) — обратный пуллу процесс. При пуше изменения из локального репозитория переносятся в удаленный. Пуш обновляет состояние текущей ветки в удаленном репозитории и не является мерджем (не создает дополнительные коммиты и не может привести к конфликтам). Если в ветке удаленного репозитория присутствуют коммиты, которых нет в локальном репозитории, сигнализируется ошибка о несовпадении истории изменений (non fast-forward merge), пуш выполнить не получится. В таком случае необходимо сначала синхронизировать состояние локального репозитория (получить недостающие коммиты с помощью пулла), и только после этого повторить процесс пуша.
Нередко возникает необходимость обновить информацию о состоянии удаленного репозитория (существующих ветках и коммитах в них) без выполнения слияния (пулла). Такой процесс называется фетчем (fetch). Таким образом, пулл является комбинаций фетча и мерджа: сперва обновляется информация о состоянии целевой ветки в удаленном репозитории, а затем ее изменения вливаются в текущую ветку в локальном репозитории.
основные понятия и термины
простые примеры терминов
применение git’a при командной разработке
некоторые проблемы, которые могут возникать при использовании git’a