Prácticas guiadas con

git y github

Luisa Parra García

2020/2021
Práctica 1: Nuestro primer repositorio 3
Paso 1: Configuración Git. 3
Paso 2: Crear un nuevo proyecto en local. 3
Paso 3. El primer commit. 3

Práctica 2. Trabajamos en local 5

Añadimos ficheros al repositorio 5
Descartar cambios en el repositorio 7
Eliminar ficheros del repositorio 8

Práctica 3: Histórico de operaciones en Git. 8

Práctica 4: El fichero .gitignore 10

Práctica 5: Cargando versiones antiguas 11

Borrar último commit. Reset vs Revert 11
Checkout 12

Práctica 6. Conectándome a un repositorio remoto. 15

Subir al remoto tu repositorio local 15
Clonar tu repositorio remoto en local 16

Práctica 7: Actualización del repositorio local 16

Git fetch + git merge 18
Git pull 19

Práctica 8: Actualización del repositorio remoto 21

Actualización simple 21
Actualización del repositorio remoto no actualizado en local 22
Actualización del repositorio remoto con conflictos 25

Práctica 9 Ramificaciones en git 29

Paso 1: Crear una rama 29
Paso 2. Realizamos cambios en la rama y confirmamos 29
Paso 3: Fusionamos las ramas 30
Paso 4: Enviamos cambios al repositorio remoto 31

2
Práctica 1: Nuestro primer repositorio

Paso 1: Configuración Git.

Después de la instalación de git, como mínimo debemos configurar el nombre y el email en
la aplicación:
git config --global user.name "Tu nombre aquí"
git config --global user.email "tu_email_aquí@example.com"
Comprueba tu configuración con el siguiente comando:
git config -–global –list
Si necesitas ayuda con git, con git help, obtendremos ayuda.

Paso 2: Crear un nuevo proyecto en local.

Sitúate en la carpeta donde tengas todos tus repositorios. Con git init y el nombre del
proyecto, se nos creará una carpeta con el mismo nombre y en su interior podemos objetar
que se crea una subcarpeta oculta .git.

Paso 3. El primer commit.

Creamos un archivo en el proyecto con algo de contenido, por ejemplo README.md en el
contenido #Prueba Git
Si ejecutamos git status, veremos que estamos en la rama master y que tenemos un
fichero untraked.

3
Lo primero que tenemos que hacer es enviar el fichero al staging area, para ello usaremos
git add. Si volvemos a ejecutar git status, veremos que ya está preparado para enviarlo a
nuestro repositorio local mediante un commit:
git commit -m “Primer commit”
Al hacer git status, veremos que el staging area está vacía y no hay ningún commit
pendiente.

4
Práctica 2. Trabajamos en local

Añadimos ficheros al repositorio

Vamos a modificar el fichero README.md. Si queremos hacer un commit, primero
tendremos que volver a añadir los cambios al staging area, con git -a

Si quiero añadir todos los ficheros a la staging area, puedo usar la opción git -a .

5
Vamos a modificar, esos dos ficheros. Siguiendo los pasos anteriores deberíamos hacer:
git -a .
git commit -m “mensaje”
Pero estas instrucciones se pueden abreviar utilizando:

git commit -am “mensaje”

6
Descartar cambios en el repositorio
Cómo podemos sacar un archivo del staging area y descartar sus cambios en el directorio
de trabajo. Nos valdremos de los comandos:
git reset HEAD <nombre del fichero> //para sacar del staging
area
git checkout -- <nombre del fichero> // para descartar cambios
en el directorio de trabajo.

7
Eliminar ficheros del repositorio
Imaginemos que uno de los archivos que ya están en el repositorio de git tras un commit no
lo queremos allí. Podemos usar el comando rm de remove y el nombre del archivo:

git rm index.html

Si nos damos cuenta que nos hemos equivocado antes de hacer el commit podemos
revertirlo:

Sí definitivamente queremos eliminarlo, después de hacer el borrado, hacemos un commit y

