"Si he visto más lejos que otros, es por pararme en hombros de gigantes" — Isaac Newton

En 1676, Isaac Newton habló de los grandes pensadores que le precedieron como "gigantes". Sus ideas le ayudaron a descubrir nuevas ideas propias.

345 años después, los gigantes son mucho más altos. Están por todas partes, no sólo en los libros, como en la época de Newton. Están en revistas académicas abiertas. En proyectos de código abierto. Conjuntos de datos abiertos.

Con una conexión a Internet, puedes pararte en los hombros de todos los gigantes que quieras.

Pero la mayoría de la gente no se da cuenta de todo lo que vería si se molestara en subir. La mayoría de la gente piensa que puede ver lo suficiente desde donde ya está parado. La subida no parece que valga la pena.

Antes de pararte en los hombros de gigantes, hay que aceptar que no ves todo. Tienes que reconocer lo mucho que hay ahí fuera y que solo esos gigantes pueden mostrarte.

Ubuntu

"Soy lo que soy por lo que somos todos." — Traducción al español de la palabra Zulú "Ubuntu"

Incluso en la oscuridad de la prehistoria humana, empezamos a descubrir algunas cosas interesantes.

Comenzaron a surgir los gigantes, montados en la tradición oral. Luego los libros.

Hemos acumulado conocimientos sobre conocimientos. Y los gigantes crecieron.

A lo largo de los eones, descubrimos algunas ideas muy buenas y construimos algunas cosas muy buenas. Cosas que valen la pena usar.

Pero cada día, miles de personas ignoran estas cosas. Dicen: "Ya sé, voy a construir esta nueva cosa desde cero".

Y se embarcan en un costoso viaje para construir sus sueños desde cero.

Gastamos mucho dinero en software. Alrededor del 60% de los 2.5 billones de dólares que gastamos en tecnología cada año se destina al desarrollo de software y a los servicios de consultoría de software.

Eso es un billón y medio de dólares. Suficiente para adquirir Instagram 1,500 veces. Cada año.

Y no siempre obtenemos el valor de nuestro dinero.

No inventado aquí (Not invented here)

Los humanos tenemos un exceso de confianza. Creemos que podemos reinventar la rueda y que nuestra versión será mejor.

Quién sabe, tal vez la rueda pueda mejorarse. Pero si tratamos de diseñar algo más complicado, como un coche, ¿realmente queremos pasar todo el tiempo reinventando ruedas?

Está en nuestra naturaleza querer construir las cosas nosotros mismos.

Nos encantan los productos integrados verticalmente, como los Ferraris, los Rolex y los iPhones.

Admiramos el trabajo artesanal que se realiza en cada detalle.

Nos maravilla cómo el diseño, la fabricación y la distribución fluyen juntos en un proceso controlado.

Y también queremos toda esa pila para nosotros.

Pero al hacerlo, caemos presa de una mentalidad paralizante llamada "No inventado aquí".

"El síndrome 'No inventado aquí' es la tendencia de un grupo de proyecto a creer que posee el monopolio del conocimiento de su campo, lo que le lleva a rechazar nuevas ideas de personas ajenas a él, en probable detrimento de su rendimiento." — Ralph Katz y Thomas J. Allen, de la Sloan School of Management del MIT

Aquí está el PDF del artículo más citado sobre Not Invented Here (publicado originalmente en 1982), por si quieres informarte sobre la gravedad de sus conclusiones.

Lo que no dice este documento es que, 39 años después, seguimos cayendo en el mismo sesgo cognitivo de siempre.

Un ejemplo reciente de No inventado aquí es la plataforma de cursos en línea Swayam, de la India. Podrían haberse limitado a construir sobre la plataforma de cursos de código abierto de edX de forma gratuita. Decenas de otras organizaciones lo hicieron, incluida la popular plataforma china XuetangX.

En su lugar, Swayam gastó 6 millones de dólares en construir una plataforma propia. Y gastarán millones más en los próximos años para mantener esta solución personalizada.

Puede que no parezca mucho dinero, pero pon esa cifra en el contexto de los 30 millones de dólares que se presupuestaron para pagar a los profesores que crearon los cursos. Y esto también retrasó su fecha de lanzamiento en dos años.

No inventado aquí comienza de forma bastante inocente...

"¿Por qué deberíamos usar WordPress para nuestro blog? Los blogs no son difíciles. Construyamos nuestro propio CMS".

Entonces la gente se pone más atrevida y empieza a pensar...

"¿Por qué deberíamos usar Sugar CRM para hacer un seguimiento de los donantes? El seguimiento de los donantes no es difícil. Construyamos nuestro propio CRM".

Lo que sólo anima a la gente a proponer cosas como:

"¿Por qué deberíamos usar AWS? La nube no es difícil. Construyamos nuestro propio centro de datos e implementemos nuestra propia nube privada".

Si no se controla, esta mentalidad puede conducir a proyectos como HealthCare.gov, un proyecto de 90 millones de dólares que acabó costando 1,700 millones a los contribuyentes estadounidenses.

Yo fui uno de los millones de personas que perdieron horas de su vida intentando contratar un seguro médico, sólo para verme frustrado por errores de JavaScript y servidores que no responden.

En medio del colapso de Healthcare.gov, tres desarrolladores de San Francisco decidieron tomar algunos componentes disponibles. Integraron algunas APIs públicas. Construyeron partes importantes de la funcionalidad de Healthcare.gov. Y lo hicieron en unas pocas semanas, por unos pocos cientos de dólares.

Una historia de pararse en los hombros de gigantes. La mía.

Hace siete años, quise crear una comunidad en la que las personas ocupadas pudieran aprender a programar juntas.

Acababa de pasar 18 meses construyendo una enorme solución a la medida: un motor de recomendación de cursos que resultó que nadie quería usar.

Así que decidí ir en la dirección opuesta. Escribiría tan poco código como fuera necesario y me centraría en utilizar el código de otras personas.

¿Qué necesitaba la comunidad?

1. Una forma de comunicarse entre sí
2. Un blog en el que todos pudieran compartir sus ideas e historias personales
3. Un plan de estudios y una forma de seguir el progreso de las personas a través de él

El viejo "no inventado aquí" de mí habría hecho lo siguiente:

1. Construí una sala de chat usando web sockets, luego construí las herramientas de moderación, varias integraciones de API, y descubrí una buena manera de persistir los mensajes a través de las sesiones.
2. Construí un blog desde cero, me ocupé de cuestiones de diseño como la legibilidad, el etiquetado, la incrustación y las funciones básicas que la gente espera, como RSS.
3. Construí un CMS personalizado para los retos de programación interactivos, luego construí el sistema de perfiles, y después diseñé e implementé un plan de estudios de programación básico.

Este último paso probablemente me habría llevado años hacerlo por mi cuenta.

Y antes de que me digas "en estos tiempos, nadie es tan tonto como para crear su propio blog"... pues parece que yo sí lo fui, porque pasé unos días haciéndolo. Unos días que nunca recuperaré.

Pero esto es lo que el nuevo yo — recién salido de un descenso de 18 meses al infierno de no inventado aquí — decidió hacer.

En ese momento no conocía Node.js. Pero conocía a gente inteligente que me convenció de que el full Stack JavaScript era el futuro.

También conocía el Hackathon Starter, un popular boilerplate de Node.js de código abierto. Así que hice un fork de él.

Como me había pasado los últimos 18 meses recopilando, auditando y clasificando miles de cursos en línea, sabía cuáles eran los que mejor cubrían la programación y la informática. Así que, en lugar de diseñar un plan de estudios, he seleccionado los recursos existentes.

Para la sala de chat, sólo usé HipChat. Para el blog, sólo usé Blogger.

Y en 3 días, la nueva comunidad estaba en marcha.

Es difícil predecir cómo evolucionará una solución con el tiempo. Se aprende mucho cuando se manda a producción la maldita cosa.

Si empiezas inmediatamente a utilizar soluciones estándar, puedes cambiarlas más tarde y ajustar las cosas sobre la marcha.

Con el tiempo, nuestra comunidad ha hecho miles de pequeños ajustes basados en los comentarios. También hemos trasladado nuestras salas de chat a Gitter y el blog de nuestra comunidad a Medium.

Una vez que tuvimos una masa crítica de colaboradores de código abierto, nos pusimos a trabajar en el diseño e implementación de nuestro propio plan de estudios de 1,200 horas.

Hoy, más de 5,000 personas de nuestra comunidad han aprendido a programar lo suficientemente bien como para conseguir sus primeros trabajos de desarrollador.

Pero si no me hubiera resistido a mis tendencias de "No inventado aquí", nunca habría conseguido que las cosas despegaran.

Cómo pararte en los hombros de gigantes

Te dejo con tres sencillos consejos para aprovechar al máximo los miles de años de conocimientos que tienes a tu alcance.

Consejo #1: Aprende a reconocer el "No inventado aquí" en ti mismo y en los demás.

Aceptar que está en nuestra naturaleza querer construir cosas por nosotros mismos. El lado luminoso de esto es un aficionado que construye sus propios muebles. El lado oscuro es un desarrollador que lanza su propia seguridad.

Consejo #2: Conoce las herramientas que existen.

La forma más fácil de entender qué tipos de herramientas están disponibles es seguir haciendo lo que estás haciendo ahora mismo: leer sobre tecnología.

La mayoría de los principales proyectos de código abierto están en GitHub, donde puedes ver su documentación. Puedes desplegar muchas de estas herramientas en minutos en tu propio servidor en la nube.

Consejo #3: Lee sobre historia.

