Aprendiendo a utilizar Git y Github - Parte 2

En el post anterior, vimos algunos comandos básicos de Git: add, commit, push, status y clone. Esta vez vamos a profundizar un poco más sobre el uso de estos comandos.

Fuente

---

Clonando repositorios existentes

La vez pasada, para ilustrar la guía, estuvimos trabajando con un repositorio que hemos creado nosotros mismos. Sin embargo, no siempre vamos a empezar a trabajar con un repositorio que hemos creado desde cero, sino que podremos enfrentar situaciones como clonar nuestro propio repositorio en otras computadoras, o incluso clonar el repositorio de otra persona. Para esto, vamos al link del repositorio que queremos clonar, nos dirigimos al botón verde que dice Clone or download, y copiamos el link que allí nos aparece.

Una vez que hemos copiado el link, utilizamos el comando git clone <repositorio> como la vez anterior, y ya habremos clonado nuestro repositorio.

---

Modificando archivos ya existentes

Ahora, volvamos a lo que veníamos discutiendo... Cada vez que se modifica un archivo dentro del repositorio, Git detectará automáticamente que han ocurrido cambios dentro de estos archivos, y es a través del comando git status que podremos visualizar cuáles han sido los archivos que han sido modificados. En este momento, voy a crear algunos archivos adicionales, y también voy a modificar el archivo que ya había creado previamente. La estructura de mi repositorio actualmente es la siguiente:

En el editor Atom los archivos y directorios nuevos se encuentran en verde, y los archivos existentes que han sido modificados se ven naranja

Como pueden ver, cree dos nuevos directorios, con un archivo en cada uno de ellos, y adicionalmente modifiqué el contenido del file1. Veamos estos cambios con el comando git status.

Efectivamente vemos que el comando nos arroja el mismo resultado: file1 ha sido modificado, y existen dos directorios a los que no se les está haciendo seguimiento: porque acaban de ser creados.

Ahora, vamos a utilizar el comando git diff que nos permite visualizar los cambios que se han realizado en nuestros archivos:

La salida del comando nos muestra que el archivo file1 ha sido modificado, y nos indica que se ha agregado (denotado por una línea verde con el símbolo +) una línea: <h1> Hello world </h1>. Como ya hemos hecho suficientes cambios, ahora vamos a hacer algunos commits.

git commit

Primero, haremos el commit de las nuevas carpetas que hemos creado. Para esto, primero tenemos que agregar las carpetas y archivos que queremos incluir en nuestro commit utilizando el comando git add

Al hacer un commit de un directorio/carpeta, estamos incluyendo automáticamente todos los archivos contenidos dentro de ésta

Una vez que hemos ejecutado git add, volvemos a ejecutar git status para ver el estado de nuestro repositorio. Como pueden ver, nos indica que hay algunos cambios para hacer un commit. Ahora, ejecutamos git commit:

Ahora hacemos el commit de file1

Y ejecutamos nuevamente git status. Como podrán observar, esta vez nos dirá que nuestro directorio de trabajo se encuentra limpio, es decir, que no tenemos cambios pendientes que no hemos gestionado (archivos y/o directorios por agregar, o archivos modificados con los cuáles no hemos hecho commit).

<

Nota: es una buena práctica que nuestros commits sean cambios bastante puntuales. Es decir, cada vez que modifiquemos un archivo, agreguemos una nueva función, o realicemos un cambios que sea lo suficientemente pequeño pero significativo, debemos realizar un commit. Esto nos permite llevar un control efectivo de los cambios que venimos realizando, y suponiendo que en algún momento hemos dañado alguna parte vital de nuestro proyecto, podremos identificar más fácilmente en donde se ha cometido el error y podremos devolvernos al estado en el cual el proyecto aún estaba operativo. Al contrario, si modificamos 10 archivos, todos con funcionalidades muy distintas entre si y hacemos un commit de los 20 archivos al mismo tiempo, será muy difícil identificar qué es lo que se ha dañado.

git diff

