Llegamos a ustedes gracias a:



Reportajes y análisis

20 consejos para dominar Git y GitHub

[20/07/2017] Aunque existen docenas de guías de inicio para Git, y GitHub ofrece una serie de guías propias, todavía no es fácil encontrar una colección de consejos útiles para desarrolladores que quieran trabajar más inteligentemente con Git y GitHub. Vamos a arreglar eso. 

Para aquellos de ustedes que no están familiarizados con Git o GitHub, los próximos párrafos le darán suficientes antecedentes para entender los consejos. Daremos una lista de una docena de recursos útiles al final de este artículo. 

Git es un sistema de control de versiones distribuido, escrito originalmente por Linus Torvalds en el 2005 para- y con ayuda de- la comunidad del kernel de Linux. No estoy aquí para vender Git, así que voy a ahorrar la broma sobre lo rápido, pequeño, flexible y popular que es, pero debe saber que cuando clona un repositorio de Git ("repo", para abreviar), obtendrá toda la historia de la versión en su propia computadora, no solo una instantánea de una rama al mismo tiempo. 

Git comenzó como una herramienta de línea de comandos, acorde con su origen en la comunidad del kernel de Linux. Todavía se puede usar la línea de comandos de Git, si desea, pero no tiene que hacerlo. En particular, si utiliza GitHub como su host, puede utilizar el cliente GitHub gratuito en Windows o Mac. Por otro lado, la línea de comandos Git funcionará para cualquier host, y viene preinstalado en la mayoría de los sistemas Mac y Linux. 

Solo usted puede decidir si está más cómodo usando la línea de comandos o un cliente nativo con una interfaz gráfica de usuario. Si le gusta una interfaz gráfica de usuario, además del cliente GitHub (Windows y Mac), es posible que desee considerar SourceTree (Windows y Mac, gratis), TortoiseGit (solo para Windows, gratis), y Gitbox (solo Mac, 14,99 dólares). O puede utilizar un editor o IDE que admita Git internamente (consulte la sugerencia 11). 

Tip Git / GitHub N° 1: Clone casi cualquier cosa

Hay muchos proyectos interesantes disponibles de GitHub y otros repositorios públicos de Git que puede clonar libremente a su propia computadora. ¿Por qué querría hacer eso? Una de las razones es aprender algo sobre el estilo de codificación, la práctica y las herramientas en un lenguaje de interés, incluyendo el estilo de comentario de commit log (ver el consejo 4). Una segunda razón es aprender cómo un determinado proyecto cumple sus metas. Una tercera razón, si la licencia le permite hacerlo y tiene sentido para sus propósitos, sería incorporar el proyecto en su propio emprendimiento o producto. Haga doble verificación de la licencia, por cierto, para que no se presenten problemas de cumplimiento más adelante. 

La definición de git clone de la página del manual:

Clona un repositorio en un directorio creado recientemente, crea ramas de seguimiento remoto para cada rama en el repositorio clonado (visible mediante git branch -r), y crea y extrae una rama inicial que se bifurca de la rama actualmente activa del repositorio clonado. 

Después del clon, un simple git fetch sin argumentos actualizará todas las ramas de seguimiento remoto, y un git pull sin argumentos, además, unirá la rama maestra remota a la rama maestra actual, si la hubiere.

Tip Git / GitHub No. 2: Jale con frecuencia

Una de las maneras más fáciles de complicarse usted mismo con Git (y, de hecho, con cualquier sistema de control de versiones), es permitir que los archivos salgan de la sincronización. Si hace git pull con frecuencia, mantendrá su copia del repo actualizada, y tendrá la oportunidad de combinar el código modificado con los cambios de otros, mientras que la fusión es fácil de entender y llevar a cabo; idealmente, cuando es tan fácil que se puede hacer automáticamente. Un corolario de este consejo es observar el estado de su proyecto. Muchos clientes de Git le mostrarán automáticamente cuando necesita actualizar para mantenerse al día. 

Tip Git / GitHub No. 3: Comience temprano ya menudo

