El SSH (Shell Seguro) es un protocolo cliente-servidor para conectarse y autenticarse a un servidor remoto.

La autenticación significa que el servidor remoto puede verificar que eres tú mismo no alguien más hablando por ti.

Podrías ya estar usando la autenticación SSH de Github, ¿pero sabes cómo funciona en sí? En este artículo, aprenderá qué sucede de forma interna y cómo funciona en realidad la autenticación de SSH.

A lo largo, entenderás los conceptos fundamentales de criptografía que cada desarrollador debería saber: encriptación de clave simétrica, encriptación de clave asimétrica, funciones hash criptográficas, y firmas digitales.

Algunos desarrolladores usualmente no tienen la chance de aprender y entender estos fundamentos de criptografía, pero estos conceptos te ayudarán a la larga. También, te ayudarán en estar en una mejor posición para tomar decisiones de seguridad informadas para tus aplicaciones de web en producción.

Así que vamos, abróchate los cinturones de seguridad, ¡y comencemos!

Esto es lo que cubriremos:

1. Primero, ¿por qué la Autenticación es tan importante?
2. Encriptación de Clave Simétrica
3. Encriptación de Clave Asimétrica
4. Funciones de Hash Criptográficas
5. Firmas Digitales
6. Cómo Funciona la Autenticación SSH
7. Resumiendo Todo

Primero, ¿por qué la Autenticación es tan importante?

Cuando ejecutamos git push, Github necesita verificar que la persona correcta está interactuando con Github. Imagina si un atacante podría llegar a hacer git push por ti.

Entonces todos tus repositorios estarían bajo el control del atacante. Podrían eliminar todo tu código juntamente con todo el historial de las confirmaciones.

Esto suena bastante peligroso, ¿no? Así que para verificar que eres tú el que está hablando con Github, y no un atacante, Github tiene varias formas de autenticarte.

El método más usado para autenticar con Github es la autenticación SSH.

Antes que entendamos cómo funciona la autenticación SSH internamente, necesitaremos entender los conceptos fundamentales de criptografía, a saber – encriptación de clave simétrica, encriptación de clave asimétrica, funciones de hash criptográficas, y firmas digitales.

¡Comencemos!

Encriptación de Clave Simétrica

En los tiempos antiguos, los gobernantes idearon varios métodos de comunicar mensajes militares secretos a sus comandantes del ejército.

En los métodos más primitivos, mayormente usados por los gobernantes Griegos antiguos y posiblemente luego los Romanos, involucrados usando una vara de madera cilíndrica llamado un Escítala.

Antes de una invasión militar, el gobernante tendría las dos mismas varas de madera cilíndricos exactas. Entonces le daría una escítala al comandante del ejército y mantener uno para sí mismo.

El dispositivo funcionaba al enrollar una tira de cuero alrededor de escítala. Después de hacer esto, el gobernante escribiría el mensaje por encima de la tira de cuero enrollada de forma que solo pudiera ser leído cuando estuviere enrollada de forma apropiada nuevamente.

Supón que la escítala le permitiera escribir tres letras alrededor en un circulo y cinco letras de forma recta a lo largo de su longitud. La tira de cuero enrollada con el mensaje attackfromright escrito luciría así:

       |   |   |   |   |   |
       | a | t | t | a | c |  |
     __| k | f | r | o | m |__|
    |  | r | i | g | h | t |
    |  |   |   |   |   |   |

Después de escribir el mensaje en la escítala, el gobernante desenrollaría la tira de cuero y lo enviaría al comandante del ejército. Cuando estaba desenrollada, la tira de cuero tendría el siguiente mensaje desordenado:

----------------
akrtfitrgaohcmt
----------------

Así que ahora lo ves, incluso si la tira de cuero fuera interceptada por un espía enemigo, el mensaje no tendría sentido. ¿No es fascinante? El uso inteligente de una vara de madera y una tira de cuero, ¡podría haber ayudado a algunos gobernantes antiguos ganar batallas!

Cuando la tira de cuero alcanzaba al comandante del ejército, lo envolvería con su propia escítala (que sería exactamente el mismo que el del gobernante), y luego el comandante sería capaz de entender el mensaje apropiadamente.

Esta técnica de la escítala en realidad es un ejemplo de la encriptación de clave simétrica en la práctica.

La encriptación es un proceso en el que el mensaje origina es modificado (o codificado) de tal forma que solamente el recipiente indicado puede decodificar y ver el mensaje actual.

El mensaje original se llama texto plano, mientras que el mensaje codificado se llama texto cifrado. La encriptación convierte el texto plano a texto cifrado con la ayuda de una clave.

Para descifrar el mensaje, que sería convertir el texto cifrado a texto plano, una persona debe tener acceso a la misma llave.

Si lo comparamos a la técnica de la escítala, la escítala es la llave. El gobernantes solamente comparte la llave (escítala) con el comandante del ejército que necesita saber lo que dice el mensaje.

Así es como luce el proceso de encriptación:

El proceso de descifrado lucirá así:

Llamamos a esto encriptación de llave simétrica porque la misma llave se usa tanto para encriptar y descifrar el mensaje.

Esta llave (la escítala) se debe mantener resguardada del acceso del enemigo. Si el enemigo accede a esta llave, entonces será capaz de descifrar los mensajes.

Pero hay otro tipo de encriptación llamada encriptación de llave asimétrica. Ahora que entiendes la encriptación de llave simétrica, sigamos con la encriptación de llave asimétrica.

Encriptación de Llave Asimétrica

En la encriptación de llave simétrica, como vimos arriba, la misma llave era usada por el gobernante y el comandante del ejército para encriptar y descifrar el mensaje.

Pero en una encriptación de llave asimétrica, hay dos llaves (llamado un par de llaves). De las dos llaves, una es una llave privada y la otra es una llave pública.

La llave pública puede ser compartido con todos (el cual por eso se llama pública). Pero la llave privada tiene que mantenerse, ¡en secreto! Nunca debe ser revelado a nadie.

Lo interesante sobre la encriptación de llave asimétrica es eso, si un mensaje es encriptado con la llave pública, entonces puede ser descifrado solamente con la llave privada correspondiente. Ninguna otra llave puede descifrarlo.

Y funciona de la otra forma también. Si un mensaje es encriptado con la llave privada entonces puede ser descifrado solamente usando la llave pública correspondiente.

Las dos llaves – pública y privada – están enlazados matemáticamente uno con el otro. Mientras uno encripta, el otro descifra.

Sólo una pequeña nota, la encriptación de llave asimétrica también se le llama encriptación de llave pública. Estos dos términos son usados de forma intercambiable pero significa lo mismo.

Funciones Hash Criptográficas

Una función hash criptográfica está diseñada para tomar una entrada de cualquier longitud y producir una salida de longitud fijada. La salida de longitud fijada se le denomina valor hash.

Un ejemplo popular de una función hash criptográfica es SHA-256.

La imagen de arriba muestra el valor hash SHA-256 de la entrada "freeCodeCamp.org". Las funciones hash criptográficas tienen tres propiedades que lo hacen muy útiles (lo veremos en las próximas secciones).

Primero, es prácticamente imposible para tomar el valor hash y averiguar la entrada del valor hash.

Por ejemplo, si nos dan el valor hash c9c31315ef2257e4b7698, no hay forma de que averigüemos que la entrada a la función hash fuere "freeCodeCamp.org".

Segundo, si pasamos la misma entrada a la función hash, obtenemos el mismo valor hash como la salida.

Si pasamos "freeCodeCamp.org" nuevamente a la función hash SHA-256, obtendremos la misma salida hash como nuestra llamada previa.

Tercero, dos entradas distintas nunca comparten el mismo valor hash. Inclusive el cambio más ligero en la entrada produce una salida totalmente distinta.

Supón que si proveemos "freeCodeCamp" como entrada en vez de "freeCodeCamp.org" – obtenemos una salida totalmente distinta.

Firmas Digitales

En tus vidas diarias, podrías tener que firma varios documentos. Podrían ser documentos legales, o el boletín de calificaciones de tus hijos, o tal vez algo más.

Cuando tu firma esté presente en el documento, le transmite a la otra parte que eres tú el que está de acuerdo cualquier cosa que esté escrito en ese documento.

Luego, no puedes dar marcha atrás de lo que está escrito en el documento. ¿Correcto?

De forma similar, en el mundo digital, tenemos las firmas digitales – o podemos simplemente llamarlos firmas.

Entendamos cómo funcionan las firmas usando un ejemplo. Tenemos dos usuarios llamados "Alice" y "Bob".

Bob quiere transferir algo de dinero a la cuenta bancaria de Alice. Así que Bob le pide a Alice su información de cuenta bancaria.

Alice sabe sobre las firmas digitales y decidió usar una. Al final, entenderás por qué Alice optó por una firma digital.

Antes de que Alice pueda crear una firma digital. Alice provee a Bib su clave pública (y guarda la clave privada para sí misma).

Luego Alice crea una firma digital y lo color al final del documento.

Una firma digital se crea primero al pasar el contenido del documento a una función hash criptográfica como SHA-256. En el caso de Alice, el contenido del documento es su número de cuenta bancaria.

Una vez que obtenemos el valor hash, se encripta con la clave privada de Alice. La salida de esta encriptación es la firma el cual se coloca al final del documento.

Luego esto se lo envía a Bob por Internet.

Cuando Bob recibe este documento, verifica si la firma es válida o no.

Para verificar la firma, Bob primero descifra la firma con la clave pública de Alice. Si lo recuerdas, Alice generó la firma al encriptar el valor hash.

 plaintext                         ciphertext  
     |                                 |
     |                                 |
     |                                 |
hash value --------encrypt--------> signature

Así que, cuando Bob descifra la firma, obtendrá el valor hash que Alice calculó. Llamemos a este valor hash de Alice.

 ciphertext                         plaintext  
     |                                 |
     |                                 |
     |                                 |
signature --------decrypt--------> hash value

Luego Bob toma el número de la cuenta bancaria que esta presente en el documento y lo pasa a la función hash.

Finalmente, Bob coincide el valor hash de Alice (la firma descifrada) y el valor hash que calculó. Si ambos valores hash coinciden entonces significa que la firma es válida.

Muy bien – ¿pero por qué necesitábamos hacer todo esto? ¿Qué significa si la firma es válida?

Cuando la verificación de la firma es exitosa, prueba dos cosas.

Primero, prueba que el documento ha sido enviado por Alice solamente. Nadie más podría haber enviado este documento.

La garantía de que solamente Alice ha enviado este documento viene del hecho de que fuimos capaces de descifrar la firma usando la clave pública de Alice.

Hemos aprendido de que si algo es encriptado usando una clave privada entonces puede ser descifrado solamente usando su clave pública vinculada.

Asi que, si Bob fue capaz de descifrar la firma usando la clave pública de Alice, significa que fue descifrado utilizando la clave privada de Alice, ¿correcto?

Y solamente Alice tiene acceso a su clave privada. Esto significa que, ¡Alice es la única persona quien podría haber enviado este documento!

Segundo, prueba que el contenido del mensaje no ha sido modificado por un atacante durante la transmisión en red.

Hicimos dos cosas para verificar la firma. Desciframos la firma, y nos dio el valor hash que Alice calculó. Y también hasheamos el número de cuenta bancaria recibido.

Si el valor hash que Alice caluló y el valor hash que Bob calculó son los mismos, significa que Alice y Bob dieron exactamente la misma entrada a la función hash.

Y esto significa que el número de cuenta bancaria que Alice envió y que Bob recibió son exactamente los mismos.

Si un atacante habría cambiado el número de cuenta bancaria antes de que el documento le llegara a Bob, entonces Bob hubiera recibido un número de cuenta bancaria modificado.

Cuando Bob fuera a calcular el valor hash de este número de cuenta bancaria modificado, el valor hash hubiera sido distinto de lo que Alice había calculado.

Así que mientras coincida el valor hash de Alice (firma descifrada) y el valor hash que Bob calculó, la coincidencia fallaría. Y evitaría que Bob transfiera dinero al número de cuenta bancaria errónea.

Para concluir, cuando la firma es verificada con éxito, significa que:

1. El documento es solamente de Alice.
2. El contenido del documento no fue modificado por algún tercero.

Ahora has aprendido sobre encriptación de clave simétrica, encriptación de clave asimétrica, funciones de hash criptográficas, y firmas digitales. ¡Es genial!

Hemos construido una fundación realmente sólido. Ahora entender la autenticación SSH va a ser mucho más fácil para ti.

Cómo Funciona la Autenticación SSH

Si no has configurado la autenticación SSH con Github, entonces después de terminar este artículo puedes seguir la documentación detallada de Github sobre cómo hacerlo. Por ahora, por favor quédate hasta el final.

La cruz del proceso de configuración es que crees un par de claves pública y privada en tu computadora local. Luego subes tu clave pública a tu perfil de Github – ¡y eso es todo!

Después que hemos creado nuestro par de claves pública y privada, en Ubuntu, el par de claves se almacenan dentro de la carpeta ~/.ssh.

La imagen de arriba muestra mi clave pública. Tengo esta clave pública cargada en mi perfil de Github:

Ahora, cuando ejecuto git push o cualquier otro comando que se quiera comunicar con Github, estaré autenticado usando la autenticación SSH.

SSH es un protocolo cliente-servidor. Nuestra computadora que ejecuta git push es el cliente SSH. Github es el servidor SSH.

El cliente comienza con el proceso de autenticación al solicitar nuestra clave pública que tenemos dentro de ~/.ssh.

Luego el cliente prepara un mensaje el cual tiene nuestra clave pública. Y luego el cliente genera la firma usando la clave privada correspondiente.

La clave pública y la firma se envían a Github. Al recibir este mensaje, Github hace dos cosas:

Primero, verifica si la clave pública mencionada en el mensaje se conecta a un perfil de Gihtub o no. Ya que subimos nuestra clave pública a Github, este paso se realizó con éxito.