Seguro que tu profesor de historia de la preparatoria te citó esto, y tenía razón:

"Los que no leen sobre historia están condenados a repetirla". — George Santayana en 1905

Hay muchos libros excelentes sobre la historia de la tecnología. Recomiendo este de Walter Isaacson, el mismo que escribió las famosas biografías de Albert Einstein y Steve Jobs. Trata específicamente de la historia del software:

The Innovators: How a Group of Hackers, Geniuses, and Geeks Created the Digital Revolution

Los gigantes están deseando subirte a sus hombros. Déjalos. Te darán una visión de cuántos problemas hay todavía ahí fuera, esperando que vayas a resolverlos.

Sólo escribo sobre programación y tecnología. Si me sigues en Twitter no te haré perder el tiempo. ?

Podrías pensar que una herramienta tan "vieja" tienes sus mejores días detrás de ella, pero estarías lejos de estar en lo cierto. En 2019, a través de la encuesta de Scale Grid DeveloperWeek, SQL fue utilizado por el 60.5% de los encuestados, mientras que NoSQL fue utilizado por solo el 39.5% de los encuestados.

Para ser claros, la categoría SQL se dividió en varias subcategorías que incluían MySQL, PostgreSQL, SQL Server, etc., mientras que la categoría NoSQL se dividió en subcategorías que contenían MongoDB, Cassandra, etc.

Incluso en 2017, según la Stack Overflow Developer's Survey, el segundo lenguaje más utilizado fue SQL (justo detrás de JavaScript) con el 50% de los 64,000 encuestados diciendo que todavía utilizan SQL en alguna forma.

Su popularidad se debe, al menos en parte, a la simplicidad del lenguaje, al hecho de que fue construido con datos relacionales en mente, y porque ha demostrado ser fiable para buscar, unir y filtrar datos.

Basta con decir que SQL no sólo está vivito y coleando, sino que prospera entre la comunidad de desarrollo de hoy en día.

¡Ahora vamos a ver por qué!

Las partes divertidas

SQL Server es el sabor preferido de SQL que utilizo en mis actividades cotidianas en el trabajo, por lo que los ejemplos siguientes se ajustarán a esas normas.

Una de las cosas que más me gusta hacer es actualizar varios registros dentro de una tabla. Ahora podría hacer este registro de uno en uno, pero SQL nos da la capacidad de actualizar múltiples (miles y miles si es necesario) registros a la vez a través de la declaración UPDATE.

La declaración UPDATE puede utilizarse para actualizar una sola columna, un conjunto más amplio de registros (mediante el uso de condiciones), y/o toda la tabla en una base de datos. La(s) condición(es) puede(n) ser un booleano, una verificación de cadena de texto o una secuencia matemática que se resuelve en un booleano (mayor que, menos que, etc.).

Aunque puede variar ligeramente de un sabor a otro, la sintaxis general es la siguiente:

UPDATE nombre-de-la-tabla
SET nombre-de-la-columna = valor[, nombre-de-la-columna=valor]
[WHERE condición]

Los corchetes ( [] ) de arriba denotan adiciones opcionales a la consulta.

***Es muy importante tener en cuenta que sin la condición de WHERE, TODOS los registros de la tabla se actualizarán tan pronto como se ejecute la consulta.***

Consultas de ejemplo

Como nuestro conjunto de datos, usaré esta tabla llamada Work_Tickets:

Consulta simple sin condiciones

Aquí hay una consulta de actualización muy simple que cambiará todos los campos de UnitCost al número 131.6152:

UPDATE Work_Tickets
SET UnitCost = 131.6152

Nota que no hay cláusula de WHERE, así que cada línea de la tabla se actualizará y nuestro conjunto de datos se verá así:

Consultas simples con condición(es)

Aquí hay una simple consulta con una declaración de condición:

UPDATE Work_Tickets
SET Billed = true
WHERE UnitCost <> 0.00

Esta consulta actualizará el campo de Billed para que sea true en cada línea que coincida con la condición de UnitCost no igual a 0. Después de ejecutar nuestra consulta, el conjunto de datos se verá así:

Abajo hay una consulta en la que cambiamos el ParentLineKey por la cadena 000134 en la que el SalesOrderNum y el WorkTicketNum coinciden con las cadenas dadas.

UPDATE Work_Tickets
SET ParentLineKey = 000134
WHERE SalesOrderNum = 00061358 and WorkTicketNumber = 000933

Así que, el 085569 en el campo ParentLineKey será reemplazado por 000134 y nuestro conjunto de datos ahora se ve así:

Actualizando múltiples campos

Digamos que tienes un conjunto de datos mucho más grande que el que estamos usando actualmente y tienes varios campos para actualizar.

Sería tedioso y aburrido actualizarlos con diferentes declaraciones de actualización. Por suerte para nosotros también es posible actualizar varios campos a la vez con una declaración de actualización (update), siempre y cuando separemos los nombres de las columnas con una coma:

UPDATE Work_Tickets
SET UnitCost = 129.8511, Qty_Ordered = 72, Qty_Shipped = 72
WHERE SalesOrderNum = 00061358

Y aquí está el resultado con los campos actualizados después de ejecutar la consulta:

Usando Update en una subconsulta

Los ejemplos anteriores son perfectos si se trabaja con una sola fuente de datos. Sin embargo, la mayoría de tus datos no se almacenarán en una sola tabla. Ahí es donde el uso de UPDATE con múltiples fuentes de datos es útil.

La sintaxis para actualizar una columna/tabla cambia un poco si queremos traer datos de otra tabla:

UPDATE nombre-de-la-tabla
SET nombre-de-la-columna = (SELECT nombre de columna(s)
FROM nombre-de-la-tabla2
WHERE condición(es))
[WHERE condición]

Y aquí están las dos tablas que usaremos para esta consulta - la tabla Work_Tickets:

y la tabla Customer_Info:

La declaración UPDATE con la subconsulta se ve así:

UPDATE Customer_Info
SET Code = (SELECT Customer_Code
FROM Work_Tickets
WHERE Work_Tickets.Customer_Contact = Customer_Info.Email)
FROM Work_Tickets
WHERE Code IS NULL

Este ejemplo actualizará el campo Code de la tabla Customer_Info donde la dirección de correo electrónico coincide con la de ambas tablas. Y así es como se ve ahora nuestra tabla Customer_Info:

Concluyendo

Espero que este artículo te haya sido útil para entender cómo funciona la declaración UPDATE en SQL.

¡Ahora estás listo para escribir tus propias sentencias SQL UPDATE como un campeón! ¡Después de hacerlo, me encantará que lo compartieras conmigo en redes sociales!

No olvides visitar mi blog donde frecuentemente publico artículos sobre desarrollo web.

Ya que estás allí, ¿por qué no te inscribes en mi boletín de noticias? Puedes hacerlo en la parte superior derecha de la página principal del blog. Me gusta enviar artículos interesantes (míos y de otros), recursos y herramientas para desarrolladores de vez en cuando.

Si tienes preguntas sobre este artículo o en general, mis MDs están abiertos - ven a saludar en Twitter o en cualquiera de mis otras cuentas de redes sociales que puedes encontrar debajo del botón de suscripción del boletín de noticias en la página principal de mi blog o en mi perfil aquí en fCC :)

¡Qué tengas un día increíble y feliz día programando, amigo!

Traducido del artículo de Jonathan Sexton - SQL Update Statement — Example Queries for Updating Table Values

La regla de Simpson es la siguiente:

En ella,

• f(x) es llamado el integrand
• a = es el límite inferior de integración
• b = es el límite superior de integración

La Regla de 1/3 de Simpson

Como se muestra en el diagrama anterior, el integrando f(x) es aproximado por un polinomio de segundo orden, el interpolante cuadrático es P(x).

Sigue la aproximación,

Reemplazando (b-a)/2 como h, obtenemos,

Como puedes ver, hay un factor de 1/3 en la expresión anterior. Por eso, se llama la Regla de 1/3 de Simpson.

Si una función es altamente oscilatorio o carece de derivados en ciertos puntos, entonces la regla anterior puede no producir resultados precisos.

Una forma común de manejar esto es usando el enfoque de la regla compuesta de Simpson. Para ello, dividir [a,b] en pequeños subintervalos, y luego aplicar la regla de Simpson a cada subintervalo. Luego, sumar los resultados de cada cálculo para producir una aproximación sobre la integral completa.

Si el intervalo [a,b] se divide en n subintervalo, y n es un número par, la regla compuesta de Simpson se calcula con la siguiente fórmula:

donde x_j = a+jh para j = 0,1,…,n-1,n con h=(b-a)/n ; en particular, x₀ = a y x_n = b.

Ejemplo en C++:

Para aproximar el valor de la integral dada abajo donde n = 8:

#include<iostream>
#include<cmath>
using namespace std;

float f(float x)
{
	return x*sin(x);	//Define la función f(x)
}

float simpson(float a, float b, int n)
{
	float h, x[n+1], sum = 0;
	int j;
	h = (b-a)/n;
	
	x[0] = a;
	
	for(j=1; j<=n; j++)
	{
		x[j] = a + h*j;
	}
	
	for(j=1; j<=n/2; j++)
	{
		sum += f(x[2*j - 2]) + 4*f(x[2*j - 1]) + f(x[2*j]);
	}
	
	return sum*h/3;
}

int main()
{
	float a,b,n;
	a = 1;		//Ingresa el límite inferior a
	b = 4;		//Ingresa el límite superior b
	n = 8;		//Ingresa la longitud del intervalo n
	if (n%2 == 0)
		cout<<simpson(a,b,n)<<endl;
	else
		cout<<"n debería ser un número par";
	return 0;
}

