Indice del contenido
En la entrada anterior vimos que es Git, GitHub y Gitkraken y cómo lo utilizamos para crear nuestro propio proyecto local. Demás está decir que cada vez que inicies un nuevo proyecto de programación es recomendable que utilices Git tal y como lo has aprendido. De esta forma en un futuro podrás retomar viejos proyectos y actualizarlos sin ningún problema!
En esta entrada vamos a aprender a subir nuestro proyecto a un repositorio remoto. Convertiremos ese proyecto en local en uno remoto para que además de estar alojado en nuestro computador se encuentre disponible en la nube y podamos incorporar a otros desarrolladores a trabajar en él si así lo deseamos!
Al momento de trabajar en un repositorio remoto explicaremos y haremos uso de otras opciones que anteriormente no hemos explicado puesto que no eran necesarias aún. Ya que nuestro proyecto solo se alojaba en nuestro computador!
Debes tener una cuenta en GitHub
Si aún no has creado tu cuenta en GitHub es momento de hacerlo, ya sea como persona o como empresa si fuera tu caso. En mi caso tengo una cuenta personal con mi nombre y apellido y otra para Pythones que es con la que me gustaría trabajar para estos ejemplos y futuros proyectos!
¿Cómo subir un proyecto a Github?
Para subir un proyecto local a GitHub podemos hacerlo a través de la consola o de GitKraken, como a tí te quede más cómodo. En este caso vamos a ver las dos formas para que quien no quiera usar una Gui comprenda el uso de la consola y tengas un conocimiento un poco más «profundo» de como funciona.
Usando GitKraken
Lo normal es que luego de instalar GitKraken nos hayamos logueado con la cuenta de GitHub que hemos creado previamente, pero si no es así al momento de subir el repositorio deberás ingresar tu cuenta en el panel de GitKraken.
Primero debemos abrir nuestro repositorio local con GitKraken e ir a la sección Remoto (REMOTE). (En este caso voy a utilizar el proyecto anterior como ejemplo).
Allí se nos abrirá una ventana donde verás si tienes la sesión iniciada en GitHub y mediante un cuadro de selección podrás optar por subir el proyecto a diferentes plataformas.
Fijate que en este caso automáticamente está seleccionado el mismo nombre que tenemos para el repositorio local «Mi Proyecto Git» y debajo en la opción «Remote Name» indica «origin» por defecto. Pues ese es el nombre que suele recibir el repositorio remoto principal con el que trabajamos. Este nombre se puede cambiar pero en la mayoría de los casos se recomienda utilizar el mismo.
Y en el caso de la privacidad del repositorio se refiere a que si nosotros seleccionamos «Public» cualquier persona podrá enviar commits al proyecto. En cambio, seleccionando «Private» solo podrán enviar commits quienes nosotros definimos en GitHub. Yo en mi caso lo puse en private!
Finalmente añadimos una descripción breve y damos a «Create remote and push local Refs»
Recibirás una alerta de que el repositorio remoto ha sido creado exitosamente y podrás ver debajo de la pestaña «Remote» a la izquierda tu proyecto tal cual estaba alojado en local.
Subir un repo local a un repositorio remoto desde la consola
En el caso que no utilices GitKraken y quieras hacerlo desde la consola puedes hacerlo ingresando los siguientes comandos parados en la carpeta del proyecto:
git remote add origin https://github.com/NOMBRE_USUARIO/NOMBRE_PROYECTO.git
git push -u origin master
Donde debes reemplazar en la url con tu nombre de usuario y el nombre que tendrá el proyecto en tu perfil de Git.
Si quieres visualizar el proyecto con el que trabajamos en el primer tutorial lo puedes hacer:
Proyecto git de ejemplo con Gitkraken
Por cierto lo he puesto en «Publico» para que puedas visualizarlo en GitHub.
Ahora además hay algunos «comandos y opciones» que debemos conocer a la hora de trabajar con un repositorio remoto.
Trabajando con nuestro repositorio remoto (Comandos y opciones)
Hay algunos comandos que debemos conocer para trabajar con repositorios remotos, tanto si es tu propio repositorio como en el ejemplo anterior. O estás trabajando en el repositorio remoto de alguien más.
Recordemos que normalmente siempre tendremos un repositorio local y uno remoto que al igual que un espejo debe coincidir o lo irán haciendo a medida que aplicamos cambios. Si alguien modifica algún archivo del repositorio remoto añadiendo nuevas ramas o commits mientras tu estás trabajando en tu repositorio local debes ir actualizando para poder visualizar esos cambios en tu repositorio local. ¿Me entiendes?
Git Pull
El comando «Pull» bajará los cambios de la rama que determinemos y los actualizará directamente contra nuestro repositorio local automáticamente. Es decir, que en nuestro ejemplo un «pull» no valdría de nada porque no hemos realizado aún cambios en el repositorio remoto para reflejarlos en el «local«. En el caso que otro desarrollador generará un commit por ejemplo en la rama «master» del repositorio remoto, haciendo nosotros un «git pull» esos cambios se verían reflejados en nuestro repositorio local. Porque es una copia exacta del remoto.
El «pull» se utiliza normalmente para sincronizar automáticamente nuestro repositorio local en el cual estamos trabajando con los cambios que se hayan hecho en el remoto mientras nos ocupamos de lo nuestro. Pero en proyectos grandes podrían causar problemas.
Pero podría existir un problema con realizar un «pull» así sin más. Y es que queramos revisar los cambios antes de combinarlos a nuestro repositorio local. Para ello se utiliza «git fetch».
Git Fetch
Este comando hace casi lo mismo que un «pull» con la diferencia que no integra los cambios directamente con nuestro repositorio local, sino que crea una carpeta oculta o «rama» donde aloja los nuevos cambios y nos permite revisarlos antes de incorporarlos al repositorio local del proyecto en el cual trabajamos. Para acceder a esta rama y ver los cambios que podemos actualizar en base al remoto debemos ejecutar «git branch -a» para ver las ramas ocultas.
Finalmente si estamos de acuerdo en añadir estos cambios a la rama principal de nuestro proyecto en local hacemos un merge unificando esos cambios de la rama a nuestra rama master del repositorio local.
Git push
El comando «Push» subirá los cambios realizados en nuestro repositorio local al repositorio remoto. Es decir que los commits, ramas y demás cambios que hayamos hechos se verán reflejados en el repositorio remoto. Los envíos tienen la posibilidad de sobre-escribir cambios por lo que debemos estar bien seguros a la hora de realizar un «push». Por ello es mejor que cuando hagamos un push lo hagamos sobre una rama nueva y finalmente se termine por hacer un merge a la rama principal que deseamos, en vez de hacer el push directamente a la rama principal. ¿Me explico?
Git push se suele usar para publicar y cargar cambios locales a un repositorio central. Después de modificar el repositorio local, se ejecuta un comando push para compartir las modificaciones con miembros remotos del equipo.
Estos tres comandos «Pull, Fetch y Push» son los que utilizaremos más a menudo cuando trabajamos con repositorios remotos. Los aprenderemos más adelante al momento de actualizar nuestro repositorio remoto.
Bien ya basta de teoría introductoria, pasamos a la acción!
¿Cómo hacemos para trabajar en el repositorio remoto de alguien más?
Para trabajar con este tutorial subí el repositorio remoto a la cuenta de GitHub de Pythones. Y trabajo sobre el con mi cuenta personal Mariano-laca como si se tratará de un desarrollador más.
Lo primero es «clonar el repositorio«, entonces se nos creará una copia local exacta del repositorio remoto en la que podremos trabajar sobre el o los archivos del proyecto remoto. Finalmente una vez hechos nuestros cambios podremos irlos incorporando a una rama del proyecto e ir realizando «push» para que nuestros cambios sean aplicados o figuren en el remoto.
Git clone
Este comando nos permitirá clonar el repositorio a nuestro ordenador y alojarlo en alguna carpeta de nuestro gusto. Para hacerlo desde consola simplemente bastará con ingresar:
git clone <url del repositorio remoto> <carpeta de destino>
Si quieres clonar el proyecto de ejemplo aquí debajo te dejo la url del repo:
https://github.com/Pythones-blog/Mi-Proyecto-Git
Hacer un git clone es casi como hacer un git init, con la diferencia de que el primero habrá de clonar un repositorio remoto y el segundo nos creará un repositorio local nuevo de nuestra propiedad.
Trabaja como si fueras un desarrollador más en tu propio repositorio remoto para aprender
En este caso estaría bueno que implementes trabajar en el repositorio que has subido como veníamos viendo en el tutorial pero con otra cuenta para no confundirte. O bien puedes trabajar con este repositorio de ejemplo.. Pero es mejor que lo hagas con un repositorio tuyo para que luego puedas ver como se aceptan o ignoran las fusiones de los cambios (merge pull request)
Pero ponte en ese papel, imagina que ese proyecto no es tuyo, olvida por un momento que lo has subido tú.
Ya sea que hayas subido tu repositorio de ejemplo que en mi caso era «Proyecto Git» mediante GitKraken o consola se me ocurre que podrías eliminar la copia local para volver a clonarlo desde la dirección remota donde lo has alojado. ¿Te animas?
Veeeenga!
Yo he subido el repositorio anterior a mi cuenta personal pero luego lo pase a la cuenta de Pythones para trabajar con mi cuenta personal como un desarrollador más. Así que también elimine el proyecto que tenía en local para volver a clonarlo desde allí. En mi caso:
git clone https://github.com/Pythones-blog/Mi-Proyecto-Git
También puedes hacerlo desde GitKraken:
Ahora una vez clonado podemos trabajar normalmente como sea de nuestra preferencia, mediante consola o GitKraken:
Yo abriré GitKraken. Fíjate que estamos trabajando en local, como anteriormente lo hicimos la única diferencia es que se trata de un repositorio clonado, perdon que sea tan repetitivo pero es donde se genera la confusión. Ahora fijate que te he marcado unas opciones importantes en GitKraken tambíen:
Ahora voy a crear una rama «Desarrollador» y voy a generar un commit, vamos nada que no hayamos aprendido antes.
Enviar cambios al repositorio remoto
Y ahora que hemos realizados cambios supongamos queremos actualizarlos al repositorio remoto, solicitar aplicar esos cambios al proyecto en verdad. Para ello hay algunas cosas a tener en cuenta!
Recuerdas que tu tenias tu cuenta de GitHub, bueno pues estate atento a ella porque llegara una solicitud de que un cambio desea ser añadido al momento que envíes un «push«. Si imaginamos que es el proyecto de otra persona con la cual nosotros estamos colaborando, esa persona podrá decidir si aplicar tu cambio (haciendo un merge) o no al proyecto remoto original. Tu cambio existirá igualmente allí, pero puede que se fusione o no..
Haciendo «Push» desde Kraken
En mi caso lo haré desde este software, para que me voy a complicar la vida con la consola, demasiado la utilizo todos los días. Pa hacerme el guapo hago «cmatrix» 😛
Al momento de hacer el «Push» se nos preguntará la rama sobre la que queremos hacerlo. Fíjate que pregunta ¿What remote/branch should «Desarrollador» push and pull from? Puesto que al enviar el push automáticamente se hace un «pull» manteniendo nuestro repositorio local también actualizado contra el remoto, en caso de haber habido un cambio antes de enviar nuestro «push» se verá reflejado inmediatamente luego de hecho ese «push». En este caso si te paras sobre la rama master no te preguntará nada y podrás hacerlo directamente, pero como sobre esa rama no hay cambios, en realidad no notarás cambios en Github. Así que debes hacerlo sobre las ramas nuevas o donde hayas creado commits nuevos. Fijate luego de hacer el «push» de «Desarrollador» al remoto como nos notifica en Github:
Y aquí podemos comparar y solicitar un pull al repositorio remoto (como desarrolladores) «Compare & Pull request». Pero en este caso es porque quien sugiere el cambio soy yo mismo que nos ofrece solicitar el pull, si no me equivoco.
Al dar clic en «Compare & Pull request» veremos lo siguiente:
Fijate que nos está diciendo que «yo» en este caso como papel de un desarrollador deseo aplicar cambios y se me pide que confirme para crear «una solicitud de cambios» (una pull request definitiva). También nos avisa que la fusión de ramas desarrollador a master del proyecto remoto es posible automáticamente.
Además en este botón nos da dos opciones: O bien solicitar aplicar los cambios y que están listos para fusionar si se desea, o enviarlos solo para revisión, como si aún no estuvieran listos.
Vamos a hacer un «pull request simple, como si ya estuviéramos listos con los cambios»
Y como administradores del repositorio remoto esto es lo que veremos:
En este caso una solicitud abierta donde mariano (osea yo, pero mi otro yo) desea fusionar un commit en master de Desarrollador (la rama que creamos).
Bien podríamos como desarrolladores continuar enviando commits.
El administrador del repositorio remoto tendrá tres opciones:
- Crear un commit de fusión añadiendo los nuevos cambios a la rama base.
- Combinar los commits en uno solo y fusionar a la rama base. (Pero en este caso es uno solo)
- O bien rebasar y fusionar (esto es fusionar todos los commits por separados en la rama base, en vez de en uno solo. Pero en este caso es uno solo, así que no tiene mayor importancia.)
Y al confirmar la fusión de los cambios como administradores del remoto veremos algo así:
Actualizar el repositorio local contra el remoto
Ahora que han aprobado esos cambios, estos aún no figuran en nuestro repositorio local, porque de hecho la rama Desarrollador ya no existe en el remoto porque fue fusionada (merge) a la master. Para «actualizar nuestro remoto debemos hacer un pull. Recuerdas? «git pull»
Y entonces ahora si veremos los cambios que fueron hechos en el remoto en nuestro repositorio local!
La confusión con pull, hermano
Pull es tanto una actualización del repositorio local contra el remoto. Como la solicitud de hacer un pull es enviar los cambios de tu repositorio local al remoto para una posible fusión (Pull request). ¿Me explico?. Aquí es donde el inglés es de más ayuda que mil cursos 😛
Esto ha sido todo por ahora pero queda aún mucho por aprender de Git. En estas dos entradas pretendo dejarte una idea básica para que puedas trabajar con git en un futuro si lo deseas. Puedes encontrar más información en español en la página oficial de:
Git Kraken (en ingles pero con vídeos)
Github documentación en español
Atlassian guía de git + bitbucket en español.
