A lo largo del libro hemos introducido docenas de comandos de Git y nos hemos esforzado para introducirlos dentro de una especie de narrativa, añadiendo más comandos a la historia poco a poco. Sin embargo, esto nos deja con ejemplos de uso de los comandos algo dispersos por todo el libro.
En este apéndice, repasaremos todos los comandos de Git que hemos tratado a lo largo del libro, agrupados por el uso que se les ha dado. Vamos a hablar de lo que hace cada comando de manera muy general y a continuación señalaremos en qué parte del libro puedes encontrar un uso de él.
Hay dos comandos que se usan bastante, desde las primeras invocaciones de Git hasta el ajuste y referenciamiento diario, los comandos config y help.
Git tiene una forma predeterminada de hacer cientos de cosas. Para muchas de estas cosas, puedes indicar a Git hacerlas por defecto de una manera diferente, o establecer tus preferencias. Esto incluye todo, desde decir a Git cuál es tu nombre a las preferencias de color específicas del terminal o qué editor utilizar. Hay varios archivos desde los que este comando lee y a los que escribe, así puedes establecer los valores a nivel global o hacia abajo para repositorios específicos.
El comando git config se ha utilizado en casi todos los capítulos del libro.
En ch01-introduction.asc lo usamos para especificar nuestro nombre, dirección de correo electrónico y editor de preferencia antes incluso de comenzar a utilizar Git.
En ch02-git-basics.asc mostramos cómo se puede utilizar para crear comandos abreviados que se expanden para secuencias largas de opciones para no tener que escribirlas cada vez.
En ch03-git-branching.asc lo usamos para hacer --rebase predeterminado cuando se ejecuta git pull.
En ch07-git-tools.asc lo usamos para establecer un almacén predeterminado para tus contraseñas HTTP.
En ch08-customizing-git.asc mostramos como configurar filtros sucios y limpios sobre contenido que entra y sale de Git.
Finalmente, básicamente la totalidad de ch08-customizing-git.asc está dedicado al comando.
El comando git help se utiliza para presentarte toda la documentación contenida con Git sobre cualquier comando. A pesar de que estamos dando una visión general de la mayoría de los más populares en este apéndice, para obtener una lista completa de todas las posibles opciones e indicadores para cada orden, siempre se puede ejecutar git help <command>.
Introducimos el comando git help en ch01-introduction.asc y te mostramos cómo utilizarlo para encontrar más información sobre el git shell en ch04-git-server.asc.
Hay dos maneras de obtener un repositorio Git. Una de ellas es copiarlo desde un repositorio existente en la red o en otro lugar y la otra es crear uno nuevo en un directorio existente.
Para tomar un directorio y convertirlo en un nuevo repositorio Git en el que puedas empezar a controlar sus versiones, simplemente puedes ejecutar git init.
En primer lugar, introducimos esto en ch02-git-basics.asc, donde mostramos la creación de un nuevo repositorio para empezar a trabajar.
Hablamos brevemente acerca de cómo puedes cambiar la rama por defecto desde ``master'' en ch03-git-branching.asc.
Usamos este comando para crear un repositorio desnudo (bare) vacío para un servidor en ch04-git-server.asc.
Por último, examinamos algunos de los detalles de lo que realmente hace detrás de escena en ch10-git-internals.asc.
El comando 'git clone` es en realidad una especie de envoltura alrededor de varios otros comandos. Éste crea un nuevo directorio, entra en él y ejecuta git init para que sea un repositorio vacío de Git, añade uno remoto (git remote add) hacia la dirección URL que se le pasa (por defecto llamado origin), ejecuta un git fetch de ese repositorio remoto y después activa el último commit en el directorio de trabajo con git checkout.
El comando git clone es utilizado en docenas de lugares a lo largo del libro, pero sólo enumeraremos algunos lugares interesantes.
Básicamente se introdujo y se explicó en ch02-git-basics.asc, donde examinamos algunos ejemplos.
En ch04-git-server.asc nos fijamos en el uso de la opción --bare para crear una copia de un repositorio Git sin directorio de trabajo.
En ch07-git-tools.asc lo usamos para desempaquetar un repositorio Git empaquetado (bundle).
Finalmente, en ch07-git-tools.asc aprendemos la opción --recursive para realizar la clonación de un repositorio con submódulos un poco más simple.
Aunque se usa en muchos otros lugares a través del libro, estos son los que son algo únicos o donde se utiliza en formas que son un poco diferentes.
Para el flujo de trabajo básico de la preparación de contenido y su confirmación a su historia, hay sólo unos pocos comandos básicos.
El comando git add añade contenido del directorio de trabajo al área de ensayo (staging area o ''index'') para la próxima confirmación. Cuando se ejecuta el comando git commit, éste, de forma predeterminada, sólo mira en esta área de ensayo, por lo que git add se utiliza para fabricar exactamente lo que te gustaría fuese tu próxima instantánea a confirmar.
Este comando es un comando increíblemente importante en Git y se menciona o se utiliza docenas de veces en este libro. Vamos a cubrir rápidamente algunos de los usos únicos que se pueden encontrar.
En primer lugar, introducimos y explicamos git add en detalle en ch02-git-basics.asc.
Mostramos como usarlo para resolver conflictos de fusión en ch03-git-branching.asc.
Repasamos su uso para seguir de forma interactiva sólo partes específicas de un archivo modificado en ch07-git-tools.asc.
Por último, lo emulamos en un bajo nivel en ch10-git-internals.asc, por lo que podemos tener una idea de lo que está haciendo detrás de escena.
El comando git status te mostrará los diferentes estados de los archivos en tu directorio de trabajo y área de ensayo. Qué archivos están modificados y sin seguimiento y cuáles con seguimiento pero no confirmados aún. En su forma normal, también te mostrará algunos consejos básicos sobre cómo mover archivos entre estas etapas.
Primero cubrimos status en ch02-git-basics.asc, tanto en su forma básica como simplificada. Mientras lo utilizamos a lo largo del libro, prácticamente todo lo que puedes hacer con el comando git status está cubierto allí.
El comando git diff se utiliza cuando deseas ver las diferencias entre dos árboles. Esto prodría ser la diferencia entre tu entorno de trabajo y tu área de ensayo (git diff por sí mismo), entre tu área de ensayo y tu última confirmación o commit (git diff --staged), o entre dos confirmaciones (git diff master branchB).
En primer lugar, vemos el uso básico de git diff en ch02-git-basics.asc, donde mostramos cómo ver que cambios tienen seguimiento y cuáles no tienen seguimiento aún.
Lo usamos para buscar posibles problemas con espacios en blanco antes de confirmar con la opción --check en ch05-distributed-git.asc.
Vemos cómo comprobar las diferencias entre ramas de manera más eficaz con la sintaxis git diff A…B en ch05-distributed-git.asc.
Lo usamos para filtrar diferencias en espacios en blanco con -w y como comparar diferentes etapas de archivos en conflicto con --theirs, --ours y --base en ch07-git-tools.asc.
Finalmente, lo usamos para realmente comparar cambios en submódulos con --submodule en ch07-git-tools.asc.
El comando git difftool simplemente lanza una herramienta externa para mostrar la diferencia entre dos árboles, en caso de que desees utilizar algo que no sea el comando`git diff` incorporado.
Mencionamos sólo brevemente esto en ch02-git-basics.asc.
El comando git commit toma todos los contenidos de los archivos a los que se les realiza el seguimiento con git add y registra una nueva instantánea permanente en la base de datos y luego avanza el puntero de la rama en la rama actual.
En primer lugar, cubrimos los fundamentos en ch02-git-basics.asc. Allí también mostramos cómo utilizar el indicador -a para saltarse el paso git add en los flujos de trabajo diarios y cómo utilizar el indicador -m para pasar un mensaje de confirmación en la línea de comandos en lugar de lanzar un editor.
En ch02-git-basics.asc cubrimos el uso de la opción --amend para deshacer el commit más reciente.
En ch03-git-branching.asc, entramos en mucho mayor detalle en lo que git commit hace y por qué lo hace así.
Consideramos como firmar criptográficamente commits con el indicador -S en ch07-git-tools.asc.
Finalmente, echamos un vistazo a lo que el comando git commit hace en segundo plano y cómo se implementa realmente en ch10-git-internals.asc.
El comando git reset se utiliza sobre todo para deshacer las cosas, como posiblemente puedes deducir por el verbo. Se mueve alrededor del puntero HEAD y opcionalmente cambia el index o área de ensayo y también puede cambiar opcionalmente el directorio de trabajo si se utiliza --hard. Esta última opción hace posible que este comando pueda perder tu trabajo si se usa incorrectamente, por lo que asegúrese de entenderlo antes de usarlo.
En primer lugar, cubrimos efectivamente el uso más simple de git reset en ch02-git-basics.asc, donde lo usamos para dejar de hacer seguimiento (unstage) de un archivo sobre el que habíamos ejecutado git add.
A continuación, lo cubrimos con bastante detalle en ch07-git-tools.asc, que está completamente dedicado a la explicación de este comando.
Utilizamos git reset --hard para abortar una fusión en ch07-git-tools.asc, donde también usamos git merge --abort, el cual es una especie de envoltorio para el comando git reset.
El comando git rm se utiliza para eliminar archivos del área de ensayo y el directorio de trabajo para Git. Es similar a git add en que pone en escena una eliminación de un archivo para la próxima confirmación.
Cubrimos el comando git rm con cierto detalle en ch02-git-basics.asc, incluyendo la eliminación de archivos de forma recursiva y sólo la eliminación de archivos desde el área de ensayo, pero dejándolos en el directorio de trabajo con --cached.
El único otro uso diferente de git rm en el libro está en ch10-git-internals.asc, donde utilizamos brevemente y explicamos el --ignore-unmatch al ejecutar git filter-branch, el cual simplemente hace que no salga un error cuando el archivo que estamos tratando de eliminar no existe. Esto puede ser útil para fines de scripting.
El comando git mv es un comando de conveniencia para mover un archivo y luego ejecutar git add en el nuevo archivo y git rm en el archivo antiguo.
Sólo mencionamos brevemente este comando en ch02-git-basics.asc.
El comando git clean se utiliza para eliminar archivos no deseados de tu directorio de trabajo. Esto podría incluir la eliminación de artefactos de construcción temporal o la fusión de archivos en conflicto.
Cubrimos muchas de las opciones y escenarios en los que es posible usar el comando clean en ch07-git-tools.asc.
Hay sólo un puñado de comandos que implementan la mayor parte de la funcionalidad de ramificación y fusión en Git.
El comando git branch es en realidad una especie de herramienta de gestión de ramas. Puede listar las ramas que tienes, crear una nueva rama, eliminar ramas y cambiar el nombre de las ramas.
La mayor parte de ch03-git-branching.asc está dedicada al comando branch y es utilizado a lo largo de todo el capítulo. En primer lugar, lo introducimos en ch03-git-branching.asc y examinamos la mayor parte de sus otras características (listar y borrar) en ch03-git-branching.asc.
En ch03-git-branching.asc usamos la opción git branch -u para establecer una rama de seguimiento.
Finalmente, examinamos algo de lo que hace en segundo plano en ch10-git-internals.asc.
El comando git checkout se usa para cambiar de rama y revisar el contenido de tu directorio de trabajo.
En primer lugar, encontramos el comando en ch03-git-branching.asc junto con el comando git branch.
Vemos cómo usarlo para iniciar el seguimiento de ramas con el indicador --track en ch03-git-branching.asc.
Lo usamos para reintroducir los conflictos de archivos con --conflict=diff3 en ch07-git-tools.asc.
Entramos en más detalle sobre su relación con git reset en ch07-git-tools.asc.
Finalmente, examinamos algún detalle de implementación en ch10-git-internals.asc.
La herramienta git merge se utiliza para fusionar uno o más ramas dentro de la rama que tienes activa. A continuación avanzará la rama actual al resultado de la fusión.
El comando git merge fue introducido por primera en ch03-git-branching.asc. A pesar de que se utiliza en diversos lugares en el libro, hay muy pocas variaciones del comando merge — en general, sólo git merge <branch> con el nombre de la rama individual que se desea combinar.
Cubrimos cómo hacer una fusión aplastada (squashed merge) (donde Git fusiona el trabajo, pero finge como si fuera simplemente un nuevo commit sin registrar la historia de la rama que se está fusionando) al final de ch05-distributed-git.asc.
Repasamos mucho sobre el proceso de fusión y dirección, incluyendo el comando -Xignore-all-whitespace y el indicador --abort para abortar un problema de fusión en ch07-git-tools.asc.
Aprendimos cómo verificar las firmas antes de la fusión si tu proyecto está usando fimas GPG en ch07-git-tools.asc.
Finalmente, aprendimos sobre la fusión de subárboles en ch07-git-tools.asc.
El comando git mergetool simplemente lanza un ayudante de fusión externo en caso de tener problemas con una combinación en Git.
Lo mencionamos rápidamente en ch03-git-branching.asc y entramos en detalle sobre cómo implementar tu propia herramienta de fusión externa en ch08-customizing-git.asc.
El comando git log se utiliza para mostrar la historia registrada alcanzable de un proyecto desde la más reciente instantánea confirmada hacia atrás. Por defecto sólo se mostrará la historia de la rama en la que te encuentres, pero pueden ser dadas diferentes e incluso múltiples cabezas o ramas desde la que hacer el recorrido. También se utiliza a menudo para mostrar las diferencias entre dos o más ramas a nivel de commit.
Este comando se utiliza en casi todos los capítulos del libro para mostrar la historia de un proyecto.
Introducimos el comando y lo cubrimos con cierta profundidad en ch02-git-basics.asc. Allí vemos las opciones -p y --stat para tener una idea de lo que fue introducido en cada commit y las opciones --pretty y --oneline para ver el historial de forma más concisa, junto con unas simples opciones de filtrado de fecha y autor.
En ch03-git-branching.asc lo utilizamos con la opción --decorate para visualizar fácilmente donde se encuentran nuestros punteros de rama y también utilizamos la opción --graph para ver la apariencia de las historias divergentes.
En ch05-distributed-git.asc y ch07-git-tools.asc cubrimos la sintaxis branchA..branchB al usar el comando git log para ver que commits son únicos a una rama en relación a otra rama. En ch07-git-tools.asc repasamos esto bastante extensamente.
En ch07-git-tools.asc y ch07-git-tools.asc cubrimos el uso del formato branchA…branchB y la sintaxis --left-right para ver que está en una rama o en la otra pero no en ambas. En ch07-git-tools.asc también vemos como utilizar la opción --merge para ayudarnos con la depuración de conflictos de fusión así como el uso de la opción --cc para ver conflictos de fusión en tu historia.
En ch07-git-tools.asc usamos la opción -g para ver el reflog de Git a través de esta herramienta en lugar de hacer un recorrido de la rama.
En ch07-git-tools.asc vemos el uso de las opciones -S y -L para hacer búsquedas bastante sofisticados de algo que sucedió históricamente en el código como ver la historia de una función.
En ch07-git-tools.asc vemos como usar --show-signature para añadir una cadena de texto de validación a cada commit en la salida de git log basado en si fue válidadmente firmado o no.
El comando git stash se utiliza para almacenar temporalmente el trabajo no confirmado con el fin de limpiar el directorio de trabajo sin tener que confirmar el trabajo no acabado en una rama.
Básicamente esto es enteramente cubierto en ch07-git-tools.asc.
El comando git tag se utiliza para dar un marcador permanente a un punto específico en el historial del código fuente. Generalmente esto se utiliza para cosas como las liberaciones (releases).
Este comando se introduce y se trata en detalle en ch02-git-basics.asc y lo usamos en la práctica en ch05-distributed-git.asc.
También cubrimos cómo crear una etiqueta con firma GPG tag con el indicador -s y verificamos uno con el indicador -v en ch07-git-tools.asc.
No son muy numerosos los comandos de Git que acceden a la red, casi todos los comandos operan sobre la base de datos local. Cuando estas listo para compartir tu trabajo u obtener cambios de otros lugares, hay un puñado de comandos que tienen que ver con los repositorios remotos.
El comando git fetch comunica con un repositorio remoto y obtiene toda la información que se encuentra en ese repositorio que no está en el tuyo actual y la almacena en tu base de datos local.
En primer lugar, observamos este comando en ch02-git-basics.asc y seguimos viendo ejemplos de su uso en ch03-git-branching.asc.
También lo usamos en varios de los ejemplos en ch05-distributed-git.asc.
Lo usamos para buscar una única referencia específica que se encuentra fuera del espacio por defecto en ch06-github.asc y vemos cómo buscar en una agrupación en ch07-git-tools.asc.
Configuramos refspecs altamente personalizadas con el fin de hacer que git fetch haga algo un poco diferente de lo predeterminado en ch10-git-internals.asc.
El comando git pull es básicamente una combinación de los comandos git fetch y git merge, donde Git descargará desde el repositorio remoto especificado y a continuación, de forma inmediata intentará combinarlo en la rama en la que te encuentres.
Se introduce rápidamente en ch02-git-basics.asc y mostramos la forma de ver lo que se fusionará si se ejecuta en ch02-git-basics.asc.
También vemos cómo usarlo para ayudar con dificultades de rebase en ch03-git-branching.asc.
Mostramos cómo usarlo con una URL para obtener los cambios de forma de una sola vez en ch05-distributed-git.asc.
Por último, mencionamos muy rápidamente que se puede utilizar la opción --verify-signatures con el fin de verificar qué commits que estás descargando han sido firmados con GPG en <ch07-git-tools.asc.
El comando git push se utiliza para comunicar con otro repositorio, calcular lo que tu base de datos local tiene que la remota no tiene, y luego subir (push) la diferencia al otro repositorio. Se requiere acceso de escritura al otro repositorio y por tanto normalmente se autentica de alguna manera.
En primer lugar, observamos el comando git push en ch02-git-basics.asc. Aquí cubrimos los fundamentos de subir una rama a un repositorio remoto. En ch03-git-branching.asc profundizamos un poco más en la subida de ramas específicas y en ch03-git-branching.asc vemos cómo configurar el seguimiento de ramas a las que subir automáticamente. En ch03-git-branching.asc utilizamos el indicador --delete para eliminar una rama en el servidor con git push.
A lo largo de ch05-distributed-git.asc vemos varios ejemplos de uso de git push para compartir trabajo en ramas de múltiples repositorios remotos.
Vemos cómo usarlo para compartir las etiquetas que has creado con la opción --tags en ch02-git-basics.asc.
En ch07-git-tools.asc utilizamos la opción --recurse-submodules para comprobar que todo nuestro trabajo en submódulos se ha publicado antes de subir el superproyecto, lo cual puede ser muy útil cuando se utilizan submódulos.
En ch08-customizing-git.asc hablamos brevemente sobre el gancho pre-push, que es un script que podemos establecer para que se ejecute antes de que una subida se complete para verificar qué se debe permitir subir.
Por último, en ch10-git-internals.asc echamos un vistazo a la subida con un refspec completo en lugar de los atajos generales que se utilizan normalmente. Esto puede ayudar a ser muy específico acerca de qué trabajo se desea compartir.
El comando git remote es una herramienta de gestión para el registro de repositorios remotos. Esto te permite guardar largas direcciones URL como cortos manejadores (handles), tales como ''origin'', para que no tengas que escribir las URL todo el tiempo. Puedes tener varios de estos y el comando git remote se utiliza para añadir, modificar y borrarlos.
Este comando se trata en detalle en ch02-git-basics.asc, incluyendo listar, añadir, eliminar y cambiar el nombre de ellos.
Se utiliza en casi todos los capítulos subsiguientes en el libro también, pero siempre en la formato estándar git remote add <nombre> <url>.
El comando git archive se utiliza para crear un archivo empaquetado de una instantánea específica del proyecto.
Usamos git archive para crear un tarball de un proyecto para su compartición en ch05-distributed-git.asc.
El comando git submodule se utiliza para gestionar repositorios externos dentro de repositorios normales.
Esto podría ser por bibliotecas u otros tipos de recursos compartidos. El comando submodule tiene varios sub-commandos (add, update, sync, etc) para la gestión de estos recursos.
Este comando es sólo mencionado y cubierto enteramente en ch07-git-tools.asc.
El comando git show puede mostrar un objeto Git de una manera simple y legible por humanos. Normalmente se usaría esto para mostrar la información sobre una etiqueta o un commit.
Primero lo usamos para mostrar información de etiqueta con anotaciones en ch02-git-basics.asc.
Más tarde lo usamos bastante en ch07-git-tools.asc para mostrar las confirmaciones que nuestras diversas selecciones de revisión resuelven.
Una de las cosas más interesantes que ver con git show está en ch07-git-tools.asc para extraer contenidos de un archivo específico de diversas etapas durante un conflicto de fusión.
El comando git shortlog se utiliza para resumir la salida de git log. Toma muchas de las mismas opciones que el comando git log pero, en lugar de enumerar todos las commits, presentará un resumen de los commits agrupados por autor.
Mostramos cómo usarlo para crear un buen registro de cambios en ch05-distributed-git.asc.
El comando git describe se utiliza para tomar cualquier cosa que remite a un commit y producir una cadena de texto que es de alguna manera legible por humanos y no va a cambiar. Es una manera de obtener una descripción de un commit que es tan inequívoca como el SHA-1 del commit, pero más comprensible.
Utilizamos git describe en ch05-distributed-git.asc y ch05-distributed-git.asc para obtener una cadena de texto para nombrar nuestro archivo de liberación.
Git tiene un par de comandos que se utilizan para ayudar a depurar un problema en tu código. Esto va desde averiguar donde algo se introdujo a averiguar quién lo introdujo.
La herramienta git bisect es una herramienta de depuración increíblemente útil, utilizada para encontrar qué commit específico fue el primero en introducir un bug o problema, haciendo una búsqueda binaria automática.
Está completamente cubierto de ch07-git-tools.asc y sólo se menciona en esa sección.
El comando git blame toma nota de las líneas de cualquier archivo con cual commit fue el último en introducir un cambio en cada línea del archivo y qué persona fue autor de ese commit. Esto es muy útil con el fin de encontrar a la persona para pedir más información sobre una sección específica de tu código.
Se cubre en ch07-git-tools.asc y sólo se menciona en esa sección.
El comando git grep puede ayudarte a encontrar cualquier cadena o expresión regular en cualquiera de los archivos en tu código fuente, incluyendo versiones más antiguas de tu proyecto.
Está cubierto en ch07-git-tools.asc y sólo se menciona en esa sección.
Unos comandos de Git se centran en el concepto de interpretar los commits en términos de los cambios que introducen, concibiendo las series de commit como series de parches. Estos comandos te ayudan a administrar tus ramas de esta manera.
El comando git cherry-pick se utiliza para tomar el cambio introducido en un único commit de Git y tratar de volver a introducirlo como un nuevo commit en la rama donde estás actualmente. Esto puede ser útil para escoger solamente uno o dos commits de una rama individual en lugar de fusionar la rama que contiene todos los cambios.
Esto se describe y se muestra en ch05-distributed-git.asc.
El comando git rebase es básicamente un cherry-pick automatizado. Determina una serie de commits y luego los escoge uno a uno en el mismo orden en otro lugar.
El rebasing se cubre en detalle en ch03-git-branching.asc, inclusive cubriendo las incidencias de colaboración involucradas con el rebasing de ramas que ya son públicas.
Lo usamos en la práctica durante un ejemplo de dividir la historia en dos repositorios separados en ch07-git-tools.asc, utilizando el indicador --onto también.
Experimentamos la ejecución de un conflicto de fusión durante el rebasing en ch07-git-tools.asc.
También lo usamos en un modo de secuencias de comandos interactiva con la opción -i en ch07-git-tools.asc.
El comando git revert es esencialmente un git cherry-pick inverso. Crea un nuevo commit que se aplica exactamente al contrario del cambio introducido en el commit que estás apuntando, esencialmente deshaciendo o revertiéndolo.
Utilizamos éste en ch07-git-tools.asc para deshacer un commit de fusión.
Muchos proyectos Git, incluido el propio Git, se mantienen totalmente a través de listas de correo. Git tiene una serie de herramientas integradas en él que ayudan a hacer más fácil este proceso, desde la generación de parches que pueden enviarse fácilmente por email a aplicar esos parches desde una casilla de correo electrónico.
El comando git apply aplica un parche creado con git diff o incluso el comando diff de GNU. Es similar a lo que el comando patch podría hacer con algunas pequeñas diferencias.
Mostramos a usarlo y las circunstancias en las que puedes hacerlo en ch05-distributed-git.asc.
El comando git am se utiliza para aplicar parches desde una bandeja de entrada de correo electrónico, en concreto una que tenga formato mbox. Esto es útil para recibir parches por correo electrónico y aplicarlos a tu proyecto fácilmente.
Cubrimos el uso y flujo de trabajo en torno a git am en ch05-distributed-git.asc incluyendo el uso de las opciones --resolved, -i y -3.
Hay también una serie de ganchos (hooks) que se pueden utilizar para ayudar con el flujo de trabajo en torno a git am y todos ellos se cubren en ch08-customizing-git.asc.
También lo utilizamos para aplicar parcheado con formato de cambios de GitHub Pull Request en ch06-github.asc.
El comando git format-patch se utiliza para generar una serie de parches en formato mbox que puedes utilizar para enviar a una lista de correo con el formato correcto.
Examinamos un ejemplo de contribución a un proyecto mediante el uso de la herramienta git format-patch en ch05-distributed-git.asc.
El comando git send-email se utiliza para enviar parches que son generados con git format-patch por correo electrónico.
Examinamos un ejemplo de contribución a un proyecto mediante el envío de parches con la herramienta git send-email en ch05-distributed-git.asc.
El comando git request-pull se utiliza simplemente para generar un cuerpo de mensaje de ejemplo para enviar por correo electrónico a alguien. Si tienes una rama en un servidor público y quieres que alguien sepa cómo integrar esos cambios sin enviar los parches a través de correo electrónico, puedes ejecutar este comando y enviar el resultado a la persona que deseas que reviva (pull) los cambios.
Mostramos como usar git request-pull para generar un mensaje pull en ch05-distributed-git.asc.
Git viene con unos pocos comandos para integrarse con otros sistemas de control de versiones.
El comando git svn se utiliza para comunicarnos como cliente con el sistema de control de versiones Subversion.
Esto significa que puedes usar Git para obtener desde y enviar a un servidor Subversion.
Este comando es cubierto en profundidad en ch09-git-and-other-scms.asc.
Para otros sistemas de control de versiones o importación desde prácticamente cualquier formato, puedes usar git fast-import para convertir rápidamente el otro formato a algo que Git pueda registrar fácilmente.
Este comando es cubierto en profundidad en ch09-git-and-other-scms.asc.
Si estás administrando un repositorio Git o necesitas arreglar algo a lo grande, Git ofrece una serie de comandos de administración para asistirte.
El comando git gc ejecuta la ''recogida de basura'' en tu repositorio, eliminando los archivos innecesarios en tu base de datos y empaquetando los archivos restantes en un formato más eficiente.
Este comando se ejecuta normalmente en segundo plano, aunque se puede ejecutar manualmente si se desea. Repasamos algunos ejemplos de esto en ch10-git-internals.asc.
El comando git fsck se utiliza para comprobar la base de datos interna en busca de problemas o inconsistencias.
Sólo lo utilizamos una vez de forma rápida en ch10-git-internals.asc para buscar objetos colgantes.
El comando git reflog examina un registro de donde han estado todas las cabezas de tus ramas mientras trabajas para encontrar commits que puedes haber perdido a través de la reescritura de historias.
Cubrimos este comando principalmente en ch07-git-tools.asc, donde mostramos el uso normal y cómo usar git log -g para ver la misma información con salida de git log.
También repasamos un ejemplo práctico de la recuperación de tal rama perdida en ch10-git-internals.asc.
El comando git filter-branch se utiliza para reescribir un montón de commits de acuerdo a ciertos patrones, como la eliminación de un archivo de todas partes o el filtrado de todo el repositorio a un solo subdirectorio para sacar un proyecto.
En ch07-git-tools.asc explicamos el comando y exploramos varias opciones diferentes, tales como --commit-filter, --subdirectory-filter y --tree-filter.
En ch09-git-and-other-scms.asc y ch09-git-and-other-scms.asc lo usamos para arreglar repositorios externos importados.
También había un buen número de comandos de fontanería de bajo nivel que nos encontramos en el libro.
El primero que encontramos es ls-remote en ch06-github.asc, que usamos para mirar las referencias en bruto en el servidor.
Usamos ls-files en ch07-git-tools.asc, ch07-git-tools.asc y ch07-git-tools.asc para echar un vistazo más en bruto a la apariencia del área de preparación.
También mencionamos rev-parse en ch07-git-tools.asc para tomar casi cualquier cadena y convertirla en un objeto SHA1.
Sin embargo, la mayoría de los comandos de bajo nivel de fontanería que cubrimos están en ch10-git-internals.asc, que es más o menos en lo que el capítulo se centra. Tratamos de evitar el uso de ellos en la mayor parte del resto del libro.