ya desaparecerá de nuestro repositorio.

Práctica 3: Histórico de operaciones en Git.

Si queremos ver los commit que se han hecho, utilizaremos un el comando git log, con git
help log podemos ver todas las opciones que existen. Aquí tenéis una muestra de una vista
compacta y colorida:
git log --oneline --graph --decorate --color
Y otra más detallada
git log --graph --decorate --color

8
Si en algún momento quieres repasar los ficheros modificados en cada commit puedes
hacerlo con la opción -p:

9
Práctica 4: El fichero .gitignore
Git tiene una herramienta imprescindible casi en cualquier proyecto, el archivo "gitignore",
que sirve para decirle a Git qué archivos o directorios completos debe ignorar y no subir al
repositorio de código.
Únicamente se necesita crear un archivo especificando qué elementos se deben ignorar y, a
partir de entonces, realizar el resto del proceso para trabajar con Git de manera habitual.
Existe una herramienta online que se llama gitignore.io. Básicamente permite escribir en
un campo de búsqueda los nombres de todas las herramientas, sistemas, frameworks,
lenguajes, etc. que puedas estar usando. Seleccionas todos los valores y luego generas el
archivo de manera automática.
Vamos a crear un archivo .gitignore que ignore los ficheros *.log y los contenidos de una
carpeta en concreto.

Ahora podemos hacer pruebas para comprobar que cada de lo que añadamos a la
carpeta_ignorar, ni ningún fichero *.log se tendrán en cuenta en un commit.

10
Práctica 5: Cargando versiones antiguas

Borrar último commit. Reset vs Revert

Muchas veces nos sucede que realizamos un commit y después nos damos cuenta que no
deberíamos haberlo hecho y necesitamos eliminarlo. ¿Cómo podemos eliminar el commit?

Si no hemos subido el commit a nuestro repositorio remoto

git reset --hard HEAD~1 → Se borran todos los commits posteriores al que
indicamos

git reset --soft HEAD~1 → No perdemos los cambios de los commits posteriores.

11
Si hemos subido el commit a nuestro repositorio remoto

Checkout

git checkout te permite ante situaciones donde hayas modificado cosas en el área de
trabajo, pero aún no las hayas pasado al área de preparación (con git add), volver a la
versión exacta del repositorio de dicho archivo, es decir, deshacer los cambios realizados.
Para ello, simplemente tienes que hacer lo siguiente:
git checkout NOMBRE_DEL_ARCHIVO
Si quieres hacer esto mismo pero para todos los archivos, utilizarás:
git checkout -- .
Si además de modificaciones, has hecho inserciones tienes que ejecutar el siguiente
comando:
git clean -df

12
Vamos a recuperar la versión de nuestro proyecto en el primer commit que hicimos. Si
hacemos git log obtenemos lo siguiente:

13
Por lo tanto f6b36a7 es el identificador de mi primer commit. Utilizando:
git checkout f6b36a7 , has solicitado cargar en tu directorio de trabajo esta
instantánea del proyecto. Pero puedes volver en cualquier momento al punto en el que te
encontrabas haciendo git checkout master.

14
Práctica 6. Conectándome a un repositorio
remoto.

Subir al remoto tu repositorio local

Primero vamos a crear el repositorio remoto, en nuestro caso en github, con el mismo
nombre que el repositorio local.

Después, ejecutando los comandos de la siguiente imagen, añadimos el ‘origin’ como el

repositorio recién creado y subimos el contenido del local al ‘origin’

15
Clonar tu repositorio remoto en local

Supongamos ahora que tenemos un repositorio en remoto y queremos clonarlo en local

para trabajar en ese proyecto.
Para seguir con el ejemplo, vamos a borrar nuestro repositorio actual en local con todo el
contenido del directorio de trabajo y posteriormente vamos a clonar el repositorio que
tenemos en github.

1º Borramos nuestro repositorio en local,

2º Clonamos nuestro repositorio remoto