Segundo, Github verifica la firma usando la clave pública que hemos subido.

Hemos aprendido que si la verificación de la firma termina siendo exitoso significa que solamente la persona quién está en posesión de la clave privada correspondiente podría haber enviado el mensaje.

Ya que solamente tenemos la clave privada vinculada a la clave pública cargada, esto prueba a Github que en realidad somos nosotros intentando comunicarse con Github y no un atacante.

Ahora, Github es 100% seguro que somos la persona correcta, estamos autenticados exitosamente, y a nuestro git push se le permite proceder.

Ves, se volvió fácil de entender la autenticación SSH ya que aprendiste los fundamentos.

La imagen de arriba es del cómic popular xkcd. El personaje allí (llamado Cueball) está pensando en revelar su clave privada. Espero que ahora sepas por qué está mal revelar tu clave privada.

Si revelas tu clave privada entonces alguien más puede autenticarse a Github en tu nombre. No quieres que eso suceda, ¿verdad? ;)

Así que, siempre asegúrate de mantener tu clave privada para ti mismo nada más.

Resumiendo Todo

Si has llegado hasta acá, entonces felicitaciones 🥳.

Has aprendido como funciona en realidad la autenticación SSH – cuando la firma fue verificado exitosamente por Github, le confirma a Github que somos nosotros quienes le estamos hablando, no un atacante.

A lo largo adquiriste una comprensión fundamental de la encriptación de clave simétrica, encriptación de clave asimétrica, funciones hash criptográficas y firmas digitales.

Gracias por estar conmigo en esta, espero que te vayas con algunos nuevos y valiosos aprendizajes.

Pongo ideas y recursos útiles en mi Twitter. Deberías seguirme allí. Respetaré tu tiempo.

Cuando era principiante en contribuciones de código abierto, uno de mis mayores desafíos era encontrar los proyectos o problemas correctos en los que trabajar.

Durante mucho tiempo, confié en recursos seleccionados por diferentes autores en Internet -muy buenos-, por cierto.

No obstante, siempre quise encontrar una forma de evitar mi denominado problema personal: una forma de buscar, acceder y seguir proyectos que fueran adecuados para mis habilidades (a fin de poder maximizar mi contribución en línea).

Acordemos una cosa: a diferencia de Google, buscar en GitHub no es fácil. Pero como desarrollador, es probable que interactúes con GitHub o Gitlab a diario.

Ahora la pregunta no es para qué usas estos sistemas de control de versiones, sino cómo los estás usando.

Así como dominar las habilidades de búsqueda en Google es esencial para cualquier usuario regular de Internet; creo que también es esencial para los desarrolladores aprender a buscar eficazmente en GitHub.

En este artículo vamos a echar un vistazo a diferentes técnicas que puedes emplear para efectuar búsquedas más exactas en GitHub. Aprenderás cómo buscar a través de:

• Problemas y solicitudes de extracción
• Repositorios
• Usuarios
• Temas

Y más... Vamos a empezar.

Consultas de búsqueda de GitHub

Es bien sabido que para encontrar información detallada sobre algo en Internet, necesitas tener las habilidades de búsqueda correctas.

No es diferente con GitHub: para encontrar información detallada, puedes utilizar técnicas comunes de filtrado, ordenación y búsqueda para encontrar fácilmente problemas y solicitudes de extracción específicos de un proyecto dado.

Aunque tienes múltiples recursos enumerados en Internet para diferentes proyectos, el principal problema surge cuando quieres hacer una búsqueda por ti mismo.

¿Cómo empiezas? ¿Qué palabras clave deberías usar para encontrar los resultados correctos?

La mayoría de los mantenedores tienden a etiquetar sus proyectos con problemas, lo que facilita que los colaboradores encuentren proyectos adecuados. A continuación se muestran algunos de los trucos que pueden ayudarte cuando estás usando GitHub.

Cómo buscar problemas y solicitudes de extracción en GitHub

Una de las formas más comunes de encontrar proyectos para contribuir es buscando a través de problemas y solicitudes de extracción relacionadas. Aquí hay algunos trucos que puedes usar para encontrar fácilmente respuestas confiables:

1. is:issue is:open label:beginner - Esta consulta particular mostrará todos los proyectos con problemas abiertos etiquetados como principiante. beginner.
2. is:issue is:open label:easy - Aquí mostrará todos los problemas abiertos etiquetados como fáciles.easy.
3. is:issue is:open label:first-timers-only - De esta forma se listan todos los problemas abiertos que dan la bienvenida a contribuciones de recién llegados.
4. is:issue is:open label:good-first-bug - Esto enumera los proyectos con problemas abiertos (open issues) etiquetados como "buenos primeros errores" good-first-bug, para atraer a los colaboradores a trabajar en ellos.
5. is:issue is:open label:"good first issue" - Con esta consulta se te mostrarán todos los problemas abiertos con la etiqueta buen primer problema, good first issue, lo que significa que es un buen lugar para que los principiantes comiencen.
6. is:issue is:open label:starter - Lista todos los problemas abiertos de GitHub etiquetados como iniciadores starters
7. is:issue is:open label:up-for-grabs - Enumera problemas abiertos que están listos para ser trabajados si tienes las habilidades necesarias.
8. no:project type:issue is:open - Mostrará todos los problemas abiertos que no están asignados a un proyecto específico.
9. no:milestone type:issue is:open - Muchas veces, los proyectos están organizados con hitos. Pero si quieres encontrar problemas que no estén rastreados, esta consulta de búsqueda los listará para ti.
10. no:label type:issue is:open - Señala todos los problemas abiertos que no tienen etiquetas.
11. is:issue is:open no:assignee - Enseña todos los problemas abiertos que aún no han sido asignados a una persona.

Cómo buscar repositorios

Por defecto, para realizar una búsqueda, escribirás el nombre del repositorio en la barra de búsqueda ¡y voilà! Obtendrás algunos resultados de búsqueda.

Pero las probabilidades de que llegues al repositorio exacto que tenías en mente son muy bajas.

Veamos algunas formas de estrechar tu búsqueda:

Cómo encontrar por nombre, descripción/README

Al buscar por nombre y descripción del archivo README, hay que tener en cuenta que la frase de búsqueda debe comenzar con el calificador in. Esto hace posible buscar "dentro" de lo que estamos buscando.

Veamos un ejemplo de cómo sería una búsqueda individual:

• Usando in:name. Digamos que estás buscando recursos para aprender más sobre Ciencia de Datos. En este caso, puedes usar el comando Ciencia de Datos in:name, que listará los repositorios con Ciencia de Datos en el nombre del repositorio.
• Usando in:description. Si deseas encontrar repositorios con una descripción específica, por ejemplo, repositorios donde se incluya el término "freeCodeCamp" en la descripción, nuestra búsqueda será: freecodecamp in:description.
• Usando in:readme Utilizas esto para buscar a través de un README de un archivo para una cierta frase. Si queremos encontrar repositorios donde se incluya el término freecodecamp en el README, nuestra búsqueda será: freecodecamp in:readme.
• Usando in:topic. Utilizas esto para encontrar si una cierta frase o palabra está etiquetada en los temas. Por ejemplo, para encontrar todos los repositorios donde freecodecamp esté listado en el tema, nuestra búsqueda será: freecodecamp in:topic.

También se pueden combinar múltiples consultas de búsqueda para estrechar aún más la búsqueda.

Cómo encontrar por Estrellas, Forks

Podemos además buscar un repositorio basado en cuántas estrellas y forks tiene el proyecto. Esto nos facilita saber qué tan popular es el proyecto.

Ejemplos

Usando stars:n. Si buscamos un repositorio con 1000 estrellas entonces la consulta será stars:1000. Esta acción listará exactamente 1000 repositorios.

Empleando forks:n. Aquí especificamos el número de forks (es decir las bifurcaciones o ramificaciones) que deseamos de un repositorio. Si queremos que los forks sean menos de 100 entonces nuestra consulta será la siguiente: forks:<100.

¿La buena noticia? ¡Siempre podemos usar operadores relacionales!  <, >, <=, >= & .. Esto nos ayudará a hacer más fácil y rápida la búsqueda.

Realizando búsquedas mediante el lenguaje

Otra forma genial de buscar en GitHub es mediante el lenguaje. Ello nos ayuda a filtrar nuestro repositorio en base al lenguaje de programación que buscamos.

Por ejemplo:

• Tenemos la forma language:LANGUAGE. Si quisieramos buscar un proyecto con código en PHP, nuestra búsqueda sería: language:PHP

Búsquedas mediante el nombre de la organización

También podemos buscar repositorios/proyectos que son mantenidos o creados por una organización en específico. Para ello necesitamos empezar nuestra búsqueda con la palabra clave org: seguida del nombre de la organización.

Si usamos org:freecodecamp nos mostrará los repositorios que sean de freeCodeCamp.

Encontrando mediante fechas

Si deseamos que los resultados se ajusten a una fecha específica, podemos buscar usando una las siguientes palabras clave: created, updated, merged and closed. Estas palabras clave deberán estar acompañadas por la fecha en el formato YYYY-MM-DD.

Ejemplo:

• Usando keyword:YYYY-MM-DD. Supongamos que deseamos buscar todos los repositorios con la palabra freeCodeCamp que fueron creados después de 2022-10-01. Entonces nuestra búsqueda será: freecodecamp created:>2022-10-01

También podemos usar los operadores relaciones <, >, >= y<= para buscar repositorios después de, antes de o en una fecha exacta . Si queremos buscar en un rango, entonces usamos....

Encontrando repositorios mediante el tipo de licencia

Las licencias son muy importantes cuando estamos buscando un proyecto al cual contribuir. Diferentes licencias otorgan diferentes derechos en cuanto a lo que un contribuidor puede o no puede hacer.

Para facilitarnos la búsqueda de proyectos con las licencias adecuadas, necesitamos tener un buen entendimiento de las licencias. Podemos leer más sobre ellas aquí.

Ejemplo:

• Usamos license:LICENSE_KEYWORD. Esta es una buena forma de buscar proyectos con licencias específicas. Para buscar proyectos con la licencia MIT, por ejemplo, haríamos lo siguiente: license:MIT.

Encontrar por visibilidad

También podemos llevar a cabo nuestra búsqueda en términos de la visibilidad del repositorio. En este caso, podemos usar tanto público como privado.

Esto coincidirá con los problemas (issues) y las solicitudes de extracción (PRs) que estén en un repositorio público o privado, respectivamente.

Ejemplos:

• Usamos is:public. Esto mostrará una lista de repositorios públicos. Tomemos un ejemplo donde queramos buscar todos los repositorios públicos propiedad de freeCodeCamp. Entonces nuestra búsqueda será: is:public org:freecodecamp.
• Usando is:private. Dicha consulta significa que listará todos los repositorios privados dentro de los parámetros.

Conclusión

Aunque hemos cubierto muchas consultas de búsqueda aquí, siempre podemos agregar nuestra creatividad para estrechar aún más nuestra búsqueda combinando varios parámetros juntos.

Para obtener recursos adicionales y más parámetros de búsqueda, siempre podemos consultar la documentación de GitHub o hacer uso de la Búsqueda Avanzada de GitHub.

Estos métodos siempre nos serán útiles ya que ofrecen más opciones de filtrado. Hay una miríada de parámetros de búsqueda y variaciones que podríamos utilizar para hacer más fácil nuestra actividad diaria en GitHub.

Espero que esto les ayude a utilizar la plataforma de manera más fácil y efectiva.

Al realizar cambios en un repositorio de Git, la mejor práctica es hacer push de los cambios a una rama diferente. Esto permite comparar los cambios antes de hacer un pull request y finalmente fusionar las ramas.

Esto es esencialmente crucial cuando se trabaja con otros desarrolladores.

La rama main de tu repositorio es considerada como la rama principal, es la única rama presente por defecto. Ahora repasemos rápidamente cómo crear ramas en Git.

Cómo crear ramas en Git

En esencia, hay dos métodos para crear ramas en Git.

Puede usar un sólo comando para crear la rama y moverse a ella. O bien, puede crear la rama primero con un comando y luego moverse a ella con otro comando cuando desee trabajar en esa rama.

Aquí está una versión rápida del código:

// crear una rama y moverse a esa rama
$ git checkout -b <nombre-rama>

// crear sólo una rama
$ git branch <nombre-rama>

Cómo crear una rama en Git y moverse a esa nueva rama

Podemos crear una nueva rama y moverse a ella usando el comando git checkout con la opción -b y <nombre-rama>. Se ve así:

$ git checkout -b <branch-name>

Supongamos que queremos crear una nueva rama de Git llamada "paginación" a partir de la rama main. Para lograr esto, usaremos el comando git checkout con la opción -b seguido del nombre de la rama "paginación".

Como puede ver, creamos una nueva rama y el comando checkout hizo que nuestra rama cambiara automáticamente de "main" a "paginación".

Veamos ahora cómo crear una rama en Git sin movernos a ella.

Cómo crear una rama en Git sin movernos a la nueva rama

Este es el método estándar para crear una rama usando el comando git branch y especificando el nombre de la rama en Git que desea crear.

$ git branch <nombre-rama>

Por ejemplo, como hicimos anteriormente, podemos crear una rama "paginación" para reemplazar con "paginación". Así es como se vería:

Como puede ver, la rama no cambió, pero se creó una nueva rama. Para ver una lista de todas las ramas disponibles, puede usar este comando:

$ git branch

Finalmente, supongamos que más tarde deseamos cambiar a nuestra nueva rama en Git o a cualquier otra rama que hayamos creado anteriormente. En este caso, podemos hacer uso del comando git checkout.

$ git checkout <branch-name>

Conclusión

En este artículo, aprendimos a usar comandos de Git en nuestra terminal para crear una rama localmente.

Si queremos agregar esta rama de forma remota, todo lo que tenemos que hacer es enviarla a nuestro proveedor de Git como GitHub usando el siguiente comando:

$ git push -u origin <nombre-rama>

