Cómo eliminar archivos no rastreados en Git

En Git, el archivo .gitignore es una herramienta esencial que te ayuda a gestionar qué archivos y directorios se incluyen en tu repositorio de control de versiones. Al usar .gitignore, los desarrolladores pueden evitar que se rastreen archivos innecesarios, como archivos de registro, dependencias o archivos específicos del sistema. Esta guía explica cómo crear y utilizar un archivo .gitignore de forma eficiente. El archivo .gitignore le indica a Git qué archivos o directorios debe ignorar en un proyecto. Permite a los desarrolladores excluir archivos que no son necesarios para el proyecto, ayudando a mantener un historial de versiones más limpio y eficiente. Por qué usar .gitignore Evitar desorden: evita que archivos grandes o innecesarios saturen tu repositorio. Privacidad: mantiene fuera del control de versiones información sensible como claves API, credenciales o archivos de configuración. Eficiencia: agiliza la colaboración asegurando que solo se rastreen y compartan los archivos esenciales. Crear un archivo .gitignore Crear un archivo .gitignore es sencillo. 1. Navega a tu repositorio Git. Abre tu terminal y navega al directorio raíz de tu proyecto Git. cd /path/to/your/git/project 2. Crea el archivo .gitignore. Puedes crear el archivo con el siguiente comando: touch .gitignore 3. Abre y edita el archivo .gitignore. Abre el archivo .gitignore en tu editor de texto y añade los archivos o directorios que deseas que Git ignore. Por ejemplo: # Ignorar la carpeta node_modulesnode_modules/# Ignorar archivos de registro*.log# Ignorar archivos .env.env 4. Guarda y confirma los cambios. Después de editar, guarda el archivo .gitignore y confirma los cambios en Git. git add .gitignoregit commit -m "Add .gitignore" Patrones comunes en .gitignore Existen varios patrones comunes utilizados en los archivos .gitignore para especificar archivos o directorios que deben excluirse. A continuación, se muestran algunos ejemplos de patrones frecuentemente utilizados. Ignorar archivos por extensión: *.log   # Ignorar todos los archivos de registro*.tmp  # Ignorar todos los archivos temporales*.swp  # Ignorar archivos swap creados por editores de texto Ignorar directorios específicos: /logs/   # Ignorar el directorio logs/temp/   # Ignorar el directorio temp Ignorar archivos ocultos: .*   # Ignorar todos los archivos ocultos que empiezan con un punto (p. ej., .DS_Store) Ignorar archivos en una carpeta específica: /docs/*.pdf   # Ignorar todos los archivos PDF dentro de la carpeta docs Negar un patrón (incluir archivos que previamente habían sido excluidos): *.pdf    # Ignorar todos los archivos PDF!resume.pdf # No ignorar resume.pdf Ignorar archivos globalmente vs. localmente Aunque .gitignore normalmente se crea en la raíz de tu repositorio, también puedes configurar Git para ignorar archivos globalmente, lo que se aplica a todos los repositorios en tu máquina. Ignorar archivos localmente Si deseas excluir archivos solo en tu repositorio actual, simplemente edita el archivo .gitignore dentro de ese proyecto. Esto asegura que la exclusión se aplique únicamente a ese repositorio. Ignorar archivos globalmente Para crear un archivo .gitignore global, que se aplique en todos tus repositorios, sigue estos pasos: 1. Crea un archivo .gitignore global: touch ~/.gitignore_global 2. Añade patrones al archivo .gitignore global: Edita el archivo e incluye patrones para los archivos que deseas ignorar globalmente. Por ejemplo: *.log*.tmp.DS_Store 3. Configura Git para usar el archivo .gitignore global: git config --global core.excludesfile ~/.gitignore_global Mejores prácticas para usar .gitignore Para aprovechar al máximo .gitignore, sigue estas buenas prácticas: Añade .gitignore desde el inicio Crea un archivo .gitignore tan pronto como inicies un proyecto para evitar que se rastreen archivos innecesarios. Mantén el archivo organizado Organiza tu .gitignore agrupando patrones relacionados y añadiendo comentarios. Por ejemplo: # Archivos generados por el sistema operativo.DS_StoreThumbs.db# Dependencias de Node.jsnode_modules/ No confirmes información sensible Usa .gitignore para asegurarte de que archivos privados como claves API y configuraciones sensibles no se confirmen accidentalmente en el control de versiones. Prueba tu .gitignore Utiliza git status para verificar si tu archivo .gitignore está excluyendo archivos correctamente. Si un archivo aún se rastrea, es posible que haya sido añadido al repositorio antes de ser ignorado. Solución de problemas con .gitignore A veces, archivos que deberían ser ignorados siguen siendo rastreados. A continuación, se presentan algunas causas comunes y sus soluciones. Archivos ya rastreados Si un archivo fue añadido al repositorio antes de incluirlo en .gitignore, Git continuará rastreándolo. Para dejar de rastrear el archivo: 1. Elimina el archivo de Git sin borrarlo localmente: git rm --cached filename 2. Añade el archivo a .gitignore. 3. Confirma el .gitignore actualizado y la eliminación del archivo en caché: git commit -m "Update .gitignore and remove cached files" Problemas de mayúsculas y minúsculas Git distingue entre mayúsculas y minúsculas, así que asegúrate de que los patrones en tu archivo .gitignore coincidan exactamente con el nombre del archivo. Por ejemplo: file.txt # Ignora file.txt pero no File.txt Probar con git check-ignore Para verificar si un archivo está siendo ignorado correctamente, puedes usar el comando git check-ignore: git check-ignore -v filename Este comando muestra la regla responsable de ignorar un archivo determinado. Conclusión Usar .gitignore de manera efectiva te permite gestionar qué archivos se incluyen en tu repositorio Git y garantiza que solo se rastreen los archivos esenciales. Sigue los pasos de esta guía para crear, personalizar y solucionar problemas de tu archivo .gitignore y así mantener una gestión de versiones eficiente.