Práctica 7: Actualización del repositorio local

Lo primero que vamos a hacer es desde github hacer una modificación del repositorio en
remoto, para ello vamos a editar el fichero README.txt y vamos a hacer un commit desde
github, actualizado la rama master.

16
Si nos fijamos tanto en el estado del repositorio local, como remoto, vemos que no
coinciden:

17
Git fetch + git merge
Si utilizamos git fetch, tan sólo recuperaremos la información del repositorio remoto y la
ubicará en una rama oculta del repositorio local (FETCH_HEAD), pero no hará el ‘merge’.
Así que tendremos que hacerlo manualmente si queremos que ambos repositorios estén
sincronizados.

Como vemos el contenido del fichero es diferente:

Para fusionar la rama oculta con la rama local necesitamos hacer un git merge:

18
Git pull

El comando git pull es un atajo para evitar realizar las dos acciones anteriores en un solo
paso. Cuando hacemos git pull, estamos bajando todos los cambios en el remoto en la rama
que estamos trabajando.
Vamos a hacer una prueba de cómo revertir los cambios que hemos hecho hasta ahora
tanto el remoto como en local:

En el siguiente enlace puedes ver como realizar este tipo de acciones:

https://midu.dev/como-deshacer-el-ultimo-commit-git/

Ahora partiremos desde el principio, volviendo a realizar una modificación en remoto, la

misma que anteriormente:

19
Y mediante pull vamos a actualizar nuestro repositorio local:

20
Práctica 8: Actualización del repositorio
remoto

Actualización simple

Vamos a modificar algunos ficheros en local de nuestro repositorio y vamos a hacer un

push, es este primer ejemplo, suponemos que sólo nosotros estamos modificando el
repositorio remoto.

En la siguiente captura vemos como se reflejan los cambios en el remoto.

21
Actualización del repositorio remoto no actualizado en
local

Supongamos que alguien más está colaborando con nosotros en el proyecto y que ha
hecho modificaciones en el repositorio, que aún nosotros no tenemos en nuestro local.
Realmente, a no ser que estemos utilizando un entorno visual con git, a simple vista, no
sabremos si eso se ha producido. Veamos qué ocurre si intentamos actualizar el remoto,
cuando no tenemos la última versión del mismo.

1º. Modificamos el repositorio en remoto

22
2º Modificamos el repositorio en local ficheros distintos.

Cuando intentamos hacer push, ocurre lo siguiente:

Esto ocurre porque no tenemos el repositorio actual actualizado, por lo tanto debemos hacer
un pull o fetch antes de actualizar el remoto.

23
Veamos ahora que los dos últimos commits están tanto en local como en remoto:

24
Actualización del repositorio remoto con conflictos
Pongámonos en la situación de que un colaborador de nuestro repositorio ha modificado el
fichero index.html y ha subido su versión al repositorio remoto. Posteriormente nosotros
tenemos que modificar ese mismo fichero y subirlo también al repositorio. Al subirlo, nos
dará un conflicto en el merge final que tendremos que resolver.

Veamos los pasos que tenemos que seguir para reproducir esta situación:
1º. Modificamos el fichero index.html en el repositorio remoto.

25
2º Modificamos el mismo fichero en local

Veamos que si queremos hacer un push de nuestra rama en local, nos dirá que no estamos
actualizados, ya que hay modificaciones pendientes de bajar.

Por lo tanto haremos un pull para actualizarnos:

El pull ha funcionado, pero no del todo, ya tenemos conflictos pendientes de resolver antes
de nos deje hacer el merge:

26
Ahora tenemos que resolver los conflictos y hacer un commit, para así poder hacer el push
al remoto.
Pero ¿cómo sabemos dónde está el conflicto? Pues git lo marca de la siguiente manera:

Lo que me quiere decir que yo en mi HEAD tengo una versión y la que viene pull tiene otra
versión y me las marca. Ahora tengo que quedarme con la versión que me interesa o una
mezcla de las dos, que es el caso.
Por lo tanto, editamos el fichero hasta que quede de la siguiente manera:

