Ruby on Rails – Flujo de trabajo de la sucursal de Git

Sé que es un concepto simple, pero no lo entiendo después de investigar varios sitios.

Tengo un proyecto de Ruby On Rails y uso git para administrar la fuente. Tengo una instantánea list para producción e inicializo git de modo que tenga un maestro (con git init, git add -A y git commit -m).

Ahora quiero probar una nueva function, así que creo una twig llamada 'testing' con git checkout -b test

Ahora, mientras estoy en la testing, pruebo un nuevo andamio con Rails. Andamio UserToken username: string

Scaffold creó todos los files ROR y hago un rake db: migrate para actualizar el DB. Luego voy a la console de Rails y pruebo la adición de loggings a la database y luego comienzo a trabajar en la actualización del otro file de model de andamio generado.

Después del almuerzo vuelvo y decido que quiero eliminar todo esto.

Preguntas – (después de probar esto por mi count) es la única forma de volver al maestro es agregar git-A, git commit -m y luego git checkout master? ¿Realmente tengo que agregar y comprometerme para volver a dominar? (Esto funciona, sin embargo, no creo que entiendo algo básico en git que me comprometa en algo que voy a desechar)

A continuación, si hago lo anterior (de nuevo, no creo que sea correcto), cuando regrese al maestro veo que mis files de andamios ya no están, como es el file de migration (que creó la tabla) y schema.rb refleja eso la tabla generada mientras estaba en la twig no está allí.

Hasta aquí todo bien:

SIN EMBARGO, si entro en la database actual, la tabla SI sigue ahí. ¿Qué fundamental básico me falta en ROR / Git de probar algo en una twig y luego abandonarlo?

ACTUALIZACIÓN # 1

Así que Stash no parece ayudar: Stash no ayuda.

Steps: rails new test_app git init git add -A git commit -m 'initial commit' git checkout -b newfeatures rails g scaffold UserToken username:string coin:integer files get generated... sqlite3 db/development.sqlite3 show that there is now a table called user_tokens: git stash save git checkout master 

Ahora en Master, sin embargo, todos los files de andamios todavía existen (y no deberían)

git reset --hard HEAD borra todo y vuelve a la cabeza en tu banco de testings para que puedas volver fácilmente con git checkout master

rake db:reset debería hacer el truco con sus datos en el DB


ACTUALIZAR:

Si realmente quieres deshacerte de algo:

git reset --hard && git clean -dfx rake db:drop rake db:create && rake db:migrate

Tienes dos preguntas aquí:

Primero: ¿Cómo me muevo entre las twigs sin comprometer el trabajo en curso?

Para moverse entre sucursales sin tener que comprometer su trabajo, puede usar git stash .

 git stash help Usage: git stash list [<options>] or: git stash show [<stash>] or: git stash drop [-q|--quiet] [<stash>] or: git stash ( pop | apply ) [--index] [-q|--quiet] [<stash>] or: git stash branch <branchname> [<stash>] or: git stash [save [--patch] [-k|--[no-]keep-index] [-q|--quiet] [<message>]] or: git stash clear 

Una vez que esconde su trabajo, puede cambiar de twig sin problemas. Tenga en count que los files que desea ocultar deben primero agregarse a una twig de git add través de git add . Los cambios en los files, incluida la creación, que no se han agregado a git no se rastrean. Por lo tanto, son como cualquier otra parte del sistema de files general y se mantendrán visibles en todas las sucursales .

Segundo: ¿Por qué mi migration de database cambia en una twig en otra?

Porque el administrador de la database no es parte de git . Cualquier DBMS que esté modificando esos cambios persiste a través del DBMS. Si desea mantener las migraciones de sucursal separadas, entonces necesita tener una instancia de database separada para cada una.

Puede ser útil si imagina una twig de git como una plantilla de sistema de files. Cuando cambia a otra sucursal, la plantilla de esa sucursal sobrescribe su sistema de files existente con lo que está bajo su control. Todo lo demás es ignorado. Cuando confirma, está actualizando la plantilla para esa twig. Sin embargo, todo su trabajo se realiza realmente en el único sistema de files verdadero.

Lo que esto significa es que las cosas que le haces al sistema de files que están fuera del control de git permanecen visibles desde todas las twigs.