Como la mayoría de los novatos, comencé a buscar en StackOverflow los comandos de Git y luego a copiar y pegar las respuestas, sin comprender realmente lo que hacían.

Recuerdo haber pensado"¿No sería bueno si hubiera una lista de los comandos de Git más comunes junto con una explicación de por qué son útiles?"

Bueno, aquí estoy años después para compilar una lista de este tipo y presentar algunas de las mejores prácticas que incluso los desarrolladores intermedios-avanzados deberían encontrar útiles.

Para mantener las cosas prácticas, baso esta lista en los comandos de Git reales que usé durante la semana pasada.

Casi todos los desarrolladores usan Git y, muy probablemente, GitHub. Pero el desarrollador promedio probablemente solo use estos tres comandos el 99% del tiempo:

git add --allgit commit -am ""git push origin master

Eso está muy bien cuando trabajas en un equipo de una sola persona, en un hackathon o en una aplicación desechable, pero cuando la estabilidad y el mantenimiento comienzan a convertirse en una prioridad, la limpieza de las confirmaciones, el apego a una estrategia de ramificación y la redacción Los mensajes de compromiso coherentes se vuelven importantes.

Comenzaré con la lista de comandos de uso común para facilitar que los principiantes comprendan lo que es posible con Git, luego pasaré a la funcionalidad más avanzada y las mejores prácticas.

Comandos de uso habitual

Para inicializar Git en un repositorio (repositorio), solo necesita escribir el siguiente comando. Si no inicializa Git, no puede ejecutar ningún otro comando de Git dentro de ese repositorio.

git init

Si está usando GitHub y está enviando código a un repositorio de GitHub que está almacenado en línea, está usando un repositorio remoto . El nombre predeterminado (también conocido como alias) para ese repositorio remoto es origen . Si ha copiado un proyecto de Github, ya tiene un origen . Puede ver ese origen con el comando git remote -v , que mostrará la URL del repositorio remoto.

Si inicializó su propio repositorio de Git y desea asociarlo con un repositorio de GitHub, tendrá que crear uno en GitHub, copiar la URL proporcionada y usar el comando git remote add originRL>, con la URL proporcionada por GitHub reemplazando "". Desde allí, puede agregar, confirmar y enviar a su repositorio remoto.

El último se usa cuando necesita cambiar el repositorio remoto. Digamos que copió un repositorio de otra persona y desea cambiar el repositorio remoto del propietario original a su propia cuenta de GitHub. Siga el mismo proceso que git remote add origin , excepto que use set-url en su lugar para cambiar el repositorio remoto.

git remote -vgit remote add origin git remote set-url origin 

La forma más común de copiar un repositorio es usar git clone, seguido de la URL del repositorio.

Tenga en cuenta que el repositorio remoto se vinculará a la cuenta desde la que clonó el repositorio. Entonces, si clonó un repositorio que pertenece a otra persona, no podrá enviarlo a GitHub hasta que cambie el origen usando los comandos anteriores.

git clone 

Rápidamente te encontrarás usando ramas. Si no comprende qué son las ramas, hay otros tutoriales que son mucho más detallados y debería leerlos antes de continuar (aquí hay uno).

El comando git branch enumera todas las ramas en su máquina local. Si desea crear una nueva rama, puede usar git branchme>, con & lt; name> que representa el nombre de la rama, como "master".

El checkout de gitEl comando me> cambia a una rama existente. También puede usar el comando git checkout -b & lt; name> para crear una nueva rama e inmediatamente cambiar a ella. La mayoría de la gente usa esto en lugar de los comandos de rama y salida separados.

git branchgit branch git checkout git checkout -b 

Si ha realizado un montón de cambios en una rama, llamémosla "desarrollar", y desea fusionar esa rama de nuevo en su rama maestra , utilice el git merge

ch> comando. Usted wa nt a ch Eckout la rama principal, el n plazo git merge d esarrollar fusionar convertirse en la rama principal.

git merge 

Si está trabajando con varias personas, se encontrará en una posición en la que se actualizó un repositorio en GitHub, pero no tiene los cambios localmente. Si ese es el caso, puede usar git pull origin