Un commit es una actualización granular de un proyecto, que incluye uno o más cambios en uno o más archivos. Piense en ello como un registro de una unidad de trabajo completado, que puede ser aplicado o eliminado del proyecto como un todo lógico. Haga un commit a cada cambio lógico que complete, incluso antes de probarlo. Los commits solo se aplican a su repositorio local. Vea los consejos No. 4 y 5 para los corolarios de este tip. 

La definición de git commit de la página del manual:

 Almacena el contenido actual del índice en un nuevo commit junto con un mensaje de registro del usuario que describe los cambios.

Tip Git / GitHub No. 4: Comente sus commits como haría que otros comenten los suyos

Hay 10 tipos de codificadores: Los que comentan sus commits, y los que no lo hacen. (Vieja broma. Sugerencia: ¿Qué base estoy usando?). 

Admito abiertamente ser un stickler para los buenos mensajes del registro de commit. He configurado mis repositorios para requerir mensajes para cada commit, y se me ha comunicado que molesto con mensajes nocturnos cuando los commits llegan con logs en el orden de "xx". Si es el tipo de desarrollador que piensa (1) el código debe hablar por sí mismo y (2) los comentarios en línea son mucho más importantes que los registros de cambios, trate de clonar un repositorio que nunca haya visto antes e identifique los recientes commits que puedan haber causado el último post publicado sin leer todo el código. Como puede ver, los registros exactos de commits son dobles y positivos. 

Tip Git / GitHub No. 5: Presione cuando los cambios son probados

El peor error relacionado con Git, del que he tenido la desgracia de saber, sucedió cuando una empresa de subcontratación cambió de Subversion, pero no entrenó a sus desarrolladores en la diferencia entre el control de fuente distribuida y el control centralizado de la fuente. Alrededor de un mes más tarde, el proyecto desarrolló extraños errores que nadie podía rastrear. En las reuniones diarias, los desarrolladores responsables del área de la aplicación que estaba funcionando mal podían protestar: "arreglé eso hace dos semanas!". O acusaban a otro desarrollador de no molestarse en incorporar los cambios que habían inspeccionado cuidadosamente. 

Eventualmente, alguien identificó el problema y enseñó a todos los desarrolladores cómo y cuándo empujar sus commits: En resumen, siempre la prueba de commits era exitosa en una compilación local. Entonces la compañía hizo un festival de fusión de dos días de largo antes de poder construir y desplegar el producto actualizado, integrado. 

Tip Git / GitHub No. 6: Ramas libres

Una de las mayores ventajas que Git tiene sobre otros sistemas de control de versiones es que la fusión suele funcionar bien, al menos en parte porque Git elige automáticamente el mejor ancestro común para usar en una fusión. La mayoría de los desarrolladores de software necesitan comenzar a crear ramas en sus proyectos con más frecuencia. Debe ser una ocurrencia diaria de rutina, no el tema de una angustiada reunión de estrategia. La probabilidad es que, cuando el proyecto de la rama esté completo, aceptado y listo para entrar en el proyecto principal, la fusión no presentará problemas insuperables. 

Sé que se necesita algún ajuste, especialmente si ha estado atrapado en una empresa que hace el control de código fuente con CVS. Pero inténtelo. Es mucho mejor que tener clientes que accidentalmente vean su código experimental inacabado cuando el proyecto troncal tenga que ser publicado debido a un error súbito. (Este artículo explica la ramificación básica y también la fusión). 

Tip Git / GitHub No. 7: Combinar cuidadosamente

Aunque las combinaciones con Git trabajan generalmente bien, si las hace sin pensar, puede ocasionalmente encontrar dificultad. El primer paso es asegurarse de que no tiene cambios no confirmados. De la página del manual git merge:

Antes de aplicar los cambios externos, debe tener su propio trabajo en buena forma y comprometido localmente, por lo que no se atascará si hay conflictos. Vea también git-stash. 

Véase también el tip 8. 

Incluso si todo va hacia el sur durante una combinación de git, no está atado:

Si se trató de una fusión que dio lugar a conflictos complejos y quiere empezar de nuevo, puede recuperar con git merge -abort. 

