Git: я забыл сделать первоначальный коммит сгенерированного кода; это работа для ребазинга?

Question

Я собрал небольшое приложение на Rails 3, чтобы продемонстрировать, как его можно использовать с библиотекой, над которой я работаю. После запуска rails new я внес несколько изменений в Gemfile, config и несколько классов. Тогда я взял на себя обязательства по мерзавцу.

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

Прежде чем я пройду все этапы настройки всего этого заново (вероятно, через 30 минут, но, возможно, из-за ошибок), мне было интересно: можно ли сделать еще один rails new, зафиксировать это, а затем перебазировать существующий выполнить коммит на это, создав коммит только с теми изменениями, которые я сделал ранее (то есть минус сгенерированная структура rails new)?

Если я понимаю, как правильно работает git, это кажется выполнимым, но я не уверен, что знаю, что делать с командами git.

Answer 1

После вашей первоначальной фиксации попробуйте следующее:

git checkout -b temp
<do the rails new>
git add .
git commit --amend
git rebase --root --onto temp master
<resolve conflicts and git add and git rebase --continue>

Answer 2

В вашем случае, поскольку ваш репо такой новый / простой, проще всего было бы просто создать новый репо, выполнить там rails new, а затем скопировать ваши изменения:

mkdir tmp; cd tmp; git init; rails new my_app; git add .;
git commit -m 'Initial commit of rails new'
rm -Rf ~/my_app/.git
cp -R ~/my_app/* ./
git add .
git commit -m 'Set up some settings in Gemfile, config, etc'

Git работает с содержимым файла (хэш SHA1), поэтому этот подход полностью допустим.

Я уверен, что есть полуосложный способ сделать это в вашем существующем репо, возможно, создав новую временную ветку git rebase --onto, а затем используя git filter-branch, чтобы извлечь временную ветку в новое git репо ... но зачем беспокоиться, когда твоя история так проста? : -)

Answer 3

Это зависит от того, является ли ваш репо публичным.Предложенная вами перебазировка полностью переписает историю хранилища.Если это все еще частное репо, вы естественным образом исправите свой ствол и любые ветви с перебазированием, и в конечном итоге git gc удалит старую историю.Если другие клонировали вашу существующую работу и сделали какие-либо свои изменения поверх нее, то это переписывание истории будет сбивать с толку и раздражать их.Вы предлагаете.Вы могли бы получить лучшие результаты, зафиксировав новую базовую ревизию, а затем с помощью git filter-branch сбросить родителя старой первой ревизии к новой первой ревизии.Алгоритм git rebase может не справиться с вашей ситуацией.Есть пример в git help filter-branch.

Answer 4

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