La Regla de 3/8 de Simpson

La regla de 3/8 de Simpson es similar a la regla de 1/3 de Simpson, con la única diferencia de que, para la regla de 3/8, el interpolante es un polinomio cúbico. Aunque la regla de 3/8 utiliza un valor de función más, es aproximadamente dos veces más precisa que la regla de 1/3.

La regla de 3/8 de Simpson establece:

Reemplazando (b-a)/3 como h, obtenemos,

La regla de 3/8 de Simpson para n intervalos (n debería ser un múltiplo de 3):

donde x_j = a+jh para j = 0,1,…,n-1,n con h=(b-a)/n; en particular, x₀ = a y x_n = b.

Traducido del artículo - Simpson's Rule: the Formula and How it Works

Git Merge

El comando git merge fusionará cualquier cambio que se haya hecho en la base de código en una rama separada de tu rama actual como un nuevo commit.

La sintaxis del comando es la siguiente:

git merge NOMBRE-DE-LA-RAMA

Por ejemplo, si estás trabajando actualmente en una rama llamada dev y deseas fusionar los nuevos cambios que se hayan realizado en una rama llamada new-features, ejecutarías el siguiente comando:

git merge new-features

Nota: Si hay algún cambio al que no se le ha hecho commit en la rama actual, Git no te permitirá fusionar hasta que se hayan realizado commit todos los cambios en tu rama actual. Para manejar esos cambios, puedes hacer lo siguiente:

Crear una nueva rama y realizar commit a los cambios

git checkout -b nombre-de-la-nueva-rama
git add .
git commit -m "<tu mensaje de commit>"

Guardarlos en el stash

git stash               # agregarlos al stash
git merge new-features  # fusionarlos
git stash pop           # obtén los cambios devuelta al árbol de trabajo (working tree)

Abandonar todos los cambios

git reset --hard        # remueve todos los cambios pendientes

Git Rebase

Realizar un rebase a una rama (branch) en Git es una form ade mover la totalidad de una rama a otro punto del árbol. El ejemplo más simple es mover una rama más arriba en el árbol. Digamos que tenemos una rama que se separó de la rama master en el punto A:

        /o-----o---o--o-----o--------- branch
--o-o--A--o---o---o---o----o--o-o-o--- master

Cuando se realiza rebase se puede mover así:

                                   /o-----o---o--o-----o------ branch
--o-o--A--o---o---o---o----o--o-o-o master

Para realizar rebase, asegúrate de tener todos los commits que quieras en el rebase en tu rama master. Revisar la rama en la que quieres hacer el rebase y escribe git rebase master (donde master es la rama en la que quieres hacer el rebase).

También es posible hacer rebase en una rama diferente, de modo que, por ejemplo, una rama que se basaba en otra rama (llamémosla feature) se rebasa en master:

                            /---o-o branch
           /---o-o-o-o---o--o------ feature
----o--o-o-A----o---o--o-o-o--o--o- master

Después de git rebase master branch o git rebase master si te encuentras (checked out) en branch, obtendrás:

           /---o-o-o-o---o--o------ feature
----o--o-o-A----o---o--o-o-o--o--o- master
                                  \---o-o branch

Git rebase interactivo en la consola

Para usar git rebase en la consola con una lista de commits, puedes elegir, editar o soltar en el rebase:

• Introduce git rebase -i HEAD~5 con el último número que sea cualquier número de commits del más reciente hacia atrás que quieras revisar.
• En vim, presiona esc, luego i para empezar a editar la prueba.
• A la izquierda puedes sobreescribir pick con uno de los comandos de abajo. Si quieres aplastar (squash) un commit a uno anterior y descartar el mensaje de commit, introduce f en lugar de pick en el commit.
• Guarda y sal del editor de texto.
• Cuando se detiene a rebase, haz los ajustes necesarios, y luego usa git rebase --continue hasta que el rebase sea exitoso.
• Si el rebase es exitoso, entonces necesitas forzar el push de tus cambios con git push -f para agregar la versión con rebase a tu repositorio remoto.
• Si hay un "merge conflict" (conflicto al querer fusionar las ramas), hay varias maneras de arreglarlo, incluyendo seguir las sugerencias de esta guía. Una forma es abrir los archivos en un editor de texto y eliminar las partes del código que no quieras. Luego usa git add <file name> seguido de git rebase --continue. Puedes saltarte el commit de conflicto ejecutando git rebase --skip, para el rebase ejecutando git rebase --abort en tu consola.

pick 452b159 <message for this commit>
pick 7fd4192 <message for this commit>
pick c1af3e5 <message for this commit>
pick 5f5e8d3 <message for this commit>
pick 5186a9f <message for this commit>

# Rebase 0617e63..5186a9f onto 0617e63 (30 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but stop to edit the commit message.
# e, edit = use commit, but stop to amend or add commit.
# s, squash = use commit, meld into previous commit and stop to edit the commit message.
# f, fixup = like "squash", but discard this commit's log message thus doesn't stop.
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom. 
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

Merge Conflicts

Un merge conflict es cuando realizar commits en ramas separadas que alteran la misma línea de manera conflictiva. Si esto ocurre, Git no sabrá que versión del archivo guardar en un mensaje de error similar al siguiente:

CONFLICT (content): Merge conflict in resumé.txt Automatic merge failed; fix conflicts and then commit the result.

Si miras el archivo resumé.txt en tu editor de texto, puedes ver dónde tuvo lugar el conflicto:

<<<<<<< HEAD
Address: 808 South Street
=======
Address: 505 North Street
>>>>>>> updated_address

Git agregó algunas líneas adicionales en el archivo:

• <<<<<<< HEAD
• =======
• >>>>>>> updated_address

Piensa en  ======= como la línea divisoria del conflicto. Todo lo que hay entre <<<<<<< HEAD y ======= es el contenido de la rama actual a la que apunta HEAD ref. Por otro lado, todo lo que hay entre  ======= y >>>>>>> updated_address es el contenido de la rama que se está fusionando, updated_address.

Git Merge vs Git Rebase

Tanto git merge como git rebase son comandos muy útiles, y uno no es mejor que el otro. Sin embargo, hay algunas diferencias muy importantes entre los dos comandos que tú y tu equipo deben tener en cuenta.

Cada vez que se ejecuta git merge, se crea un merge commit extra. Siempre que trabajes en tu repositorio local, tener demasiados merge commits puede hacer que el historia del commits parezca confuso. Una forma de evitar el merge commit es usar git rebase en su lugar.

git rebase es una característica muy poderosa. Dicho esto, también es arriesgado si no se usa de la manera correcta. git rebase altera el historial de commits, así que úsalo con cuidado. Si el rebase se hace en el repositorio remoto, entonces puede crear muchos problemas cuando otros desarrolladores intentan sacar los últimos cambios de código del repositorio remoto. Recuerda que sólo debes ejecutar git rebase en un repositorio local.

Eso es todo lo que necesitas saber para merge y rebase con lo mejor de ellos.

Traducido del artículo - The Ultimate Guide to Git Merge and Git Rebase

Esta funcionalidad es útil cuando has hecho cambios en una rama que no estás listo para realizarle commit, pero necesitas cambiar a otra rama.

Guardar cambios en el stash

Para guardar tus cambios en el stash, ejecuta el comando:

git stash save "mensaje opcional para ti"

Esto guarda los cambios y revierte el directorio de trabajo a como se veía en tu último commit. Los cambios guardados están disponibles en cualquier rama de ese repositorio.

Ten en cuenta que los cambios que quieras guardar deben estar en los archivos rastreados. Si has creado un nuevo archivo e intentas guardar tus cambios, puede que obtengas el error No local changes to save (No hay cambios locales que guardar).

Ver los cambios guardados en el stash

Para ver lo que hay en tu stash, ejecuta el comando:

git stash list

Esto devuelve una lista de tus capturas guardadas en el formato stash@{0}: RAMA-STASHED-CAMBIOS-SON-PARA: MESSAGE. La parte de stash@{0} es el nombre del stash, y el número en las llaves ({ }) es el índice (index) del stash. Si tienes múltiples conjuntos de cambios guardados en stash, cada uno tendrá un índice diferente.

Si olvidaste los cambios que hiciste en el stash, puedes ver un resumen de ellos con el comando git stash show NOMBRE-DEL-STASH. Si quieres ver el típico diseño "diff" (con los + y - en las líneas con los cambios), puedes incluir la opción -p (para parche o patch). Aquí tienes un ejemplo:

git stash show -p stash@{0}

# Ejemplo de un resultado:
diff --git a/PathToFile/fileA b/PathToFile/fileA
index 2417dd9..b2c9092 100644
--- a/PathToFile/fileA
+++ b/PathToFile/fileA
@@ -1,4 +1,4 @@
-What this line looks like on branch
+What this line looks like with stashed changes

Recuperar Cambios en Stash

Para recuperar los cambios del stash y aplicarlos a la rama actual en la que estás, tienes dos opciones:

1. git stash apply NOMBRE-DEL-STASH aplica los cambios y deja una copia en el stash
2. git stash pop NOMBRE-DEL-STASH aplica los cambio y elimina los archivos del stash

Puede haber conflictos cuando se aplican los cambios. Puedes resolver los conflictos de forma similar a un merge (ver git merge para más detalles).

Borrar los Cambios Guardados en Stash

Si quieres remover los cambios guardados en stash sin aplicarlos, ejecuta el comando:

git stash drop NOMBRE-DEL-STASH

