#git
#git
Вопрос:
Я хочу перебазировать свою ветку (branch) на master (main). фиксация m1 означает, что я добавил комментарий со строкой m1 в файл. m2, b1 и так далее одинаковы. Что я делаю, так это:
git checkout branch
gitk --all
git rebase main
Во-первых, перемотайте head, чтобы воспроизвести вашу работу поверх нее…
Применение: b1
Использование информации об индексе для восстановления базового дерева…
M HelloWorld.java
Возвращаемся к исправлению базы и 3-стороннему слиянию…
Автоматическое слияние HelloWorld.java
КОНФЛИКТ (содержимое): конфликт слияния в HelloWorld.java
ошибка: не удалось объединить изменения.
Ошибка исправления в 0001 b1
подсказка: используйте ‘git am —show-current-patch’, чтобы увидеть неудачный патч
Разрешите все конфликты вручную, пометьте их как разрешенные с
помощью «git add/rm <conflicted_files>», затем запустите «git rebase —continue».
Вместо этого вы можете пропустить этот коммит: запустите «git rebase —skip».
Чтобы прервать и вернуться к состоянию до «git rebase», запустите «git rebase —abort».
#I fix the conflicts and add the file.
git rebase --continue
Применение: b1
Применение: b2
Использование информации об индексе для восстановления базового дерева…
M HelloWorld.java
Возвращаемся к исправлению базы и 3-стороннему слиянию…
Автоматическое слияние HelloWorld.java
Применение: b3
Использование информации об индексе для восстановления базового дерева…
M HelloWorld.java
Возвращаемся к исправлению базы и 3-стороннему слиянию…
Автоматическое слияние HelloWorld.java
Применение: b4
Использование информации об индексе для восстановления базового дерева…
M HelloWorld.java
Возвращаемся к исправлению базы и 3-стороннему слиянию…
Автоматическое слияние HelloWorld.java
Применение: b5
git status
На ветке ветки
Ваша ветвь и ‘origin / branch’ разошлись
и имеют 7 и 5 разных коммитов соответственно.
(используйте «git pull», чтобы объединить удаленную ветку с вашей)
ничего не нужно фиксировать, рабочее дерево чистое
gitk --all
Я хотел бы знать, почему он расходится и почему перебазирование не работает должным образом, что является причиной этого и как я могу это исправить? я делаю перебазирование неправильно? При попытке выяснить, как исправить эту проблему, единственное, что я могу найти, это как вернуться к первому состоянию (рис. 1) с помощью:
git fetch origin
git reset --hard origin/<branchname>
Комментарии:
1. я думаю, что это работает правильно, ваша локальная <ветка> теперь имеет фиксацию из <main> ветки. и ваша удаленная <ветка> все еще является ее более старой версией. чего вы ожидаете?
2. Почему это расходится: потому что при переназначении master в ветку GIT сначала перематывает ветку к первому общему предку фиксации. В вашем случае кажется, что их нет. Итак, GIT принимает коммит от master (m1), который создает новую «базу коммитов» для вашей ветки (вот почему rebase), а затем применяет все коммиты вашей ветки один за другим поверх них. При этом создаются новые коммиты, поэтому хэши коммитов локальной ветви отличаются от хэшей в origin. Вот почему вы получаете сообщение «они разошлись».
3. просто нажмите на свою ветку, <git push origin branch>, чтобы выровнять локальную и удаленную
4. что меня смущает, так это сообщение «7 и 5 разных коммитов каждый». Я еще не пытался нажимать, так как git рекомендует «git pull», но это предложение может быть неправильным? Я не рассматривал push как вариант.
5. в вашей локальной «ветке» есть 7 коммитов, добавленных 2 мастером. в вашей удаленной «ветке» более старая версия имеет только 5.
Ответ №1:
Перебазирование сработало так, как предполагалось. И если бы вы не нажали на ветку перед перебазированием git status , вы были бы совершенно счастливы. Недоразумение больше связано с удаленными устройствами.
Что происходит, когда вы нажимаете обычную ветку. У вас есть несколько новых коммитов, в истории которых есть удаленная ветвь. Когда вы нажимаете, коммиты загружаются, и удаленная ветка быстро перенаправляется туда, где находится ваша локальная ветка.
Быстрая перемотка вперед важна, потому что вы не можете разрешить конфликты слияния на удаленном компьютере. Но если вы перебазируете, например, удаленную ветку, ее больше не будет в истории вашей ветки. Таким образом, вы не можете нормально нажимать, и это то, о чем git status вас предупреждает.
В вашем случае вы знаете, почему он разошелся, и проверили, что никто другой не совершал коммиты для перехода. вы можете решить это с помощью git push --force-with-lease
Ответ №2:
Я думаю, что вы делаете это неправильно, вы выполняете проверку branch и перебазируете master, что означает, что вы применяете изменения к своему branch
Если вы хотите применить ветвь функции изменения к мастеру :
git checkout master
git rebase <feature-branch>
ps: имхо, было бы неплохо назвать git не веткой branch , а чем-то вроде feature-x или любым, чтобы не путать.
Комментарии:
1. Я впервые использую rebase. Насколько я понимаю, я должен сначала проверить ветку, а затем перебазировать ее в master, push branch. Когда это будет сделано, я должен проверить master и перебазировать его с помощью origin / branch. Разве это не так?
2. ваша цель — обновить главную ветку или ветку функций?
3. перебазирование похоже на слияние. но вместо того, чтобы создать другую фиктивную фиксацию, такую как merge, rebase применяет фиксацию к вашей ветке без создания фиктивной фиксации (немного упрощает).
4. В данном случае основная ветвь, но в то же время, если мне когда-нибудь в будущем придется обновлять функциональную ветку, я узнаю, как сделать это обоими способами. Я также подумал, что это может быть «лучшим» способом, чтобы каким-то образом не испортить главную ветку, сначала посмотрите, все ли работает так, как ожидалось, прежде чем я переустанавливаю и нажимаю на master.
5. вы уже полностью обновили свою функцию ветки, ваш коммит на master уже находится в ветке функций, вот что такое перебазирование. но если вы хотите первым делом обновить главную ветку, просто используйте git checkout master и функцию git rebase.