Каким образом в Git перенести отдельный коммит из одной ветки А в ветку Б? При этом коммит содержит файлы, которые были изменены в ветке Б.
3 ответа 3
В Git есть специальная команда cherry-pick , которая позволяет вставлять в текущую ветку изменения из любого коммита. Работает она так:
Пример выше применяет последний коммит из ветки test в текущую ветку.
При желании, можно перенести более одного коммита за один раз. Например:
Из примера выше видно, что на коммит можно сослаться сразу несколькими способами:
- Используя SHA хэш коммита (или его сокращенный вариант).
- Используя имя ветки (можно использовать синтаксис ^ и
).
Более подробная информация о том, как сослаться на коммит есть в документации к Git.
Стоит отметить, что в отличии от слияния ( merge ) при cherry-pick переносятся только изменения, а не сам коммит полностью. При этом, в целевой ветке создается новый коммит (коммиты) содержащий необходимые изменения.
именно. я так в вебшторме делал и результат предсказуемый получился
* в ветке dev на делал изменений
* понял что это задел под новую фичу сделал новый бранч
* в новом бранче сделал коммит
* сделал пуш на сервер
там пару коммитов назад есть на схеме подобный кусочек ответвления где мердж уже сделан
Иногда бывает, что я вношу некоторые изменения в свой рабочий каталог, и я понимаю, что эти изменения должны быть зафиксированы в ветки, отличной от текущей. Обычно это происходит, когда я хочу опробовать новые вещи или сделать некоторые тесты, и я забыл создать новую ветвь заранее, но я не хочу передавать грязный код в главную ветвь.
Итак, , как я могу сделать, что незафиксированные изменения (или изменения, хранящиеся в индексе), будут переданы в другую ветку, чем текущая?
Другие ответы, предлагающие проверить другую ветку, а затем выполнить ее, работают только в том случае, если проверка возможна с учетом локальных изменений. Если нет, вы используете наиболее распространенный прецедент для git stash :
Первый stash скрывает ваши изменения (в основном, делает временную фиксацию), а последующий stash pop повторно применяет их. Это позволяет git использовать возможности слияния.
Если при попытке всплывать тайник, вы запускаете конфликты слияния. следующие шаги зависят от того, что такое конфликты. Если все спрятанные изменения действительно принадлежат к этой другой ветки, вам просто придется их сортировать — это следствие внесения изменений в неправильную ветвь.
С другой стороны, если вы действительно перепутались, и в вашем дереве работ есть сочетание изменений для двух ветвей, а конфликты — только те, которые вы хотите зафиксировать на исходной ветке, вы можете сохранить некоторые работы. Как обычно, есть много способов сделать это. Здесь один, начиная с того момента, когда вы попнете и увидите конфликты:
В качестве альтернативы, если вы осознаете, что это произойдет, просто передайте вещи, принадлежащие текущей ветке. Вы всегда можете вернуться и исправить это сообщение:
И, конечно же, помните, что все это заняло немного времени, и в следующий раз избегайте его, возможно, поместив ваше текущее имя ветки в приглашение, добавив $(__git_ps1) к вашему PS1 в вашем bashrc. (См. Например Git в Bash.