Chemaclass - git

Commits de Git Verificados

2024-11-17T00:00:00+00:00

En desarrollo de software, la confianza y la seguridad son clave. Una forma fácil de mejorar ambas: usar commits verificados.

Ya trabajes en open-source o en una empresa privada, los commits verificados aseguran que tus contribuciones son legítimas. Veamos qué son, por qué importan y cómo empezar a usarlos.

¿Qué son los commits verificados? #

Un commit verificado es un commit de Git firmado digitalmente por su autor. La firma demuestra que el commit viene de quien dice haberlo hecho. Herramientas como GPG (GNU Privacy Guard) permiten adjuntar esta firma.

En plataformas como GitHub verás una insignia “Verified” junto a los commits firmados. Es una forma rápida de mostrar que el commit es auténtico.

¿Por qué son importantes? #

Los commits firmados mantienen tus contribuciones auténticas y confiables. La firma criptográfica demuestra que los cambios vinieron de ti. En entornos colaborativos, donde la confianza y la responsabilidad importan mucho, esto es clave.

Sin firmar, cualquiera puede falsificar un commit usando tu email. GitHub lo vincularía a tu perfil, pareciendo que hiciste los cambios aunque no fuera así. Nada bueno.

Al firmar tus commits, demuestras que el trabajo es tuyo. Evitas la suplantación, generas confianza y mantienes todo transparente.

Nota: Para esta demo, usé un email público de Linus Torvalds. Al hacer push, GitHub reconoció el email y lo vinculó a su perfil. Suplantación solo con fines de demo para mostrar los riesgos. Usa siempre tu propio email para commits.

Cómo empezar con commits verificados #

Configura una clave GPG #

Primero necesitas una clave GPG. Así se hace:

Genera una clave GPG:

gpg --full-generate-key

Encuentra tu ID de clave:

gpg --list-secret-keys --keyid-format=long

Dile a Git que use tu clave:

git config --global user.signingkey <tu-id-de-clave>

Haz que firmar commits sea el valor por defecto:

git config --global commit.gpgsign true

Añade tu clave a GitHub/GitLab #

Exporta tu clave pública:

gpg --armor --export <tu-id-de-clave>

Navega a “Settings > SSH and GPG keys,” y pega tu clave.

Empieza a firmar commits #

A partir de ahora, Git firmará tus commits automáticamente.

Si quieres firmar un commit a mano, usa la bandera -S:

git commit -S -m "Tu mensaje de commit"

Puedes verificar la firma del commit con:

git log --show-signature

También puedes hacer clic en la insignia “Verified” en GitHub.

Los commits verificados parecen un paso pequeño, pero hacen tu código más confiable. Una capa extra de protección fácil de añadir. Pruébalo.

Extra: Configuración completa en español #

Enlaces relacionados

Aprende más: ¿Qué es el cifrado PGP? Un tutorial de 3 minutos para principiantes

Software de Código Abierto

2021-05-03T00:00:00+00:00

Cada proyecto que publicas se apoya en software de código abierto. Tu framework, tu test runner, tu compilador, la pequeña librería en la que nunca piensas.

Lo usas cada día. La pregunta de verdad es si alguna vez devuelves algo.

Devolver no es caridad. Es una de las formas más rápidas de crecer como desarrollador.

¿Qué es OSS? #

El código abierto no es lo mismo que el software libre. El software libre es una forma de código abierto, pero el código abierto no tiene por qué ser gratis. Dos ejemplos marcan la línea. PHPUnit es código abierto y gratuito. Spryker es código abierto y de pago. Ambos publican su código para que cualquiera lo lea.

OSS es software público, abierto al mundo.

Beneficios #

Dos grupos ganan con el código abierto: las empresas que lo publican, y la gente que contribuye.

Para empresas #

El acceso abierto impulsa la adopción. Cuanto más fácil es conseguir el código, más rápido construye la gente sobre él. La formación y los tutoriales atraen a los que empiezan y hacen crecer el ecosistema. El código suele estar en la vanguardia, porque el software que se queda quieto se vuelve obsoleto. Un proyecto público reúne una comunidad a su alrededor, y los canales públicos hacen fácil unirse a ella.

Y como cualquiera puede leer el código, cualquiera puede comprobar su calidad. Esa confianza no se puede fingir.

Para contribuidores individuales #

Tú eliges en qué trabajas. Practicas habilidades reales sin la presión de una caída en producción. Puedes jugar con las últimas novedades de tu lenguaje, o probar un lenguaje que nunca has tocado.

También afilas las habilidades blandas que sostienen una carrera: escribir con claridad, explicar un cambio, mantener tu postura cuando la gente no está de acuerdo.

El código enseña las habilidades técnicas. Los desacuerdos enseñan el resto.

Contribuyendo a OSS #

Empezando con GitHub #

Empezar es fácil, y tienes dos puertas. Abrir tu propio proyecto, o contribuir a uno que ya existe. Un proyecto personal encaja perfectamente en la primera puerta.

Proyectos personales #

Un proyecto personal es un terreno de juego para crear software real y entrenar habilidades reales. Ponlo en tu perfil público de GitHub y tienes todos los beneficios de contribuir a OSS, más uno: no le respondes a nadie. Tú marcas la hoja de ruta. Tú decides qué construir y cómo. Eres tu propio jefe.

