Git: Olvidé hacer una confirmación inicial del código generado; ¿Es este un trabajo para rebase?

Arreglé una pequeña aplicación de Rails 3 para demostrar cómo podría usarse con una biblioteca en la que estoy trabajando. Después de ejecutar rails new realicé algunos cambios en Gemfile, config y algunas classs. Entonces me comprometí con git.

Lo que debería haber hecho es comprometer la estructura generada inicialmente y luego mis cambios para poder get una buena diferencia de la configuration mínima para esta biblioteca.

Antes de seguir todos los pasos para volver a configurar todo esto (probablemente como 30 minutos, pero posiblemente inducir a error), me preguntaba: ¿es posible hacer otros rails new , comprometerlos y luego volver a establecer el compromiso existente en eso, produciendo un compromiso con solo los cambios que hice anteriormente (es decir, less la rails new estructura generada en los rails new )?

Si entiendo cómo funciona git correctamente, parece factible, pero no estoy seguro de saber cómo hacerlo con los commands de git.

Después de su confirmación inicial, intente lo siguiente:

 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> 

En su caso, dado que su repository es tan nuevo / simple, lo más fácil sería crear un nuevo repository, hacer los rails new allí y luego copyr sus cambios:

 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 funciona fuera del contenido del file (SHA1 hash), por lo que este enfoque es totalmente válido.

Estoy seguro de que hay una forma semi complicada de hacerlo dentro de su repository existente, posiblemente creando una nueva twig temporal, git rebase --onto , y luego usando git filter-branch para extraer la twig temporal en un nuevo repository git … pero ¿para qué molestarse cuando tu historia es tan simple? 🙂

Generalmente uso twigs para este tipo de cosas. Haz una nueva twig vacía, haz nuevos Rails en ella, compárala y luego fusiona la twig original encima de ella.

Depende de si su informe es público. La rebase propuesta reescribirá por completo el historial del repository. Si esto sigue siendo un repository privado, naturalmente arreglarás tu tronco y cualquier twig con rebases y eventualmente un git gc eliminará el historial anterior. Si otros han clonado su trabajo existente y han confirmado alguno de sus propios cambios, esta reescritura del historial les resultará confusa y molesta.

Nunca he reemplazado la primera revisión como lo propones. Puede get mejores resultados al comprometer la nueva revisión base y luego usar git filter-branch para restablecer el elemento primario de la primera revisión anterior a la primera revisión nueva. El algorithm de git rebase puede no lidiar con tu situación. Hay un ejemplo en git help filter-branch .