Aprende a clonar una rama específica con Git con este artículo.  

¡Feliz codificación!

Puedes acceder a más de 200 de mis artículos visitando mi sitio web. También puedes usar el campo de búsqueda para ver si he escrito un artículo específico.

Sí, el título es un clickbait. No hay forma de que puedas comprender los conceptos básicos de la tecnología git en solo 10 minutos. Pero puedes acercarte bastante en unos 25 minutos. Y ese es el propósito de este artículo.

Si deseas comenzar a aprender sobre la tecnología Git, has venido al lugar correcto. Esta es una guía completa para principiantes de Git. Hay muchos clientes para Git. La tecnología es la misma sin importar el cliente. Pero en esta guía usaremos GitHub para entender Git.

¡Empecemos!

¿Qué es el control de versiones?

El control de versiones es un sistema que registra los cambios en un archivo o conjunto de archivos a lo largo del tiempo para que pueda recuperar versiones específicas más adelante. Es decir que, idealmente; podemos colocar cualquier archivo en la computadora en el control de versiones.

En teoría esto está bien... ¿Pero por qué habríamos de hacer eso?

Este es el por qué:

Un Sistema de control de versiones (VCS en inglés) nos permite revertir los archivos a un estado anterior, revertir todo el proyecto a un estado anterior, revisar los cambios realizados a lo largo del tiempo, ver quién modificó por última vez algo que podría estar causando un problema, quién introdujo un problema y cuando, y más. El uso de un VCS también significa que si por descuido arruinamos las cosas o perdemos nuestros archivos, generalmente podemos recuperarlos fácilmente. Y a veces solo quieres saber “quién escribió esta porquería”. ¿y tener acceso a esa información vale la pena?.

Entonces, ¿qué es Git?

Git es un sistema de control de versiones para rastrear cambios en archivos de computadora y coordinar el trabajo en esos archivos entre varias personas. Git es un sistema de control de versiones distribuido. Git no depende necesariamente de un servidor central para almacenar todas las versiones de los archivos de un proyecto. En cambio, cada usuario “clona” una copia de un repositorio (una colección de archivos) y tiene el historial completo del proyecto en su propio disco duro. Este clon tiene todos los metadatos del original, mientras que el original en sí se almacena en un servidor autohospedado o en un servicio de alojamiento de terceros como GitHub.

Git te ayuda a realizar un seguimiento de los cambios que realizas en tu código. Es básicamente la pestaña de historial para tu editor de código (¿sin modo de incógnito?). Si en algún momento durante la codificación te encuentras con un error fatal y no sabes qué lo está causando, siempre puedes volver al estado estable. Por lo tanto, es muy útil para la depuración. O simplemente puede ver qué cambios realizó en su código a lo largo del tiempo.

En el ejemplo anterior, las tres "tarjetas" representan diferentes versiones del mismo archivo. Podemos seleccionar qué versión del archivo queremos usar en cualquier momento. Entonces puedo saltar de un lado a otro a cualquier versión del archivo en el continuo de tiempo de git.

Git también te ayuda a sincronizar código entre varias personas. Así que imagina que tú y tu amigo están colaborando en un proyecto. Ambos están trabajando en los mismos archivos de proyecto. Git toma esos cambios que tú y su amigo hicieron de forma independiente y los fusiona en un solo repositorio "maestro" (Master). Entonces, al usar Git, puedes asegurarse de que ambos estén trabajando en la versión más reciente del repositorio. Por lo tanto, no tienes que preocuparte por enviar tus archivos por correo y trabajar con una cantidad ridícula de copias del archivo original. ¿Y colaborar a larga distancia se vuelve tan fácil como HTML?.

Flujo de trabajo Git:

Antes de comenzar a trabajar con los comandos de Git, es necesario que comprendas lo que representa.

¿Qué es un Repositorio?

Un repositorio, también conocido como repositorio, no es más que una colección de código fuente.

Hay cuatro elementos fundamentales en el flujo de trabajo de Git.

1.Directorio de trabajo.

2.Área de ensayo.

3.Repositorio local.

4.Repositorio remoto.

Si consideras un archivo en su Directorio de trabajo, puedes estar en tres estados posibles.

1. Puede ser escenificado. Lo que significa que los archivos con los cambios actualizados están marcados para ser confirmados en el repositorio local pero aún no confirmados.
2. Se puede modificar. Lo que significa que los archivos con los cambios actualizados aún no están almacenados en el repositorio local.
3. Se puede consolidar (commit). Lo que significa que los cambios que realizó en su archivo se almacenan de forma segura en el repositorio local.

• git add es un comando que se usa para agregar un archivo que está en el directorio de trabajo al área de preparación.
• git commit es un comando que se usa para agregar todos los archivos que están almacenados en el repositorio local.
• git push es un comando que se usa para agregar todos los archivos comprometidos en el repositorio local al repositorio remoto. Entonces, en el repositorio remoto, todos los archivos y cambios serán visibles para cualquier persona con acceso al repositorio remoto.
• git fetch es un comando que se usa para obtener archivos del repositorio remoto al repositorio local, pero no al directorio de trabajo.
• git merge es un comando que se usa para obtener los archivos del repositorio local en el directorio de trabajo.
• git pull Este comando se usa para obtener archivos del repositorio remoto directamente en el directorio de trabajo. es equivalente a un git fetch y un git merge .

Ahora que sabemos qué es Git y sus terminologías básicas, veamos cómo podemos colocar un archivo en git. Lo haremos de la manera correcta y de la manera difícil. Sin ninguna aplicación GUI.

Supongo que ya tienes un archivo que deseas colocar bajo el control de versiones. Si no, cree una carpeta de muestra llamada 'MuskCult' y coloques algunos archivos de código de muestra en ella.

Paso 0: Crea una cuenta de GitHub

Si aún no tienes una cuenta, puedes crear una aquí.

Paso 1: Asegúrate de tener installado Git en tu equipo

Si estás en una Mac, enciende la terminal e ingresa el siguiente comando:

$ git --version

Esto te pedirá que abras un instalador si aún no tienes git. Así que configúralo usando el instalador. Si ya tienes git, solo te mostrará qué versión de git tienes instalada.

Si estás usando Linux(deb), escribe lo siguiente en la terminal:

$ sudo apt install git-all

Si estás en Windows:

winget install --id Git.Git -e --source winget

Paso 2: Dile a Git quien eres

Preséntate. En serio, menciona tu nombre de usuario y dirección de correo electrónico de Git, ya que en cada confirmación de Git se utilizará esta información para identificarte como el autor.

$ git config --global user.name "YOUR_USERNAME"

$ git config --global user.email "im_satoshi@musk.com"

$ git config --global --list # To check the info you just provided

Paso 3: Genera/comprueba tu equipo en busca de claves SSH existentes. (Opcional)

¿Porque preguntas? Con el protocolo SSH, puede conectarse y autenticarse en servidores y servicios remotos. Con las claves SSH, puede conectarse a GitHub sin proporcionar su nombre de usuario o contraseña en cada visita.

Sigue este link para aprender más acerca de SSH.
Visita aquí para verificar si tienes una clave SSH existente.
Ve aquí para generar una clave SSH.
Ve aquí para añadir la clave SSH a tu cuenta de GitHub.
Finalmente aquí puedes comprobar la conección.

Si configuraste SSH, cada comando de git que tiene un enlace lo reemplazará por:

Instead of : https://github.com/username/reponame

You use    : git@github.com:username/reponame.git

           Note : You can use both ways alternatively

Usaré el protocolo SSH en este tutorial.

Paso 4: Hagamos Git

Crear un nuevo repositorio en GitHub. Sigue este link.
Ahora, ubica la carpeta que deseas colocar debajo de git en su terminal.

$ cd Desktop/MuskCult

Inicia Git:

Y para colocar la carpeta debajo de git, ingresa:

$ touch README.md    # To create a README file for the repository
$ git init           # Initiates an empty git repository

Cómo editar el archivo README.md para proporcionar información acerca del repositorio.

Agrega archivos al área de preparación para la confirmación:

Ahora, para agregar los archivos al repositorio de git el commit:

$ git add .  
# Adds all the files in the local repository and stages them for commit

OR if you want to add a specific file

$ git add README.md 
# To add a specific file

Antes del commit, veamos qué archivos se preparan:

$ git status # Lists all new or modified files to be committed

Confirma los cambios que realizaste en tu Git Repo:
Ahora para confirmar los archivos que agregó a su repositorio de git:

$ git commit -m "First commit"
# The message in the " " is given so that the other users can read the message and see what changes you made

Anula la confirmación de los cambios que acaba de realizar en su Git Repo:

Ahora supongamos que que acabamos de cometer algún error en el código o colocamos un archivo no deseado dentro del repositorio. Este archivo no deseado puede desorganizar los archivos que acabamos de agregar, por lo tanto usamos:

$ git reset HEAD~1
# Remove the most recent commit
# Commit again!

Añadiendo un origen remoto y un Git Push:

Ahora cada vez que tú hagas cambios en los archivos y los guardes, no será automáticamente actualizado en GitHub. Todos los cambios que hicimos en el archivo se actualizan en el repositorio local. Ahora para actualizar los cambios en el repositorio maestro:

$ git remote add origin remote_repository_URL
# sets the new remote

El comando git remote nos permite crear, ver y eliminar conexiones a otros repositorios.

$ git remote -v
# List the remote connections you have to other repositories.

El comando git remote -v enumera las URL de las conexiones remotas que tiene con otros repositorios.

$ git push -u origin master # pushes changes to origin

Ahora, el comando git push traslada los cambios en su repositorio local hasta el repositorio remoto que especificó como origen.

Y ahora, si vamos y revisamos nuestra página de repositorio en GitHub, debería verse así:

Y eso es. Acabas de agregar los archivos al repositorio que acabas de crear en GitHub.

Observa los cambios que realizaste en tu archivo:

Una vez que empieces a hacer cambios en tus archivos y los guardes, el archivo no coincidirá con la última versión que se comprometió con git. Para ver los cambios que acabas de hacer:

Has hecho lo siguiente:

$ git diff # To show the files changes not yet staged

Vuelve a la última versión comprometida con Git Repo:

Ahora puedes optar por volver a la última versión confirmada ingresando:

$ git checkout .

OR for a specific file

$ git checkout -- <filename>

Ver historial de commits:

Puedes emplear el comando git log para observar el historial de commits que has hecho en tus archivos.

$ git log

Cada vez que realiza cambios que desea que se reflejen en GitHub, los siguientes son los flujos de comandos más comunes:

$ git add .
$ git status # Lists all new or modified files to be committed
$ git commit -m "Second commit"
$ git push -u origin master

Ahora, si vamos y vemos nuestro repositorio, podemos identificar si la confirmación fue exitosa mirando el mensaje de confirmación para cada archivo.

Paso 5 : Eso está muy bien... Pero, ¿cómo descargo y trabajo en otros repositorios en GitHub?

Clonando un Repo de Git:

Localiza el directorio en el que deseas clonar el repositorio. Copia el enlace del repositorio que deseas e ingresa lo siguiente:

$ git clone remote_repository_URL

Siéntete libre de seguir adelante y clonar el repositorio que creé arriba usando: https://github.com/Gothamv/MuskCult

Empujar cambios al Git Repo:

Ahora puedes trabajar en los archivos que deseas y comprometerte con los cambios localmente. Si deseas enviar cambios a ese repositorio, debes agregarte como colaborador para el repositorio o bien, debes crear algo conocido como solicitud de extracción. Observa cómo hacer uno aquí y envíame una solicitud de extracción con tu archivo de código.

Colaborando:

Así que imagina que tú y tu amigo están colaborando en un proyecto. Ambos están trabajando en los mismos archivos de proyecto. Cada vez que realizas algunos cambios y los inserta en el repositorio maestro, tu amigo tiene que extraer los cambios que insertaste en el repositorio de git.

Es decir, para asegurarse de que está trabajando en la última versión del repositorio de git cada vez que comienzas a trabajar, un comando de extracción de git es el camino a seguir.
Ahora a continuación hay un ejemplo de un proyecto en el que mi amigo y yo estamos colaborando:

Entonces, para asegurarme de que esos cambios se reflejen en mi copia local del repositorio:

$ git pull origin master

Aquí hay dos comandos git más útiles:

$ git fetch
    AND
$ git merge

En los términos más simples, git fetch seguido de un git merge equivale a un git pull. Pero entonces... ¿Porqué existe?

Cuando usas git pull, Git intenta hacer tu trabajo automáticamente. Es sensible al contexto, por lo que Git fusionará cualquier confirmación extraída en la rama en la que estás trabajando actualmente. git pull fusiona automáticamente las confirmaciones sin permitirle revisarlas primero.

Cuando aplicas git fetch, Git recopila todas las confirmaciones de la rama de destino que no existen en tu rama actual y las almacena en tu repositorio local. Sin embargo, no los fusiona con su rama actual. Esto es particularmente útil si necesita mantener su repositorio actualizado, pero está trabajando en algo que podría fallar si actualiza sus archivos. Para integrar las confirmaciones en su rama maestra, usa git merge.

Un detalle más:

.gitignore

¿Qué es esto?

.gitignore le dice a git qué archivos (o patrones) debe ignorar. Por lo general, se usa para evitar enviar archivos transitorios de su directorio de trabajo que no son útiles para otros colaboradores, como productos de compilación, archivos temporales creados por IDE, etc.

Entonces, en el ejemplo anterior, el sistema usa archivos como pycache, .DS_Store para almacenar información para un acceso más rápido. Esto no es útil para otros colaboradores. Entonces podemos decirle a git que los ignore agregando un archivo .gitignore .

Usa el comando touch para crear el archivo  .gitignore :

$ touch .gitignore

Y puede agregar los siguientes patrones para decirle a git que ignore dichos archivos.

