Перемещение измененных файлов в другую ветку для регистрации

Это часто случается со мной: я пишу код, проверяю мои изменения, а затем понимаю, что я не в надлежащей ветке, чтобы проверить эти изменения. Однако я не могу переключиться на другую ветку, не возвращая свои изменения. Есть ли способ переместить изменения в другую ветку, которую нужно проверить там?

Ответ 1

git stash - ваш друг.

Если вы еще не сделали фиксацию, просто запустите git stash. Это сэкономит все ваши изменения.

Переключитесь на ветку, в которую вы хотите включить изменения и запустите git stash pop.

Существует много применений для git stash. Это, безусловно, одна из наиболее полезных причин.

Пример:

# work on some code
git stash
git checkout correct-branch
git stash pop

Ответ 2

Если вы еще не сделали свои изменения, просто используйте git checkout, чтобы перейти к новой ветке, а затем скопировать их в обычном режиме - изменения в файлах не привязаны к определенной ветке, пока вы не зафиксируете их.

Если у вас есть, уже были внесены изменения:

  • Введите git log и запомните SHA фиксации, которую вы хотите переместить.
  • Проверьте ветку, на которую вы хотите переместить фиксацию.
  • Введите git cherry-pick SHA, заменив SHA сверху.
  • Вернитесь к исходной ветке.
  • Используйте git reset HEAD~1 to reset назад, прежде чем совершить ошибку.

cherry-pick принимает заданный фиксатор и применяет его к текущей вывернутой голове, что позволяет скопировать фиксацию на новую ветку.

Ответ 3

Если вы хотите переместить изменения в новую ветку, это можно сделать всего двумя командами:

git stash
git stash branch new-branch

Согласно документации по git stash:

branch <branchname> [<stash>]

Создает и извлекает новую ветку с именем <branchname>, начиная с коммит, на котором <stash> был изначально создан, применяет изменения записываются в новое рабочее дерево и индекс.

Ответ 4

К сожалению, это происходит со мной довольно регулярно, и я использую git stash, если я осознал свою ошибку до git commit, и использую git cherry-pick, в противном случае обе команды довольно хорошо объясняются в других ответах

Я хочу добавить пояснение для git checkout targetBranch: эта команда сохранит ваш рабочий каталог и промежуточный снимок, только если targetBranch имеет ту же историю, что и ваша текущая ветвь

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

Оператор @Amber не является ложным, когда вы переходите в newBranch, git checkout -b newBranch, создается новый указатель, который указывает на тот же коммит, что и ваша текущая ветвь.
Фактически, если у вас есть другая ветвь, которая делится историей с вашей текущей веткой (обе указывают на один и тот же коммит), вы можете "переместить свои изменения" на git checkout targetBranch

Однако обычно разные ветки означают разную историю, и Git не позволит вам переключаться между этими ветками с грязным рабочим каталогом или промежуточной областью. в этом случае вы можете выполнить git checkout -f targetBranch (чистые и одноразовые изменения) или git stage + git checkout targetBranch (очистить и сохранить изменения), простой запуск git checkout targetBranch выдаст ошибку:

ошибка: ваши локальные изменения в следующих файлах будут перезаписаны по кассе:         ... Пожалуйста, передайте изменения или спрячьте их, прежде чем переключать ветки. Aborting

Ответ 5

soft git reset вернет зафиксированные изменения в ваш индекс. Затем проверьте ветку, которую вы намеревались зафиксировать. Затем выполните git commit с новым сообщением commit.

  1. git reset --soft <commit>

  2. git checkout <branch>

  3. git commit -m "Commit message goes here"

Из git docs:

git reset [<mode>] [<commit>] Эта форма сбрасывает текущий заголовок ветки и, возможно, обновляет индекс (сбрасывает его в дерево о) и рабочее дерево в зависимости от. Если есть опущено, по умолчанию --mixed. Должно быть одно из следующего:

--soft вообще не касается файла индекса или рабочего дерева (но сбрасывает голову, как это делают все режимы). Это оставляет все ваши измененные файлы "Изменения будут зафиксированы", как будет указано состояние git Это.