Как нажать/вытащить Git rebase

Я хотел бы использовать git rebase, чтобы аккуратно объединить функцию в основной ветке (с меньшим количеством коммитов или, по крайней мере, в верхней части журнала изменений). Обратите внимание, что над репозиторием работаю только я.

Прочитав вопросы о рабочем процессе Git и перебазировании и слиянии, я обнаружил, что git rebase будет быть довольно милым и, как Мика, я хотел бы git push перебазировать изменения просто потому, что я работаю над ними из разных мест (например, с моего ноутбука, моего дома, другого компьютера где-то...)

Итак, вот два решения (для двунаправленного уродливого слияния):

  1. Использование git push -f для отправки, а затем извлечения на другую машину, но как чисто получить последнюю версию на других машинах?
  2. Использование слияния для слияния основных изменений в ветке функций, git push/pull, а после завершения выполнения одной перебазировки (чисто в одном или нескольких коммитах)

(2) будет выглядеть следующим образом:

git co -b feature-a
... change files
git push origin feature-a
... moving to another PC
git pull origin feature-a
... change files
git merge master
... change files (not the "special rebase")
git rebase master
git co master
git merge feature-a
git branch -d feature-a
git push origin :feature-a

Как вы думаете, какое решение будет работать? Я пока не пробовал ни один из них (в основном из-за боязни сделать мой журнал более грязным).


git git-pull git-merge git-rebase
person Wernight    schedule 08.02.2010    source источник

Ответы (2)


arrow_upward
11
arrow_downward

Помните, что git rebase воспроизводит изменения и создает новые коммиты. Перебазируя и форсируя толчки повсюду, вы идете против сути инструмента. Обратите внимание на "Восстановление из вышестоящей перебазировки" начинается раздел документации git rebase (с дополнительным акцентом):

Перебазирование (или любая другая форма перезаписи) ветки, на которой работали другие, — плохая идея: любой, кто находится ниже по течению, вынужден вручную исправлять свою историю. В этом разделе объясняется, как выполнить исправление с точки зрения нисходящего потока. Однако реальное исправление заключается в том, чтобы в первую очередь избегать перебазирования восходящей ветки.

Даже если вы единственный разработчик, вы все равно будете другими (с точки зрения одного репо) при работе с другими клонами. Как вы видели, этот рабочий процесс доставляет много хлопот.

Пусть ваши изменения готовятся в ветках. Когда ветвь будет готова к использованию в прайм-тайм, затем перебазируйте ее, объедините с основной и удалите ее тематическую ветвь. Ваша жизнь будет проще, если вы сделаете жизнь ветвей короткой, а их область действия — узкой.

person Greg Bacon    schedule 08.02.2010
comment
Похоже на вариант (2) в моих предложениях. - person Wernight; 10.02.2010
comment
Пусть ваши изменения готовятся в ветках. Я не понимаю этот комментарий. Он уже использует тематические ветки для новых изменений. Суть вопроса, похоже, заключается в том, как совместить удаленные ветки и перебазирование, не раздражая всех вокруг вас. - person Mark E. Haase; 06.10.2011

arrow_upward
13
arrow_downward

Я всегда уверен, что фиксирую и нажимаю (-f) все с любой машины, которую покидаю.

Когда я подхожу к какой-то другой машине:

 git fetch -v
 git checkout mybranch # Already checked out with old HEAD
 git reset --hard origin/mybranch

Это хорошо работает, потому что я знаю, что другой «я» на разных компьютерах постоянно фиксирует и отправляет, прежде чем я уйду (и, следовательно, на машине, к которой я прихожу, нет неотправленных изменений)

person krosenvold    schedule 08.02.2010
comment
В настоящее время я создаю патч своих изменений и передаю его на следующую машину, над которой буду работать. Мое личное правило заключается в том, чтобы коммитить только тот код, который без проблем компилируется, а также проходит все тесты. Однако это довольно болезненно, и я довольно часто думал о вашем подходе. С другой стороны, не замутит ли это историю/рефлог на машинах? - person Jonathan Neufeld; 20.10.2015
comment
Это действительно плохая практика, если вы работаете с кем-то еще. push -f удаляет историю других и заставляет их переделывать. - person rvazquezglez; 25.01.2016