El proyecto está ahí para ti. Tú eres responsable de jugar, explorar y superar tus límites.

Mis proyectos personales #

Activos:

agnostic-ai: escribe agents, skills, rules y hooks de IA una vez, úsalos en cada CLI de IA.
bashdep: un gestor de dependencias sencillo para Bash.
phel-snake: el juego de la serpiente en tu terminal, escrito en Phel.
edifact-parser: un parser para formato de archivo UN/EDIFACT en PHP.
unspent: una librería PHP para contabilidad tipo UTXO con entradas no gastadas.

Inactivos:

create-pr: un script de Bash para abrir un pull request desde tu rama y contexto.

Abandonados:

stock-ticker: recibe una notificación con las noticias de tus Tickers favoritos.
jira-status-notifier: notifica cuando los tickets de JIRA no avanzan.
php-best-practices: lo que consideraba mejores prácticas para desarrollo web (archivado).
php-scaffolding: un scaffolding básico de PHP con Docker (archivado).
knob-mvc: un framework para crear plantillas WordPress (2015/2017).

… y muchos más en github.com/Chemaclass

Mis contribuciones a organizaciones OSS #

Activas:

phel-lang: Phel es un lenguaje de programación funcional que compila a PHP. Es un dialecto de Lisp inspirado en Clojure y Janet. Ya escribí un post sobre esto: Phel: Un Lisp que compila a PHP
gacela-project: Gacela es un framework PHP que te ayuda a mejorar el diseño de tu aplicación dividiendo la lógica en diferentes módulos.

Abandonadas:

nm_template: La plantilla base para NuevaMetal (2013-2016).

Compartir Conocimiento e Impacto #

El código es solo la mitad. La otra mitad es lo que escribes y le entregas a la siguiente persona.

Posts del blog #

… y muchos más en https://chemaclass.com/es/blog/

La belleza del OSS #

Contribuye en público el tiempo suficiente y empiezas a ver tu propio crecimiento. Las correcciones que sigues haciendo. El código que escribiste el año pasado, ya envejecido. Los errores, todos ellos, a la vista. Y por debajo, la prueba lenta de que estás mejorando.

Vas desarrollando un sexto sentido para detectar patrones que ya has visto, los buenos y los dolorosos.

Muestra tus habilidades. Ayuda a la gente a tu alrededor. Eso es trabajar con la puerta del garaje abierta.

El Software de Código Abierto te ofrece una de las mejores oportunidades para empezar a construir una carrera hacia la mejora continua.

Esta es una charla (en español) que hice de forma remota en abril de 2021, para la Comunidad PHPMad Madrid. Presento todas estas ideas junto con una demo en vivo de cómo contribuir a un OSS real.

Compartiendo tus Parches de Git

2020-12-01T00:00:00+00:00

Descubre otra forma de compartir sugerencias con tu equipo de desarrollo.

Imagina esta situación #

Estás revisando un Pull Request (PR), y ves algunas mejoras menores o sugerencias que te gustaría compartir con el autor. Podrías escribir algunos comentarios, y normalmente, eso sería suficiente.

Imagina que para transmitir tu “idea completa” necesitarías cambiar algunos archivos porque simplemente comunicar la imagen completa acabará en un comentario enorme que podría no ser tan claro como podría ser.

¿Qué posibilidades hay aparte de solo comentarios en un PR? #

Bueno, hay múltiples opciones. La clave es ser consciente de ellas y usarlas sabiamente dependiendo de la prioridad de la tarea y los cambios en sí:

Como ya se mencionó, escribir un comentario como retroalimentación es una buena idea por defecto, pero no la única.
Siempre podemos hacer algo de pair-thinking, hablar en cualquier momento. La comunicación siempre es buena para aclarar la posible incertidumbre.
Compartir tus parches de git es otra buena opción.

¡Git diff al rescate! #

¿Y si tú (como revisor) pudieras compartir tu idea sin ningún commit o comentario en el PR, pero compartiendo tus cambios directamente con el autor?

Bueno, eso es realmente posible y muy fácil. Como ya sabes, el comando git diff te da las diferencias entre dos ramas cualesquiera.

git diff origin develop > ../my-origin-develop.patch

Lo que estamos haciendo aquí es redirigir la salida del comando diff a un archivo (también conocido como: parche), para poder compartir esa salida con cualquier otro compañero de equipo.

¿Y ahora qué? #

Bueno, teniendo ese archivo de parche, es bastante fácil aplicar esos cambios en tu máquina local sin hacer ningún commit:

git apply ../my-origin-develop.patch

Aplicar este parche simplemente cambiará tu sistema local de la misma manera que se creó el parche.

“Cómo hacerlo” por pasos #

Dividamos las responsabilidades en dos: el creador del parche y su usuario:

El creador del parche: la persona que creará el parche #

# Cambia a esa rama
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Haz tus sugerencias y cambios en la rama objetivo
# Genera el archivo de parche usando el comando diff
$ ~/myProject git:(the-branch) ➜ git diff > ../your-diff.patch
# Comparte el archivo de parche con el autor del PR

El usuario del parche: la persona que verá el parche #

# Asegúrate de estar en esa rama
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Aplica el archivo de parche
$ ~/myProject git:(the-branch) ➜ git apply ../your-diff.patch

Referencias #

Documentación oficial de “git apply”