Para limpiar todo del stash, ejecuta el comando:

git stash clear

Traducido del artículo - Git Stash Explained: How to Temporarily Store Local Changes in Git

Los commits están en el corazón del uso de Git. Puedes pensar en un commit como una captura de tu proyecto, donde se crea una nueva versión de ese proyecto en el repositorio actual. Dos características importantes de los commits son:

• puedes recordar los cambios a los que se les hizo commits en una fecha posterior, o revertir el proyecto a esa versión (ver Git checkout)
• si varios commits editan diferentes partes del proyecto, no se sobrescribirán entre sí aunque los autores de los commits no se conozcan entre sí. Este es uno de los beneficios de usar Git sobre una herramienta como Dropbox o Google Drive.

Opciones

Hay un número de opciones que puedes incluir con git commit. Sin embargo, esta guía sólo cubrirá las dos opciones más comunes. Para una lista extensa de opciones, por favor consulta la documentación de Git.

La Opción -m

La opción más común utilizada con git commit es la opción -m. La -m significa mensaje. Cuando se llama a git commit, es necesario incluir un mensaje. El mensaje debe ser una breve descripción de los cambios a los que se les está realizando commit. El mensaje debe estar al final del comando y debe estar envuelto entre comilla " ".

Un ejemplo de cómo usar la opción -m:

git commit -m "Mi mensaje"

La salida de tu terminal debería ser algo así:

[master 13vc6b2] Mi mensaje
 1 file changed, 1 insertion(+)

NOTA: Si la -m no está incluida en el comando git commit, se te pedirá que agregues un mensaje en tu editor de texto predeterminado - ve "Uso de mensajes de commit detallados" más abajo.

La Opción -a

Otra opción popular es la opción -a. La -a representa todo (all). Esta opción prepara automáticamente todos los archivos para realizarles commit. Si se agregan nuevos archivos, la opción -a no los preparará. Solo se confirmarán los archivos que el repositorio de Git tenga conocimiento.

Por ejemplo:

Digamos que tienes un archivo README.md que ya se le ha realizado commit en el repositorio. Si haces cambios en este archivo, puedes usar la opción -a en tu comando commit para preparar y agregar los cambios a tu repositorio. Sin embargo, ¿qué pasaría si también agregara un nuevo archivo llamado index.html? La opción -a no pondrá en escena (no lo pondrá en el staging area) el index.html ya que no existe actualmente en el repositorio. Cuando se han agregado nuevos archivos, el comando git add debería ser invocado para preparar los archivos antes de que se les realice commit en el repositorio.

Un ejemplo de cómo usar la opción -a:

git commit -am “Mis nuevos cambios”

La salida de tu terminal debería ser algo así:

[master 22gc8v1] Mis nuevos cambios
 1 file changed, 1 insertion(+)

Uso de mensajes de commit detallados

Aunque git commit -m "mensaje de commit" funciona muy bien, puede ser útil para proporcionar información más detallada y sistemática.

Si realizas un commit sin usar la opción -m, git abrirá tu editor de texto por defecto con un nuevo archivo, que incluirá una lista comentada de todos los archivos/cambios que se han puesto en escena en el commit. Luego escribes tu mensaje de commit detallado (la primera línea será tratada como la línea de asunto) y el commit se realizará cuando guardes/cierres el archivo.

Ten en cuenta:

• Mantén la longitud de tus líneas de mensajes de commit por debajo de 72 caracteres como práctica estándar.
• Está perfectamente bien, e incluso recomendado, escribir mensajes de commit multilínea.
• También puedes referirte a otros temas o a pull requests en tu mensaje de commit. GitHub asignó un número de referencia a todos los pull requests e issues, así que por ejemplo si quieres referirte al pull request #788 simplemente hazlo en la línea de asunto o en el cuerpo del texto según sea apropiado.

La Opción --amend

La opción --amend te permite cambiar tu último commit. Digamos que acabas de realizar un commit y cometiste un error en tu mensaje de commit. Puedes modificar convenientemente el último commit usando el comando:

git commit --amend -m "un mensaje de commit actualizado"

Si se te olvida incluir un archivo en el commit:

git add NOMBRE-DEL-ARCHIVO-OLVIDADO
git commit --amend -m "un mensaje de commit actualizado"

# Si no necesitar cambiar el mensaje de commit, usa la opción --no-edit
git add NOMBRE-DEL-ARCHIVO-OLVIDADO
git commit --amend --no-edit

Los commits prematuros suceden todo el tiempo en el curso del desarrollo diario. Es fácil olvidarse de preparar un archivo o de cómo formatear correctamente tu mensaje de commit. La bandera --amend es una forma conveniente de corregir estos pequeños errores. Este comando sustituirá el antiguo mensaje de commit por el actualizado que se especifica en el comando.

Los commits enmendados son en realidad commits completamente nuevos y el commit anterior ya no estará en tu rama actual. Cuando estés trabajando con otros, deberías intentar evitar modificar los commits si el último commit ya se encuentra empujado (en la nube o remoto) en el repositorio.

Con --amend, una de las opciones útiles que puedes usar es --author, que te permite cambiar el autor del último commit que has hecho. Imagina una situación en la que no has configurado correctamente tu nombre o tu correo electrónico en las configuraciones de git, pero ya has hecho un commit. Con la bandera --author puedes simplemente cambiarlos sin reiniciar el último commit.

git commit --amend --author="John Doe <johndoe@email.com>"

La Opción -v o --verbose

La opción -v o --verbose se usa sin la opción -m. La opción -v puede ser útil para cuando deseas editar un mensaje de commit de Git en tu editor por defecto, mientras que puedes ver los cambios que has hecho para el commit. El comando abre tu editor de texto por defecto con una plantilla de mensaje de commit, así como una copia de los cambios que has realizado para este commit. Los cambios, o diferencias (diff), no se incluirán en el mensaje de commit, pero proporcionan una bonita forma de referenciar tus cambios cuando los describas en tu mensaje de commit.

Cómo aplastar varios commits en uno solo

Esta es una característica genial de rebase que puede ser usada en el modo interactivo. Para aplastar los últimos n commits en uno, ejecuta el siguiente comando:

git rebase -i HEAD~n

Eso abrirá tu editor de texto con algo similar a lo siguiente:

pick commit_1
pick commit_2
pick commit_3
...
pick commit_n
# Un montón de comentarios

Deja el primer commit solo, y cambia el resto de los picks por squash. Guarda y sal del editor.

Así que si quieres aplastar (squash) los últimos tres commits, primero ejecutarás git rebase -i HEAD~3 y luego querrás editar tus commits para que se parezcan a esto:

pick dd661ba Commit 1
squash 71f5fee Commit 2
squash f4b4bf1 Commit 3

Si ya has empujado a remoto antes de aplastar tus commits, tendrás que volver a empujar a remoto de nuevo, con la bandera -f, de lo contrario git te arrojará un error.

Se recomienda encarecidamente que leas la información del archivo abierto, ya que hay muchas cosas que puedes hacer.

Más información:

• Documentación de Git: commit

Traducido del artículo - Git Commit Command Explained

En versiones antiguas de Git, los comandos eran git reset HEAD <archivo> y git reset HEAD respectivamente. Esto se cambió en Git 1.8.2

Puedes leer más sobre otras acciones de Git comúnmente usadas en estos útiles artículos:

• Git checkout
• Git pull vs Git fetch
• Gitignore

Aquí hay un poco más de información de fondo sobre Git

Comprende las Tres Secciones de un Proyecto de Git

Un proyecto de Git tendrá las siguientes tres secciones principales:

1. El directorio de Git (Git directory)
2. El directorio de trabajo (working directory) o árbol de trabajo (working tree)
3. La zona de montaje (staging area)

El directorio de Git (localizado en TU-RUTA-DEL-PROYECTO/.git/) es donde Git almacena todo lo que necesita para rastrear el proyecto con precisión. Esto incluye metadatos y una base de datos de objetos que incluye versiones comprimidas de los archivos del proyecto.

El directorio de trabajo es donde un usuario hace cambios locales a un proyecto. El directorio de trabajo extrae los archivos del proyecto de la base de datos de objetos del directorio de Git y los coloca en la máquina local del usuario.

La zona de montaje es un archivo (también llamado "index", "stage", o "cache") que almacena la información sobre lo que irá en su próxima confirmación. Una confirmación es cuando le dices a Git que guarde estos cambios escalonados. Git toma una captura de los archivos tal y como están, y la almacena permanentemente en el directorio de Git.

Con tres secciones, hay tres estados principales en los que un archivo puede estar en cualquier momento: confirmado (committed), modificado (modified) o puesto en escena (staged). Se modifica un archivo cada vez que se hacen cambios en el directorio de trabajo. Luego, se pone en escena cuando lo mueves a la zona de montaje. Finalmente, se confirma después de realizar un commit.

Instalar Git

• Ubuntu: sudo apt-get install git
• Windows: Descarga
• Mac: Descarga

Configurar el entorno de Git

Git tiene una herramienta git config que te permite personalizar tu entorno Git. Puedes cambiar el aspecto y las funciones de Git estableciendo ciertas variables de configuración. Ejecuta estos comandos desde una interfaz de línea de comandos en tu máquina (Terminal en Mac, Command Prompt o Powershell en Windows).

Hay tres niveles de donde se almacenan estas variables de configuración:

