что такое 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.
Резюме
11 концепций и команд git, которые заставят вас плакать
В самой популярной системе контроля версий нужно хорошо разбираться. Проверьте знание команд git, ответив на 11 каверзных вопросов.
Последние опросы на Stack Overflow показывают, что более 70% разработчиков используют git для ПО с открытым исходным кодом и для коммерческих продуктов. Преимущества этой VCS для командной работы сложно переоценить.
Вопрос 1. В чем разница между fork, branch и clone?
Вопрос 2. В чем разница между pull request и branch?
Вопрос 3. Объясните разницу команд git pull и git fetch?
Простыми словами, git pull = git fetch + git merge.
Вопрос 4. Как отменить предыдущий коммит?
Предположим, у вас сложилась следующая ситуация. Указатель HEAD находится в C, а (F) – это текущее состояние ваших файлов.
Откатиться к предыдущему состоянию можно с помощью группы команд git reset с разными флагами.
• Чтобы полностью отменить коммит, используйте
• Чтобы отменить коммит, но сохранить сделанные в нем изменения, просто выполните
Так мы передвигаем HEAD на один коммит назад (на B), но оставляем файлы в том состоянии, в котором они находятся. git status покажет, что файлы соответствуют фиксации C.
• Чтобы отменить коммит и сохранить все проиндексированные файлы, используйте
Вызовите git status и убедитесь, что в индексе git находятся те же файлы, что и раньше.
Вопрос 5. Что такое git cherry-pick?
Команда git cherry-pick используется для перенесения отдельных коммитов из одного места репозитория в другое, обычно между ветками разработки и обслуживания. Этот механизм отличается от привычных команд git merge и git rebase, которые переносят коммиты целыми цепочками.
Вопрос 6. Расскажите о преимуществах forking workflow.
Работа через форки принципиально отличается от других популярных методов организации командной разработки. Вместо того чтобы использовать один серверный репозиторий в качестве центральной кодовой базы, здесь каждый разработчик получает свой собственный репозиторий. Чаще всего эта модель применяется в общедоступных open source проектах.
Основное преимущество forking workflow заключается в том, что все изменения вносятся без загрязнения истории проекта. Разработчики делают push в собственные репозитории, а доступ к центральному есть только у менеджера.
Когда обновление готово к интеграции, программист делает pull-запрос в главный репозиторий, а менеджер одобряет и вносит его.
Вопрос 7. В чем разница между HEAD, рабочим деревом и индексом?
Вопрос 8. Расскажите о gitflow-организации рабочего процесса.
Модель gitflow использует две параллельные «долгие» ветки для хранения истории проекта: master и develop.
Вопрос 9. Когда следует использовать git stash?
git stash берет ваши изменения, подготовленные и неподготовленные к фиксации, сохраняет их для последующего использования и убирает из рабочей области.
Это полезно в ситуации, когда вы внезапно поняли, что последний коммит следует изменить, но уже начали другую работу в той же самой ветке.
Вопрос 10. Как удалить файл из git, но оставить его в файловой системе компьютера?
Если вы не будете осторожны с использованием команд git add, то можете случайно добавить в индекс файлы, которые там быть не должны. git rm может удалить их из индекса, но одновременно сотрет и из файловой системы (рабочего дерева). Это не всегда то, что требуется.
Используйте вместо этого git reset :
противоположна git add
Вопрос 11. Когда следует использовать git rebase вместо git merge?
Предназначение этих команд git – интеграция изменений из одной ветки в другую, но делают они это по-разному.
Предположим, у вас сложилась такая ситуация:
После обычного мержа репозиторий будет выглядеть так:
А после git rebase – так:
Rebase указывает на то, что коммиты нужно буквально перенести со старого места на новое.
Учитывайте следующие факторы:
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 Cherry Pick
git cherry-pick is a powerful command that enables arbitrary Git commits to be picked by reference and appended to the current working HEAD. Cherry picking is the act of picking a commit from a branch and applying it to another. git cherry-pick can be useful for undoing changes. For example, say a commit is accidently made to the wrong branch. You can switch to the correct branch and cherry-pick the commit to where it should belong.
When to use git cherry pick
git cherry-pick is a useful tool but not always a best practice. Cherry picking can cause duplicate commits and many scenarios where cherry picking would work, traditional merges are preferred instead. With that said git cherry-pick is a handy tool for a few scenarios.
Team collaboration.
Often times a team will find individual members working in or around the same code. Maybe a new product feature has a backend and frontend component. There may be some shared code between to two product sectors. Maybe the backend developer creates a data structure that the frontend will also need to utilize. The frontend developer could use git cherry-pick to pick the commit in which this hypothetical data structure was created. This pick would enable the frontend developer to continue progress on their side of the project.
Bug hotfixes
When a bug is discovered it is important to deliver a fix to end users as quickly as possible. For an example scenario,say a developer has started work on a new feature. During that new feature development they identify a pre-existing bug. The developer creates an explicit commit patching this bug. This new patch commit can be cherry-picked directly to the main branch to fix the bug before it effects more users.
Undoing changes and restoring lost commits
How to use git cherry pick
To demonstrate how to use git cherry-pick let us assume we have a repository with the following branch state:
git cherry-pick usage is straight forward and can be executed like:
Then we execute the cherry-pick with the following command:
Once executed our Git history will look like:
The f commit has been successfully picked into the main branch
Examples of git cherry pick
git cherry pick can also be passed some execution options.
In addition to these helpful options git cherry-pick also accepts a variety of merge strategy options. Learn more about these options at the git merge strategies documentation.
Summary
Cherry picking is a powerful and convenient command that is incredibly useful in a few scenarios. Cherry picking should not be misused in place of git merge or git rebase. The git log command is required to help find commits to 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