git: Как мне перезаписать все локальные изменения при слиянии?

Question

Вот ситуация. Я работаю над веткой master. Я создаю file1 и фиксирую. Я создаю file2 и фиксирую. Упс. Возможно, я когда-нибудь захочу использовать file2, но это определенно не то, что должно быть помещено в главную ветку. Чтобы я не потерял file2 я использую

git checkout head~1
git branch new-branch
git checkout new-branch

чтобы я мог продолжать развиваться. Я добавляю file3 к new-branch. Если вы обратили внимание, у меня есть две ветви, master, которые содержат «file1» и «file2» и new-branch, которые содержат «file1» и «file3».

Теперь пришло время вернуть сделанные мной изменения в основную ветку. Какой лучший способ сделать это? Я определенно хочу, чтобы глава ветки master указывал на файлы в том виде, в каком они появляются в new-branch, но я также не хочу потерять работу, которую я проделал в file2, выполнив сброс, на случай, если я захочу использовать его.

Имейте в виду, это упрощение. Вместо трех файлов у меня есть дюжина файлов с десятками строк кода, которые меняются повсеместно, с несколькими коммитами. Я, конечно, надеюсь, что решение заключается не в слиянии / извлечении файлов, потому что это было бы огромной болью.

Есть идеи?

Answer 1

Я работаю над основной веткой. я создать файл1 и зафиксировать.

date >file1
git add file1
git commit -m 'added file1'

Я создаю файл2 и фиксирую.

date >file2
git add file2
git commit -m 'added file2'

Упс. Я могу хотеть использовать file2, когда-нибудь, но это определенно не то, что должно быть помещено в мастер ветка.

К сожалению. Очень просто. Создайте новую ветку, из которой вы находитесь:

git checkout -b savingfile2

Это заставит файл2 изменить коммит для savingfile2. Теперь вернитесь и сделайте один шаг на мастере

git checkout master
git reset --hard HEAD~1

В этот момент коммиты, ведущие к мастеру, будут отражать добавление file1, и дополнительная фиксация между master и savefile2 будет добавлением file2 к этому.

Если вы внесете дополнительные изменения в мастер, а затем в конце концов захотите вернуть file2, вам понадобится переназначить эту боковую ветвь на новый мастер:

date >file3
git add file3
git commit -m 'adding file3'
date >file4
git add file4
git commit -m 'adding file4'

И теперь мы, наконец, хотим file2:

git checkout savingfile2
git rebase master # might need to fix conflicts here
git checkout master
git merge savingfile2 # will be a fast-forward
git branch -d savingfile2 # no need any more

Это должно сделать это.

Answer 2

Поскольку вы не следовали оптимальному рабочему процессу , описанному Томи Кёстиля , но также, поскольку вы еще ничего не публиковали (не нажимали), почему бы не переключить две ветви? 1005 * (при условии, что все совершено)

master и new-branch - лишь некоторые указатели на некоторые SHA1:

$ git checkout master              #start from master
$ git branch tmp                   # tmp points on master HEAD
$ git checkout new-branch          # switch to new-branch
$ git branch -f master new_branch  # master points at new-branch HEAD
$ git checkout tmp                 # switch back to *former* master branch
$ git branch -f new_branch tmp     # new-branch points at former master HEAD
$ git checkout master              # go to new master
$ git branch -D tmp                # remove tmp pointer

... и все готово.
(заявление об отказе: еще не проверено, поэтому попробуйте с осторожностью;))

См:

• аналогичный подход в параграфе "Исправление ошибок без git-reset" "Ветвление и слияние с git" ,
• а также в этой теме

Answer 3

Что вы должны сделать, это то, что вы должны были сделать, когда заметили свою ошибку при передаче файла2: отменить фиксацию (вместо создания новой ветви):

git checkout master
git reset HEAD^

В результате файл2 не будет отслежен и не поврежден, а возможные модификации не будут загружены. Тогда вы должны (иметь) stash (ed) незафиксированные модификации на случай, если вы захотите использовать их позже:

git stash save "modifications that should not be in the master branch"

Stashing избавляет от любых локальных изменений, что позволяет master указывать на new-branch:

git merge new-branch

Цель здесь состояла в том, чтобы устранить расхождение между двумя ветвями, то есть сделать master предком new-branch. Таким образом, фактическое слияние не должно происходить, и последняя команда будет просто fast-forward ветвь master (при условии, что локальных изменений нет).