1. Sistema: ubicado en /etc/gitconfig, aplica la configuración por defecto a cada usuario de la computadora. Para hacer cambios en este archivo, usa la opción --system con el comando git config.
2. Usuario: ubicado en ~/.gitconfig o ~/.config/git/config, aplica las configuraciones a un solo usuario. Para hacer cambios en este archivo, usa la opción --global con el comando git config.
3. Proyecto: ubicado en TU-RUTA-DEL-PROYECTO/.git/config, aplica las configuraciones sólo al proyecto. Para hacer cambios en este archivo, usa al comando git config.

Si hay configuraciones que entran en conflicto entre sí, las configuraciones de nivel de proyecto anularán las de nivel de usuario, y las de nivel de usuario anularán las de nivel de sistema.

Nota para los usuarios de Windows: Git busca el archivo de configuración a nivel de usuario (.gitconfig) en tu directorio $HOME (C:\Users\$USER). Git también busca /etc/gitconfig, aunque es relativo al root de MSys, que es donde decides instalar Git en tu sistema Windows cuando ejecutas el instalador. Si estás usando la versión 2.x o posterior de Git para Windows, también hay un archivo de configuración a nivel de sistema en C:\Documents and Settings\All Users\Application Data\Git\config en Windows XP, y en C:\ProgramData\Git\config en Windows Vista y posteriores. Este archivo de configuración sólo puede ser cambiado por git config -f FILE como un administrador.

Agregar Tu Nombre y Correo Electrónico

Git incluye el nombre de usuario y el correo electrónico como parte de la información en un commit. Querrás configurar esto en tu archivo de configuración de usuario con estos comandos:

git config --global user.name "Mi Nombre"
git config --global user.email "micorreo@ejemplo.com"

Cambiar Tu Editor de Texto

Git utiliza automáticamente tu editor de texto predeterminado, pero puedes cambiarlo. Aquí tienes un ejemplo para usar el editor Atom en su lugar (la opción --wait le dice al shell que espere al editor de texto para que puedas hacer tu trabajo en él antes de que el programa avance):

git config --global core.editor "atom --wait"

Agregar Color a la Salida de Git

Puedes configurar tu shell para agregar color a la salida de Git con este comando:

git config --global color.ui true

Para ver todos tus ajustes de configuración, usa el comando git config --list.

Inicializar Git en un Proyecto

Una vez que Git esté instalado y configurado en tu computadora, debes inicializarlo en tu proyecto para empezar a usar sus poderes de control de versiones. En la línea de comandos, utiliza el comando cd para navegar hasta la carpeta de nivel superior (o raíz) de tu proyecto. A continuación, ejecuta el comando git init. Esto instala una carpeta del directorio de Git con todos los archivos y objetos que Git necesita para rastrear tu proyecto.

Es importante que el directorio de Git se instale en la carpeta raíz del proyecto. Git puede rastrear archivos en sub carpetas, pero no rastreará los archivos ubicados en una carpeta principal relativa al directorio de Git.

Obtener Ayuda en Git

Si olvidas cómo funciona cualquier comando en Git, puedes acceder a la ayuda de Git desde la línea de comandos de varias maneras:

git help COMANDO
git COMANDO --help
man git-COMANDO

Esto muestra la página del manual del comando en su ventana shell. Para navegar, desplázate con las teclas de flecha arriba y abajo o utiliza los siguientes atajos de teclado:

• f o barra espaciadora para avanzar la página
• b para volver a la página
• q para salir

Traducido del artículo - How to Undo a Git Add

Checkout un commit específico

Para realizar un checkout a un commit específico, ejecuta el comando:

git checkout id-del-commit-específico

podemos obtener el identificador (id) del commit específico ejecutando:

git log

Checkout a una Rama (Branch) Existente

Para realizar checkout a una rama existente, ejecuta el comando:

git checkout NOMBRE-DE-LA-RAMA

Por lo general, Git no te dejará realizar checkout a otra rama a menos que tu directorio de trabajo esté limpio, porque perderías cualquier cambio del directorio de trabajo al que no le has hecho commit. Tienes tres opciones para manejar tus cambios: 1) tirarlos a la basura, 2) realizarles un commit, 3) realizarles un stash.

Checkout a una Rama Nueva

Para crear y hacer checkout a una rama nueva con un solo comando, puedes usar:

git checkout -b NOMBRE-DE-LA-RAMA-NUEVA

Esto te cambiará automáticamente a la rama nueva.

Checkout a una Rama Nueva or Reiniciar una Rama a un Punto de Partida

El siguiente comando es similar al de realizar checkout a una rama nueva, pero utiliza la bandera -B (fíjese en la B mayúscula) y un parámetro opciones de PUNTO-DE-PARTIDA:

git checkout -B NOMBRE-DE-LA-RAMA PUNTO-DE-PARTIDA

Si la rama NOMBRE-DE-LA-RAMA no existe, Git la creará y la iniciará en PUNTO-DE-PARTIDA. Si la rama NOMBRE-DE-LA-RAMA ya existe, entonces Git restablece la rama a PUNTO-DE-PARTIDA. Esto equivale a ejecutar git branch con -f.

Forzar un Checkout

Puedes pasar la opción -f o --force con el comando git checkout para forzar a Git a cambiar de rama, incluso si tienes cambios fuera de la zona de montaje (en otras palabras, el índice del árbol de trabajo difiere de HEAD). Básicamente, se puede usar para tirar los cambios locales.

Cuando ejecutes el siguiente comando, Git ignorará las entradas no fusionadas:

git checkout -f NOMBRE-DE-LA-RAMA

# Alternativa
git checkout --force NOMBRE-DE-LA-RAMA

Deshacer los Cambio en tu Directorio de Trabajo

Puedes usar el comando git checkout para deshacer los cambios que has hecho en un archivo de tu directorio y trabajo. Esto revertirá el archivo a la versión en HEAD:

git checkout -- NOMBRE-DEL-ARCHIVO

Traducido del artículo - Git Checkout Explained: How to Checkout, Change, or Switch a Branch in Git

Por el contexto, vale la pena recordar que probablemente estemos trabajando en un repositorio clonado. ¿Qué es un clon? Es simplemente un duplicado de otro repositorio. Básicamente es obtener tu propia copia del código fuente de otra persona.

Dicho esto, para mantener tu clon actualizado con cualquier cambio que se haya aplicado al original, necesitarás llevarlos a tu clon.

Ahí es donde entran fetch y pull.

git fetch es el comando que le dice a tu git local que recupere la última información de los metadatos del original (aunque no hace ninguna transferencia de archivos. Es más bien como comprobar si hay algún cambio disponible).

git pull por otro lado hace eso Y trae (copia) esos cambios del repositorio remoto.

Por ejemplo:

git pull origin ankur bugfix

Lo que hay que tomar de aquí es tener en cuenta que generalmente hay al menos tres copias de un proyecto en tu estación de trabajo.

• Una copia es tu propio repositorio con tu propio historial de confirmación (el ya guardado, por así decirlo).
• La segunda copia es tu copia de trabajo donde estás editando y construyendo (aún sin realizar commit a tu repositorio).
• La tercera copia es tu copia local "en caché" de un repositorio remoto (probablemente el original de donde clonaste el tuyo).

Puedes usar git fetch para saber los cambios hechos en el repo/rama remoto desde tu último pull. Esto es útil para permitir la comprobación antes de hacer un pull real, lo que podría cambiar los archivos en tu rama actual y en la copia de trabajo (y potencialmente perder tus cambios, etc.).

git fetch    
git diff ...origin

Traducido del artículo - Git Fetch vs Pull: What's the Difference Between the Git Fetch and Git Pull Commands?

Todos los desarrolladores han realizado algún commit a archivos confidenciales o sensibles en el pasado. Entonces, ¿cómo arreglamos la situación y nos aseguramos de que no nos vuelva a suceder?

En este artículo, te explicaré qué hacer cuando se realiza un commit accidentalmente a un archivo confidencial e incluyo los comandos de Git necesarios para ajustar el historial.

Control de Daños

Así que accidentalmente realizaste un commit a un archivo confidencial. Vamos a llamarlo .env. Hay dos preguntas importantes que responder:

• ¿Subiste el commit a un repositorio remoto?
• ¿Es público el repositorio remoto?

No ha sido subido

Si aún no se ha subido, la situación no es para nada crítica. Puedes volver a un commit anterior:

git reset HEAD^ --soft

Tus archivos se quedarán en la copia de trabajo para que puedas arreglar el archivo/información confidencial. Si quieres mantener el commit y simplemente eliminar el archivo confidencial, realiza:

git rm .env --cached
git commit --amend

Puedes usar --amend solo en el último commit. Si logras añadir un montón de commits encima de eso, usa:

git rebase -i HEAD~{¿cuántos commits a volver?}

Esto te permitirá arreglar el commit defectuoso y reproducirá todos los commits restantes después de la corrección para que no se pierdan.

Ya se ha subido

Si subiste, hay una importante diferencia entre los repositorios públicos y privados.

Si tu repositorio es privado y no hay bots o gente en la que no confíes con acceso a él, puedes modificar fácilmente el último commit usando los dos comandos anteriores.

Si subiste un montón de commits encima del problemático, puedes seguir usando filter-branch o el limpiador de repositorios BFG para eliminar el archivo confidencial del historial de git:

git filter-branch --force --index-filter "git rm --cached --ignore-unmatch .env" --prune-empty --tag-name-filter cat -- --all

Pero ten en cuenta dos aspectos importantes de estos cambios:

• En realidad estás cambiando el historial
  hay otras personas, otras ramas, otros forks, o solicitudes abiertas de pull requests que dependen del estado actual del repositorio, las romperás. En esos casos, trata el repositorio como si fuera pública y evita cambiar el historial.