El comando de seguimiento a git merge es generalmente git mergetool, suponiendo que le guste usar una interfaz gráfica de usuario para la fusión. Si prefiere el método de la vieja escuela, puede editar los archivos en conflicto con su editor de programación favorita, eliminar por completo las líneas <<<<<<<, =======, y >>>>>> >, guardar los archivos revisados, y hacer git add con cada archivo que fijó.

Tip Git / GitHub No. 8: Escóndase antes de cambiar ramificaciones

El flujo de trabajo de un desarrollador de software rara vez es lineal. Los usuarios tienen las agallas para reportar errores, los gerentes tienen la audacia de dar prioridad a los tickets que no son el que eligió para trabajar, y usted mismo podría cambiar de opinión acerca de lo que quiere hacer. 

Ahí está usted, con tres archivos comprometidos para un lanzamiento, y un cuarto archivo en un estado cambiado pero que no funciona. (El comando git status le dirá todo esto si no llega a recordar dónde estaba). De repente necesita trabajar en una corrección de errores en una versión de producción. Necesita cambiar ramificaciones pronto, pero no puede. Su directorio de trabajo está sucio y tiene dos horas de trabajo que no desea perder. 

Introduzca git stash. Voilà! Ahora tiene todos sus cambios almacenados en una ramificación WIP (work in progress), y puede cambiar a la rama de producción de su directorio limpio. Cuando haya terminado con eso, vuelva a donde estaba con git stash apply. 

Tip Git / GitHub tip No. 9: Utilice las herramientas para compartir fragmentos

Los "gists de GitHub -fragmentos de código compartidos- no son una característica de Git, pero utilizan Git. Todos los conceptos son gists son repositorios de Git, y GitHub Gist hace que sea fácil de compartir. Puede buscar Gist para encontrar gists públicos por tema, lenguaje de programación, estado bifurcado y estado destacado. También puede crear claves secretas y compartirlas por URL. 

Tip Git / GitHub No. 10: Explore GitHub

Muchos interesantes proyectos de código abierto tienen repositorios en GitHub. GitHub Explore proporciona una interfaz de navegación para encontrar algunos de ellos, pero sobre todo es más fácil de teclear las primeras letras del nombre del proyecto en el cuadro de búsqueda para encontrar sus repositorios. Por ejemplo, el tipo jq o la back o ang encontrar tres de los principales marcos de JavaScript de código abierto. 

Tip Git / GitHub No. 11: Contribuya a proyectos de código abierto

Mientras navega por proyectos de código abierto, ¿por qué no contribuye a ellos? No es tan difícil como podría pensar, y aprenderá mucho. Por ejemplo, puede clonar el proyecto jquery / jquery (jQuery Core) y explorar a través de README.MD. Cerca de la parte superior verá: 

En el espíritu de desarrollo de software de código abierto, jQuery siempre fomenta la contribución de código comunitario. Para ayudarle a empezar y antes de saltar en escribir código, asegúrese de leer a fondo estas importantes directrices de contribución...

Eso es seguido por tres enlaces. El primero de los tres le ayudará a empezar con bastante rapidez. No todos los proyectos de código abierto exponen el plan tan claramente, pero todos lo intentan. 

Entienda la diferencia entre ser un contribuyente y un commiter. Un contribuyente ha firmado los acuerdos requeridos y ha hecho una contribución disponible para el proyecto. Un commiter está facultado para comprometer realmente la contribución proferida al repositorio del proyecto. Debido a que habrá un retraso mientras un commiter prueba su contribución y no querrá atar su rama maestra, debe realizar sus cambios en otra rama (ver sugerencia No. 6) antes de enviar una solicitud de extracción (vea el tipo No 16). 

Tip Git / GitHub No. 12: Utilice editores e IDEs

Si está avanzando en una edición solo para descubrir, cuando va a chequearla, que alguien más ha estado trabajando en el mismo código que tiene, es probable que se sienta frustrado. Puede evitar -o al menos minimizar- esa frustración mediante el uso de un editor o IDE que integre Git y realmente le dice que el código que está viendo tiene nuevos commits que debe incorporar, y lo que los nuevos commits se supone que cumplirán. 

Tipo Git / GitHub No. 13: Bifurque de un repo

