Как нажать / вытащить Git ребаз - PullRequest
Новая
       90

Как нажать / вытащить Git ребаз

16 голосов
/ 08 февраля 2010

Я бы хотел использовать 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

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

Ответы [ 2 ]

13 голосов
/ 08 февраля 2010

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

Когда я прибуду на другую машину: 

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

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

11 голосов
/ 08 февраля 2010

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

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

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

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

...