• Necesitas limpiar el caché
  Siempre tienes que contactar con el apoyo de tu proveedor de almacenamiento de Git y pedirles que limpien el caché de tu repositorio. Aunque hayas arreglado el commit problemático o reescrito el historial, el viejo commit con el archivo confidencial permanece en el caché. Necesitarías saber su ID para acceder a él, pero sigue siendo accesible hasta que limpies el caché.

¿Necesito regenerar las claves si se suben a un repositorio público?

En resumen, sí. Si tu repositorio es público o no piensas que es un lugar seguro por cualquier otro razón, debes considerar que la información confidencial ha sido comprometida.

Incluso si eliminas los datos de tu repositorio, no puedes hacer cualquier cosa sobre los bots y otros forks del repositorio. Entonces, ¿cuáles son los siguientes pasos?

• Desactiva todas las claves y/o contraseñas
  Haz esto como el primer paso. Una vez que desactives las claves, la información confidencial se vuelve inútil.
• Ajusta gitignore
  Agrega todos los archivos confidenciales a .gitignore para asegurarte de que git no los rastreará.
• Elimina el archivo confidencial
• Realiza un commit del arreglo con una explicación significativa
  No trates de ocultar el error. Otros colaboradores y tú en un mes apreciarán la explicación de lo que pasó y lo que este commit arregla.

Mejores prácticas para el almacenamiento de datos confidenciales en Git

Para evitar una situación como está en el futuro, aquí hay algunos consejos sobre el almacenamiento de datos confidenciales:

Mantén los datos confidenciales en un archivo .env (o un archivo similar en otras plataformas)

Mantén las claves del API y otros datos confidenciales en un solo archivo .env. De esa manera, no realizarás un commit accidentalmente con la nueva clave cuando el archivo .env ya está excluido de git.

Otro gran beneficio es que tienes acceso a todas las claves usando una variable de proceso global.

Usa claves API si es posible

Las claves API son fáciles de generar y desactivar si se ven comprometidas. Si es posible, úsalas y evita el uso de credenciales/contraseñas.

Agrega las claves API a tu herramienta de construcción

Las claves API suelen ser necesarias durante la construcción de aplicaciones. Las herramientas de construcción como Netlify permiten agregar estas claves en las áreas seguras de su administración. Estas claves se inyectan automáticamente en tu aplicación a través de la variable de proceso global.

Agrega el archivo .env a gitignore

Asegúrate de que Git no rastree los archivos que contengan información confidencial.

Proporciona un archivo .env.template

El archivo de plantilla (template) instruye a otros colaboradores para que añadan las claves API necesarias sin necesidad de leer largos documentos.

No cambies el historial en remoto

Usa esto como una regla general. Si has seguido las reglas anteriores, no necesitarás cambiar el historial.

Espero que esta información te haya ayudado a mantenerte en el lado seguro. ¿Tienes una experiencia personal al deshacer commits o quizás una buena lección aprendida? Háblame en Twitter :-)

Traducido del artículo de Ondrej Polesny - How to Uncommit Sensitive Files from Git

Veremos como una sesión de SSH es realmente "segura" y cómo las computadores establecen y configuran una sesión de SSH en primer lugar. También veremos los beneficios de usar SSH.

Nota: Esto está pensado como notas futuras para mí, ¡pero espero que tú también aprendas algo de ello!

¿Qué es SSH?

SSH es la abreviatura de 'secure shell'. Es un protocolo para compartir datos entre dos computadoras a través de Internet.

Un protocolo es esencialmente un conjunto de reglas que definen el lenguaje que las computadores pueden utilizar para comunicarse.

Típicamente, las dos computadores involucradas son tu computadora (el "cliente) y un servidor remoto (el "host).

¿Por qué nos importa?

Comunicación segura entre computadoras

Siempre que dos computadoras se comunican por Internet queremos estar seguros de que nuestros mensajes no pueden ser interceptados y entendidos por nadie que escuche los mensajes.

Imagina enviar tus datos bancarios a través de Internet para comprar algo en línea. Si tus mensajes no estuvieran cifrados, entonces cualquier computadora que estuviera escuchando o cualquier computadora que recibiera los mensajes para transmitirlos podría ver tu número de cuenta y tu contraseña. ¡Eso no es bueno!

Creo que es un concepto importante de entender para cualquiera que aspire a trabajar con tecnologías web.

Acceso seguro a computadoras remotas

El uso de SSH para comprobar la autenticación es una forma más segura de autenticación que el uso de una contraseña. A continuación exploraremos cómo funciona esto.

¿Cómo es SSH seguro?

SSH es una forma segura de enviar comunicaciones entre dos computadoras.

Por 'seguro', me refiero a una forma de codificar los mensajes en una computadora cliente de tal manera que la única otra computadora que puede decodificar los mensajes y entenderlos es el host. Esta codificación/decodificación se llama cifrado, así que lo que realmente queremos decir aquí es que SSH es seguro porque utiliza un canal de comunicación cifrado.

¿Cómo se establece una sesión de SSH?

Hay varios procesos que deben ocurrir entre dos computadoras para que comience una sesión de SSH.

1. Primero necesitamos una forma de establecer un método seguro de intercambio de mensajes entre las computadoras. Necesitamos establecer un canal cifrado.
2. Necesitamos una forma de comprobar que los datos recibidos por el host no han sido manipulados. Esto se llama verificación y aquí estamos verificando la integridad de los datos que son enviados por el cliente.
3. Verificación (de nuevo). Necesitamos una forma de comprobar que la computadora con la que nos comunicamos no es un impostor. Esta es otra forma de verificación pero aquí estamos verificando la identidad de la computadora.

Después de estos tres pasos, ahora podemos comunicarnos de forma segura con una computadora remota.

Después de estos pasos, podemos compartir datos "secretos" de forma segura y también podemos comprobar si un cliente tiene permiso para acceder a un host de forma más segura que usando una contraseña. Este proceso se llama autenticación usando cifrado asimétrico.

Cada una de estas secciones a continuación entrará en más detalles sobre estos pasos.

Configurar un canal cifrado

Una parte esencial del protocolo SSH es que es seguro (¡está incluso en el nombre!), lo que significa que toda la información que se envía usando SSH está cifrada.

¿Cómo se cifra esta información?

Cifrar esencialmente sólo significa "mezclar las letras" usando algunas matemáticas inteligentes. Ambas computadoras necesitan tener una forma de cifrar la información para que sólo la otra computadora pueda descifrarla y entenderla.

¿Cómo funciona esto?

Ambas computadoras tienen una versión idéntica de una clave simétrica. La clave simétrica es sólo una cadena de letras almacenadas en algún lugar de las computadoras. Las computadoras pueden usar las claves simétricas para cifrar y también descifrar los mensajes que se les envían.

El uso de este enfoque de clave simétrica se llama cifrado simétrico. La parte "simétrica" viene del hecho de que la clave simétrica en cada computadora es idéntica. Este enfoque funciona muy bien... pero sólo funciona mientras ninguna otra computadora tenga acceso a la clave simétrica.

Un problema

¿Cómo saben ambas computadoras cuál es la clave simétrica?

Una computadora podría crearla y enviarla en un mensaje a través de Internet. Pero los mensajes no estarían cifrados todavía, así que cualquiera que intercepto los mensajes tendría instantáneamente la clave simétrica ... y podría descifrar todas las comunicaciones futuras. ¡Eso es malo!

Esto a veces se llama el problema del "intercambio de claves". Está claro que necesitamos agregar otro paso en el proceso antes de poder usar las claves simétricas.

Una solución

Una solución al problema del "intercambio de claves" mencionado anteriormente es que ambas computadoras compartan alguna información pública entre sí (es "pública", lo que significa que no les importa si alguien la intercepta) y la combinen con alguna información en su propia computadora para crear independientemente claves simétricas idénticas.

Estas claves simétricas pueden ser usadas en el cifrado simétrico de la manera descrita anteriormente.

Cómo funciona

Ambas computadoras tienen cada una su propia clave privada y su clave pública. Juntos forman un par de claves (key-pair). Las computadoras comparten sus claves públicas entre sí a través de Internet. Así que, en este punto del proceso cada computadora sabe

• su propia clave privada,
• su propia clave pública,
• y la clave pública de la otra computadora.

Generando Claves Simétricas

Ambas computadoras usan estas tres piezas de información para generar independientemente una clave simétricas idéntica.

Cada computadora utiliza un algoritmo matemático que utiliza las 3 entradas mencionadas anteriormente. Este algoritmo es parte del algoritmo de intercambio de claves Diffie-Hellman. El algoritmo que se ejecutará en cada computadora es algo así:

Host
pub_2 = other computer's public key
pub_1 = my public key
pri_1 = my private key

f(pub_2, pub_1, pri_1) = abcdefg // Symmetric Key

Client:
f(pub_1, pub_2, pri_2) = abcdefg // Symmetric Key

Lo importante es que las computadoras sólo han compartido información pública a través de Internet, ¡pero aún así han sido capaces de crear claves simétricas!

El enfoque de utilizar pares de claves y compartir información pública para generar claves simétricas idénticas se llama cifrado asimétrico. Se llama "asimétrico" porque ambas computadoras comienzan con sus propios pares de claves, diferentes.

Hasta ahora: hemos visto cómo usar el cifrado asimétrico para generar independientemente claves simétricas idénticas en ambas computadoras de una manera segura (resolviendo el problema de intercambio de claves) y luego intercambiar información de manera segura entre las computadoras usando claves simétricas para el cifrado y descifrado.

Verificación