En el sistema de control de versiones Git, existen dos formas de combinar una rama con otra, representadas por diferentes comandos: git merge. Los commits de una rama se transfieren a otra creando un commit de fusión (merge commit). git rebase. Los commits de una rama se transfieren a otra mientras se conserva el orden original de los cambios. En pocas palabras: con git merge, los commits de una rama se “comprimen” en uno solo, mientras que con git rebase permanecen intactos, pero las ramas se combinan igualmente. El comando git rebase permite, por tanto, combinar los commits de ambas ramas formando un historial compartido de cambios. Esta guía aborda el comando git rebase, que se encarga de reasignar (rebasar) los commits (cambios) de una rama a otra. Todos los ejemplos mostrados usan Git versión 2.34.1, ejecutándose en un servidor de Hostman con el sistema operativo Ubuntu 22.04. Puedes usar estas guías para instalar Git en tu equipo: Installing Git on Ubuntu Installing Git on Windows Qué es Git Rebase Git Rebase es un comando potente que se usa principalmente para integrar cambios de una rama sobre otra reescribiendo el historial de commits. A diferencia de git merge, que crea un nuevo commit de fusión y preserva el historial de ambas ramas, git rebase mueve o “reproduce” una serie de commits de una rama sobre otra. Este proceso genera un historial lineal, que parece como si la rama de funciones se hubiera desarrollado directamente desde el último commit de la rama principal (por ejemplo, main o master). Así, se limpia el historial y se eliminan commits de fusión innecesarios, resultando en una estructura de proyecto más clara y organizada. Cómo funciona Git Rebase La mejor manera de entender cómo funciona rebase en Git es observar un repositorio abstracto compuesto por varias ramas. El proceso debe analizarse paso a paso. Creación de ramas Supongamos que creamos un repositorio con una sola rama, master, que contiene un único commit. La rama master se ve así: master   commit_1 Luego, a partir de master, creamos una nueva rama llamada hypothesis, donde decidimos probar algunas funciones. En esta nueva rama realizamos varios commits mejorando el código. La rama ahora se ve así: hypothesis   commit_4   commit_3   commit_2   commit_1 Más tarde, añadimos otro commit a la rama master para corregir urgentemente una vulnerabilidad. La rama master ahora se ve así: master   commit_5   commit_1 Ahora nuestro repositorio tiene dos ramas: master   commit_5   commit_1 hypothesis   commit_4   commit_3   commit_2   commit_1 La rama master es la principal, mientras que hypothesis es secundaria (derivada). Los commits más recientes se muestran encima de los anteriores, como en la salida del comando git log. Fusión de ramas Supongamos que queremos seguir trabajando en la función que habíamos movido a la rama hypothesis. Sin embargo, esta rama no contiene la corrección crítica que hicimos en master. Por lo tanto, queremos “sincronizar” el estado de hypothesis con master para que el commit de corrección también aparezca en la rama de funciones. En otras palabras, queremos que la estructura del repositorio se vea así: master   commit_5   commit_1 hypothesis   commit_4   commit_3   commit_2   commit_5   commit_1 Como puedes ver, ahora hypothesis repite exactamente el historial de master, aunque originalmente se creó antes de commit_5. Es decir, hypothesis ahora contiene el historial de ambas ramas: la suya y la de master. Para lograrlo, debemos usar git rebase. Después, los cambios hechos en hypothesis pueden fusionarse en master usando el comando clásico git merge, que crea un commit de fusión. La estructura del repositorio se verá así: master   commit_merge   commit_5   commit_1 hypothesis   commit_4   commit_3   commit_2   commit_5   commit_1 Además, ejecutar git merge después de git rebase puede reducir la probabilidad de conflictos. Práctica: git rebase Una vez cubierto el aspecto teórico del comando git rebase, podemos probarlo en un repositorio real de un proyecto de ejemplo. La estructura del repositorio será la misma que en el ejemplo teórico anterior. Creación de un repositorio Primero, crea un directorio separado para el repositorio: mkdir rebase Luego entra en él: cd rebase Ahora podemos inicializar el repositorio: git init En la consola aparecerá un mensaje informativo estándar: hint: Using 'master' as the name for the initial branch. This default branch name hint: is subject to change. To configure the initial branch name to use in all hint: of your new repositories, which will suppress this warning, call: ... Y en el directorio actual aparecerá una carpeta oculta .git, que puedes ver con: ls -a El parámetro -a significa all y permite ver el sistema de archivos en modo extendido. Su contenido será: .  ..  .git Antes de crear commits, debemos configurar algunos datos básicos del usuario. Primero, el nombre: git config --global user.name "NAME" Luego el correo electrónico: git config --global user.email "NAME@HOST.COM" Llenar la rama master Usando archivos de texto simples, simularemos la adición de diferentes funciones al proyecto. Cada nueva función se representará como un commit separado. Crea un archivo para la primera función: nano function_1 Rellénalo con el siguiente contenido: Function 1 Ahora indexa los cambios: git add . Verifica el estado de indexación: git status En la consola debería aparecer un mensaje indicando los cambios indexados: On branch master No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: function_1 Ahora podemos hacer commit: git commit -m "commit_1" La consola mostrará un mensaje confirmando el commit exitoso en master: [master (root-commit) 4eb7cc3] commit_1  1 file changed, 1 insertion(+)  create mode 100644 function_1 Llenar la rama hypothesis Ahora crea una nueva rama llamada hypothesis: git checkout -b hypothesis El parámetro -b sirve para cambiar inmediatamente a la nueva rama. La consola mostrará un mensaje de confirmación: Switched to a new branch 'hypothesis' A continuación, debemos realizar tres commits consecutivos con tres archivos, igual que en master: commit_2 con el archivo function_2 y contenido: Function 2 commit_3 con el archivo function_3 y contenido: Function 3 commit_4 con el archivo function_4 y contenido: Function 4 Si luego comprobamos la lista de commits: git log --oneline La consola mostrará la siguiente secuencia: d3efb82 (HEAD -> hypothesis) commit_4 c9f57b7 commit_3 c977f16 commit_2 4eb7cc3 (master) commit_1 Aquí, la opción --oneline se usa para mostrar la información de los commits en formato resumido. Añadir un commit a la rama master El último paso es añadir otro commit a la rama principal master. Cambia a ella: git checkout master La consola confirmará el cambio: Switched to branch 'master' Crea otro archivo de función: nano function_5 Con el siguiente contenido: Function 5 Indexa los cambios: git add . Y haz el nuevo commit: git commit -m "commit_5" Si comprobamos la lista de commits: git log --oneline La rama master ahora tendrá dos commits: 3df7a00 (HEAD -> master) commit_5 4eb7cc3 commit_1 Combinar ramas con git rebase Para realizar el rebase, primero hay que cambiar a la rama hypothesis: git checkout hypothesis Y ejecutar el rebase: git rebase master Después, la consola mostrará un mensaje confirmando un rebase exitoso: Successfully rebased and updated refs/heads/hypothesis. Ahora puedes comprobar la lista de commits: git log --oneline La consola mostrará una lista con los commits de ambas ramas en el orden original: 8ecfd58 (HEAD -> hypothesis) commit_4 f715aba commit_3 ee47470 commit_2 3df7a00 (master) commit_5 4eb7cc3 commit_1 Ahora la rama hypothesis contiene el historial completo del repositorio. Resolución de conflictos Al igual que con git merge, al usar el comando git rebase pueden ocurrir conflictos que requieren resolución manual. Crea otro archivo en la rama hypothesis: nano conflict Y escribe el siguiente texto: There must be a conflict here! Indexa los cambios: git add . Haz un commit: git commit -m "conflict_1" Ahora cambia a la rama master: git checkout master Crea un archivo similar: nano conflict Y agrega el siguiente contenido: There must NOT be a conflict here! Indexa los cambios: git add . Haz un commit: git commit -m "conflict_2" Modifica nuevamente el archivo: nano conflict Cámbialo por: There definitely must NOT be a conflict here! Indexa y haz otro commit: git add . git commit -m "conflict_3" Cambia de nuevo a hypothesis y ejecuta: git checkout hypothesis git rebase master La consola mostrará un mensaje de conflicto: Auto-merging conflict CONFLICT (add/add): Merge conflict in conflict error: could not apply 6003ed7... conflict_1 hint: Resolve all conflicts manually, mark them as resolved with hint: "git add/rm <conflicted_files>", then run "git rebase --continue". hint: You can instead skip this commit: run "git rebase --skip". hint: To abort and get back to the state before "git rebase", run "git rebase --abort". Could not apply 6003ed7... conflict_1 Git sugiere editar el archivo de conflicto, indexar los cambios con git add y luego continuar con --continue. nano conflict El archivo contendrá dos versiones en conflicto dentro de marcadores especiales: <<<<<<< HEAD There definitely must NOT be a conflict here! ======= There must be a conflict here! >>>>>>> 6003ed7 (conflict_1) Nuestro trabajo es eliminar las partes innecesarias y dejar una versión final: There must absolutely definitely unanimously NOT be any conflict here! Indexa los cambios y continúa: git add . git rebase --continue Después de esto, la consola abrirá un editor de texto que te sugerirá modificar el mensaje de confirmación original de la confirmación donde ocurrió el conflicto: conflict_1 # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # interactive rebase in progress; onto bd7aefc # Last commands done (4 commands done): # pick 8ecfd58 commit_4 # pick 6003ed7 conflict_1 # No commands remaining. # You are currently rebasing branch 'hypothesis' on 'bd7aefc'. # # Changes to be committed: # modified: conflict # La consola mostrará un mensaje indicando que el proceso de rebase se ha completado correctamente: [detached HEAD 482db49] conflict_1  1 file changed, 1 insertion(+), 1 deletion(-) Successfully rebased and updated refs/heads/hypothesis. Ahora, si revisas la lista de confirmaciones en la rama de hipótesis: git log --oneline Verás la secuencia original de todos los cambios realizados: 482db49 (HEAD -> hypothesis) conflict_1 bd5d036 commit_4 407e245 commit_3 948b41c commit_2 bd7aefc (master) conflict_3 d98648d conflict_2 3df7a00 commit_5 4eb7cc3 commit_1 Observa que las confirmaciones conflict_2 y conflict_3, realizadas en la rama master, aparecen en el historial antes que la confirmación conflict_1. Sin embargo, esto aplica a todas las confirmaciones realizadas en la rama master. Rebase de un repositorio remoto Además de trabajar con ramas locales, también es posible hacer rebase al extraer cambios de un repositorio remoto. Para ello, se añade la opción --rebase al comando pull: git pull --rebase remote branch Donde: remote es el repositorio remoto branch es la rama remota Básicamente, esta configuración de pull es equivalente a git rebase, salvo que los commits aplicados en la rama actual provienen del repositorio remoto. Principales ventajas de Git Rebase Historial lineal El comando git rebase permite crear un historial lineal en la rama de destino, compuesto por commits secuenciales. Esta secuencia sin ramificaciones hace que el historial sea más fácil de leer y entender. Menos conflictos  Ejecutar git rebase antes puede reducir significativamente la probabilidad de conflictos al fusionar ramas con git merge. Los conflictos son más fáciles de resolver en commits secuenciales que en uno solo de fusión. Esto es especialmente útil al enviar ramas a repositorios remotos. Desventajas de Git Rebase Modificación del historial A diferencia de merge, rebase reescribe parcialmente el historial de la rama de destino, eliminando elementos innecesarios. Riesgo de errores  La capacidad de reestructurar significativamente el historial puede causar errores irreversibles en el repositorio, lo que podría provocar la pérdida permanente de datos. Cuándo usar Git Rebase Git rebase es especialmente útil al trabajar en ramas pequeñas o de características individuales que finalmente se fusionarán en la rama principal. También es ideal para mantener un historial limpio y lineal, lo que resulta beneficioso en proyectos de código abierto o cuando es necesario un historial claro para depuración y comprensión. Sin embargo, en entornos colaborativos con varios desarrolladores, se debe usar con precaución para evitar problemas por reescritura de historial público. Es importante comunicar al equipo cuándo es apropiado rebasar. En muchos casos, git merge puede ser más seguro y simple. Consideraciones importantes Reescritura del historial Uno de los aspectos críticos de git rebase es que reescribe el historial de commits, lo que cambia los identificadores SHA-1. Esto puede generar problemas en entornos colaborativos, especialmente si se rebasea una rama que ya fue enviada a un remoto. Esto puede provocar conflictos al intentar hacer push. Evita rebasear ramas públicas Como práctica recomendada, evita hacer rebase a ramas públicas que ya han sido compartidas, ya que esto puede crear historiales divergentes y conflictos difíciles de resolver. Git rebase es más adecuado para ramas locales o para preparar una rama de funciones antes de fusionarla con la principal. Posibles conflictos Durante un rebase, si existen cambios conflictivos entre ramas, Git se detendrá y pedirá resolverlos manualmente. Aunque la resolución es similar a la de merge, puede requerir más trabajo, especialmente en ramas largas. Después de resolver los conflictos, puedes continuar con: git rebase --continue Conclusión Combinar dos ramas usando rebase, mediante el comando git rebase, es fundamentalmente diferente del merge clásico con git merge. git merge combina los commits de una rama en un solo commit dentro de otra. git rebase mueve los commits de una rama al final de otra, manteniendo el orden original. Un efecto similar se puede lograr usando git pull con la opción --rebase. Por un lado, git rebase permite mantener un historial más limpio y comprensible en la rama principal, mejorando la mantenibilidad del repositorio. Por otro lado, git rebase simplifica la historia eliminando algunos detalles, lo que puede reducir la trazabilidad de los cambios. Por esta razón, rebase es una herramienta pensada para usuarios experimentados que entienden cómo funciona Git. A menudo, git rebase se usa junto con git merge para lograr una estructura óptima del repositorio y las ramas.