27
Ya podemos hacer el commit y el push de nuestros cambios al remoto:

Éste sería el estado del repositorio en local:

Y este el estado del remoto:

28
Práctica 9 Ramificaciones en git
Una rama (branch) es una bifurcación en la línea de tiempo del proyecto que nos permite
crear una copia paralela para desarrollar cambios sin afectar la versión estable (por defecto
la rama master).
Supongamos que nos mandan una tarea nueva y es hacer la página aboutus.html de
nuestra página web y para ello queremos partir de la última versión de “master”. Una vez
creada la rama, haremos las modificaciones necesarias y una vez que comprobamos que
hace lo que nosotros queramos, subiremos las modificaciones a la rama master.

Paso 1: Crear una rama

Como vemos en la siguiente imagen, en este repositorio sólo existe la rama master, por lo
tanto vamos a crear una nueva rama llamada LPG_aboutus.html_20201012, es interesante
que durante el trabajo colaborativo se establezca un protocolo en la nomenclatura de las
ramas de los diferentes colaboradores para facilitar un búsqueda.

Como vemos, la rama donde nos encontramos, es la rama marcada con un *. Vamos ahora
a hacer un checkout para posicionarnos en la rama recién creada.

Paso 2. Realizamos cambios en la rama y confirmamos

Vamos a hacer cambios, empezaremos por crear el fichero y posteriormente introduciremos
contenido.

29
Confirmamos los cambios:

Paso 3: Fusionamos las ramas

Una vez aquí tenemos dos opciones, subir la rama al remoto o no. Para esta práctica,
dejaremos la rama sólo en local y sólo subiremos los cambios resultantes de fusionarnos
con master.
Si en este punto listamos el contenido de master y de nuestra rama, vemos que son
distintos.

Necesitamos por lo tanto fusionar nuestro contenido con master. Para ello, sobre la rama
master, hacemos un git merge con nuestra rama.

Como vemos, master, ya contiene los cambios realizados en nuestra rama.

30
Paso 4: Enviamos cambios al repositorio remoto

Práctica 10: Las ramas en remoto

Subir mi rama a remoto y actualizarla

Supongamos que queremos hacer una modificación que durará por un largo tiempo y que
puede que nos interese que algún colaborador pueda verla. Necesitamos, por tanto, subirla
al remoto.
Como se puede ver en la siguiente imagen, hemos procedido igual que en la práctica
anterior, creando la rama, posicionándonos sobre ella y confirmando los cambios
pertinentes.

31
Vamos ahora a subir la rama al remoto:
git push -u origin <nombre rama>

Como podemos ver, en github aparece la nueva rama:

32
La manera de proceder para ir actualizando la rama es, modificar y confirmar los cambios
en local y subirlos al origin. Una vez que demos por finalizada la tarea, procederemos igual
que en la práctica 9, fusionando nuestra rama con master y subiéndolo al repositorio.
Cuando hablemos de workflow en git, veremos que se producen eliminación de ramas (
en local: git branch -d rama_a_borrar y en remoto:git push origin
--delete rama_a_borrar) , pero lo veremos en entorno gráfico.

Bajar rama del remoto y trabajar en ella

Vamos a crear una nueva rama en el remoto:

33
Y vamos a hacer alguna modificación y la vamos a confirmar:

Si listamos las ramas que tenemos en local, vemos que no tenemos la rama que acabamos
de crear en remoto:

Por lo tanto vamos a bajarla para poder trabajar en ella:

34
Si observamos sólo la tenemos como remota, no hay ninguna rama local con ese nombre,
pero al hacer checkout sobre ella, ya si se nos crea una rama local con ese nombre:

La manera de proceder será igual que en casos anteriores, podemos:

● Añadir modificaciones en local

● Subir modificaciones a remoto
● Descargarnos modificaciones de remoto
● Resolver conflictos si fuese necesario.

35