Así que podemos comunicarnos de forma segura. Pero la siguiente parte del proceso de establecer una sesión de SSH es verificar que los datos no han sido manipulados como han sido transmitidos y que la otra computadora es realmente quien dice ser.

¿Por qué necesitamos esto?

Otra computadora podría personificar otra de las computadoras e iniciar el intercambio de claves de arriba. Entonces, ¿cómo podemos averiguar con seguridad que el mensaje es realmente de la otra computadora y no de un impostor?

Hashing

Tenemos que usar una función de hash. Esta es sólo una función matemática que toma entradas y produce una cadena de un tamaño fijo.

La característica importante de esta función es que es virtualmente imposible calcular lo que las entradas fueron sólo usando salidas.

Después de que un cliente y un host hayan generado sus claves simétricas, el cliente usará una función hash para generar un HMAC. Esto sólo significa "código de autenticación de mensaje basado en hash" (hash-based message authenticacion code). El cliente enviará este HMAC al servidor para su verificación.

Los ingredientes de la función de hash son

• La clave simétrica en el cliente
• El número de secuencia del paquete (cada mensaje que se envía está contenido en un "paquete" de información)
• El contenido (¡¡¡cifrado!!!) del mensaje

Un ejemplo con datos falsos:

symm_key       = abcdefg
pkge_no        = 13
encr_message   = encrypted_password

Hash(symm_key, pkge_no, encr_message) = *HMAC* // Hashed value

¿Cómo es que el host usa esta información?

Cuando el host recibe el HMAC, puede usar la misma función hash con estos tres ingredientes:

• su propia copia de la clave simétrica (¡idéntica!),
• el número de secuencia del paquete,
• y el mensaje cifrado.

Si el valor calculado es el mismo que el HMAC que recibió del cliente, entonces hemos verificado que la computadora que se conecta es el mismo que tiene la clave simétrica.

Recuerde que sólo el host y el cliente saben lo que es la clave simétrica y ninguna otra computadora lo sabe.

Así que aquí no importa que el host no conozca el contenido decodificado del mensaje cifrado — ¡el host aún ha verifica la identidad de la computadora que se conecta!

La belleza de este enfoque es que no sólo hemos verificado la identidad del cliente y nos hemos asegurado de que los datos no han sido manipulados, sino que lo hemos hecho de forma segura (sin compartir ninguna información privada).

Resumen: hemos utilizado una función hash en el cliente y luego en el host para verificar la integridad de los datos y comprobar la identidad del cliente.

Autenticación

La parte final de la comunicación segura con las computadoras remotas es:

incluso si hemos generado claves simétricas con la computadora de conexión e

incluso si estamos usando las claves simétricas para comunicarnos de forma segura e

incluso si la computadora que se conecta es realmente el cliente que esperamos y no un impostor,

entonces hemos establecido una sesión de SSH... ¿pero la computadora que se conecta tiene permiso para acceder al contenido del host?

Esto se llama "autenticación": el acto de comprobar los permisos y derechos de acceso.

Hay dos formas para comprobar la autenticación:

1—Usando una contraseña

El cliente puede enviar al host un mensaje (cifrado) que contenga una contraseña. El host puede descifrar el mensaje y comprobar la contraseña en una base de datos para comprobar si el cliente tiene permiso para acceder al "usuario" (área de la computadora) especificado. Listo.

2 — Usando par de claves y cifrado asimétrico

Antes vimos cómo el cifrado asimétrico puede utilizar dos pares de claves para generar de forma segura claves simétricas idénticas tanto en el cliente como en el host. Usando ideas similares, el cliente puede iniciar sesión sin una contraseña.

Este es un enfoque de muy alto nivel de cómo funciona el proceso:

Preparación:

En el cliente, dirígete a la terminal y usa un comando para generar una clave pública y una clave privada (bajo la superficie utiliza "RSA", un algoritmo matemático) en el cliente. Copia la clave pública (¡NO la privada!) en el portapapeles.

Repito: Copia la clave PÚBLICA (¡NO LA CLAVE PRIVADA!) en el portapapeles.

Luego, en la terminal del cliente, usa una contraseña para ingresar remotamente al host. Pega la clave pública del cliente en la carpeta apropiada del host junto con cualquier otra clave pública.

Ahora, el host tiene

• Su propio par de claves pública/privada
• La clave pública del cliente

Mirando la sección anterior sobre el algoritmo de intercambio de claves, ¡se puede ver cómo el host tiene todos los ingredientes que necesita para generar una clave simétrica!

Desafiante:

Cuando el cliente quiere conectarse, el host puede emitir un "desafío" enviando un mensaje que ha sido cifrado (con la clave simétrica del host) y decir: "¡Sólo te autorizaré el acceso si puedes descifrar este mensaje!".

El cliente entonces tiene

• su propia clave pública y privada
• la clave pública del host
• el mensaje cifrado

Así que ahora el cliente tiene todo lo necesario para generar una clave simétrica (idéntica) ... ¡y descifrar el mensaje! Puede descifrar el mensaje y enviar una confirmación de que ha "tenido éxito" en el desafío de vuelta al host.

El host está satisfecho de que el cliente que se conecta está autorizado y concede permiso para el acceso.

¿Por qué molestarse en usar el segundo enfoque?

Esto se considera más seguro que el simple uso de una contraseña, ya que un bot puede utilizar un enfoque de "fuerza bruta" para seguir usando muchas combinaciones para adivinar tu contraseña, pero no tendrá el par de claves correctos para que funcione el segundo enfoque.

Más lecturas:

SSH Tutorial for Beginners - How Does SSH Work
SSH, or Secure Shell, is a remote administration protocol that allows users to control and modify their remote servers…www.hostinger.com

https://www.udemy.com/the-complete-junior-to-senior-web-developer-roadmap/

Conclusión

SSH es una importante herramienta utilizada para controlar remotamente otras computadoras.

SSH es seguro porque ambas computadoras pueden cifrar y descifrar el mensaje usando idénticas claves simétricas (conocido como "cifrado simétrico").

Los principales pasos para iniciar una sesión de SSH son:

1. Configurar un canal cifrado. Usando cifrado asimétrico para resolver el problema de intercambio de claves que genera independientemente claves simétricas idénticas en ambas computadoras sin compartir ninguna información privada.
2. Verificación. Usando hashing en ambas computadoras para verificar la identidad de la computadora conectada.
3. Verificación (otra vez). El uso de hashing en ambas computadoras para verificar la integridad de los datos no se ha visto comprometido en la transmisión.

Podemos usar SSH para enviar datos de forma segura entre las computadoras. Un caso de uso importante de esto es para la autenticación. Aunque se puede usar una contraseña, el uso de cifrado asimétrico para comprobar que el "cliente" que se conecta tiene permiso para acceder al "host" se considera más seguro.

Si estás interesado en subir el nivel de tu SSH, te recomiendo seriamente este curso. ¡He encontrado muy útil para perfeccionar algunas de mis habilidades! (descargo de responsabilidad: No tengo ningún vínculo o conexión con el autor o la plataforma. ¡Tomé el curso hace un tiempo y lo encontré realmente bueno!)

¡Gracias por leer!

Traducido del artículo de Sam Ollason - A top-down introduction to SSH and how it enables secure data-sharing

Después de unas semanas de escribir, vuelvo hoy con un seguimiento de una de mis publicaciones más buscadas en Google.

Cuando empecé a escribir, hace un año, creé un artículo sobre cómo empezar y crear tu primer repositorio con Git.

Este artículo ayuda a mucha gente cada semana. Así que decidí escribir este post sobre cómo escribir un buen mensaje de commit para que puedas llevar tus habilidades en Git al siguiente nivel.

¿Qué es un buen mensaje de commit?

Como un breve recordatorio, un mensaje de commit es el texto corto que dejaste cuando guardaste tu trabajo en Git. Este mensaje tiene como objetivo identificar tu trabajo.

La idea es que con solo leerlo, cualquiera podrá entender claramente lo que hiciste en esta parte de tu trabajo.

Un buen ejemplo de commit

A continuación, puedes encontrar los últimos commits del proyecto Angular.js en GitHub. Como puedes ver, los mensajes son claros, y podemos entender mejor qué trabajo se ha hecho en las diferentes partes.

Por ejemplo, el 24 de julio de 2019, "gkalpak" actualizó "SauceConnect" y cambió a la última versión de Safari (el navegador web).

¿Por qué no todos realizan commits de la misma manera?

Desafortunadamente, no hay una forma universal de escribir commits. Cada proyecto y cada empresa definen reglas específicas para sus necesidades.

Pero no te preocupes, a menudo encontrarás formas similares de escribir un mensaje.

Para saber cuáles son, te recomiendo que leas las reglas antes de empezar en una empresa o de trabajar en un proyecto de código abierto.

Te daré más detalles sobre estas pautas más adelante en este artículo.

Por qué es esencial escribir bien tu commit

He creado una lista corta de las ventajas de usar un buen mensaje de commit.

Mejor colaboración

Si trabajas en una empresa, o en un proyecto de código abierto, es esencial seguir las reglas para una mejor cooperación. Si escribes algo comprensible, siguiendo las reglas del proyecto, otros desarrolladores podrán trabajar más eficientemente. No tendrán que hacer preguntas sobre tu trabajo.

Nota: Si estás trabajando en un proyecto personal, te recomiendo encarecidamente que también sigas unas normas específicas. Esto mejorará tu productividad, y si necesitas ayuda de otro desarrollador, será más fácil para ellos empezar a trabajar en tu proyecto.

Mejor entendimiento

