Как объединить мои локальные незафиксированные изменения в другую ветвь Git?
Как это сделать в git:
Моя текущая ветка - branch1, и я внес некоторые локальные изменения. Однако теперь я понимаю, что я действительно хотел применить эти изменения к branch2. Есть ли способ применить/слить эти изменения так, чтобы они стали локальными изменениями на ветке2, не помещая их в branch1?
Ответы
Ответ 1
Так как ваши файлы еще не зафиксированы в branch1
:
git stash
git checkout branch2
git stash pop
или
git stash
git checkout branch2
git stash list # to check the various stash made in different branch
git stash apply x # to select the right one
Как прокомментировано benjohn (см. git stash
справочная страница):
Чтобы также сохранить в настоящее время незатребованные (недавно добавленные) файлы, добавьте аргумент -u
, поэтому:
git stash -u
Ответ 2
Штамповка, временные фиксации и перезарядка могут быть переполнены. Если вы еще не добавили измененные файлы в индекс, вы можете просто проверить другую ветку.
git checkout branch2
Это будет работать до тех пор, пока никакие файлы, которые вы редактируете, не отличаются между branch1 и branch2. Он оставит вас на ветке2 с сохраненными рабочими изменениями. Если они отличаются друг от друга, вы можете указать, что вы хотите объединить свои локальные изменения с изменениями, внесенными переключением ветвей с помощью опции -m
для проверки.
git checkout -m branch2
Если вы добавили изменения в индекс, вам нужно сначала отменить эти изменения с помощью reset. (Это сохранит вашу рабочую копию, она просто удалит поэтапные изменения.)
git reset
Ответ 3
Ниже приведена более короткая альтернатива ранее упомянутому подходу:
Временно переместите изменения в тире.
git stash
Создайте и переключитесь на новую ветку, а затем нажмите на нее в один шаг.
git stash branch new_branch_name
Затем add
и commit
изменения этой новой ветки.
Ответ 4
ПРЕДУПРЕЖДЕНИЕ: Не для git новичков.
В моем рабочем процессе этого достаточно, что я почти попытался написать для него новую команду git. Обычный поток git stash
- это путь, но немного неудобный. Я обычно делаю новую фиксацию сначала, начиная с , если бы я искал изменения, вся информация была свежей в моем сознании, и лучше просто начать git commit
-используя то, что я нашел (как правило, bugfix принадлежащих к мастеру, который я обнаружил, работая над ветвью функций) сразу.
Также полезно - если вы столкнетесь с подобными ситуациями, - другой рабочий каталог рядом с вашим текущим, который всегда имеет master
выведена.
Итак, как я это достигаю:
-
git commit
изменяется сразу с хорошим сообщением фиксации.
-
git reset HEAD~1
, чтобы отменить фиксацию из текущей ветки.
- (необязательно) продолжить работу над этой функцией.
Иногда позже (асинхронно) или сразу в другом окне терминала:
-
cd my-project-master
, который является другим WD, использующим один и тот же .git
-
git reflog
, чтобы найти исправление, которое я только что сделал.
-
git cherry-pick SHA1
фиксации.
Необязательно (по-прежнему асинхронно) вы можете переустановить (или объединить) ветвь вашей функции, чтобы получить исправление, как правило, когда вы собираетесь отправить PR и уже очистили свою ветку функций и WD:
-
cd my-project
, который является основным WD, над которым я работаю.
-
git rebase master
, чтобы получить исправления.
Таким образом, я могу продолжать работать с этой функцией без перерыва и не беспокоиться о git stash
-в любой ситуации или о необходимости очистить свой WD до git checkout
(а затем снова проверить регенерацию ветки функции) и все мои исправления переходят на master
вместо скрытых в моей ветке свойств.
IMO git stash
и git checkout
- это реальный PIA, когда вы находитесь в середине работы над некоторой большой функцией.
Ответ 5
Если бы речь шла о фиксированных изменениях, вы должны взглянуть на git -rebase, но, как указано в комментарии VonC, поскольку вы говорите о локальных изменениях, git -stash, безусловно, будет хорошим способ сделать это.
Ответ 6
Ответы, данные до сих пор, не являются идеальными, потому что они требуют много ненужной работы, разрешающей конфликты слияния, или они делают слишком много допущений, которые часто являются ложными. Вот как это делается. Ссылка на мой собственный сайт.
На my_branch
, которые вы хотите зафиксировать на master
, вы не имеете никаких изменений, не внося никаких изменений из my_branch
.
Пример
git merge master
git stash -u
git checkout master
git stash apply
git reset
git add example.js
git commit
git checkout .
git clean -f -d
git checkout my_branch
git merge master
git stash pop
Описание
Начните с объединения master
в свою ветку, так как вам все равно придется это сделать, и теперь самое лучшее время для разрешения конфликтов.
Опция -u
(aka --include-untracked
) в git stash -u
не позволяет вам потерять ненужные файлы, когда вы позже сделаете git clean -f -d
внутри master
.
После git checkout master
важно, чтобы вы НЕ git stash pop
, потому что вам понадобится этот штамп позже. Если вы закроете тайник, созданный в my_branch
, а затем выполните git stash
в master
, вы вызовете ненужные конфликты слияния, когда вы позже примените этот штрих в my_branch
.
git reset
устраняет все, что возникает из git stash apply
. Например, файлы, которые были изменены в кошельке, но не существуют в master
, становятся поставленными как конфликты "удалены нами".
git checkout .
и git clean -f -d
отбросить все, что не было выполнено: все изменения в отслеживаемых файлах и все необработанные файлы и каталоги. Они уже сохранены в кошельке, и если оставить в master
вызовет ненужные конфликты слияния при возврате к my_branch
.
Последний git stash pop
будет основан на исходном my_branch
, и поэтому не вызовет конфликтов слияния. Однако, если ваш кошелек содержит файлы без следа, которые вы поручили освоить, git будет жаловаться на то, что он "не смог восстановить неиспользуемые файлы из stash". Чтобы устранить этот конфликт, удалите эти файлы из рабочего дерева, затем git stash pop
, git add .
и git reset
.