Bifurcar un repositorio significa crear su propia copia del servidor de escritura de un repo; es decir, crear una bifurcación en el camino. Recordemos que clonamos un repo (ver el tip 1) para hacer nuestra propia copia del cliente de la misma. Si se trata de un repo público para el que no tenemos privilegios de commit (ver sugerencia 11), entonces la forma más fácil de contribuir con nuestros cambios es enviarlos primero a nuestra propia bifurcación del repo en el servidor mediante el botón de la bifurcación en el Proyecto original de GitHub. A continuación, podemos emitir una solicitud de incorporación (ver sugerencia 16) a los propietarios del reporte de bifurcación para que puedan probar, y posiblemente utilizar, nuestra contribución. Es confuso al principio, pero se vuelve más fácil. Véase, por ejemplo, esta sección de libros sobre contribuir a un pequeño proyecto público. 

Tip Git / GitHub No. 14: Observe proyectos

Cuando bifurca un proyecto, lo más probable es que desee saber lo que está sucediendo en el proyecto principal. Si es así, vea el repo. Si la charla de actualización le molesta, no la vea. Si observa cambios que le afectan, busque y fusione los commits ascendentes. 

Tip Git / GitHub No. 15: Siga a sus amigos

GitHub sugiere que siga a los empleados de GitHub "de una manera no-espeluznante. También debe seguir a la gente de los proyectos que le interesan, y que lo podrían conducir a otros proyectos que le interesan. Seguí a dmethvin en GitHub, pero eso no es espeluznante, ya que hemos trabajado juntos desde que estaba en PC Tech Journal y ahora es presidente de la Fundación jQuery.

Tip Git / GitHub No. 16: Enviar solicitudes para extracción

En el tip No. 13 hablamos de bifurcar un repositorio de GitHub. La forma de obtener el repositorio principal (del que usted bifurcó el suyo) para incorporar algunos o todos sus cambios es enviarles una solicitud de extracción, siguiendo esta guía.

Tip Git / GitHub tip No. 17: Crear y resolver problemas

Todo el software tiene errores. Muchos proyectos de software utilizan un sistema de seguimiento de errores independiente, pero algunos utilizan la función Temas en GitHub. Puede ser útil para un proyecto al informar de un problema, y aún más útil al resolver uno.

Tip Git / GitHub No. 18: Escriba las páginas informativas README

En la sugerencia 11, lo envié a la página README de jquery para averiguar sobre el proyecto. Escriba buenas páginas README para sus proyectos, y no se arrepentirá. El README ha sido una convención establecida en el desarrollo de software desde al menos la década de 1960, cuando vi mi primer README impreso todo en mayúsculas en el papel verde y blanco que estaba envolviendo una pila de tarjetas Hollerith destinado a ser ejecutado en una IBM 1640. Vi muchos más en la década de 1970, en todos los medios y sistemas operativos concebibles, cuando trabajaba en minicomputadoras DEC y grandes mainframes IBM. Vea también el REAMDE.

Tip Git / GitHub No. 19: Utilice Markdown

Los primeros archivos README, todos en MAYÚSCULAS, eran más que un poco básicos. El estándar actual para el formato de archivos README es Markdown, específicamente GitHub Flavored Markdown. Solía ver archivos README en HTML, pero la práctica parece estar desapareciendo.

Tip Git / GitHub No. 20: Convierta sus repos más antiguos a Git

De todos los consejos que he enumerado, éste podría ser el más difícil de implementar, tanto técnica como políticamente. Políticamente es difícil porque los programadores son por naturaleza conservadores sobre sus herramientas. Es necesario abordar esta cuestión con la capacitación (ver sugerencia No. 5).

Es técnicamente difícil convertir grandes y viejos repositorios con millones de líneas de código, decenas de miles de commits y miles de etiquetas, porque los procesos para esto usan una tonelada métrica de memoria. He tenido repositorios CVS de una década de antigüedad que solo se convertirían en instancias grandes o extragrandes de Amazon EC2, y aun así tomó días completar la conversión. Si está convirtiendo desde Subversion, intente usar svn2git. Si está convirtiendo desde CVS, considere git -cvsimport y cvs2git.