ch> para extraer los cambios más recientes de esa rama remota.

git pull origin 

Si tiene curiosidad por ver qué archivos se han cambiado y qué se está rastreando, puede usar git status . Si desea ver cuánto ha cambiado cada archivo, puede usar git diff para ver el número de líneas cambiadas en cada archivo.

git statusgit diff --stat

Comandos avanzados y mejores prácticas

Pronto llegas a un punto en el que quieres que tus compromisos se vean bien y sean consistentes. También es posible que tenga que jugar con su historial de confirmaciones para que sus confirmaciones sean más fáciles de comprender o para revertir un cambio de ruptura accidental.

El comando git log te permite ver el historial de confirmaciones. Querrá usar esto para ver el historial de sus confirmaciones.

Tus confirmaciones vendrán con mensajes y un hash , que es una serie aleatoria de números y letras. Un hash de ejemplo podría verse así: c3d882aa1aa4e3d5f18b3890132670fbeac912f7

git log

Digamos que presionó algo que rompió su aplicación. En lugar de arreglarlo y lanzar algo nuevo, prefiere retroceder una confirmación e intentarlo de nuevo.

Si desea retroceder en el tiempo y verificar su aplicación desde una confirmación anterior, puede hacerlo directamente usando el hash como nombre de la rama. Esto separará su aplicación de la versión actual (porque está editando un registro histórico, en lugar de la versión actual).

git checkout c3d88eaa1aa4e4d5f

Luego, si realiza cambios desde esa rama histórica y quiere presionar nuevamente, tendrá que hacer un empuje forzado.

Precaución: empujar con fuerzais dangerous and should only be done if you absolutely must. It will overwrite the history of your app and you will lose whatever came after.

git push -f origin master

Other times it’s just not practical to keep everything in one commit. Perhaps you want to save your progress before trying something potentially risky, or perhaps you made a mistake and want to spare yourself the embarrassment of having an error in your version history. For that, we have git rebase.

Let’s say you have 4 commits in your local history (not pushed to GitHub) in which you’ve gone back and forth. Your commits look sloppy and indecisive. You can use rebase to combine all of those commits into a single, concise commit.

git rebase -i HEAD~4

The above command will open up your computer’s default editor (which is Vim unless you’ve set it to something else), with several options for how you can change your commits. It will look something like the code below:

pick 130deo9 oldest commit messagepick 4209fei second oldest commit messagepick 4390gne third oldest commit messagepick bmo0dne newest commit message

In order to combine these, we need to change the “pick” option to “fixup” (as the documentation below the code says) to meld the commits and discard the commit messages. Note that in vim, you need to press “a” or “i” to be able to edit the text, and to save and exit, you need to type the escape key followed by “shift + z + z”. Don’t ask me why, it just is.

pick 130deo9 oldest commit messagefixup 4209fei second oldest commit messagefixup 4390gne third oldest commit messagefixup bmo0dne newest commit message

This will merge all of your commits into the commit with the message “oldest commit message”.

The next step is to rename your commit message. This is entirely a matter of opinion, but so long as you follow a consistent pattern, anything you do is fine. I recommend using the commit guidelines put out by Google for Angular.js.

In order to change the commit message, use the amend flag.

git commit --amend

This will also open vim, and the text editing and saving rules are the same as above. To give an example of a good commit message, here’s one following the rules from the guideline:

feat: add stripe checkout button to payments page

- add stripe checkout button- write tests for checkout

One advantage to keeping with the types listed in the guideline is that it makes writing change logs easier. You can also include information in the footer (again, specified in the guideline) that references issues.

Note: you should avoid rebasing and squashing your commits if you are collaborating on a project, and have code pushed to GitHub. If you start changing version history under people’s noses, you could end up making everyone’s lives more difficult with bugs that are difficult to track.

There are an almost endless number of possible commands with Git, but these commands are probably the only ones you’ll need to know for your first few years of programming.

Sam Corcos is the lead developer and co-founder of Sightline Maps, the most intuitive platform for 3D printing topographical maps, as well as LearnPhoenix.io, an intermediate-advanced tutorial site for building scalable production apps with Phoenix and React.