No sé en qué lenguaje de programación está escribiendo, pero estoy seguro de que usa Geet durante el desarrollo. Cada vez hay más herramientas para apoyar el desarrollo, pero incluso en el proyecto de prueba más pequeño, siempre comienzo con el comando git init . Y durante el día laboral escribo un promedio de otros 80 equipos, refiriéndome a este sistema de control de versiones.
Pasé muchos nervios cuando comencé a volver a aprender sobre el método de impresión de diez dedos. Al final, esta fue la mejor decisión para mejorar su flujo de trabajo personal. Entre las siguientes optimizaciones más importantes se encuentra el desarrollo avanzado de Geeta.
Se han escrito muchos artículos sobre Gita en Habr, pero no van más allá de la documentación oficial, y los autores proponen simplificar el trabajo con muletas hechas a sí mismas. Estoy seguro de que es necesario estudiar el Geet en ejemplos concretos de tareas y aumentar la eficiencia de trabajar con él utilizando medios estandarizados.
¿Quién se beneficiará de este artículo?
¿Ya dominaste el conjunto de caballeros de Gita y estás listo para seguir adelante? Hay 2 formas:
- Domina los comandos abreviados: alias. Casi siempre son mnemotécnicos y fáciles de recordar. Olvidar los comandos originales es problemático, los escribo fácilmente cuando es necesario. Además, no estoy confundido al verificar algo en el Gita mientras escribo el código.
- Conozca las banderas adicionales para los equipos, así como su integración entre ellos. Entiendo que alguien odia cortar. Para usted, también, hay material interesante en el artículo: cómo aumentar la utilidad y la conveniencia de la salida de comandos, así como cómo resolver no los problemas más triviales, pero a menudo encontrados en la práctica .
Dedique hoy un par de horas a los experimentos descritos en el artículo y ahorre mediante cálculos aproximados seis meses de vida laboral.
¡Bienvenido a cat!
Preparación
Entre los desarrolladores, el estándar para la alternativa Bash es Zsh , un shell de software avanzado que admite ajustes. Y entre los usuarios de Zsh , el estándar es usar Oh My Zsh , un conjunto de configuraciones predefinidas para Zsh . Por lo tanto, después de instalar este kit, sacaremos de la caja un conjunto de hacks que la comunidad ha estado recopilando y desarrollando para nosotros a lo largo de los años.
Es muy importante tener en cuenta que Zsh es para Linux , y para Mac , e incluso para Windows .
Instale Zsh y Oh My Zsh
Instale Zsh y Oh My Zsh acuerdo con las instrucciones con un comando:
Dado que la tarea es optimizar la interacción con Geet , agregaremos un par de complementos a Zsh . Abra el ~/.zshrc y agregue plugins a la lista:
plugins=(git gitfast)
Total:
git : un conjunto de alias y funciones auxiliares;gitfast : autocompletado mejorado para Gita.
Ajuste tig
Y el toque final es la instalación de la utilidad de consola tig :
Hablaremos más al respecto.
Git en la práctica
Tratar con Geeta se hace mejor resolviendo problemas específicos. A continuación, consideramos las tareas de la práctica diaria y las opciones para su solución conveniente. Para hacer esto, considere cierto repositorio con archivos de texto.
Los bloques amarillos indican el alias principal para resolver el problema de la sección. Aprende solo y deja todo lo demás para el desarrollo general.
Verifique el estado del directorio de trabajo
Comencemos con lo más básico. Trabajamos un poco y ahora veamos qué sucede en el directorio de trabajo:
$ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: e.md Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: b.md Untracked files: (use "git add <file>..." to include in what will be committed) d.md
El estado actual de todos los archivos se describe con gran detalle, se dan instrucciones adicionales para la acción. Al principio es muy útil cuando se usa Geeta, pero hay muchas cosas superfluas para el trabajo diario. Bajemos el nivel de ruido con teclas adicionales:
$ git status -sb
Sí, estamos en la rama master , cambiamos el b.md ( M-odified ) y creamos dos archivos, agregando el primero al índice Geeta ( A-dded ) y el segundo dejando el índice fuera ( ?? ). Corto y claro.
Queda por optimizar la entrada sin fin de este comando mediante el alias " g it s tatus with b ranch" :
Mostrar el estado del directorio de trabajo acortado
$ gsb
Crear un compromiso
Continuamos
Por supuesto, puedes hacer commits. Pero intentemos optimizar la solución de esta simple tarea. Agregue todos los cambios al índice con el alias " g it a dd a ll" :
$ gaa
Verificamos que el índice obtuvo exactamente lo que necesitamos usando el alias " g it d iff ca ched" :
$ gdca # git diff --cached diff --git a/b.md b/b.md index 698d533..cf20072 100644 --- a/b.md +++ b/b.md @@ -1,3 +1,3 @@ # Beta -Next step. +Next step really hard. diff --git a/d.md b/d.md new file mode 100644 index 0000000..9e3752e --- /dev/null +++ b/d.md @@ -0,0 +1,3 @@ +# Delta + +Body of article.
Hmm, los cambios que resuelven una sola tarea deben caer en una confirmación. Aquí, los cambios de ambos archivos no están conectados de ninguna manera. d.md archivo d.md del índice con el alias " g it r eset u ndo" :
$ gru d.md # git reset
Y cree un commit con el alias " g it c ommit" :
$ gc
Escribimos el nombre del commit y lo guardamos. Y luego creamos otra confirmación para el archivo d.md comando más familiar usando el alias " g it c ommit m e s sa g e" :
$ gaa
Y podemos ...
... confirmar archivos modificados del índice con un comando:
$ gcam "Add changes"
... vea los cambios por palabras en lugar de líneas (muy útil cuando se trabaja con texto):
$ gdw
... agregue archivos en partes (muy útil cuando necesita agregar a la confirmación solo una parte de los cambios del archivo):
$ gapa
... agregue al índice solo archivos que ya están bajo la supervisión de Geeta:
$ gau
Total:
Agregar al índice / Crear confirmación
$ ga
Fix commit
El nombre de la última confirmación no explica los cambios que realizamos. Reformulemos:
$ gc!
Y en el editor de texto que se abre, lo llamaremos más claramente: "Add Delta article" . Estoy seguro de que nunca usa el modificador -v , aunque al editar la descripción de la confirmación, muestra todos los cambios realizados, lo que ayuda a navegar mejor.
Y podemos ...
... realice cambios de archivo en la confirmación, pero no toque la descripción:
$ gcn!
... realice todos los cambios de archivo inmediatamente en la confirmación, sin agregar primero al índice:
$ gca!
... combina los dos comandos anteriores:
$ gcan!
Bueno, es importante tener en cuenta una vez más que en lugar de escribir el git commit -v --amend completo que se usa regularmente, solo escribimos tres caracteres:
Cambiar último compromiso
$ gc!
Comenzando con una nueva característica
Cree una nueva rama desde el alias actual " g it c heckout b ranch" :
$ gcb erlang
Aunque no, es mejor escribir un artículo sobre un lenguaje más moderno de Elixir alias " g it b ranch with the key m ove" (el cambio de nombre en el Gita se realiza a través del move ):
$ gb -m elixir
Sería lógico usar el alias gbmv , pero, desafortunadamente, aún no se ha inventado. Una buena opción para contribuir.
Realizamos cambios en el repositorio y creamos una confirmación, como ya sabemos:
$ echo "# — ." > e.md $ gaa && gcmsg "Add article about Elixir"
Y recuerda:
Crea una nueva sucursal
$ gcb
Fusionar cambios
Ahora agregamos nuestro nuevo artículo sobre Elixir para master . Primero, cambie a la rama principal con el alias " g it c heckout m aster" :
$ gcm
No realmente. Uno de los comandos más utilizados en tres caracteres fáciles de recordar. Ahora el mergim del cambio de alias es " g it m erge" :
$ gm elixir
Vaya, pero alguien ya logró hacer cambios para master . Y en lugar de la hermosa historia lineal que se adoptó en nuestro proyecto, creé odiaba fusionar commit.
Fusionar ramas
$ gm
Eliminar la última confirmación
¡Nada de qué preocuparse! Solo necesita eliminar la última confirmación e intentar fusionar los cambios nuevamente " g it r eset hh ard" :
Eliminar último compromiso
$ grhh HEAD~
Resolvemos conflictos
La secuencia de checkout – rebase – merge estándar checkout – rebase – merge para preparar un historial de cambios lineales se realiza mediante la siguiente secuencia de alias:
gco elixir
Todos ellos se usan con tanta frecuencia que ya están volando lejos de los dedos, y al realizar tales operaciones, no hay necesidad de pensar qué conjunto de letras escribir. Y no olvide que en Zsh puede complementar los nombres de las ramas con la tecla Tab .
Hacer un rebase
$ grb
Enviar cambios al servidor
Primero agregamos origin alias " g it r emote a dd" :
$ gra origin git@github.com/...
Y luego enviamos los cambios directamente a la rama actual del repositorio ( "gg" - doblar g al comienzo del comando indica la ejecución de la acción en la rama actual):
$ ggpush
También puedes ...
... envíe los cambios al servidor con la instalación upstream del alias " g it p ush s et up stream" :
$ gpsup
Enviar cambios al servidor
$ gp
Recibimos cambios del servidor
El trabajo está en pleno apogeo. Logramos agregar un nuevo artículo f.md a master , y nuestros colegas cambiaron el artículo a.md y enviaron este cambio al servidor. Esta situación también se resuelve de manera muy simple:
$ gup
Entonces puede enviar cambios de forma segura al servidor. El conflicto está resuelto.
Obtenga cambios del servidor
$ gl
Eliminar ramas fusionadas
Entonces, fusionamos con éxito varias ramas en master , incluida la rama elixir del ejemplo anterior. Ya no los necesitamos. Puede eliminar el alias " g it b ranch d elete a nother" :
$ gbda
Equipo muy bonito y astuto. Por lo general, me olvido de eliminar las ramas que han perdido relevancia y este elegante equipo es una verdadera salvación. Si no desea utilizar un alias, simplemente copie la versión completa del comando en sus notas y ejecútelo según sea necesario.
Crear una confirmación temporal
El trabajo en un nuevo artículo de h.md sobre Haskell está en pleno apogeo. Mitad escrito y necesita recibir comentarios de un colega. Sin pensarlo dos veces , escribimos el alias " g it w ork i n p rogress" :
$ gwip
Y luego se crea un commit con el nombre Work in Progress , omitiendo CI y eliminando los archivos "extra". Enviamos la sucursal al servidor, hablamos sobre este colega y esperamos la revisión.
Luego, esta confirmación se puede deshacer y los archivos vuelven a su estado original:
$ gunwip
Y para verificar si hay confirmaciones WIP en su rama, use el comando:
$ work_in_progress
El comando gwip es un análogo bastante confiable de stash cuando necesita cambiar a una rama vecina. Pero en Zsh hay muchos alias para el stash sí.
Agregar confirmación temporal / Restablecer confirmación temporal
$ gwip $ gunwip
Ocultar cambios
Debes tener cuidado con este comando. Los archivos pueden ocultarse y luego eliminarse por completo con una acción descuidada, ya que hay un reflog en el que puede intentar encontrar el trabajo perdido.
Ocultemos los archivos en los que estamos trabajando con el alias g it st ash a ll :
$ gsta
Y luego devolverlos con el alias " g it st ash p op" :
$ gstp
O el método más seguro " g st st ash a ll a pply" :
$ gstaa
También puedes ...
... mira qué ocultamos exactamente:
gsts
... use abreviaturas para comandos relacionados:
gstc
Ocultar cambios / Obtener cambios
$ gsta $ gstaa
Buscando un error
La herramienta git-bisect , que repetidamente me ha salvado la vida, también tiene sus propios alias. Comenzamos comenzando el procedimiento de "búsqueda de errores binarios" con el alias " g it b i s ect s tart" :
$ gbss
Notamos que la confirmación actual, la última en la rama, contiene un error con el alias " g it b i s ect b ad" :
$ gbsb
Ahora marcamos el compromiso que nos garantiza el estado operativo de la aplicación " g it b i s ect g ood" :
$ gbsg HEAD~20
Y ahora queda por responder las preguntas de Gita con las frases gbsb o gbsg , y después de encontrar al culpable, reinicie el procedimiento:
$ gbsr
Y realmente escribo estas abreviaturas cuando uso esta herramienta.
Error al confirmar búsqueda
$ gbss
Estamos buscando el instigador de la anarquía
Incluso con un alto porcentaje de cobertura de código con pruebas, nadie es inmune a una situación en la que la aplicación se bloquea y amablemente señala una línea específica con un error. O, por ejemplo, en nuestro caso, queremos averiguar quién cometió un error en la segunda línea del archivo a.md Para hacer esto, ejecute el comando:
$ gbl a.md -L 2
Verán, los colaboradores de Oh My Zsh hicieron un alias no solo para el equipo de git blame , sino que agregaron claves que hacen que sea fácil encontrar al instigador directamente.
Bono
Ver una lista de confirmaciones
Para ver la lista de confirmaciones, use el comando git log con claves de formato de salida adicionales. Por lo general, este comando, junto con las teclas, se ingresa en los alias personalizados de Gita. Somos más afortunados, ya tenemos un alias listo para glog : glog . Y si instaló la utilidad tig siguiendo los consejos del principio del artículo, entonces es un campeón absoluto.
Ahora, para aprender el historial de confirmaciones en la consola de una manera muy conveniente, debe escribir la palabra git viceversa:
$ tig
La utilidad también proporciona un par de adiciones útiles que no están en el Gita fuera de la caja.
Primero, un comando para buscar a través de los contenidos de una historia:
$ tig grep
En segundo lugar, ver una lista de todas las fuentes, ramas, etiquetas junto con su historial:
$ tig refs
En tercer lugar, tal vez encuentres algo interesante para ti:
$ tig --help
Accidentalmente hecho git reset --hard
Trabajaste en la rama de elixir todo el día:
$ glog * 17cb385 (HEAD -> elixir) Refine Elixir article * c14b4dc Add article about Elixir * db84d54 (master) Initial commit
Y al final, borraron accidentalmente todo:
$ grhh HEAD~2 HEAD is now at db84d54 Initial commit
No hay necesidad de entrar en pánico. La regla más importante es dejar de ejecutar cualquier comando en el Gita y exhalar . Todas las acciones con el repositorio local se registran en un registro especial - reflog . A partir de él, puede obtener el hash de la confirmación deseada y restaurarlo en el árbol de trabajo.
Veamos el reflog, pero no de la forma habitual a través de git reflog , pero más interesante con una transcripción detallada:
$ glg -g
Encuentre el hash del commit 17cb385 deseado y 17cb385 :
Por casualidad, en lugar de crear una nueva confirmación, hice cambios a la anterior
Aquí volvemos al rescate de ayuda para volver a registrar. Encontramos el hash del commit 17cb385 original, si cancelamos el commit de inmediato, entonces en lugar de buscar el hash, podemos usar el enlace rápido HEAD@{1} . A continuación, hacemos un restablecimiento parcial, mientras que el índice no se restablece:
La rama es muy vieja
A veces comienzas a trabajar en una función, pero su lanzamiento se retrasa indefinidamente. Te comprometes y cambias a otras tareas. Junto con el equipo, realiza una serie de cambios en el maestro y, después de un tiempo, regresa a la sucursal con funciones. Intentas rebasear, pero él ofrece analizar los conflictos en una docena de commits. Puedes intentar resolverlos todos o hacerlo más fácil.
Veamos un ejemplo de una rama característica llamada elixir :
Entonces, en lugar de tratar de actualizar la rama, tomamos y transferimos una única confirmación sin ningún problema.
Eliminar datos importantes del repositorio
Para eliminar datos importantes del repositorio, he guardado el siguiente fragmento:
$ git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch <path-to-your-file>' --prune-empty --tag-name-filter cat -- --all && git push origin --force --all
Ejecutar este comando romperá tu stash . Antes de su ejecución, se recomienda obtener todos los cambios ocultos. Lea más sobre esta técnica aquí .
Refiriéndose a la rama anterior
Al ejecutar algunos comandos que esperan que se ingrese un nombre de rama, podemos pasar un guión como referencia a la rama con la que vinimos. Es especialmente bueno usar este truco de pago:
$ gco -
Eliminar todos los archivos marcados en .gitignore
Otro revés común es demasiado tarde para agregar cualquier archivo o directorio no deseado a .gitignore . Para limpiarlos del repositorio ( y eliminarlos del disco ), ya hay claves preparadas para el comando git clean :
$ gclean -X
Ten cuidado
Siga leyendo para conocer la forma correcta.
¿Por qué muchos equipos necesitan el interruptor --dry-run ?
El --dry-run necesario solo como precaución al desinstalar y actualizar. Por ejemplo, la sección anterior describió cómo eliminar todo lo que se especifica en el archivo .gitignore . Es mejor tener cuidado y usar el --dry-run , --dry-run lista de todos los archivos que se eliminarán, y solo luego ejecutar el comando sin --dry-run .
Conclusión
El artículo muestra un punto para optimizar el trabajo del programador. Recuerde 10-20 abreviaturas mnemotécnicas no es difícil, olvide que el equipo original es casi imposible. Los alias están estandarizados, por lo que cuando cambia todo el equipo a Zsh + Oh My Zsh , puede trabajar a la misma velocidad y comodidad, incluso con la programación de pares.
¿A dónde ir después?
Ofrezco las siguientes opciones:
- Finalmente, descubra cómo se organiza el Geet por dentro . Ayuda a entender lo que está haciendo y por qué lo que quiere hacer no funciona.
- No seas perezoso para mirar una vez más la documentación de los comandos:
git --help o ghh . - Vea la lista completa de alias en el enlace . Intentar recordarlos a todos es una locura, pero usar la lista como una colección de comandos y teclas interesantes para ellos es una buena idea.
Algunos alias se hacen de manera no trivial, pero demuestran ser muy útiles en la práctica. Muchos de los alias presentados no son solo abreviaturas, sino pequeñas funciones que optimizan aún más el trabajo. Usar Git se ha vuelto más agradable, la calidad de los commits ha mejorado.
Espero que el material haya resultado útil y que puedas aprender algo nuevo por ti mismo. O tal vez ya han comenzado a introducir activamente un nuevo enfoque. Buena suerte