Git dummy necesita ayuda en Windows

Es cierto que soy nuevo en Git. Lo sé … bienvenido al siglo correcto! Pero aquí está mi problema …

Tengo un repository que contiene una aplicación angular. La aplicación contiene un file de video MP4 que excede el límite de 100mb de GitHub. (Antes de recomendar que el video no sea local para la aplicación … créame, debe ser en este caso particular). Mi bash inicial de enviar el repository a GitHub falló debido al tamaño de ese file.

Entonces hice algo estúpido … Revertí el compromiso, pensando que simplemente volvería al estado en que estaba antes de intentar presionar a GitHub. Pero lo que REALMENTE hizo fue restaurar mi repository (toda la aplicación) al estado original en que estaba cuando fue creado por la CLI angular … así que era solo una aplicación nueva y en blanco.

Así que borré el repository, restauré mi código de una copy de security y comencé de nuevo. Esta vez, agregué una exclusión para .mp4 a mi file .gitignore . Estaba seguro de que esa exclusión evitaría que Git intente upload el video con la confirmación. No lo hizo. Así que básicamente estoy en el mismo barco que ayer. Estoy en medio de un empujón sin éxito. El file de video ofensivo está en mi historial y no entiendo por qué no fue excluido, o qué debo hacer para recuperarlo.

Estoy usando GitHub Desktop para Windows. Y tengo la versión 2.15.0 de Git instalada.

Entiendo que GitHub Desktop puede no proporcionar la solución que necesito, ya que parece que solo proporciona un subset limitado de la funcionalidad de git. Me siento muy cómodo trabajando desde una command-line para hacer lo que sea necesario hacer. No estoy seguro de qué es eso. Al intentar search soluciones a escenarios similares, las respuestas no parecían muy relevantes o no indicaban que definitivamente resolverían el problema.

Aquí está mi file .gitignore

# compiled output /dist /tmp /out-tsc # dependencies /node_modules # IDEs and editors /.idea .project .classpath .c9/ *.launch .settings/ *.sublime-workspace # IDE - VSCode .vscode/* !.vscode/settings.json !.vscode/tasks.json !.vscode/launch.json !.vscode/extensions.json # misc /.sass-cache /connect.lock /coverage /libpeerconnection.log npm-debug.log testem.log /typings # e2e /e2e/*.js /e2e/*.map # System Files .DS_Store Thumbs.db # Video file exclusion .mp4 

Cambie el .mp4 a *.mp4 , de lo contrario, solo coincidirá con los files llamados .mp4 . Puede usar git rm --cached $(file) para eliminar files que ya están comprometidos sin eliminarlos del tree de trabajo.

Comencemos por aclarar un concepto erróneo.

git revert no eliminó nada de su repository. Si no se perdió el historial detallado al eliminar el repository y comenzar de nuevo, está bien; pero la reversión no es una razón para hacer eso. Lo que revert es crear uno o más parches para "deshacer" los cambios de uno o más commits antiguos, y bien crear un nuevo commit para cada parche (el pnetworkingeterminado) o aplicar todos los parches al work-in-progress. Aunque el estado posterior a la revocación puede haber parecido presentar un tree de trabajo vacío, el historial todavía estaba allí (como se vería con el git log , por ejemplo). Este historial es la razón principal para utilizar el control de origen, por lo que es importante comprender la diferencia entre un tree de trabajo vacío y un repository vacío.

Inmediatamente después del command de revert , podría haber deshecho la revert con un reset , como

 git reset --hard HEAD^ 

Incluso si hicieras otras cosas en el medio, serás capaz de deshacer de manera segura la reversión siempre y cuando no hayas empujado con éxito nada. (La guía exacta sería más matizada, pero este es un buen punto de partida para comprender). El único truco sería encontrar un "nombre" del compromiso original al que desea regresar.

Dicho esto, si tenía una copy de security del código y el repository no tenía un historial valioso, comenzar con un nuevo repository no es una mala solución al problema de que un file grande ya estaba comprometido con el repository existente. Hay forms de limpiar un repository existente y deshacerse de sus files grandes, pero esas forms son un poco complicadas; Entonces, en este caso, un nuevo comienzo es razonable.

Pero, por último, debe asegurarse de comprender cómo funciona el mecanismo de "ignorar la regla" de git. Cada regla de ignorar es un patrón que puede coincidir con una o más routes, y cualquier file sin seguimiento en dicha ruta se ignora. Un file está "sin seguimiento" si no hay ninguna input para esa ruta en el índice. Una vez que un file ha sido organizado (con git add ) está en el índice, donde normalmente permanece. (Cuando se commit , el file también se agrega a la database, es bastante difícil eliminar un file de la database).

Entonces, lo que quieres hacer es, a medida que recreas el repository, antes de hacer cualquier command de git add , crea tu .gitignore . También asegúrese de que contenga una ruta que coincida con su file. Como se discutió en otra parte, .mp4 no coincidirá con "todos los files MP4"; eso sería *.mp4