Necesitas crear mensajes claros y comprensibles. Esto te ayudará a ti y a tu colaborador a trabajar juntos en un proyecto. A continuación, puedes encontrar un ejemplo de un historial de git commits con mensajes poco claros. Como verás, es difícil de entender lo que estaba pasando.

BONUS - Una generación de registro de cambios

Te diré un pequeño secreto: si escribes buenos mensajes, podrás generar un registro de cambios directamente desde tus mensajes de commits.

Aquí hay algunas herramientas para hacerlo:

• Github Changelog Generator
• Git Chglog
• Auto Changelog
• Conventional Changelog.

También escribiré un próximo artículo sobre este tema. Si quieres estar al día, puedes seguirme en Twitter. Yo publico todas las actualizaciones allí.

Nota: Si quieres tener más ejemplos de malos commits y divertirte al mismo tiempo, una cuenta de Twitter llamada "gitlost" está twiteando todos los días con los commits divertidos y sin filtros.

Bien, ahora entremos en más detalles y veamos lo que realmente se necesita para escribir un buen mensaje de commit.

Cómo escribir un mensaje de commit

Si quieres escribir un buen mensaje de commit, tienes que seguir algunas reglas. He creado una lista de verificación a continuación. Cada vez que quieras hacer un commit, tómate el tiempo de consultar esta lista.

• Siempre revisa tu gramática. Nunca es agradable leer un mensaje lleno de errores. Para ello, te recomiendo que utilices una herramienta gramatical. Si escribes en inglés, puedes usar Grammarly, Reverso o GrammarCheck. Estar herramientas no son perfectas, pero eliminarán la mayoría de tus errores.
• Un commit, un cambio. Trata de realizar commits a menudo. Lo ideal es que cada cambio se haga en un commit diferente. Será más fácil para ti volver a tu trabajo anterior.
• Sé claro. Cuando escribas un commit, intenta ser lo más transparente posible. Te recomiendo que uses inglés (o español) sencillo y vayas directo al grano.
• Detalla lo que hiciste. Tómate el tiempo de releer tu código para escribir lo que hiciste. En caso de que necesites agregar muchos detalles, usa la parte de la descripción del commit.

El comando git commit

Quiero compartirte más detalles sobre el comando 'git commit'. Si no estás usando git software, debes saber que puedes crear commits detallados escribiendo este comando.

$ git commit -m "Título" -m "Descripción"

Es lo mismo que antes, pero con una segunda parte para la descripción. Así "-m 'título' " te permite escribir el título corto del commit, y "-m 'descripción' " te permite escribir la descripción si necesitas dar más detalles.

Usa directrices o pautas de git

Si quieres tener un historial de git commits claro, debes seguir algunas pautas. En mi caso elegí este simple de Udacity.

Hay muchas otras, como los Conventional Commits, y el Angular Guideline. Una pauta de commits te ayudará a estructurar tus commits.

Por ejemplo, añadiendo una etiqueta para aclarar lo que hiciste: "git commit -m 'fix: borra correctamente toda la información del usuario cuando se activa el botón de borrar la cuenta'".

Conclusión

¡Espero que te haya gustado esta guía sobre cómo realizar commits con Git! Si tienes alguna pregunta o comentario, no dudes en preguntar.

Si tienes algún otro consejo sobre cómo hacer buenos commits, por favor házmelo saber.

No te pierdas mi contenido siguiéndome en Twitter e Instagram.

Puedes encontrar otros artículos como este en mi sitio web: herewecode.io.

¿Quieres más?

• Cada semana recibe una cita motivacional con algunos consejos, un breve tutorial en una cuantas diapositivas, y una foto de un desarrollador en Instagram.
• Suscríbete al boletín de noticias y recibe los últimos artículos, cursos, tutoriales, consejos, libros, motivación y otros contenidos exclusivos.

Traducido del artículo de Gaël Thomas - A Beginner’s Guide to Git — How to Write a Good Commit Message

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

npm (node package manager) es el gestor de dependencias/paquetes que obtienes por defecto cuando instalas Node.js. Proporciona una manera para que los desarrolladores instalen paquetes tanto a nivel global como local.

A veces puede que quieras echar un vistazo a un paquete específico y probar algunos comandos. Pero no puedes hacerlo sin instalar las dependencias en tu carpeta local de node_modules.

Ahí es donde entra npx.

En este artículo, vamos a echar un vistazo a las diferencias entre npm y npx y aprenderemos cómo obtener lo mejor de ambos.

En primer lugar, vamos a entender lo que npm es en realidad y lo que podemos hacer con él.

El gestor de paquetes npm

npm es un par de cosas. En primer lugar, es un repositorio en línea para la publicación de proyectos de código abierto Node.js.

Segundo, es una herramienta CLI que ayuda a instalar esos paquetes y a manejar sus versiones y dependencias. Hay cientos de miles de librerías y aplicaciones de Node.js en npm y muchas más se agregan cada día.

npm por sí mismo no tiene ningún paquete. Si quieres ejecutar un paquete usando npm, debes especificar ese paquete en tu archivo package.json.

Cuando los ejecutables se instalan a través de paquetes npm, npm crea enlaces a ellos:

• las instalaciones locales tienen enlaces creados en el directorio ./node_modules/.bin/
• las instalaciones globales tienen enlaces creados desde el directorio global bin/ (por ejemplo: /usr/local/bin en Linux o %AppData%/npm en Windows)

Para ejecutar un paquete con npm tienes que escribir la ruta local, así:

$ ./node_modules/.bin/tu-paquete

o puedes ejecutar un paquete instalado localmente agregándolo a tu archivo package.json en la sección de scripts, así:

{
  "name": "tu-aplicacion",
  "version": "1.0.0",
  "scripts": {
    "tu-paquete": "tu-paquete"
  }
}

Luego puedes ejecutar el script usando npm run:

npm run tu-paquete

Puedes ver que manejar un paquete con npm simple requiere bastante ceremonia.

Afortunadamente, aquí es donde npx es útil.

El ejecutor de paquetes npx

Desde la versión 5.2.0 de npm, npx está preinstalado con npm. Así que es más o menos estándar hoy en día.

npx es también una herramienta CLI cuyo propósito es facilitar la instalación y la gestión de las dependencias alojadas en el registro npm.

Ahora es muy fácil ejecutar cualquier tipo de ejecutable basado en Node.js que normalmente se instalaría a través de npm.

Puedes ejecutar el siguiente comando para ver si ya está instalado para tu versión actual de npm:

$ which npx

Si no lo está, puede instalarlo así:

$ npm install -g npx

Una vez que te asegures de tenerlo instalado, veamos algunos de los casos de uso que hacen que npx sea extremadamente útil.

Ejecutar un paquete instalado localmente fácilmente

Si deseas ejecutar un paquete instalado localmente, todo lo que tienes que hacer es escribir:

$ npx tu-paquete

npx comprobará si <comando> o <paquete> existe en $PATH, o en los binarios del proyecto local, y si es así lo ejecutará.

Ejecutar los paquetes que no estén previamente instalados

Otra gran ventaja es la capacidad de ejecutar un paquete que no fue instalado previamente.

A veces sólo quieres usar algunas herramientas CLI pero no quieres instalarlas globalmente sólo para probarlas. Esto significa que puedes ahorrar algo de espacio en disco y simplemente ejecutarlos sólo cuando los necesites. Esto también significa que tus variables globales estarán menos contaminadas.

Ejecuta código directamente desde GitHub

Este es bastante radical.

Puedes usar npx para ejecutar cualquier gist y repositorio de GitHub. Centrémonos en ejecutar un gist de GitHub porque es más fácil crear uno.

El script más básico consiste en el archivo principal de JS y un package.json. Después de configurar los archivos, todo lo que tienes que hacer es ejecutar el npx con el enlace a ese gist como se muestra en la imagen de arriba.

Aquí puedes encontrar el código que usé para este ejemplo.

Asegúrate de leer atentamente cualquier script antes de ejecutarlo para evitar problemas serios que pueden ocurrir debido a código malicioso.

Prueba diferentes versiones de los paquetes

npx hace que sea extremadamente fácil probar diferentes versiones de un paquete o módulo de Node.js. Para probar esta impresionante característica, vamos a instalar localmente el paquete create-react-app y probar una próxima versión.

Esto enlistará algunas etiquetas dist cerca del final de la salida. Las etiquetas dist proporcionan alias para los números de versión, lo que hace que sea mucho más fácil de escribir.

$ npm v create-react-app

Usemos npx para probar la etiqueta dist next de create-react-app que creará la aplicación dentro de un directorio sandbox.

$ npx create-react-app@next sandbox

npx instalará temporalmente la siguiente versión de create-react-app, y luego se ejecutará para andamiar la aplicación e instalar sus dependencias.

Una vez instalada, podemos navegar a la aplicación de esta manera:

$ cd sandbox

y luego empezar con este comando:

$ npm start

Se abrirá automáticamente la aplicación de React en una ventana de tu navegador predeterminado. ¡Ahora tenemos una aplicación que funciona en la próxima version del paquete create-react-app!

Conclusión

npx nos ayuda a evitar el versionado, los problemas de dependencia y la instalación de paquetes innecesarios que sólo queremos probar.

También proporciona una forma clara y fácil de ejecutar paquetes, comandos, módulos e incluso listas y repositorio de GitHub.

Si no has usado npx antes, ¡ahora es un buen momento para empezar!

Esto fue originalmente publicado en mi blog.
Puedes contactarme y preguntarme cualquier cosa en Twitter y Facebook.

Traducido del artículo de Carol-Theodor Pelu - npm vs npx — What’s the Difference?