Можно ли сделать git-rebase после выполнения git-commit

Question

Я начал переписывать некоторые программы на Perl из исходных файлов NASM . Я уже сделал несколько коммитов для своей собственной рабочей копии , и мне было интересно, стоит ли мне вместо git pull делать, если бы мне следовало делать git rebase.

Я в значительной степени решил, что должен был сделать git rebase, но я не знаю, как переработать мой репозиторий для достижения этого эффекта, или даже если это возможно.

Answer 1

Это возможно, и учебник Git Magic объяснит, как это сделать. Но , если кто-то еще видел вашу ветку, небезопасно . Даже если никто не видел вашу ветку, позвольте мне убедить вас пересмотреть.

Почему перебазирование? Почему бы просто не потянуть / слить?

Цель перебазирования - переписать историю, чтобы ваш репозиторий отражает то, как вы считаете, что ваше программное обеспечение должно развиваться так, как это было на самом деле. Когда это важно? Когда ты младший член распределенной команды разработчиков, и у вас нет назначить привилегии & mdash; вместо этого все, что вы можете сделать, это отправить исправления привратник и надеюсь, что они приняты. Чтобы максимизировать шансы принятия, вы хотите переписать историю, чтобы сделать ваши патчи как чисто и ясно, насколько это возможно. Модель разработки звучит знакомо?

Манодж Сривастава написал довольно вдумчивый анализ rebase-vs-merge .

Answer 2

1. Убедитесь, что текущий коммит является коммитом слияния: git log
2. Сначала мы переустанавливаем мастер на предыдущий коммит (тот, что прямо перед слиянием): git reset HEAD^
   • HEAD ^ означает: 'коммит до коммита, на который ссылается HEAD'
3. Теперь вы можете сделать обычную ребазу: git rebase origin / master

В следующий раз я рекомендую сделать git fetch, а затем выполнить перебазировку как шаг 3.

Я бы порекомендовал создать небольшой tarball из вашего текущего git-репо, на тот случай, если ребаз не пройдет. Вы будете делать это реже, когда будете чувствовать себя более уверенно (и обычно вы можете исправить почти все с помощью git, но иногда тарбол быстрее).

Answer 3

Я имел успех с помощью следующего метода:

Для этого метода я добавил следующий псевдоним:

up = pull --rebase origin

1. Разветвите свою основную ветку на что-то вроде 'dev' или что-то еще
2. Работа в dev
3. когда вы закончите добавлять и фиксировать изменения
4. Учись, мастер
5. переключиться на мастер
6. git merge dev
7. git push

При получении изменений из удаленного репо:

1. переключиться на мастер
2. Git Up
3. переключиться на dev
4. мастер на все руки

YMMV

Answer 4

В качестве ответа на ответ Дастина это должно быть "git config --global branch.master.rebase true".

Answer 5

Вы должны иметь возможность отменить последнее слияние, изменив ветки следующим образом:

git branch your-changes <reflog of "Reworked test files...">
git branch -f master remotes/origin/master

После этого вы можете попробовать перебазировать.