/*.cmake
/*.DS_Store
/.user
/build
etc. depending upon the files you want git to untrack

Y eso es todo por lo básico. Estén atentos a la Parte 2, que se centrará en Branch, Merge, Stash, Rebase, etc.

Si usas Github sin configurar una clave SSH, te lo estas perdiendo. Sólo piensa en todo el tiempo que gastas en introducir tu correo electrónico y contraseña en la consola cada vez que haces push de un commit, que podría ser dedicado a programar.

Bueno, no mas. Aquí hay una guía rápida para generar y configurar una clave SSH con GitHub, para que nunca mas tengas que autenticarte de la manera antigua.

Verifica si ya existe una clave SSH

Primero, revisa si ya tienes generadas claves SSH para tu maquina. Abre la terminal e ingresa el siguiente comando.

ls -al ~/.ssh

Si ya generaste claves SSH, deberías ver una respuesta similar a esta:

-rw-------  1 user_name user_name  1766 Jul  7  2018 id_rsa
-rw-r--r--  1 user_name user_name   414 Jul  7  2018 id_rsa.pub
-rw-------  1 user_name user_name 12892 Feb  5 18:39 known_hosts

Si tus claves ya existen, avanza a la sección copiar tu clave SSH pública mas debajo.

Si no ves ninguna respuesta o recibes un mensaje de que el archivo o directorio no existe (No such file or directory), entonces ejecuta en la terminal:

mkdir $HOME/.ssh

Luego genera un nuevo conjunto de claves con:

ssh-keygen -t rsa -b 4096 -C your@email.com

Ahora revisa que tus claves existan con el comando ls -al ~/.ssh y asegurate de que la salida de la terminal es similar a la mostrada mas arriba.

Aviso: Las claves SSH siempre son generadas como un par de claves públicas (id_rsa.pub)  y privadas (id_rsa). Es extremadamente importante que nunca reveles tu clave privada, y solo uses tu clave pública para cosas como la autenticación en GitHub. Puedes leer mas sobre como funcionan los pares de claves SSH / RSA aquí.

Agregua tu clave SSH al ssh-agent

ssh-agent es un programa que se inicia cuando inicias sesión y almacena tus claves privadas. Para que funcione correctamente, necesita estar ejecutandose y tener una copia de tu clave privada.

Primero, asegúrate de que ssh-agent esta ejecutándose con:

eval "$(ssh-agent -s)" # for Mac and Linux

o:

eval `ssh-agent -s`
ssh-agent -s # for Windows

Luego, añade tu clave privada al ssh-agent con:

ssh-add ~/.ssh/id_rsa

Copia tu clave SSH publica

A continuación, debes copiar tu clave SSH pública en el portapapeles

Para Linux o Mac, imprime el contenido de tu clave pública a la consola con:

cat ~/.ssh/id_rsa.pub # Linux

Luego selecciona y copia la respuesta.

O para Windows simplemente ejecuta:

clip < ~/.ssh/id_rsa.pub # Windows

Añade tu clave pública SSH a GitHub

Ve a la página de ajustes de GitHub, click en SSH and GPG keys y en dar al botón "New SSH key":

Luego ingresa un nombre reconocible y pega tu clave pública  (id_rsa.pub) :

Finalmente, comprueba la autenticación en la terminal con:

ssh -T git@github.com

Si seguiste correctamente todos los pasos, deberías ver este mensaje:

Hi your_user_name! You've successfully authenticated, but GitHub does not provide shell access.

Lighthouse es un proyecto de código abierto de Google para mejorar la calidad de las páginas web. Proporciona métricas centradas en el usuario para auditar el SEO, el rendimiento, la accesibilidad, mejores prácticas y las aplicaciones web progresivas. Para profundizar en Lighthouse, lee "Cómo analizar el rendimiento de un sitio web con Lighthouse". Este post demostrará lo siguiente:

• Implementación básica de Lighthouse en un flujo de trabajo de GitHub Actions.
• Configuración avanzada para mostrar los resultados de Lighthouse en los comentarios de las solicitudes de extracción.
• Reporte de informes Lighthouse en S3.
• Notificaciones de Slack.

Lighthouse Comprobación de GitHub Action

Esta entrada proporcionará una guía para utilizar Lighthouse Check Action para automatizar las auditorías de Lighthouse. Se puede utilizar dentro de un flujo de trabajo, desencadenado por cualquier evento. Este post demostrará cómo utilizar la acción cuando se desencadena por un evento de solicitud de extracción.

Ejemplo básico

Con los siguientes pasos podemos crear un flujo de trabajo básico.

1. Crea y cambia a una nueva rama localmente.
2. Cree un archivo en su proyecto con una ruta similar a la siguiente .github/workflows/mi-flujo-de-trabajo.yml (sustituyendo mi-flujo-de-trabajo por cualquier nombre de tu elección).
3. Rellene el archivo anterior con el ejemplo que se muestra a continuación, sustituyendo el campo urls por una lista separada por comas de las URLs que deseas probar.
4. Confirme los cambios localmente y envíe la rama a la remota.
5. Desde tu nueva rama, abre un pull request.

name: Lighthouse Check
on: [pull_request]

jobs:
  lighthouse-check:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - run: mkdir /tmp/artifacts
    - name: Run Lighthouse
      uses: foo-software/lighthouse-check-action@master
      with:
        outputDirectory: /tmp/artifacts
        urls: 'https://www.foo.software,https://www.foo.software/contact'
    - name: Upload artifacts
      uses: actions/upload-artifact@master
      with:
        name: Lighthouse reports
        path: /tmp/artifacts

Y Voilà? - ¡Nosotros tenemos un flujo de trabajo con Lighthouse! Asumiendo que tienes las Github Actions habilitadas en tu repo, tú deberías ver algo como lo siguiente (nota: en el momento de escribir esto las Github Actions están en modo "beta" y requieren registro).

Al hacer clic en "Acciones" se enumeran todos los flujos de trabajo que se están ejecutando y los anteriores.

Después de seguir los pasos de nuestro ejemplo básico, tú deberías ver un elemento en esta lista. Al hacer clic en él se nos mostrarán los resultados de Lighthouse impresos en la consola.

Desde nuestra configuración, también tenemos resultados capturados en informes HTML guardados como "artefactos".

Ejemplo avanzado

Lighthouse Check Action ofrece un conjunto completo de campanas y silbatos utilizando el módulo de NPM( lighthouse-check) bajo el capó. Hay mucho más que podemos hacer con esto. ¡Vamos a proceder!

Comentarios del Pull Request

Al utilizar esta función, los comentarios se publican con los resultados de Lighthouse en cada confirmación. Nosotros podemos hacerlo siguiendo los siguientes pasos.

1. Crea un nuevo usuario o busca uno ya existente para que actúe como "bot".
2. Crear un token de acceso personal desde esta cuenta de usuario.
3. Crea un secreto de GitHub para mantener el valor encriptado desde arriba. En nuestro ejemplo lo nombramos LIGHTHOUSE_CHECK_GITHUB_ACCESS_TOKEN.
4. Actualizar nuestro archivo de flujo de trabajo con el diff que se muestra a continuación.
5. Commit y push.

with:
+  accessToken: ${{ secrets.LIGHTHOUSE_CHECK_GITHUB_ACCESS_TOKEN }}
  outputDirectory: /tmp/artifacts

Con esto, hemos creado un bot para publicar los resultados de Lighthouse en los pull requests

Reporte de informes S3

En nuestro ejemplo, nosotros persistimos los resultados cargando los informes como artefactos en nuestro flujo de trabajo. Esta solución podría ser suficiente en algunos casos, pero los artefactos no se almacenan permanentemente. Para ver los informes, tenemos que navegar en el flujo de trabajo y descargar manualmente los informes desde la vista de artefactos.

Pero, ¿Si queremos una forma más fiable de almacenar y referenciar los informes? Aquí es donde entra en juego la función S3. Nosotros podemos configurar el almacenamiento de AWS S3 siguiendo los siguientes pasos.

1. Cree una cuenta de AWS, si, tú no tienes una.
2. Crea un S3 bucket, si, tú no tienes uno.
3. Adquiere un identificador de clave de acceso de AWS y una clave de acceso secreta.
4. Crea secretos de GitHub para estos dos valores. En nuestro ejemplo nosotros usaremos LIGHTHOUSE_CHECK_AWS_ACCESS_KEY_ID  y LIGHTHOUSE_CHECK_AWS_SECRET_ACCESS_KEY, respectivamente.
5. Añade el nombre del cubo y la región (ejemplo: us-east-1) como secretos de GitHub: LIGHTHOUSE_CHECK_AWS_BUCKET y LIGHTHOUSE_CHECK_AWS_REGION.

A continuación, nosotros actualizaremos nuestra configuración con el siguiente diff.

with:
  accessToken: ${{ secrets.LIGHTHOUSE_CHECK_GITHUB_ACCESS_TOKEN }}
+  awsAccessKeyId: ${{ secrets.LIGHTHOUSE_CHECK_AWS_ACCESS_KEY_ID }}
+  awsBucket: ${{ secrets.LIGHTHOUSE_CHECK_AWS_BUCKET }}
+  awsRegion: ${{ secrets.LIGHTHOUSE_CHECK_AWS_REGION }}
+  awsSecretAccessKey: ${{ secrets.LIGHTHOUSE_CHECK_AWS_SECRET_ACCESS_KEY }}

¡En nuestro próximo commit y push, los informes se suben automáticamente a S3 ✅! También los tenemos enlazados en los comentarios de nuestro PR.

Notificaciones de Slack

¿Qué es una nueva función en un flujo de trabajo de DevOps sin las notificaciones de Slack? Una tristeza sin duda. Vamos a acelerar las cosas añadiendo notificaciones a un canal de Slack para que todo nuestro equipo las vea. Nosotros podemos lograr esto en los siguientes pasos.

1. Cree un "Webhook entrante" en su espacio de trabajo de Slack y autorice un canal.
2. Añade la URL del Webhook como secreto de GitHub  - LIGHTHOUSE_CHECK_WEBHOOK_URL.
3. Añade los datos de GitHub y la URL del Webhook a nuestra configuración con el siguiente diff. Los datos de GitHub se renderizarán en nuestras notificaciones. Nosotros pasamos los datos de GitHub a través de la configuración con el "contexto" de GitHub.

with:
  accessToken: ${{ secrets.LIGHTHOUSE_CHECK_GITHUB_ACCESS_TOKEN }}  +  author: ${{ github.actor }}
  awsAccessKeyId: ${{ secrets.LIGHTHOUSE_CHECK_AWS_ACCESS_KEY_ID }}
  awsBucket: ${{ secrets.LIGHTHOUSE_CHECK_AWS_BUCKET }}
  awsRegion: ${{ secrets.LIGHTHOUSE_CHECK_AWS_REGION }}
  awsSecretAccessKey: ${{ secrets.LIGHTHOUSE_CHECK_AWS_SECRET_ACCESS_KEY }}
+  branch: ${{ github.ref }}
  outputDirectory: /tmp/artifacts
+  sha: ${{ github.sha }}
+  slackWebhookUrl: ${{ secrets.LIGHTHOUSE_CHECK_WEBHOOK_URL }}
  urls: 'https://www.foo.software,https://www.foo.software/contact'

¡Nuestro próximo commit y push introduce las notificaciones de Slack! El enlace "Lighthouse audit" está en la siguiente captura de pantalla, navega por el informe del S3 tal y como está configurado✨.

Mantener un registro histórico

Foo's Automated Lighthouse Check es una herramienta que podemos utilizar para gestionar un registro histórico de las auditorías de Lighthouse. Nosotros podemos conectarnos a ella con el GitHub de Lighthouse Check. De esta forma podemos ejecutar Lighthouse de forma remota frente a un entorno local y dockerizado de GitHub. Con esto nosotros podemos estar seguros de que nuestros resultados de Lighthouse no son defectuosos por el cambio de infraestructura de GitHub. Siga los pasos documentados para conectarse con Automated Lighthouse Check.

¿Y ahora qué?

Puede encontrar un ejemplo completo de lo anterior en la documentación de Lighthouse Check Action. ¡Espero que este artículo sea un complemento útil para su flujo de trabajo en DevOps!. Con Lighthouse integrado en un pipeline de CI/CD, podemos estar totalmente equipados para asegurar una alta calidad en el SEO del sitio web, el rendimiento, la accesibilidad, las mejores prácticas y las aplicaciones web progresivas.

Traducido del artículo de Adam Henson - How to use Lighthouse in GitHub Actions

Detenme si esto suena familiar...

Quieres iniciar con un nuevo framework/tiempo de ejecución. Así que instalas dicho framework/tiempo de ejecución.

Entonces, abres la terminal y ... comando no encontrado(command not found). Gran suspiro.

Revisitas los documentos que sugieren que has hecho algunos cambios a la configuración de perfil. De lo cual no estás seguro cómo hacerlo, así que vas a StackOverflow, donde encuentras una respuesta de "user92902399" que parece como si pudiera ser legítimo (quién sabe); así que copias y pegas eso en tu terminal y le ruegas a dios que no borre tu disco duro, y le envíes tu historial de búsqueda al presidente por correo.

Ahora el comando del tiempo de ejecución funciona. Pero falla. El error es críptico.

Regresas a Google.

Esta vez no hay respuesta clara en StackOverflow, a pesar de que varias personas tienen un problema similar. Encuentras un issue de Github que pareciera que podría estar relacionado. En algún lado, en el medio de una masa de gente diciendo "¡Gracias, esto funciona!" y "Esto no funciona para nada", alguien utiliza la palabra "Python".

Revisas tu versión de Python, y suficientemente seguro, este framework/tiempo de ejecución no es compatible con el que tienes instalado. Estás a punto de degradarlo, cuando te das cuenta de que la última vez que miraste en la dirección general de la instalación de Python, te tomó un día hacerlo funcionar nuevamente y todavía no está seguro de cómo lo hiciste.

¿Sabes qué? Este nuevo framework/tiempo de ejecución probablemente no sea tan bueno. Definitivamente no vale la pena tanto esfuerzo. ¡Oh mira! Una publicación de blog sobre cómo nunca debes usar declaraciones ternarias. ¿En qué estabas trabajando antes? A quien le importa.

¿Un poco demasiado parecido a lo que hiciste? Así es como es intentar configurar un nuevo proyecto, framework o tiempo de ejecución. Cada vez. Esto es parte de la razón por la que todos los desarrolladores, en un momento dado, miraron a alguien sin comprender, a mitad de un Cheeto, y dijeron: "funciona en mi máquina".

Funciona en TODAS las máquinas

La raíz del problema es que, para que el código funcione, hay un entorno completo que también debe configurarse correctamente. Este es un problema difícil de resolver. Lo que necesitamos es una forma de aislar el entorno de desarrollo y luego enviarlo con el código para que funcione en todas las máquinas. Y debemos hacerlo sin tener que enviar un sistema operativo completo.

La clave está en la palabra "aislar". Resulta que tenemos una forma de aislar y enviar entornos completos. Se llama "Docker". Puedes crear un contenedor con cualquier configuración y luego enviarlo a cualquier otra persona. Todo lo que necesitas ahora es una forma de desarrollar en ese contenedor como si fuera su máquina local.

Tú puedes.

En este artículo, te mostraré cómo puedes usar algunos archivos de configuración para empaquetar, y enviar todo tu entorno de desarrollo sin tu mal gusto en dubstep.

Todo esto gracias a la nueva extensión de contenedores de desarrollo para VSCode.

VS Code y contenedores de desarrollo

El concepto básico detrás de contenedores de desarrollo (Dev containers), es que especifiques un archivo Docker, que a su vez especifica todas las dependencias y pasos de configuración necesarios para obtener la configuración correcta del entorno de desarrollo. VS Code activará ese contenedor, instalará un pequeño servidor en él y luego se conectará de nuevo a tu instancia de VS Code. Lo que esto significa, es que ahora estás desarrollando dentro de un entorno preconfigurado. Pero para ti, es solo VS Code.

Para mostrarte cómo funciona esto, voy a crear un contenedor en el cual desarrollar la API de backend de un proyecto en el que trabajé llamado theurlist.com. El backend de este proyecto está escrito en C# y se ejecuta en Azure Functions. Para ejecutarlo localmente, tendría que instalar el .NET Core tiempo de ejecución, CLI de Azure Functions y la extensión Azure Functions VS Code.

El primer paso es instalar la extensión Dev Containers. Esto agregará un pequeño ícono en la esquina inferior izquierda de tu VSCode.

También necesitarás tener instalado Docker. Los contenedores de Docker no funcionan muy bien si no tienes Docker. Puede descargar la Community Edition aquí.

Con la extensión instalada, necesitas agregar los archivos de configuración adecuados a este proyecto. Es decir, un "Dockerfile" que especifique el contenedor en el que se cargará el proyecto. La extensión viene con un montón de entornos preconfigurados. Para agregar uno al proyecto, abre la paleta de comandos y selecciona "Dev Containers: Add Development Container Configuration Files" ("Contenedores de Desarrollo: Agregar archivos de configuración de contenedor de desarrollo").

Este proyecto utiliza Azure Functions y C#, por lo que seleccionarás esa definición de container.

Tan pronto como lo hagas, VS Code agregará una carpeta ".deployment" con "Dockerfile" y un archivo "devcontainer.json" dentro. También preguntará inmediatamente si quieres volver a abrir el proyecto en un contenedor. Decimos que no, y dejas que VS Code se relaje por un minuto mientras miramos estos archivos.

Primero vamos a mirar en el "Dockerfile".

Configuración Dockerfile

El "Dockerfile" especifica lo que habrá en el contenedor. Si lo abres, puedes ver que hay bastante allí. Es un poco detallado. Pero podemos analizar las partes importantes.

Lo primero que hace es incorporar la última versión de .NET Core SDK.

Luego instala algunas utilidades en el contenedor. Específicamente, instala ...

• Git (Fuente de controles)
• procps (utilidad de inspección de procesos)
• curl (utilidad HTTP)
• apt-transport-https (utilidad HTTPS)
• gnupg2 (una herramienta de encriptado)
• lsb-release (Imprime información específica de Linux)

Todo esto es para crear un entorno que tenga todas las herramientas oscuras que un desarrollador pueda necesitar para ejecutar este proyecto y poder registrarlo dentro y fuera del control de código fuente.

Luego, instala las herramientas principales de Azure Functions. Configura todas las ubicaciones de repositorio necesarias antes de la instalación. Estas son todas las cosas que un desarrollador tendría que hacer antes de poder ejecutar este proyecto.

El otro archivo de la carpeta ".devcontainer" es el archivo "devcontainer.json".

El archivo devcontainer.json

Este archivo especifica algunas configuraciones adicionales para el entorno de desarrollo remoto. Específicamente...

1. Indica que el "Dockerfile" debe usarse para construir el contenedor.
2. Se asegura de que el puerto "7071" se reenvíe desde el contenedor para que puedas acceder a él en "localhost: 7071". Este es el puerto en el que Azure Functions se ejecuta localmente.
3. Especifica las extensiones que se deben instalar en el contenedor. Dado que en realidad no estás usando VS Code localmente, sus extensiones no se instalan automáticamente. Especificarlos en este archivo asegura que estén allí cuando se abre el proyecto.

Y con eso, podemos abrir la paleta de comandos y seleccionar "Dev Containers: Reopen folder in container".

VS Code se recargará y comenzará a construir el contenedor para este proyecto.

La primera vez que hace esto, tarda uno o dos minutos porque las imágenes base deben extraerse y construirse. Una vez hecho esto por primera vez, las cargas posteriores son mucho más rápidas, ya que la imagen existe en tu máquina.

En el caso de este proyecto, una vez que se construye el contenedor, VS Code se propone restaurar las dependencias de C#, lo cual se realiza con la extensión C# que se incluyó en el archivo de configuración "devcontainer.json".

Cuando todo haya terminado, puedes ejecutar este proyecto simplemente presionando F5. Y así, la aplicación está en funcionamiento.

Piensa en lo que habríamos tenido que hacer para obtener esta configuración localmente ...

1. Instalar .NET Core
2. Instalar las Functions Core Tools
3. Instalar la extensión VS Code Functions
4. Instalar la extensión VS Code C#

Con los contenedores de desarrollo, nada de eso es necesario. Podemos configurar y enviar un entorno de desarrollo completo en dos archivos de texto.

Por favor, pon tu entorno de desarrollo en Github

Así que aquí está mi humilde súplica: en lugar de describir 15 pasos en un README de Github para configurar tu proyecto para que se ejecute, coloca todo tu entorno de desarrollo en Github. Eso significa registrar en esa carpeta ".devcontainers". Si un desarrollador usando tu proyecto no tiene VS Code o la extensión "Dev Containers", no sucede nada. No puedes perder.

Estoy emocionado porque siento que los días de configuraciones del infierno están llegando a su fin. Y además, piensa en todas las personas que salvaremos de los artículos dogmáticos sobre sentencias ternarias.

No voy a entrar en todos los quién, qué, cuándo, dónde o por qué de las web estáticas. Asumo que tienes al menos una vaga idea de lo que son o sólo quieres crear tu propia página web estática, asimismo no te importan los demás detalles. De cualquier manera esta publicación es para ti.

Primero, quiero que sepas que estoy escribiendo esto para una audiencia tan amplia como sea posible; tu no necesitas ningún conocimiento de programación para seguirlo, aunque un poco de familiaridad con la línea de comandos y Git ayudará mucho.

Entonces, ¿cómo puedes crear una página web estática con GitHub en 10 minutos?

Nosotros trabajaremos con dos herramientas específicas: GitHub Pages, que está específicamente diseñado para servir contenido estático y un generador de contenido estático llamado Jekyll.

Jekyll es una gema de Ruby para crear sitios web estáticos fácilmente, por lo que necesitarás tener Ruby instalado en tu computador si quieres usar Jekyll. Si, tú tienes OSX lo más probable es que ya tengas una versión de Ruby (aunque puede que tú necesites actualizarla). Si no lo tienes o estás en un ordenador con Windows, tú puedes aprender más sobre su instalación aquí: Instalando Ruby.

Con eso fuera del camino, abrir una nueva ventana con la terminal y escribe gem install bundler jekyll. Esto instalará Bundler (una herramienta de gestión de paquetes de Ruby asimismo Jekyll).

Una vez que esas gemas (paquetes de Ruby) se hayan instalado, escribe Jekyll new mi-sitio-estatico (llámalo como quieras) que ejecutará el generador de Jekyll para crear tu proyecto en un nuevo directorio. Después de que tu sitio sea creado, salta al directorio del sitio recién creado escribiendo cd mi-sitio-estatico (o cd como sea que llames a tu proyecto).

Abre tu proyecto en un editor de texto y tú verás varios archivos y carpetas que Jekyll creadas por ti. Ahora mismo sólo tienes que preocuparte por el Gemfile (no el Gemfile.lock). El Gemfile es un archivo de Ruby que maneja todos los paquetes asociados de Ruby necesarios para ejecutar un proyecto.

El archivo contendrá una línea con la versión de Jekyll, coméntala:

#gem "jekyll", "~> 4.0.0"

Entonces, añade esta línea:

gem "github-pages", group: :jekyll_plugins

A veces las gemas de las que depende están desactualizadas o las gemas que has instalado localmente son demasiado modernas para GitHub Pages.

He descubierto que esto puede dificultar la construcción y la prueba de mi página web de Jekyll localmente. Puede ser más fácil probar tu sitio localmente y guardar la construcción hasta que esté listo para el despliegue. Sin embargo, en el momento de escribir esto puedes especificar estas versiones de dependencia en tu Gemfile y Jekyll funcionará tanto localmente como con GitHub Pages:

gem "jekyll", "~> 3.8.5"
gem "github-pages","~> 202" , group: :jekyll_plugins
group :jekyll_plugins do
  gem "jekyll-feed", "~> 0.11.0"
end

Gracias a Alex Waibel en StackOverflow por la configuración más reciente.

Para ver tu sitio web en acción, ejecute bundle exec Jekyll serve  en la línea de comandos. Esto iniciará un servidor y podrás ver tu sitio web escribiendo localhost:4000 en la barra de direcciones de tu navegador.

¡Felicitaciones! Has creado un sitio web estático con Jekyll y estás en el directorio del proyecto. Ya has terminado el 50%.

Pongamos esto en línea

Ve a GitHub.com y regístrate o si ya tienes una cuenta selecciona el botón "nuevo" y crea un repositorio. Es importante que le pongas un nombre a tu repositorio, después del enlace que servirá tu cuenta de GitHub Pages, que es tú_nombredeusuario.github.io. Por ejemplo, mi nombre de usuario de GitHub es tfantina y mi blog es tfantina.github.io, por lo que mi repositorio GitHub se llama: "tfantina.github.io".

Vuelve a la ventana de tu terminal, sube tu sitio Jekyll desde tu computadora hasta GitHub ejecutando los siguientes comandos:

git init
git remote add origin git@github.com:<tu-nombre_usuario>/<tu_nombre_del_repo>.git
git commit -am “Configurando Jekyll!”
git push -u origin master

(Al sustituir el nombre de usuario y el nombre del proyecto, tú no necesitas abrir o cerrar <>).

Una vez que tus cambios han sido subidos a tu repositorio, tú deberías tener un sitio web estático que funcione. Esto se debe a que estás usando la gema GitHub Pages y has nombrado tu repositorio de tal manera que GitHub entienda que quieres alojarlo con GitHub Pages.

Tú puedes confirmarlo visitando tu sitio o entrando en la pestaña de configuración de GitHub y desplazándote a la sección de páginas. Tú deberías ver un botón verde que muestra dónde se ha publicado tu sitio:

Tú también notarás que se puede cambiar fácilmente el tema desde aquí también. GitHub ofrece algunos temas predeterminados para Jekyll, pero por supuesto también puedes crear propios.

Si tu sitio web dice que está publicado, pero se ve en blanco, es posible que tengas que hacer una refrescar la página o intentar mirar tu sitio en una ventana privada. Esto puede parecer obvio, pero pasa usualmente cada vez que configuro una nueva instancia de Jekyll.

Si, todo va de acuerdo con el plan, tu sitio debería verse algo como esto:

Ahí lo tienes - en pocos minutos has creado y desplegado un sitio web estático con GitHub Page. Pero, tú probablemente quieras ser capaz de poner algo de contenido en tu página.

Prometí que esto sólo tomaría diez minutos, así que no me sumergiré en todos los detalles de las páginas, la portada o el lenguaje de plantillas de Liquid. Eso es una publicación para otro día. En este instante compartiré cómo crear tu primera publicación.

De vuelta en tu editor de texto, abre la carpeta "_posts".  Ya hay una entrada que te da la bienvenida a tu nuevo blog. Crea un nuevo archivo de anotaciones y guárdalo con un nombre en este formato: AÑO-MES-DÍA-TÍTULO.markdown (ver abajo):

Una publicación de Jekyll contiene dos secciones: portada y cuerpo.

La portada da instrucciones específicas a Jekyll, como cuál va a ser el título de la publicación, qué diseño usar y cuándo fue escrito la publicación.

La portada es altamente personalizable. Por ejemplo, quería que mis mensajes tuvieran imágenes de héroes, así que creé una etiqueta lead_image y puse algo de sintaxis en mi diseño para comprobar específicamente si hay imágenes "lead" en el material de portada de cada publicación. El lenguaje de plantillas Liquid facilita la incorporación de contenido del material de portada en el tema.

Hay mucho más que se puede hacer con la portada, pero empecemos con un ejemplo genérico.

La portada por defecto se ve así:

—
layout: post 
title:  "Welcome to Jekyll!"
date:   2019-11-09 18:07:11 -0600
categories: jekyll update
—

• El diseño le dice a Jekyll en qué parte quieres que se muestre el contenido. Tú puedes tener varios diseños para diferentes páginas o tipos de publicaciones.
• El título de la publicación.
• Fecha de la publicación.
• Categorías, que son esencialmente etiquetas. Tú puedes añadir tantas o tan pocas como quieras separadas por espacios.

Después de la portada, tu publicación puede ser escrito en Markdown, lo que te da mucha flexibilidad para escribir el contenido de tu publicación.

Una vez tu publicación este finalmente guardado, abre una ventana terminal  

git commit -am “Públicar"
git push

Después de un minuto (y tal vez un refresco), tú podrás ver tu publicación.

¡Espero que ahora tengas un sitio web estático en GitHub Pages creado con Jekyll! Si tienes algún problema o pregunta por favor hazme un tweet @tfantina, o puedes mandarme un correo electrónico a contact@travisfantina.com.

Traducido del artículo - How to create a free static site with GitHub Pages in 10 minutes del autor Travis Fantina

Al comienzo puede ser tentador pensar que Git y GitHub son lo mismo. Pero en realidad no lo son. En realidad es posible utilizar Git sin GitHub! En definitiva, los dos existen por diferentes razones.

Este artículo comenzará dando una buena mirada a los propósitos de Git y GitHub. Después, vamos a aprender sobre las principales diferencias entre estas dos tecnologías vitales.

Sin más preámbulos, comencemos con Git.

¿Qué es Git?

Git es un Sistema de Control de Versiones Distribuido (DVCS) utilizado para guardar diferentes versiones de un archivo (o conjunto de archivos) para que cualquier versión sea recuperable cuando lo desee.

Git también facilita el registro y comparación de diferentes versiones de un archivo. Esto significa que los detalles sobre qué cambió, quién cambió qué, o quién ha iniciado una propuesta, se pueden revisar en cualquier momento.

¿Pero si Git es un Sistema de Control de Versiones Distribuido, qué significan exactamente esos términos?

¿Qué significa "distribuido"?

El término "distribuido" significa que cuando le instruyes a Git que comparta el directorio de un proyecto, Git no sólo comparte la última versión del archivo. En cambio, distribuye cada versión que ha registrado para ese proyecto.

Este sistema "distribuido" tiene un marcado contraste con otros sistemas de control de versiones. Ellos sólo comparten cualquier versión individual que un usuario haya explícitamente extraído desde la base de datos central/local.

Bueno, entonces "distribuido" significa distribuir todas – no solo algunas seleccionadas – versiones de los archivos del proyecto que Git haya registrado. Pero qué es exactamente un sistema de control de versiones?

¿Qué es un Sistema de Control de Versiones?

Un Sistema de Control de Versiones (VCS) se refiere al método utilizado para guardar las versiones de un archivo para referencia futura.

De manera intuitiva muchas personas ya utilizan control de versiones en sus proyectos al renombrar las distintas versiones de un mismo archivo de varias formas como blogScript.js, blogScript_v2.js, blogScript_v3.js, blogScript_final.js, blogScript_definite_final.js, etcétera. Pero esta forma de abordarlo es propenso a errores y inefectivo para proyectos grupales.

Además, con esta forma de abordarlo, rastrear qué cambió, quién lo cambió y porqué se cambió, es un esfuerzo tedioso. Esto resalta la importancia de un sistema de control de versiones confiable y colaborativo como Git.

Sin embargo, para obtener lo mejor de Git, es importante entender cómo Git administra tus archivos.

Estados de los archivos en Git

En Git hay tres etapas primarias (condiciones) en las cuales un archivo puede estar: estado modificado, estado preparado, o estado confirmado.

Estado modificado

Un archivo en el estado modificado es un archivo revisado – pero no acometido (sin registrar).

En otras palabras, archivos en el estado modificado son archivos que has modificado pero no le has instruido explícitamente a Git que controle.

Estado preparado

Archivos en la etapa preparado son archivos modificados que han sido seleccionados – en su estado (versión) actual – y están siendo preparados para ser guardados (acometidos) al repositorio .git durante la próxima instantánea de confirmación.

Una vez que el archivo está preparado implica que has explícitamente autorizado a Git que controle la versión de ese archivo.

Estado confirmado

Archivos en el estado confirmado son archivos que se guardaron en el repositorio .git exitosamente.

Por lo tanto un archivo confirmado es un archivo en el cual has registrado su versión preparada en el directorio (carpeta) Git.

Nota: El estado de un archivo determina la ubicación donde Git lo colocará.

Ubicación de archivos

Existen tres lugares principales donde pueden residir las versiones de un archivo cuando se hace control de versiones con Git: el directorio de trabajo, el sector de preparación, o el directorio Git.

Directorio de trabajo

El directorio de trabajo es una carpeta local para los archivos de un proyecto. Esto significa que cualquier carpeta creada en cualquier lugar en un sistema es un directorio de trabajo.

Nota:

• Los archivos en el estado modificado residen dentro del directorio de trabajo.
• El directorio de trabajo es distinto al directorio .git. Es decir, tu creas un directorio de trabajo mientras que Git crea un directorio .git.

Zona de preparación

La zona de preparación – técnicamente llamado “index” en lenguaje Git  – es un archivo normalmente ubicado en el directory .git, que guarda información sobre archivos próximos a ser acometidos en el directorio .git.

Nota:

• Los archivos en la etapa de preparación residen en la zona de preparación.

Directorio Git

El directorio.git es la carpeta (también llamada "repositorio") que Git crea dentro del directorio de trabajo que le has instruido para realizar un seguimiento.

La carpeta .git también es donde Git guarda las bases de datos de objetos y metadatos de los archivos que le hayas instruido realizar un monitoreo.

Nota:

• El directorio.git es la vida de Git – es el item copiado cuando se clona un repositorio desde otra computadora (o desde una plataforma en línea como GitHub).
• Los archivos en el estado acometido residen en el directorio Git.

El flujo de trabajo básico de Git

Trabajar con el Sistema de Control de Versiones Git se ve algo así:

1. Modificar archivos en el directorio de trabajo.
   Observe que cualquier archivo que modifiques se convierte en un archivo en el estado modificado.
2. Prepare selectivamente los archivos que quieras confirmar al directorio .git.
   Observe que cualquier archivo que prepares (agregues) a la zona de preparación se convierte en un archivo en el estado preparado.  
   También tenga en cuenta que los archivos preparados todavía no están en la base de datos .git.
   Preparar significa que la información sobre el archivo preparado se incluye en un archivo (llamado "index") en el repositorio .git.
3. Confirme el/los archivos que has preparado en el directorio .git. Esto es, guardar de manera permanente una instantánea de los archivos preparados en la base de datos .git.
   Observe que cualquier versión del archivo que confirmes al directorio .git se convierte en un archivo en el estado confirmado.

Lo esencial hasta ahora

En resumidas cuentas de todo lo discutido hasta el momento es que Git es un sistema de control de versiones genial para versionado, administración y distribución de archivos.

Pero espera un segundo, si Git nos ayuda en la administración y distribución eficaz de distintas versiones de los archivos de un proyecto,  ¿cúal es el propósito de GitHub?

GitHub Desmitificado

GitHub es una plataforma basada en la web donde los usuarios pueden alojar repositorios Git. Facilita compartir y colaborar fácilmente en proyectos con cualquier persona en cualquier momento.

GitHub también fomenta una participación más amplia en proyectos Código Abierto al proporcionar una manera segura de editar archivos en repositorios de otros usuarios.

Para alojar (o compartir) un repositorio Git en GigHub, siga los siguientes pasos:

Paso 1: Registrar una cuenta de GitHub

El primer paso para comenzar con el alojamiento en GitHub es crear una cuenta personal. Visite la página de registro oficial para registrarse.

Paso 2: Crear un repositorio remoto en GitHub

Después de registrarse, crear un home (un repositorio) en GitHub para el repositorio Git que quieres compartir.

Paso 3: Conectar el directorio Git del proyecto con el repositorio remoto

Una vez que hayas creado un repositorio remoto para tu proyecto, tienes que vincular el directorio .git del proyecto – ubicado localmente en tu sistema – con el repositorio remoto en GitHub.

Para conectar con el repositorio remoto, debes ubicarte en el directorio raíz del proyecto que quieras compartir, utilizando tu terminal local, y ejecuta este comando:

git remote add origin https://github.com/tuUsuario/tuRepositorio.git

Nota:

• Reemplaza tuUsuario en el código de arriba con tu nombre de usuario de GitHub.
  También reemplaza tuRepositorio con el nombre del repositorio remoto al que te quieres conectar.
• El comando de arriba implica que git debe agregar al proyecto la URL especificada como una referencia remota con la cual el directorio local .git puede interactuar.
• La opción origin en el comando de arriba es el nombre predeterminado (un nombre corto) que Git le otorga al servidor que aloja tu repositorio remoto.
  Es decir, Git utiliza el nombre corto origin en vez de la URL del servidor.
• No es obligatorio quedarse con el nombre predeterminado del servidor. Si prefieres otro nombre que origin, simplemente sustituya el nombre origin en el comando git remote add de arriba por cualquier nombre que prefieras.
• Siempre recuerda que un nombre corto del servidor (por ejemplo,  origin) no es nada especial! Sólo existe – localmente – para ayudarte a referenciar fácilmente la URL del servidor. Por lo tanto, siéntete libre de cambiarlo a un nombre corto que puedas referenciar fácilmente.
• Para renombrar cualquier URL remota que exista, utilice el comando git remote rename de esta manera:

git remote rename nombreURLactual nuevoNombreURL

• Cada vez que clones (descargues) cualquier repo remota, Git automáticamente le pone nombre origin a la URL de la repo. Sin embargo, le puedes especificar un nombre distinto con el comando git clone -o tuNombrePreferido.
• Para ver la URL exacta guardada para los nombres como origin, ejecuta el comando git remote -v.

Paso 4: Confirmar la conexión

Una vez que hayas conectado tu directorio Git con el repositorio remoto, verifica si la conexión fue exitosa ejecutando el comando git remote -v.

Después verifica la impresión para confirmar que la URL mostrada sea la misma que la URL remota que intentas conectarte.

Nota:

• Ver el artículo “Conectar con SSH” si quieres conectar utilizando la URL SSH en lugar de la URL HTTPS.
• Sin embargo, si no estás seguro de la URL remota que vas a utilizar, echa un vistazo al artículo “¿Qué URL remota debería utilizar?”.
• ¿Quieres cambiar tu URL remota? Cambiar la URL de un remoto es una excelente guía.

Paso 5: Subir un repo Git local a un repo remoto

Después de conectar exitosamente tu directorio local con el repositorio remoto puedes comenzar a subir (cargar) tu proyecto local upstream.

Cuando estés listo para compartir tu proyecto en otra parte, en cualquier repo remoto, simplemente le dices a Git que suba todos tus confirmaciones, ramas y archivos en tu directorio .git local al repositorio remoto.

La sintaxis del código utilizado para subir (push) un directorio local Git a un repositorio remoto es git push -u nombreRemoto nombreRama.

Esto es, para subir tu directorio local .git y suponiendo que el nombre corto de la URL remota es “origin”, ejecuta:

git push -u origin master

Nota:

• El comando de arriba implica que git debe subir tu rama master local a la rama master remota ubicada en la URL con nombre origin.
• Técnicamente puedes sustituir la opción origin con la URL del repositorio remoto. Recuerda, la opción origin es solo un nombre de la URL que hayas registrado en tu directorio .git local.
• El indicador -u (indicador de referencia upstream/seguimiento) automáticamente vincula la rama local del directorio .git con la rama remota. Esto te permite usar git pull sin ningún argumento.

Paso 6: Confirmar la subida

Por último, vuelve a tu página de repositorio GitHub para confirmar que Git haya subido exitosamente tu directorio Git local al repositorio remoto.

Nota:

• Tal vez tengas que refrescar la página del repositorio remoto para reflejar los cambios.
• GitHub también tiene un servicio gratuito opcional para convertir tu repositorio remoto en una página web funcional. Abajo vamos a ver “cómo” hacerlo.-

Publica tu página web con GitHub pages

Después de subir tu proyecto al repositorio remoto, fácilmente puedes publicarlo en la web de esta forma:

1. Asegurate que el nombre del archivo principal HTML de tu proyecto sea index.html.
2. En el sitio web de la plataforma GitHub ingresa al repositorio del proyecto que quieres publicar y haz click en la pestaña settings.
3. Desplaza hacia la sección GitHub Pages y cambia la rama Source de none a master.
4. Después aparecerá una notificación que dice “Your site is published at https://your-username.github.io/your-github-repo-name/”.
5. Ahora puedes ver – y publicitar – tu proyecto en la URL especificada.

Esta sección solo ha comenzado a tratar el tema de publicar tu proyecto con GitHub. Para aprender más sobre GitHub pages, echa un vistazo a esta documentación “Trabajar con páginas de GitHub Pages”.

En resumen

GitHub es una plataforma en línea de alojamiento (o para compartir) repositorios de Git. Nos ayuda crear una avenida para colaborar fácilmente con cualquier persona, en cualquier lugar, en cualquier momento.

Todavía en duda?

Todavía estás perplejo por la delgada línea entre Git y GitHub? No te preocupes – Te tengo cubierto. Abajo hay cinco diferencias claves entre Git y GitHub.

Diferencia 1: Git vs. GitHub — Función principal

Git es un sistema de control de versiones distribuido que registra las distintas versiones de un archivo (o conjunto de archivos). Le permite a los usuarios acceder, comparar, actualizar, y distribuir cualquiera de las versiones registradas en cualquier momento.

Sin embargo GitHub principalmente es una plataforma de alojamiento para albergar tus repositorios Git en la web. Esto permite a los usuarios mantener sus repositorios remotos privados o abiertos para esfuerzos colaborativos.

Diferencia 2: Git vs. GitHub — Plataforma de operación

Los usuarios instalan y ejecutan Git en sus equipos locales. Esto significa que la mayoría de las operaciones de Git se pueden lograr sin una conexión a internet.

Sin embarg GitHub es un servicio basado en la web que opera solamente en línea. Esto significa que necesitas estar conectado para hacer cualquier cosa en GitHub.

Diferencia 3: Git vs. GitHub — Creadores

Linus Torvalds comenzó Git en Abril del 2005.

Chris Wanstrath, P. J. Hyett, Tom Preston-Werner, y Scott Chacon fundaron GitHub.com en Febrero 2008.

Diferencia 4: Git vs. GitHub — Mantenedores

En Julio 2005, Linus Torvalds entregó el mantenimiento de Git a Junio C. Hamano — quien ha sido el principal mantenedor desde entonces.

En Octubre 2018, Microsoft compró GitHub.

Diferencia 5: Git vs. GitHub — Competidores

Algunas alternativas populares para Git son Mercurial, Team Foundation Version Control (TFVC), Perforce Helix Core, Apache Subversion, y IBM Rational ClearCase.

Los competidores más cercanos a GitHub son GitLab, Bitbucket, SourceForge, Cloud Source Repositories, y AWS CodeCommit.

Considerando todo

Git y GitHub son dos entidades diferentes que te ayudan a administrar y alojar archivos. En otras palabras Git sirve para controlar las versiones de los archivos mientras que GitHub es una plataforma para alojar tus repositorios Git.

Traducido del artículo - Git vs GitHub – What is Version Control and How Does it Work? de Oluwatobi Sofela

Cuando nos gusta el repositorio de alguien y nos gustaría tenerlo en nuestra cuenta de GitHub, hacemos un fork o bifurcación para poder trabajar con él en forma separada.

Cuando hacemos un fork de un repositorio, obtenemos una instancia de todo el repositorio con todo su historial. Luego, podemos hacer lo que queramos sin afectar la versión original.

¿Qué es un pull request?

Los pull requests son la forma de contribuir a un proyecto grupal o de código abierto.

Por ejemplo, un usuario llamado Harry realiza un fork de un repositorio de ThanoshanMV y le efectúa algunos cambios. Ahora Harry puede hacer un pull request a ThanoshanMV, pero dependerá de ThanoshanMV aceptar o declinarlo. Es como decir: "ThanoshanMV, ¿podrías por favor extraer (pull) mis cambios?"

¿Que significa contribuir?

No solo podemos contribuir a un proyecto de código abierto con código, sino que podemos hacerlo de muchas otras maneras. Algunas de ellas están descritas abajo.

Como indica la guía de hacktitude para iniciados de la firma IT 99xtechnology, podemos contribuir a un proyecto de código abierto de las siguientes maneras:

1. Diseñando: Puedes construir los diseños de un proyecto para mejorar su usabilidad, mejorar la navegación y el menú del proyecto en función de lo indicado por investigaciones acerca de las preferencias del usuario, crear arte para logotipos o camisetas y proporcionar guías de estilo para el proyecto.
2. Escribiendo: Puedes escribir y mejorar la documentación del proyecto o traducirla, iniciar un boletín o escribir tutoriales para el proyecto y tomar nota de los aspectos más destacados de la lista de correo, u organizar una carpeta de ejemplos mostrando cómo se utilizan los proyectos.
3. Organizando: Puedes vincular problemas duplicados, sugerir nuevas etiquetas de problemas, sugerir cerrar viejos problemas aún abiertos y hacer preguntas sobre problemas abiertos recientemente para hacer avanzar la discusión.
4. Ayuda a otros: Responde preguntas de problemas aún en discusión, revisa el código enviado por otras personas y ofrécete a ser mentor de otro colaborador.
5. Elaborando código: Ayuda a resolver problemas aún en discusión, consulta si puedes proveer nuevas funciones y mejorar las herramientas y las pruebas.

¡Realicemos nuestro primer pull request!

1. Realicemos un fork del repositorio

Realiza un fork del repositorio haciendo un clic en el botón fork de la parte superior de la página. Esto creará una instancia del repositorio completo en tu cuenta.

2. Clona el repositorio

Una vez que el repositorio esté en tu cuenta, clónalo a tu computador para trabajarlo localmente.

Para clonarlo, has clic en el botón "Code" y copia el link.

Abre la terminal y ejecuta el siguiente comando. Esto clonará el repositorio localmente.

$ git clone [DIRECCIÓN HTTPS]

Ahora hemos configurado una copia de la rama maestra desde el repositorio principal del proyecto en línea.

Debemos ir al repositorio clonado ejecutando el siguiente comando:

$ cd [NOMBRE DEL REPOSITORIO]

3. Crea una rama

Es una buena práctica crear una rama (branch) nueva cuando trabajas con repositorios, ya sea que se trate de un proyecto pequeño o estés contribuyendo en un equipo de trabajo.

El nombre de la rama debe ser breve y debe reflejar el trabajo que estamos haciendo.

Ahora crea una rama usando el comando git checkout:

$ git checkout -b [Nombre de la Rama]

4. Realiza cambios y confírmalos

Has cambios esenciales al proyecto y guárdalos.

Luego ejecuta git status , y verás los cambios.

Agrega esos cambios a la rama recién creada usando el comando git add:

$ git add .

Ahora confirma esos cambios utilizando el comando git commit:

$ git commit -m "Adding an article to week 02 of articles of the week"

5. Envía los cambios a GitHub

Para enviar los cambios a GitHub, debemos identificar el nombre del repositorio remoto.

$ git remote

Para este repositorio el nombre es "origin".

Luego de identificar el nombre podemos enviar en forma segura los cambios a GitHub.

git push origin [Nombre de la Rama]

6. Crea un pull request

Ve a tu repositorio en GitHub y verás un botón llamado "Pull request", has clic en él.

Por favor, provee todos los detalles necesarios de lo que has hecho (puedes referenciar problemas utilizando "#"). Ahora, envía el pull request.

¡Felicitaciones! Has hecho tu primer pull request.

Si tu pull request es aceptado recibirás un mail.

7. Sincroniza tu rama maestra con la del repositorio original

Antes de enviar cualquier pull request al repositorio original debes sincronizar tu repositorio con aquel.

Incluso si no vas a enviar un pull request al repositorio original, es mejor efectuar la sincronización, ya que pueden haberse agregado algunas prestaciones o funciones adicionales y haberse corregido algunos errores desde la vez que realizaste un fork de aquel repositorio.

Sigue estos pasos para actualizar/sincronizar aquellos cambios con tu rama maestra:

1. Primero, revisa en que rama estás ubicado.

$ git branch

Esto enumerará todas las ramas y indicará en verde la rama actual o activa.

2. Cambia a la rama maestra.

$ git checkout master

3. Agrega el repositorio original como un repositorio upstream.

Para poder extraer los cambios desde el repositorio original a tu versión local, necesitas agregar el repositorio Git original como un repositorio upstream.

$ git remote add upstream [HTTPS]

Aquí, [HTTPS] es el URL que debes copiar del repositorio del propietario.

4. Busca (fetch) el repositorio.

Busca todos los cambios  del repositorio original. Las confirmaciones (commits) del repositorio original serán almacenadas en una rama local llamada upstream/master.

$ git fetch upstream

5. Fusionala.

Fusiona los cambios de la rama upstream/master a tu rama maestra local. Esto hará que tu rama maestra se sincronice con el repositorio upstream sin perder tus cambios locales.

$ git merge upstream/master

6. Envía (push) los cambios a GitHub

En este punto tu rama local está sincronizada con la rama maestra del repositorio original. Si deseas actualizar el repositorio de GitHub, necesitas enviar tus cambios.

$ git push origin master

NOTA: Luego de sincronizar tu rama maestra puedes eliminar el repositorio upstream, si lo desea. Pero lo necesitará para actualizar/sincronizar tu repositorio en el futuro, por lo que es una buena práctica conservarlo.

$ git remote rm [Nombre del Repositorio Remoto]

8. Elimina ramas innecesarias

Las ramas son creadas para propósitos especiales. Una vez que ese propósito se cumple, aquellas ramas ya no son necesarias, por lo que puedes eliminarlas.

$ git branch -d [Nombre de la Rama]

También, puedes eliminar su versión en GitHub.

git push origin --delete [Nombre de la Rama]

Conclusión

GitHub es una poderosa herramienta para controlar el historial de versiones. Todos pueden contribuir a proyectos de código abierto mediante pull requests. Las contribuciones no siempre son un código; también hay otras formas de contribuir.

Finalmente, debo decirte que no debes preocuparte si tus pull requests son rechazadas. Los encargados de los proyectos dedican mucho tiempo a mejorarlos y saben mucho más sobre sus proyectos que nosotros. Así que no te preocupes si tu solicitud no es tenida en cuenta.

Mantente fuerte, positivo y nunca te rindas.
― Roy T. Bennett, The Light in the Heart

Este artículo fue originalmente publicado en Medium.

Puedes contactarme y conectar conmigo en Twitter.

¡Sigue contribuyendo al mundo del código abierto!

Traducido del arículo de Thanoshan MV - How to make your first pull request on GitHu

Bueno, ya no más. Aquí hay una guía rápida para generar y configurar una clave SSH con GitHub para que nunca más tengas que autentificarte a la antigua.

Comprobar si existe una clave SSH

Primero, comprueba si ya has generado las claves SSH para tu máquina. Abre una terminal e introduce el siguiente comando:

ls -al ~/.ssh

Si ya has generado las claves SSH, deberías ver una salida similar a esta:

-rw-------  1 usuario usuario  1766 Jul  7  2018 id_rsa
-rw-r--r--  1 usuario usuario   414 Jul  7  2018 id_rsa.pub
-rw-------  1 usuario usuario 12892 Feb  5 18:39 known_hosts

Si tus claves ya existen, pasa a la sección Copia tu clave pública de SSH abajo.

Si no ves ninguna salida o ese directorio no existe (obtienes un mensaje de No such file or directory), entonces ejecuta:

mkdir $HOME/.ssh

Luego genera un nuevo conjunto de claves con:

ssh-keygen -t rsa -b 4096 -C tu@correo.com

Ahora comprueba que tus claves existen con el comando ls -al ~/.ssh y asegúrate de que la salida es similar a la anterior.

Nota: Las claves SSH siempre se generan como un par de claves públicas (id_rsa.pub) y privadas (id_rsa). Es extremadamente importante que nunca reveles tu clave privada, y que sólo uses tu clave pública para cosas como la autenticación de GitHub. Puedes leer más sobre cómo funcionan los pares de claves SSH / RSA aquí.

Agrega tu clave SSH a ssh-agent

ssh-agent es un programa que se inicia cuando te conectas y almacena tus claves privadas. Para que funciones correctamente, debe estar ejecutándose y tener una copia de tu clave privada.

Primero, asegúrate de que ssh-agent se está ejecutando con:

eval "$(ssh-agent -s)" # para Mac y Linux

o:

eval `ssh-agent -s`
ssh-agent -s # para Windows

Entonces, agrega tu clave privada a ssh-agent con:

ssh-add ~/.ssh/id_rsa

Copia tu clave pública de SSH

A continuación, tienes que copiar tu clave pública de SSH en el portapapeles.

Para Linux o Mac, imprime el contenido de tu clave pública en la consola con:

cat ~/.ssh/id_rsa.pub # Linux

Luego resalta y copia la salida.

O para Windows, simplemente ejecuta:

clip < ~/.ssh/id_rsa.pub # Windows

Agrega tu clave SSH pública a GitHub

Ve a la página de configuración de tu GitHub y haz clic en el botón "New SSH key":

Luego dale a tu clave un título reconocible y pégala en tu clave pública (id_rsa.pub):

Finalmente, prueba la autenticación con:

ssh -T git@github.com

Si has seguido todos estos pasos correctamente, deberías ver este mensaje:

Hi tu_usuario! You've successfully authenticated, but GitHub does not provide shell access.

Más información sobre SSH:

• Ultimate guide to SSH
• A top-down intro to SSH

Traducido del artículo - How to Get and Configure Your Git and GitHub SSH Keys

¿Y si solo necesitan editar un archivo, tal vez el README de un proyecto para arreglar una errata?

No necesitas saber cómo programar o cómo usar Git para hacerlo. Pero una vez que empieces a hacer Pull Requests, podrás hacer muchas más cosas y colaborar en proyectos con otras personas. Y tal vez esto te empuje a contribuir también con código más adelante.

Supongo que ya tienes una cuenta de GitHub (gratuita). Si no la tienes, entonces ve a github.com y consigue una.

Déjame mostrarte el proceso.

Fui a esta página https://web.dev/prefers-color-scheme/ y encontré una posible errata. A esta línea le falta un punto al final.

No soy muy riguroso con la gramática, esto es sólo para encontrar un ejemplo...

Sé que ese sitio está alojado en GitHub, y que el artículo exacto está alojado aquí: https://github.com/GoogleChrome/web.dev/tree/master/src/site/content/en/blog/prefers-color-scheme

Abro el archivo index.md https://github.com/GoogleChrome/web.dev/blob/master/src/site/content/en/blog/prefers-color-scheme/index.md directamente en GitHub y presiono el icono del lápiz en la barra de herramientas del archivo. Al pasar el ratón por encima de él dice: "Fork this project and edit the file".

Esto trae una vista de editor con esta información:

Estás editando un archivo en un proyecto al que no tienes acceso de escritura. Enviando un cambio a este archivo lo escribirá a una nueva rama en su fork flaviocopes/wev.dev, para que puedas enviar un pull request.

Puedo ir y agregar ese punto, luego en el formulario de abajo explico los cambios que hice:

Presioné el botón "Propose File Change" y apareció una vista comparativa.

Allí puedo revisar los cambios que hice, para asegurarme de que todo está bien, y finalmente puedo hacer clic en el botón "Create Pull Request". Actualmente los cambios se han hecho en el fork del proyecto, que fue hecho automáticamente por GitHub cuando hiciste clic en el icono del lápiz.

En la parte superior de esta vista pueden ver que estoy a punto de enviar un PR (Pull Request) al proyecto GoogleChrome/web.dev desde mi formulario flaviocopes/web.dev, desde mi rama patch-2 a su rama master.

Al pulsar el botón "Create Pull Request" se muestra otro formulario donde puedo escribir una descripción detallada del Pull Request.

Los Pull Requests puede contener muchos cambios diferentes, así que en teoría podrías tener muchos archivos editados en el mismo PR, por eso puedes agregar un resumen.

Este repositorio tiene una plantilla para el texto del PR, para ayudar al equipo a manejarlo. Nuestro PR es muy simple, así que quito la plantilla y solo pego el contenido del mensaje de confirmación de antes.

¿Notas la pista de la derecha? Me dice que el proyecto tiene un archivo CONTRIBUTING.md, que explica cómo contribuir y las directrices. Bastante genial.

Parece que necesitamos firmar un CLA (Acuerdo de Licencia de Contribuyente) para completar nuestro PR. Ya firmé un CLA de Google en el pasado, así que este paso está claro para mí, pero puede que tengas que arreglarlo. La mayoría de los proyectos no lo necesitan realmente.

¡Hice clic en "Create pull request" y ahora se envía el PR!

Ahora depende de que los que mantienen el proyecto intervengan y lo acepten, solo tienes que esperar a que te envíen un correo electrónico diciéndote que se ha fusionado, o cualquier comentario que otras personas hayan hecho.

[... un par de horas pasaron...]

Recibí un correo electrónico de vuelta, el PR fue rechazado ¡porque ese punto este en el lugar correcto! (No sabía eso).

Pero de todos modos, aquí hay una cosa que quería añadir: no te enfades o te molestes si un PR que presentas no es aceptado. Los que mantienen el proyecto trabajan en él durante meses o años y saben mejor que tú lo que es mejor para él.

Además, especialmente con el código, los puntos de vista pueden ser muy diferentes y un PR que creas que es genial puede no ser bienvenido.

También es mejor preguntar antes de trabajar en un PR sustancial, para ver si es algo que el proyecto realmente necesita.

La corrección de bugs (errores) es un comienzo fácil.

Traducido del artículo de Flavio Copes - How to make your first Pull Request on GitHub

Hace poco creé mi propia cuenta personal en Gitlab solo por el hecho que GitLab me ofrecía una forma muy fácil de automatizar mi proceso de compilación y despliegue de una aplicación simple de una página en React usando tan solo un archivo  .gitlab-ci.yml

Sin embargo, cuando obtuve acceso al beta de GitHub Actions tenía que darle un intento. Así que decidí construir algo similar.

¡Muéstrame el código!

Si ya tienes una idea de qué acciones son y solo quieres ver el código relacionado, siéntete libre de explorar el repositorio para este artículo en el siguiente enlace: https://github.com/pedsm/tryGithubAction

Un breve descargo

Toda mi experiencia con GitHub Action hasta el momento está basada en su versión beta, así tenlo en consideración. Pueda que muchas de las cosas de las que hablo aquí no sean liberadas en versión final, además ignoraré los errores y comportamientos raros que he ido encontrando.

¿Qué es?

GitHub Actions te permite automatizar tareas a ser completadas cuando algo sucede en tus repositorios (como pushes, issues, versión y demás). Esto significa que puedes configurar tu repositorio de manera tal que pueda ser automáticamente probado y desplegado cada vez hay un nuevo commit, que es exactamente lo que yo hice.

Como ya mencioné, la única razón por la que decidí crear una cuenta en GitLab fue la posibilidad de tener un flujo de trabajo en el cual todo nuevo código agregado al Master sea desplegado directamente al sitio web, entonces decidí recrear esto exactamente.

La Configuración

Una vez que tienes acceso a GitHub Action, verás una nueva pestaña con el nombre de Actions en tus repositorios. En ella podrás crear tu primer flujo de trabajo. Un flujo de trabajo es un archivo de flujo de trabajo que vive dentro del .github que ya se usa para otras cosas, como plantillas de relaciones públicas y otras configuraciones de GitHub específicas del repositorio.

GitHub Actions viene con un editor gráfico completamente equipado para tus flujos de trabajo. Esto es un soplo de aire fresco si pensaste que ibas a tener que aprender un nuevo esquema YAML or algún lenguaje específico a la tecnología como en el caso de Jenkinsfile. Por otro lado, si no quieres usar ninguna de estas alucinantes herramientas gráficas siempre puedes editar el archivo .workflow a tu gusto.

Los archivos de Workflow usan el lenguaje de configuración HashiCorp(conocido también como HCL). Si conoces de Terraform, este lenguaje se te hará familiar.

Las diferencias

Si has implementado algún tipo de prueba automatizada, todo esto se te hará muy familiar. Quizá aparte de tener acceso a un editor gráfico. De todas maneras, encontraremos menos similitudes a medida que avancemos.

GitHub Actions, como el nombre lo sugiere, es una serie de actions que son ejecuciones de comandos individuales, lo cual es bastante inusual. Si le prestas atención al archivo de flujo de trabajo, habrás notado que la definición de las acciones tiene un parámetro uses. Si usas una acción npm podrías crear una solo tarea NPM como npm install y luego otra acción para hacer la prueba npm test. Esto es inusual, ya que algunas tareas lógicas como "instalar dependencias" podrían requerir más de un comando y usualmente están agrupadas en "Etapas" en otras soluciones de integración continua.

Al usar el editor gráfico y agregas una nueva acción, lo primero que se te muestra es una lista de acciones disponibles. Luego aparece un formulario simple en el cual solo debes ingresar texto en los campos label, args y run.

El campo label, como podrías inferir, es solo un nombre amigable para lo que hace tu acción, como por ejemplo "Testing". La acción luego realizas un ‘runs args’  en la terminal considerando que runs no está siendo sobreescrito. Esto significa que para ejecutar npm install en una acción que use npm, tendrías que dejar el campo runs con el texto por defecto (vacío) y en el campo args escribir install

A este momento me provoca un poco de decepción, porque al parecer GitHub quiere restringir la funcionalidad de esta característica a solo las cosas que la plataforma determine. Npm está disponible por el momento, pero si usas pip para tu proyecto en Python entonces tendrás que implementar una acción propia o buscar una alternativa de código abierto. Ya es posible crear tus propias acciones personalizadas, pero dado que aún está en su versión beta es poco probable que encuentres gran variedad. Mirando el lado positivo, si tenían las dos cosas que necesitaba, NMP y Heroku.

El Proyecto

La idea del proyecto es bastante simple: Quería construir una aplicación en Vue(ya que es lo que estoy aprendiendo actualmente) y tener un despliegue automático a un servicio de alojamiento.

Después quería crearlo de manera que el contenido del sitio web refleje un archivo json con una serie de nombres de usuario de GitHub. De esta manera cualquier podría crear un PR con su nombre de usuario de GitHub y yo podría darle clic a un botón y tener todo desplegado mágicamente.

Omitiré todo el contenido en Vue.js e iré directamente a los Actions. Luego de construir esta simple aplicación, sólo tenía que hacer las siguientes acciones:

1. Instalar las dependencias
2. Ejecutar los linters (muy importante para prevenir cualquier mala estructura en el archivo json)
3. Construir el código listo para ir a producción
4. Desplegar en algún sitio web. (Decidí usar Heroku ya que parece ser el menos complicado en términos de servidores y que hay acciones disponible para esta plataforma).

Con los 3 primeros pasos tuve la experiencia más intuitiva automatizando cualquier cosa. Me recordó mucho a la plataforma IFTT. Solo tienes que darle clic a la acción NPM y luego escoger que quieres que NPM haga. Sé que mencioné que me sentí un poco restringido al solo tener una par de acciones, pero la realidad es que en ningún momento tuve que preocuparme sobre la distribución de Linux que estaba usando, si NPM estaba empaquetado con la instalación Node.js, y lo más importante cero preocupación si es que la sintaxis HCL estaba correcta. Un par de clic en la interfaz gráfica y listo. El proceso completo tomó 4 acciones y menos de 5 minutos.

Luego pasé a la fase de despliegue. Sabía que esta iba a ser un poco más complicada, porque a pesar de saber cómo funciona Heroku, nunca antes lo había utilizado. Sin embargo, en el repositorio actions/heroku  encontré instrucciones claras que me ayudaron a hacer exactamente lo que quería hacer. Al final, fue un tema de más clics y listo.

Secretos

Creo que esté el momento perfecto para hablar sobre mi funcionalidad favorita de GitHub Actions, los secretos. Como podrás suponer, Heroku requiere una API Key para poder permitirle a alguien desplegar la aplicación. De lo contrario, cualquiera leyendo este artículo podría reemplazar mi aplicación con lo que le plazca. Usualmente, esto es algo molesto al encargarse de un proyecto de código abierto, ya que no puedes almacenarlo dentro del mismo repositorio. AWS tiene incluso un servicio dedicado a esta clase de problema. A pesar de ellos, GitHub ha implementado una elegante solución a este problema.

Los secretos son valores que puedes almacenar al mismo nivel del repositorio y que será automáticamente encriptados y luego enviados como variables de entorno a las acciones que definas que tengan acceso a estos valores.

Si le has pegado una mirada al repositorio de la acción de Heroku, te habrás dado cuenta de que HEROKU_API_KEY está listado como un secreto requerido. El proceso para hacer esto en el editor es tan simple como darle clic a *new secret*, y luego darle un nombre y valor. A partir de ellos, puedes marcar el checkbox para cualquier acción que quieras que tenga acceso a esta información.

Ya que estos secretos se convierten en variable de entorno, no te quedas limitado a las acciones. Por ejemplo, tu framework de pruebas podría recibir las credenciales para un base de datos ya existente para guardar los resultados de tus pruebas, entonces podrías enviar estos secretos mediante una acción npm test.

Env

Env es otra opción dentro del editor gráfico que básicamente hace lo mismo que Secrets, pero omite todos los malabares de encriptar tu información. No es un gran problema, ya que la información no sensible podría ser almacenada en un archivo .env dentro del mismo repositorio.

Mis reflexiones sobre GitHub Actions

GitHub Actions no está haciendo nada novedoso. Hay docenas si no cientos de soluciones disponibles ya sea comerciales o gratuitas que hacen lo mismo que hace Actions. Incluso GitHub tiene toda una categoría de marketplace para la automatización de tareas para tu repositorio.

Sin embargo, personalmente nunca he tenido tan buena experiencia de usuarios configurando una canalización de CI/CD. GitHub actions no está reinventando la rueda, solo la está haciendo más económica.

Como desarrolladores, siempre tenemos que encontrar el balance entre simplicidad de uso y cuántas funcionalidades queremos agregarle a algo. El eternos dilema entre usar la terminal de Git o su interfaz gráfica. Por otra parte, GitHub está súper consciente de lo que el mercado tiene disponible y que ellos no están tratando de ser competidores de los grandes. No, no te vas a deshacer de Jenkins, Circle o cualquier otra solución que tu organización esté ya usando. Pero si tienes un pequeño proyecto propio, definitivamente vale la pena darle una chance con GitHub Actions.

Contribuye

Todo el código para éste artículo es abierto y disponible en https://github.com/pedsm/tryGithubActions. Si deseas registrar algún issue y agregar tu usuario de GitHub al proyecto, siéntete libre de crear un PR.

Traducido del artículo de Pedro Mendonça - A first look at GitHub Actions with Heroku de Pedro Mendonça

Siendo esta la 238,947,234 vez y probablemente última vez que cambiaré mi nombre de usuario (el matrimonio es permanente, ¿verdad?), pensé que sería mejor escribir un post rápido sobre cómo se puede lograr esta transición de la manera más fluida posible. La siguiente es una guía rápida de algunas cosas a considerar después.

Donde hacer cambios

1. Cambia tu nombre de usuario haciendo clic en Change username en las opciones de tu cuenta de GitHub.
2. Si usas GitHub Pages, cambia el nombre de tu repositorio “nombredeusuario.github.io”.
3. Si usas otros servicios que apunten a tu dirección de repositorio "nombredeusuario.github.io", actualízalos.
4. Si usas Netlify, es posible que desees iniciar sesión y volver a conectar tus repositorios.
5. Inicia sesión en Travis CI y otras integraciones, encuéntralas en la pestaña (Settings -> Integrations) de tu repositorio. Esto actualizará tu nombre de usuario allí.
6. Actualiza tus archivos locales y enlaces de repositorio usando muy cuidadosamente comandos find y sed, empujando luego los cambios a GitHub.
7. Relanza cualquier sitio web que puedas tener con tu enlace de GitHub actualizado.
8. Corrige cualquier enlace en la web hacia tu perfil, tus repositorios, o Gists que hayas compartido.

Actualización de archivos locales

Aquí hay algunas sugerencias de cadenas para buscar y reemplazar tu nombre de usuario.

• github.com/nombredeusuario (Referencias a tu página de GitHub en READMEs o en la copia del sitio web)
• nombredeusuario.github.io (Enlaces a tu página de GitHub)
• git@github.nombredeusuario (URL ssh remotas de configuración de Git)
• travis-ci.com/nombredeusuario(Insignias de Travis en READMEs)
• shields.io/github/.../nombredeusuario(Insignias Shields en READMEs, incluyen contribuyentes, estrellas, etiquetas, y más)

Puedes identificar rápidamente dónde se encuentran las cadenas anteriores utilizando este comando para cada cadena:

grep -rnw -e 'foobar'

Esto buscará recursivamente (r) todos los archivos para cadenas que coincidan con todo (w) el patrón (e) proporcionado y antepondrá los resultados con los números de línea (n) para que puedas encontrarlos fácilmente.

Usando find y sed puedes hacer estos cambios mucho más rápido. Consulta este artículo sobre buscar y reemplazar .

¡Disfruta tu nuevo nombre! (Espero que este haga click contigo.)

Traducido del artículo de Victoria Drake - A quick guide to changing your GitHub username