Es mucho más recomendado usar SSH para clonar repositorios, en vez de HTTPS.
Una buena práctica a la hora de hacer commits es no usar puntos. El mensaje de los commits realmente son sus títulos, y estos nunca se puntúan. Es tan fácil como fijarse en como GitHub hace sus propios commits.
Recordar que un commit es una confirmación. Cuando hacemos un commit estamos indicando que queremos confirmar los cambios que hemos realizado.
Al clonar repositorios con el comando git clone podemos utilizar el parámetro --depth=1 para descargar el proyecto en el estado actual y únicamente el último commit que se ha realizado. Por ejemplo git clone link-repositorio.git --depth=1. De esta manera la clonación será mucho más rápida y además el proyecto no ocupará tanto espacio.
A la hora de clonar un repositorio, podemos indicar la carpeta en la que queremos que se clone poniendo la ruta al final del comando: git clone repositorio ./carpeta.
Se puede utilizar el comando git switch nombre-rama para cambiar de rama, al igual que haríamos con el comando git checkout nombre-rama aunque la sintaxis queda algo más clara con el comando switch que con el checkout. Además, el comando checkout ya no es recomendado ya que viola la filosofía UNIX, y fue por eso que añadieron a Git los comandos switch y restore.
Con git switch -c "nombre-rama" estaremos creando una nueva rama y a su vez moviéndonos a ella.
En caso de haber realizado un commit que no queríamos, aún estamos a tiempo de volver atrás. Con el comando git reset --hard HEAD~1 eliminaremos el último commit realizado y descartaremos todos los cambios que este realizaba. Si solamente queremos eliminar el commit pero conservar los cambios, también podemos hacerlo cambiando el parámetro git reset --soft HEAD~1. Si quisiéramos devolver el estado de nuestro proyecto a un commit anterior en concreto, podemos sustituir HEAD~1 por el código SHA-1 de 40 caracteres, o la abreviatura de 7, que identifica el commit, por ejemplo con git reset --soft 8f8f5d9 eliminaríamos todos los commits que se han realizado después del indicado pero conservaríamos los cambios.
Para ver todos los commits que hemos realizado podemos utilizar el comando git log. Si queremos reducir la información que se muestra, podemos utilizar el parámetro git log --oneline.
El comando fetch es muy similar al pull pero tienen una diferencia. Con fetch los cambios remotos solo se aplican a nuestros cambios confirmados, y no reemplazan los cambios que tengamos sin confirmar. En cambio el pull aplica los cambios remotos tanto a nuestros cambios confirmados como a nuestro working directory.
Contribuciones con GitHub Flow
El primer paso para hacer una contribución a un repositorio ajeno es hacer un Fork.
Una vez hecho el fork, deberemos clonar el fork en local. Para ello, una herramienta que nos va a facilitar la vida es usar la CLI de GitHub.
El equivalente a git clone link-repositorio.git sería gh repo clone usuario/repositorio.
La principal diferencia es que la CLI de GitHub ya nos enlaza el repositorio remoto upstream1 (desde donde hemos hecho el fork), mientras que con el comando de git tendríamos que hacerlo manual. Para hacerlo manual utilizaríamos el comando git remote add upstream link-repositorio.git (en upstream realmente podemos poner la palabra que nosotros queramos, pero lo estándar es así)1.
Para ver los remotos que tenemos configurados, podemos utilizar el comando git remote --verbose. Podemos tener tantos repositorios remotos como queramos.
Esto es interesante ya que si en el repositorio original se realizan modificaciones, podemos coger esos cambios directamente con git fetch upstream1 y aplicarlos en nuestro repositorio local (main, en el ejemplo) con git pull upstream main1.
Una vez realizados los cambios pertinentes, deberemos subirlos a GitHub.
En primer lugar podemos crear una rama, en nuestro repositorio local, con el comando git switch -c "nombre-rama". Importante darle un nombre descriptivo a la rama de lo que arregla.
Luego deberemos crear los commits necesarios y subirlos a nuestro repositorio remoto (el fork que hemos hecho). Una manera sería con el comando git push -u origin nombre-rama.
Una vez tengamos los cambios publicados a nuestro repositorio remoto en GitHub, veremos que nos aparece un cartel que nos indica que tenemos una nueva rama nuevos cambios respecto a la rama principal.
Al hacer click en el botón, será cuando realmente podremos hacer la pull request hacia el repositorio original (de donde hemos hecho el fork).
Esta imagen significa que haremos una pull request de la rama fix-accessibility-issues de nuestro repositorio (midudev/svgl) hacia el repositorio base (pheralb/svgl) a la rama main.
- Ser quirúrgicos: modificar solo y únicamente lo que necesitemos para arreglar/implementar nuestra feature. No crear "ruido" innecesario modificando el estilo o re-formateando el código.
- Separar: utiliza una pull request para arreglar una cosa concreta. Si ves que hay más errores o cosas que podrías implementar, crea otras pull requests.
- Imitar el estilo de los commits: siempre habrá más probabilidades de que os acepten una pull request si seguís con el estilo usado.
- Revisar los commits: antes de enviar la pull request, no es mala idea revisar los commits que hemos hecho y las líneas que modifican, para no enviar cosas que no queramos.
- Minimizar el número de ramas.
Una vez se haga el merge de nuestra pull request, GitHub nos dará la opción de borrar la rama de nuestro repositorio (el fork que habíamos hecho). Al eliminar la rama desde GitHub, luego podremos sincronizar los cambios con nuestro repositorio local con el comando git fetch.
Además, luego también podremos sincronizar los cambios de nuestro repositorio (el fork, que está atrasado) con los nuevos cambios que se han integrado al repositorio original con nuestra pull request. GitHub nos ofrecerá también un botón para hacerlo. Si no, podemos utilizar el comando git pull upstream main1 para llevar los cambios realizados en el repositorio original desde donde habíamos hecho el fork hacia nuestro repositorio local. Para ver si tenemos vinculado el upstream1 (con la CLI de GitHub se vinculaba automáticamente) utilizaríamos el comando git remote --verbose. Luego, deberíamos actualizar los cambios a nuestro repositorio remoto con git push -u origin main.
Curso de GIT y GITHUB DESDE CERO Para Aportar a Proyectos
Borrar último commit con reset y revert en git | Solucionex
For Good First Issue | Make your next open-source contribution matter.
Good First Issue: Make your first open-source contribution