Git repo está teniendo problemas

ok así que confié mis files después de git add . --all git add . --all Al parecer borré mis files que acabo de hacer en lugar de savelos. ¿Hay alguna forma de recuperar estos files? Intenté todo y terminé arruinando mi repository local también. Tampoco muestra ningún cambio cuando presiono a github.

 M .DS_Store M Gemfile M Gemfile.lock D app/assets/javascripts/hashtags.js.coffee D app/assets/stylesheets/hashtags.css.scss M app/assets/stylesheets/profiles.css.scss M app/controllers/application_controller.rb D app/controllers/hashtags_controller.rb D app/controllers/moneytags_controller.rb M app/controllers/postings_controller.rb D app/controllers/usertags_controller.rb D app/helpers/hashtags_helper.rb D app/helpers/tags_helper.rb M app/models/posting.rb D app/views/hashtags/index.html.erb D app/views/hashtags/show.html.erb M app/views/layouts/application.html.haml D app/views/moneytags/index.html.erb D app/views/moneytags/show.html.erb M app/views/postings/_form.html.erb D app/views/postings/_posting.html.haml M app/views/postings/index.html.erb M app/views/postings/index.json.jbuilder M app/views/postings/show.html.erb M app/views/postings/show.json.jbuilder M app/views/profiles/show.html.haml D app/views/usertags/index.html.erb D app/views/usertags/show.html.erb M config/routes.rb M db/migrate/20140301150615_create_postings.rb D db/migrate/20140303200423_add_body_to_postings.rb D db/migrate/20140305184935_create_supertag_tags.rb D db/migrate/20140305184936_create_supertag_taggings.rb D db/migrate/20140305214420_create_supertag_hashtags.rb D db/migrate/20140305214421_create_supertag_hashtaggings.rb D db/migrate/20140305214422_create_supertag_usertags.rb D db/migrate/20140305214423_create_supertag_usertaggings.rb D db/migrate/20140305214424_create_supertag_moneytags.rb D db/migrate/20140305214425_create_supertag_moneytaggings.rb M db/schema.rb D test/controllers/hashtags_controller_test.rb D test/helpers/hashtags_helper_test.rb 

El --all (o -A ) para git add significa " git add automáticamente cualquier file nuevo o modificado, y eliminar automáticamente cualquier file que haya eliminado manualmente". O, más simplemente: "configura el siguiente compromiso para que parezca que el directory de trabajo se ve ahora".

Lo anterior indica que cuando ejecutó git add . --all git add . --all tenía, por ejemplo, una app/assets/stylesheets/profiles.css.scss que era diferente de la confirmación HEAD , pero no tenía ningún file llamado app/assets/stylesheets/hashtags.css.scss . Así que le pediste a Git que por favor hiciera que el próximo commit tenga los diferentes profiles.css.scss , pero no tenga hashtags.css.scss . Luego hiciste un git commit para que la nueva confirmación se vea así.

¿Hay alguna forma de recuperar estos files?

Sí. Están en el viejo compromiso. Ese es el punto de los commits: cada commit tiene una copy completa y completa de su tree de trabajo.

Tampoco muestra ningún cambio cuando presiono github.

Todo lo que hace un push es enviar los nuevos commit (s) al extremo receptor, y actualizar sus cabezas de bifurcación. En general, esto solo agrega nuevas confirmaciones (para eliminar confirmaciones durante un impulso debe presionar con --force o -f ). Por lo tanto, cada versión anterior de cualquier file aún está disponible en las confirmaciones más antiguas.

Utilice git log o git log --all , o gitk --all o algún otro visualizador gráfico, para ver los commits antiguos.

Si solo desea recuperar un file de una confirmación anterior, puede usar git show para verlo:

 git show master~5:app/views/hashtags/index.html.erb 

le mostrará cómo se veía ese file "cinco commits ago on branch master" (el ~5 da el número de confirmaciones para "retroceder en el time", por así decirlo).

Para volver a tener esa versión de ese file en su tree de trabajo, y también progtwigr la versión anterior para pasar al compromiso "siguiente", use la git checkout :

 git checkout master~5 -- app/views/hashtags/index.html.erb 

(La diferente syntax para git show vs git checkout es un poco molesto, pero uno puede acostumbrarse).

Si quieres deshacer completamente la confirmación "incorrecta", puedes usar git revert :

 git revert <bad-commit-ID> 

Este command dice: "Compare la identificación de compromiso que le di con el compromiso que viene antes. Cualquier cambio que haya hecho, haga el cambio exactamente opuesto ahora". Entonces, si eliminaste un file, git lo creará con su contenido anterior. Si agregó algo de text, git elimina ese text. Si eliminó una línea de un file, git agrega esa línea al file (en el lugar original). Si agregó un file, git lo elimina.

Puede revertir cualquier compromiso anterior, no solo el más reciente, aunque en algunos casos es posible que git necesite su ayuda. Por ejemplo, digamos que hace tres commits ( master~3 ) agregaste dos líneas a zorg.txt , y luego en el último commit cambiaste una de esas. Si ahora intentas git revert master~3 , git querrá eliminar ambas líneas, pero una de ellas es diferente ahora, por lo que no estará seguro de qué hacer.

(La reversión de la confirmación más reciente siempre funciona, porque, por definición, no hay cambios más nuevos que interfieran con la anulación de los cambios más recientes).

En casos especiales, puedes descartar el último commit con git reset --hard HEAD^ , pero no hay vuelta atrás de esto, y si has empujado (publicado a otros) el commit incorrecto, deberás forzar el push del resultado. Mientras tanto, pueden estar basando su trabajo en el mal compromiso; no esperan que simplemente se desvanezca, y estarás haciendo un trabajo extra para que se recuperen. Por lo tanto, en general, es mejor revert una confirmación publicada, en lugar de descartarla. (Revert agrega un nuevo compromiso, por lo que simplemente no puede perder nada, simplemente agrega más cosas a su Git Borg Collective, por así decirlo).

(Para ver cómo nombrar commits, mira la documentation de gitrevisions . A menudo parece más fácil usar git log para get los nombres RAW-1 crudos, cosas como 676699a0e0cdfd97521f3524c763222f1c30a094 y cortarlos y pegarlos con el mouse, si eres utilizando herramientas de command-line. Pero es bueno aprender nombres como master^ y branch~4 y así sucesivamente).