Supongamos que hice todos los commits que tenía que hacer, y luego de un rato modifiqué el archivo file1 pero ya no me acuerdo cuál era su contenido original antes de haberlo modificado. En este momento es cuando resulta útil el comando git diff, ya que al ejecutarlo, nos muestra cuáles han sido los cambios que hemos realizado sobre nuestro archivo desde la última vez que realizamos un commit. Luego de haber modificado file1, ejecuto git diff y obtengo el siguiente resultado:

La salida nos muestra que en el archivo file1 se ha eliminado la línea (denotado por una línea roja y un símbolo -) cuyo contenido era <h1> Hello world </h1> y en su lugar he colocado la línea <h2> Hello Steemit </h2>. Este comando resulta especialmente útil cuando trabajamos con varias personas en un mismo proyecto, para saber cuáles han sido los cambios que los demás participantes han realizado sobre los archivos.

Una vez que hemos terminado de trabajar con nuestros archivos, es hora de subir todos los cambios a Github.

git push origin master

Este es el comando que utilizamos para subir todos nuestros cambios desde nuestro repositorio local (en nuestras computadoras) al repositorio remoto (en Github). Este comando recibe dos argumentos: origin y master. Todo el mundo escribe en tutoriales git push origin master, pero ¿qué significan exactamente estas palabras?

git push

Como ya habíamos dicho, git push es el comando que utilizamos para subir (push, pushear) nuestros cambios a Github.

origin

Cada vez que ejecutamos el comando git clone <repositorio>, git guarda ciertas configuraciones en nuestra computadora al momento de descargar el repositorio. Una de esas configuraciones son los remotes, o repositorios remotos. Nuestro repositorio en Github es un repositorio remoto, por ejemplo. Cuando clonamos un repositorio, el nombre por defecto que recibe el repositorio remoto en nuestra computadora es origin, de allí viene el nombre. Sin embargo, podemos agregar más remotes si así lo deseamos, con los nombres que deseemos. Mediante el comando git remote -v podemos obtener una lista de todos los remotes que están configurados en nuestro repositorio local

Primero aparece el nombre asignado al repositorio, y luego el link del repositorio. Para ilustrar, en este caso he agregado un repositorio viejo de mi cuenta de Github bajo el nombre de TestRemote. Ahora, al ejecutar git remote -v, aparecerá también dicho remote.

master

En Git se trabajan con branches o ramas. Las ramas son copias de nuestro repositorio en algún punto de su existencia. Podemos crear ramas para poder obtener una copia idéntica de nuestro proyecto en algún momento y así poder trabajar de manera paralela, sin tener que modificar directamente la copia original de nuestros archivos. Cada vez que creamos un repositorio, se crea automáticamente un rama principal denominada master. Si utilizamos el comando git branch podremos visualizar todas las ramas que tenemos actualmente:

---

El siguiente es un esquema que sumariza todas las acciones principales de Git. Allí se pueden ver acciones que ya hemos cubierto, como add, commit y push. Eventualmente aprenderemos a utilizar todas estas acciones.

Fuente

---

Resumen

Esta vez hemos afianzado un poco más el uso de los comandos básicos de git, como lo son add, status, commit y push. Estos 4 comandos nos acompañarán siempre que utilicemos Git, y lo mejor es tomarse el detenimiento de aprender a utilizarlos bien y entender exactamente su función. Adicionalmente, hemos visto algunos comandos nuevos:

• git diff: nos permite visualizar los cambios que hemos hecho en nuestros archivos, tomando como punto de origen la última vez que hicimos un commit.
• git remote -v: nos permite visualizar los remotes que tenemos configurados en nuestro repositorio local.
• git remote add <nombre> <link>: nos permite agregar un nuevo remote a nuestro repositorio local.
• git branch: nos permite visualizar las ramas o branches que tenemos en nuestro repositorio local.

En la próxima parte vamos a empezar a trabajar con ramas. Vamos a crearlas, eliminarlas, unirlas (merge) y subirlas a nuestro repositorio en Github.

Si tienes alguna duda acerca del procedimiento, o algún comentario al respecto, puedes dejarlo en los comentarios.

---

Todas las imágenes no citadas son de mi autoría