Git - Egg
Git - Egg
Git - Egg
TUTORIAL: GUÍA
INICIAL DE USO DE
GIT CON GITHUB
Objetivos de la Guía
En esta guía aprenderemos a:
• Instalar git
o Git Commit
o Git Push
o Git Pull
o Git Status
Los desarrolladores que trabajan en equipos están escribiendo continuamente nuevo código
fuente y cambiando el que ya existe. El código de un proyecto, una aplicación o un componente
de software normalmente se organiza en una estructura de carpetas o "árbol de archivos". Un
desarrollador del equipo podría estar trabajando en una nueva función mientras otro desarrollador
soluciona un error no relacionado cambiando código. Cada desarrollador podría hacer sus
cambios en varias partes del árbol de archivos.
El control de versiones ayuda a los equipos a resolver estos tipos de problemas, al realizar un
seguimiento de todos los cambios individuales de cada colaborador y ayudar a evitar que el
trabajo concurrente entre en conflicto.
1
En definitiva, tener un control de los cambios en los códigos de nuestra aplicación es una variable
crucial para el éxito de nuestro desarrollo. Git es un sistema de control de versiones de código
abierto, diseñado para manejar grandes y pequeños proyectos con rapidez y eficiencia. La
pretensión de este tutorial es abordar el uso básico de Git proporcionando ejemplos prácticos
útiles para comenzar a administrar repositorios remotos con plataformas
como Bitbucket o GitHub.
P¿QUÉ ES GIT?P
Git es la mejor opción para la mayoría de los equipos de software actuales. Aunque cada equipo
es diferente y debería realizar su propio análisis, aquí recogemos los principales motivos por los
que destaca el control de versiones de Git con respecto a otras alternativas:
Git goza de una amplia base de usuarios y de un gran apoyo por parte de la comunidad. La
documentación es excepcional y para nada escasa, ya que incluye libros, tutoriales y sitios web
especializados, así como podcasts y tutoriales en vídeo.
El hecho de que sea de código abierto reduce el costo para los desarrolladores aficionados,
puesto que pueden utilizar Git sin necesidad de pagar ninguna cuota. En lo que respecta a los
proyectos de código abierto, no cabe duda de que Git es el sucesor de las anteriores
generaciones de los exitosos sistemas de control de versiones de código abierto, SVN y CVS.
P¿QUÉ ES GITHUB?P
Github es un portal creado para alojar el código de las aplicaciones de cualquier desarrollador. La
plataforma está creada para que los desarrolladores suban el código de sus aplicaciones y
herramientas, y que como usuario no solo puedas descargarte la aplicación, sino también entrar a
su perfil para leer sobre ella o colaborar con su desarrollo.
Un sistema de gestión de versiones es ese con el que los desarrolladores pueden administrar su
proyecto, ordenando el código de cada una de las nuevas versiones que sacan de sus
aplicaciones para evitar confusiones. Así, al tener copias de cada una de las versiones de su
aplicación, no se perderán los estados anteriores cuando se va a actualizar.
Git, al ser un sistema de control, va ser la herramienta que nos va a permitir comparar el código de
un archivo para ver las diferencias entre las versiones, restaurar versiones antiguas si algo sale
mal, y fusionar los cambios de distintas versiones.
Así pues, Github es un portal para gestionar proyectos usando el sistema Git.
2
¿CÓMO VAMOS A LOGRAR ESO?
Github permite que los desarrolladores alojen proyectos creando repositorios de forma
gratuita. Un repositorio es como una carpeta para tu proyecto. El repositorio de tu proyecto
contiene todos los archivos de tu repositorio y almacena el historial de revisión de cada archivo.
También puedes debatir y administrar el trabajo de tu proyecto dentro del repositorio.
¿Cómo se ve en GitHub?
Para subir tu proyecto a GitHub, deberás crear un repositorio donde alojarlo. Para poder crear un
repositorio deberemos crearnos una cuenta en GitHub.
3
2) Escribe un nombre corto y fácil de recordar para tu repositorio. Por ejemplo: "hola-mundo".
3) También puedes agregar una descripción de tu repositorio. Por ejemplo, "Mi primer repositorio
en GitHub".
4) Elige la visibilidad del repositorio. Puedes restringir quién tiene acceso a un repositorio
eligiendo la visibilidad de un repositorio: público o privado. Publico significa que cualquier
persona puede ver ese repositorio y privado significa que solo personas autorizadas pueden
verlo. Que sea publico no significa que la gente puede subir cosas a nuestro repositorio, lo
único que permite es que se puedan ver los archivos.
4
5) Podemos crear el repositorio con un ReadMe
• Crear tu repositorio
5
Si bien esta compilación de Git está bien para algunos usuarios, es posible que desee instalar la
versión más actualizada. Puede hacerlo de muchas formas diferentes; hemos recopilado algunas
de las opciones más fáciles a continuación. Recordamos que si ya tenemos Git en nuestra Mac, no
es necesario instalarlo, solo si queremos una versión más nueva.
https://sourceforge.net/projects/git-osx-installer/files/
Abre un terminal y escribe el siguiente texto para comprobar que la instalación se ha realizado
correctamente:
git --version:
$ git --version
git version 2.9.2
Esta opción SOLO la vamos a utilizar si no nos funcionó la opción anterior, de lo contrario obviar
esta parte de la guía.
Homebrew instala una lista de paquetes útiles que no vienen preinstalados en Mac.
B. El terminal le pedirá que ingrese una contraseña. Ingrese la contraseña que usa para
iniciar sesión en su Mac y continuar con el proceso de instalación.
C. Una vez terminado, ingrese brew install git en la terminal y espere a que se descargue.
Verifique que Git se instaló ejecutando git –version
6
2. Introduce el siguiente texto para verificar que la instalación se ha realizado correctamente:
git --version:
$ git --version
git version 2.9.2
3. Selecciona las opciones Siguiente y Finalizar para completar la instalación. Las opciones
predeterminadas son las más lógicas en la mayoría de los casos.
4. Abre el símbolo del sistema (o Git Bash si durante la instalación seleccionaste no usar Git
desde el símbolo del sistema de Windows).
5. Introduce el siguiente texto para verificar que la instalación se ha realizado correctamente:
git --version:
$ git --version
git version 2.9.2
7
P¿QUÉ ES EL GIT TOKEN EN GITHUB?P
Para poder subir nuestros cambios o nuestras tareas a GitHub, vamos a tener que configurar
nuestro Personal Access Token, este le permite a GitHub autenticar que eres tú, el que está
tratando de subir cosas al GitHub. De modo que puedas realizar todo tipo de operativas, como
clonar repositorios o enviar cambios a GitHub desde local a remoto.
En GitHub han declarado recientemente como obsoleta la autenticación por medio de usuario y
clave y ahora los desarrolladores debemos autenticarnos a través de lo que llaman el Personal
Access Token. Esta acción debes hacerla para poder conectarte y realizar cualquier tipo de
operativa con el servicio de GitHub.
Este procedimiento lo tendrás que hacer en todo lugar donde necesites una clave para poder
utilizar GitHub desde fuera del sitio web. Por ejemplo, clonar un repositorio privado de GitHub en
local, enviar cambios a GitHub con Push, traerte cambios con Pull, etc.
8
Las siguientes opciones las accedes mediante el navegador vertical de la izquierda. Ahí pulsamos
la opción Developer Settings y luego Personal Access Tokens.
Entonces accederás a una página donde puedes administrar tus Personal Access Tokens.
Aquí vamos a crear un nuevo token con el botón Generate new token.
9
Entonces aparecerá un formulario que debes rellenar, indicando el nombre del token (para saber
en qué lo vas a utilizar) y otros detalles como la expiración del token y los scopes.
Nombre Token
Expiración Token
Scopes:
10
Los scopes son simplemente las operaciones que estarán o no permitidas desde este token. Lo
más común es que des permisos para acceder a los repositorios remotos alojados en GitHub, pero
existen otras operativas que puedes hacer o no tú y que podrías permitir o no con este token que
vas a crear.
¡Por supuesto, no lo debes pegar en el código de ninguna aplicación, para no dejarlo visible para
otras personas!! o tus accesos a GitHub podrían verse comprometidos.
Otro detalle importante es que este token solamente aparecerá una vez en la página de GitHub.
Si lo necesitas recuperar porque lo has perdido simplemente no podrás hacerlo. Tendrás que
generar uno nuevo.
Por ejemplo, en la siguiente imagen vemos el comando de clonado de un repositorio. Cuando nos
piden la clave, simplemente colocamos toda la cadena del token que hemos copiado en GitHub.
Con esto habremos autenticado con el token correctamente y podremos acceder a los servicios
de GitHub.
11
CACHEO DEL PERSONAL ACCESS TOKEN
El PAT(Personal Access Token) se utilizará solo en operaciones de HTTPS, para cada operación
nos pedirá que lo ingresemos de nuevo, para evitar eso podemos realizar un cacheo del PAT, de
esa manera no tendremos que ingresarlo para cada operación.
El cacheo del Access Token lo puedes realizar en cualquier sistema operativo por medio de Git.
En MacOS se hace automáticamente con la aplicación de llaves. Para los usuarios de otros
sistemas operativos como Linux y Windows en la documentación de GitHub encontramos algunas
otras indicaciones interesantes.
En Linux te informan de dos comandos útiles. Este te permite indicar que las credenciales se
cacheen:
Y este otro comando te permite que las credenciales permanezcan cacheadas por el tiempo que
tú estimes conveniente. El tiempo se indica en segundos. Por ejemplo, para cachear las
credenciales por 3 horas lanzas el siguiente comando.
Eso es todo! Espero que con estas indicaciones puedas realizar toda la configuración de GitHub
para el acceso desde el terminal en local y poder administrar tus repositorios remotos.
Para abrir la aplicación tendremos que hacer Barra Espaciadora + Commnad ⌘ y ahí
escribiremos Keychain Access o Acceso a Llaveros. Cuando aparezca le damos al Enter
12
Las credenciales son las que tienen el arroba @ azul. Puede ser que nos salgan dos credenciales
de GitHub, tenemos que abrir la que tenga nuestra cuenta como credencial. Para revisarlo le
haremos doble click a la credencial y ahí nos va a mostrar la credencial y dentro podremos ver la
cuenta. Se vería algo así:
Dentro de la credencial con nuestra cuenta, vamos a agregar el Token. Para esto vamos a copiar
el token y dentro de la credencial vamos a darle a Mostrar contraseña o Show Password, nos va
a pedir la contraseña de nuestra computadora, ingresamos la contraseña y le damos a Permitir.
Después de realizar este paso, puede ser que al intentar hacer alguna operativa de nuevo con
GitHub se pedirá tu usuario y contraseña, e introducirás tu usuario y el token.
13
Revisemos lo aprendido hasta aquí
PCONFIGURACIÓN INICIALP
Abra su terminal de Git para comenzar con la ejecución de comandos, por ejemplo, abrirá el
programa Git bash en Windows para ingresar a la línea de comandos de este programa.
Una vez que ingrese, use el siguiente comando para establecer el nombre de usuario de git:
Recuerde sustituir el texto entre comillas por su nombre real. Ahora indique el correo electrónico
del usuario para git:
Sustituyendo el texto entre comillas por su cuenta de correo electrónico. Esta configuración inicial
debería ser suficiente para comenzar. Para comprobar otros valores de su configuración actual
ejecute:
...
color.diff=auto
color.status=auto
...
user.name=Juan Perez
user.email=micorreopersonal@juan.com
14
P¿CÓMO TRABAJAMOS CON GIT?P
Para trabajar con Git con Github tenemos dos formas de trabajar:
Vamos a elegir de momento la opción 1) que nos permitirá comenzar desde cero y con la que
podremos apreciar mejor cuáles son las operaciones básicas con Git. En este sentido, cualquier
operación que realizas con Git tiene que comenzar mediante el trabajo en local, por lo que tienes
que comenzar por crear el repositorio en tu propia máquina. Incluso si tus objetivos son
simplemente subir ese repositorio a Github para que otras personas lo puedan acceder a través
del hosting remoto de repositorios, tienes que comenzar trabajando en local.
Los repositorios locales residen en las computadoras de los miembros del equipo. Por el
contrario, los repositorios remotos se alojan en un servidor al que pueden acceder todos los
miembros del equipo, probablemente en Internet o en una red local.
Nosotros trabajaremos en nuestro repositorio local y cuando sintamos que lo que hemos hecho
está bien o ya está listo, lo subiremos a nuestro repositorio remoto, de esa manera todos lo
cambios que hayamos hecho estarán subidos a internet y nuestros compañeros de equipo podrán
verlos. Pero esto significa que mientras estemos trabajando, estaremos trabajando en el
repositorio local y después unificaremos con el remoto.
En Windows podemos hacer click derecho a la carpeta y darle a Git Bash Here, eso nos abrirá la
terminal Git Bash en la carpeta para trabajar Git.
En Mac podemos hacer lo mismo, click derecho a la carpeta y darle a la opción Nuevo Terminal
en la carpeta.
Una vez parados en nuestra carpeta. Para crear un nuevo repositorio, usa el comando git init. git
init es un comando que se utiliza una sola vez durante la configuración inicial de un repositorio
nuevo. Al ejecutar este comando, se creará un nuevo subdirectorio .git en tu directorio de trabajo
actual. También se creará una nueva rama principal.
git init
15
¿COMO VINCULAMOS NUESTRO REPOSITORIO CON GITHUB?
Primero deberemos crear un repositorio, sin el archivo readME.
Una vez que tenemos el archivo agregado y guardado de manera local, tenemos que vincular este
repositorio local a un repositorio remoto en GitHub. Para esto vamos a utilizar el comando git
remote add.
Este comando va a tomar el alias nuestro repositorio y la url de nuestro repositorio en GitHub, con
esto va a vincularlo con nuestro repositorio local.
El alias que vamos a utilizar para Github es origin y para obtener la url de nuestro repositorio,
podemos encontrarla al principio de nuestro repositorio:
Buscamos el url de nuestro repositorio de GitHub y lo hacemos en nuestro terminal. Por lo que
pondremos:
Git Status
El comando de git status nos da toda la información necesaria sobre la rama actual.
git status
16
Nota: veremos el concepto de ramas más adelante.
Git Add
Necesitamos usar el comando git add para incluir los cambios del o de los archivos en tu siguiente
commit.
git add .
Si revisas la captura de pantalla del git status, verás que hay nombres de archivos en rojo - esto
significa que los archivos sin preparación. Estos archivos no serán incluidos en tus commits hasta
que no los añadas.
Hacemos un git add . para agregar nuestro archivo txt. Una vez que hacemos el git add hacemos
otro git status, ahora veremos que los archivos que estaban en rojo, están en verde, esto quiere
decir que ya los hemos agregado para hacer nuestro commit.
Git Commit
Este sea quizás el comando más utilizado de Git. Una vez que se llega a cierto punto en el
desarrollo, queremos guardar nuestros cambios (quizás después de una tarea o asunto específico)
o subir un archivo / proyecto.
Git commit es como establecer un punto de control en el proceso de desarrollo al cual puedes
volver más tarde si es necesario. Es como un punto de guardado en un videojuego.
También necesitamos escribir un mensaje corto para explicar qué hemos desarrollado o
modificado en el código fuente.
17
git commit -m "mensaje de confirmación"
Hacemos un commit para guardar nuestro txt y le ponemos un mensaje que explique que hemos
hecho.
Todos estos “puntos de guardado” se van a guardar en la rama donde estemos parados, en esta
guía vamos a trabajar sobre la rama Main, más adelante explicaremos que es una rama. Pero
ahora pienselo como el lugar donde se guardarían todos esos “puntos de guardado”.
Acá podemos ver que, sobre la misma línea, que seria la rama Main, tenemos el commit 0, el
commit 1, el commit 2 y el commit 3, que serían todos nuestros cambios, sobre el proyecto.
Nosotros podemos acceder a todos esos commit y volver hacia atrás a esos “puntos de
guardado”, para tener una versión “antigua” del proyecto.
Nombre remoto
De nombre remoto usualmente vamos a poner la palabra origin, pero ¿que significa la palabra
origin?
En nuestra vida como desarrolladores cuando utilizamos Git generalmente vamos a tener varios
repositorios remotos contra los que trabajamos. Bien, pues origin es simplemente el nombre
predeterminado o alias que recibe el repositorio remoto principal contra el que trabajamos.
Cuando clonamos o creamos un repositorio por primera vez desde GitHub o cualquier otro
sistema remoto, el nombre que se le da a ese repositorio es precisamente origin.
Básicamente origin es el alias que se le da a la url del repositorio remoto, nosotros en vez de
poner push, más, el url del repositorio remoto al que queremos pushear, usamos el alias origin
para especificarle que tiene que pushear a ese repositorio remoto concreto.
18
De todos modos, ese nombre se puede cambiar, y se pueden crear más remotos contra los que
hacer push. Pero en un porcentaje muy alto de los casos, como ese nombre por omisión no se
cambia, puedes asumir que vas a enviar la información a origin.
Nombre de tu rama
Cuando creamos un repositorio en GitHub, nos crea una rama por defecto llamada main, que será
a la rama que tendremos que pushear.
Una vez que hemos hecho esto, si refrescamos nuestro repositorio vamos a ver nuestro archivo txt
en nuestro repositorio de GitHub.
Este proceso se va a repetir, quitando la vinculación y la inicialización del repositorio, cada vez
que nosotros hagamos un cambio dentro de nuestro repositorio. Esto puede ser modificar un
archivo ya existente o agregar más archivos a la carpeta local.
Rama en Git es similar a la rama de un árbol. De manera análoga, una rama de árbol está unida a
la parte central del árbol llamada tronco. Si bien las ramas pueden generarse y caerse, el tronco
permanece compacto y es la única parte por la cual podemos decir que el árbol está vivo y en
pie. De manera similar, una rama en Git es una forma de seguir desarrollando y codificando una
nueva función o modificación del software y aún así no afectar la parte principal del proyecto. La
rama principal o predeterminada en Git es la rama maestra o main (similar al tronco de un
árbol) . Tan pronto como se crea el repositorio, también lo hace la rama principal ( o la rama
predeterminada ).
Básicamente la rama va a ser el lugar donde se guarden nuestros commits (nuestros cambios) y
podamos ver todos los cambios que vayamos haciendo a lo largo del tiempo reflejados en esa
rama.
Como nosotros por ahora no vamos a trabajar con ramas, ósea, no vamos a crear más ramas o
borrar ramas, etc. Vamos a simplemente trabajar con la rama main, por eso cuando queramos
subir nuestros cambios al repositorio remoto, vamos a utilizar la rama main, ya que es la única que
tenemos disponible por ahora.
19
PFLUJO DE TRABAJO GITP
Ahora que conocemos todos los comandos que vamos a ver en esta guía de Git con GitHub.
Vamos a ver un diagrama, de como se verían todos los comandos previamente mencionados, git
add, git commit y git push, en un flujo de trabajo normal.
En este diagrama se muestra cual sería el flujo de trabajo de Git con GitHub. Para poder entender
este diagrama, vamos a primero explicar los tres estados de nuestros archivos que existen en Git.
Tres estados
Git tiene tres estados principales en los que se pueden encontrar tus archivos: confirmado
(committed), modificado (modified), y preparado (staged).
• Confirmado: significa que los datos están almacenados de manera segura en tu base de
datos local.
• Modificado: significa que has modificado el archivo, pero todavía no lo has confirmado a
tu base de datos.
• Preparado: significa que has marcado un archivo modificado en su versión actual para que
vaya en tu próxima confirmación.
Esto nos lleva a las tres secciones principales de un proyecto de Git: El directorio de Git (Git
directory), el directorio de trabajo (working directory), y el área de preparación (staging area).
El directorio de Git es donde se almacenan los metadatos y la base de datos de objetos para tu
proyecto. Es la parte más importante de Git, es el subdirectorio .git que se crea cuando
ejecutamos el comando git init. Y también, es lo que se copia cuando clonas un repositorio desde
otra computadora.
El directorio de trabajo es una copia de una versión del proyecto. Estos archivos se sacan de la
base de datos comprimida en el directorio de Git, y se colocan en disco para que los puedas usar
o modificar. O esto seria el proyecto que tenemos de manera local y se convierte en directorio de
trabajo cuando le hacemos un git init, ya que, como dijimos el proyecto pasa a tener un directorio
de git, cuando ejecutamos dicho comando.
20
El área de preparación es un archivo, generalmente contenido en tu directorio de Git, que
almacena información acerca de lo que va a ir en tu próxima confirmación (commit). A veces se le
denomina índice (“index”), pero se está convirtiendo en estándar el referirse a ella como el área de
preparación. Esto se generaría con el comando git add, porque “agregaríamos” que información
queremos enviar en el commit.
3. Confirmas los cambios, lo que toma los archivos tal y como están en el área de
preparación y almacena esa copia instantánea de manera permanente en tu directorio de
Git. (Git Commit)
Podemos ver como el cuadrado, empieza en el directorio de trabajo, pasa al área de preparación
con el Git Add, después se confirman los cambios con el Git Commit y pasa al repositorio local y
por último el push envía ese cuadrado al repositorio remoto, que seria el repositorio que tenemos
en GitHub
21
CLONAR UN REPOSITORIO
Ahora vamos a hablar de la operativa de clonado de un repositorio, el proceso que tienes que
hacer cuando quieres traerte el código de un proyecto que está publicado en GitHub y lo quieres
restaurar en tu ordenador, para poder usarlo en local, modificarlo, etc.
Este paso es bastante básico y muy sencillo de hacer, pero es esencial porque lo necesitarás
realizar muchas veces en tu trabajo como desarrollador. Además, intentaremos complementarlo
con alguna información útil, de modo que puedas aprender cosas útiles y un poquito más
avanzadas.
DESCARGAR VS CLONAR
Al inicio de uso de un sitio como GitHub, si no tenemos ni idea de usar Git, también podemos
obtener el código de un repositorio descargando un simple Zip. Esta opción la consigues
mediante el botón de la siguiente imagen.
Sin embargo, descargar un repositorio así, aunque muy sencillo no te permite algunas de las
utilidades interesantes de clonarlo, como:
• No crea un repositorio Git en local con los cambios que el repositorio remoto ha tenido a
lo largo del tiempo. Es decir, te descargas el código, pero nada más.
• No podrás luego enviar cambios al repositorio remoto, una vez los hayas realizado en
local.
En resumen, no podrás usar en general las ventajas de Git en el código descargado. Así que es
mejor clonar, ya que aprender a realizar este paso es también muy sencillo.
Primero copiarás la URL del repositorio remoto que deseas clonar (ver el icono "Copy to
clipboard” en la siguiente imagen).
22
Luego abrirás una ventana de terminal, para situarte sobre la carpeta de tu proyecto que quieras
clonar. Yo te recomendaría crear ya directamente una carpeta con el nombre del proyecto que
estás clonando, o cualquier otro nombre que te parezca mejor para este repositorio. Te sitúas
dentro de esa carpeta y desde ella lanzamos el comando para hacer el clon, que sería algo como
esto:
El último punto, después de la url copiada desde git, le indica que el clon lo vas a colocar en la
carpeta donde estás situado, en tu ventana de terminal. La salida de ese comando sería más o
menos como tienes en la siguiente imagen:
De esta manera nosotros ya tenemos el repositorio remoto para trabajar local y podremos hacer
los cambios que queramos y subir los cambios con los comandos que explicamos previamente.
• Clonar un repositorio
23
pImportantep
Para que sigas practicando esta herramienta tan importante, los ejemplos
de las siguientes guías para descargar, van a estar alojados en el siguiente
portal de tu curso con repositorios. La idea es que practiquen descargar
esos ejemplos usando Git y así no perder la practica. ¡¡Recomendamos que
se guarden este link para siempre tenerlo a mano!!
GitHub Egg: https://github.com/EggCooperation
PEJERCICIOS DE APRENDIZAJEP
Ahora es momento de poner en practica todo lo visto en la guía.
VIDEOS: Te sugerimos ver los videos relacionados con este tema, antes de empezar los
ejercicios, los podrás encontrar en tu aula virtual o en nuestro canal de YouTube.
PRIMER EJERCICIO
1) Tendremos que crear desde GitHub un repositorio SIN ARCHIVO README y copiar la URL
directa hacia el repositorio.
2) Crear una carpeta que contenga un archivo .txt con un mensaje inicial
3) Recordar que deberemos inicializar el repositorio haciendo click derecho sobre la carpeta
que contiene el archivo y abrir Git . O también podremos hacer click derecho en un lugar
en blanco al costado del archivo .txt. Inicializar el repositorio con:
4) git init
7) Luego controlo los cambios que están bajo observación en la rama principal con:
8) git status
13) Y finalmente hago un git push origin para mandar mis cambios al repositorio remoto
14) Podría cambiar el mensaje del .txt y repetir los pasos desde el 2 al 10 y debería ver en la
página de git mis cambios
24
Todo lo que hacemos desde el paso 2 al 9 debemos repetirlo en todos
los ejercicios que quisiéramos guardar en nuestro Git personal.
Desde Egg sugerimos hacerlo con todos los siguientes ejercicios y
cada vez que terminemos nuestra jornada de estudio. Lo
recomendamos por dos motivos: uno, para practicar Git desde ahora
hasta la última guía y dos, para que nuestros ejercicios no se pierdan
ante algún eventual problema en nuestra computadora.
SEGUNDO EJERCICIO
1) Tendremos que pedirle un repositorio publico a algún estudiante de nuestro curso.
3) Tendremos que abrir Git en alguna carpeta y correr el comando git clone
URL_ESTUDIANTE
25
CURSO DE PROGRAMACIÓN FULL STACK
TUTORIAL: GUÍA DE
GIT Y GITHUB CON
RAMAS
PREPASO DE COMANDOSP
Veamos un cuadro con los comandos que ya aprendimos
Comando Explicación
Objetivos de la Guía
En esta guía aprenderemos a:
• Fusionar ramas
1
PRAMAS EN GITP
En la guía anterior vimos que una rama en Git es similar a la rama de un árbol. De manera análoga,
una rama de árbol está unida a la parte central del árbol llamada tronco. Si bien las ramas pueden
generarse y caerse, el tronco permanece compacto y es la única parte por la cual podemos decir
que el árbol está vivo y en pie. De manera similar, una rama en Git es una forma de seguir
desarrollando y codificando una nueva función o modificación del software y aún así no afectar la
parte principal del proyecto. También vimos que la rama principal o predeterminada en Git es la
rama maestra o main.
En esta guía vamos a ver como nos pueden ayudar para el trabajo grupal y de que manera
podemos crear nuestra propia rama.
Una rama en el trabajo grupal se ve como una línea independiente de desarrollo. Las ramas
sirven como una abstracción de los procesos de cambio, preparación y confirmación (commit).
Puedes concebirlas como una forma de solicitar un nuevo directorio de trabajo o un nuevo
entorno de ensayo.
Las ramas son espacios de desarrollo independientes que emergen de la rama principal cuando
quieres añadir una nueva función o solucionar un error, independientemente de su tamaño,
generas una nueva rama para alojar estos cambios. Esto hace que resulte más complicado que el
código inestable se fusione con el código base principal, y te da la oportunidad de limpiar tu
historial futuro antes de fusionarlo con la rama principal.
Funcionalidad Pequeña
Rama Main
Funcionalidad Grande
El diagrama anterior representa un repositorio con dos líneas de desarrollo aisladas, una para una
funcionalidad pequeña y otra para una funcionalidad más extensa. Al desarrollarlas en ramas, no
solo es posible trabajar con las dos de forma paralela, sino que también se evita que el código
dudoso se fusione con la rama main.
Explicándolo de otra manera, la rama main va a ser donde este alojado el proyecto final, el
proyecto que va a tener todo lo que se trabaje en las demás ramas y las ramas van a ser los
lugares en donde cada persona trabajara su parte del proyecto sin afectar al proyecto final que se
encuentra en la rama main.
2
Ahora veremos como se crea una rama propia, como borrarlas y como unir nuestras ramas con la
rama principal (rama main)
VER RAMAS
Para ver las ramas en un repositorio Git, ejecuta el comando:
git branch
Para ver tanto las ramas de seguimiento remoto como las ramas locales, ejecuta el comando:
git branch -a
Podemos obtener una descripción más detallada de las ramas con este otro comando:
git show-branch
Esto nos muestra todas las ramas del proyecto con sus commits realizados. La salida sería como la
de la siguiente imagen.
3
Revisemos lo aprendido hasta aquí
Rama Main
Commit 1
4
Rama Main
Commit 1
Experimento
Ten en cuenta que este comando solo crea la nueva rama tendrás que usar git checkout para
moverte a ella y a continuación, utilizar los comandos estándar git add y git commit. Pero, hay un
atajo para crear y moverte a la nueva rama al mismo tiempo. Puedes pasar la opción b (para
rama) con git checkout. Los siguientes comandos hacen lo mismo:
# Método de 2 pasos
# Atajo
Si corriéramos un git show-branch podríamos ver la rama nueva ya tiene el primer commit que
realizamos en la rama main porque como explicamos más arriba, estamos clonando la rama main.
5
Revisemos lo aprendido hasta aquí
CAMBIOS EN LA RAMA
De momento en nuestro ejemplo las dos ramas tenían exactamente el mismo contenido, pero
ahora podríamos empezar a hacer cambios en el proyecto ramaGit y sus correspondientes commit
y entonces los archivos tendrán códigos diferentes, de modo que puedas ver que al pasar de una
rama a otra hay cambios en los archivos.
Al igual que explicamos antes cada vez que quieras subir un cambio a tu branch sitúate en ella y
ejecuta los comandos:
No vamos a hacer un push todavía porque eso lo vamos a explicar más adelante, ya que eso hará
que nuestra rama aparezca en el repositorio remoto.
Habiendo hecho un commit en nuestra nueva rama, observarás que al hacer el show-branches te
mostrará nuevos datos:
Como podras ver, el proyecto puede tener varios estados en un momento dado y tú podrás
moverte de uno a otro con total libertad y sin tener que cambiar de carpeta ni nada parecido.
Experimento
Rama Main
Rama Develop
6
Revisemos lo aprendido hasta aquí
Para subir una rama en remoto la haces mediante el comando push, indicando el nombre de la
rama que deseas subir. Por ejemplo, de esta manera:
Si no quieres poner siempre origin y el nombre de tu rama en tus push, tienes que sumarle al
push anterior, -u antes de la palabra origin. Esto hará que puedas poner git push solamente y vaya
siempre a esa rama.
Es importante asegurarse que lo hagamos en una rama nuestra y no en main, ya que podríamos
mandar cambios a la rama main pensando que iban a la nuestra.
git push
7
Y ahí podremos ver las dos ramas
Podes subir tanto commits como creas convenientes a tu rama antes de fusionar tus cambios con
la rama main, siempre es mejor pequeños y frecuentes cambios que pocos y grandes.
PFUSIONAR RAMASP
A medida que crees ramas y cambies el estado de las carpetas o archivos de tu proyecto
empezará a divergir de una rama a otra. Llegará el momento en el que te interese fusionar ramas
para poder incorporar el trabajo realizado a la rama main.
8
El proceso de fusionado se conoce como merge y puede llegar a ser muy simple o más complejo
si se encuentran cambios que Git no pueda procesar de manera automática. Git para procesar los
merge usa un antecesor común y comprueba los cambios que se han introducido al proyecto
desde entonces, combinando el código de ambas ramas.
Para hacer un merge nos situamos en una rama, en este caso la "main", y decimos con qué otra
rama se debe fusionar el código.
El siguiente comando, lanzado desde la rama "main", permite fusionarla con la rama "ramaGit".
9
PPULL REQUESTP
Previamente habíamos fusionado nuestras ramas a través del comando merge, pero GitHub nos
permite fusionar nuestras ramas y además ver los cambios que hay entre una rama y otra, gracias
al Pull Request.
Vamos a pararnos de nuevo en una etapa en donde no hemos mergeado las ramas. Hasta ese
punto habíamos logrado independizar nuestros cambios de los del resto del equipo, pero se
acercaba la hora de publicar nuestros cambios y surge la necesidad de conocer y/o validar cuan
diferente es nuestra versión y de ver que todo está bien fusionar esos cambios. Aquí es donde la
herramienta de pull request viene al rescate.
Para crear un pull request debemos ir a la sección de branches, buscar nuestro branch y clickear
en el botón New pull request.
Antes de hacer nuestro pull request, podemos ver, cuantos commits (cambios) son los que
separan a otra rama de main. Si nos fijamos nos salen dos ceros, pero si main estuviera un commit
por delante de alguna rama saldrían un uno en el cero de la izquierda y asi se incrementa el
numero según la cantidad de commits que este por delante main. Ahora, si el numero estuviera a
la derecha, sería que la otra rama está x commits por delante main.
Como podemos ver ramaGit está un commit por delante de main, por lo que si mergeamos las
ramas, sería solo un commit el que se le aplicaría a main.
10
Nos mostrará algo similar a lo siguiente.
Referencias:
2. En esta sección podremos poner un titulo informativo de que se tratan nuestros cambios y
una descripción como documentación adicional. Detalle de los cambios propuestos, test
plan, etc.
4. En la ultima sección nos muestra el detalle de los archivos modificados. Para visualizar los
cambios podemos alternar entre los modos de vista “Unified” y “Split”
Hasta este momento aún no hemos creado nada, solo estamos viendo un resumen previo, para
continuar clickeamos en el botón “Create pull request”. A continuación, veremos el pull request
creado de la siguiente manera.
11
Por otro lado, podemos usar la pestaña de “Files changed” para hacer code review.
Si detectamos alguna línea de código que requiera cambios puedes clickear sobre ella y agregar
un comentario para que el autor del pull request lo modifique. No es necesario volver a crear un
nuevo pull request para actualizar los cambios, simplemente haciendo un commit sobre el branch
es suficiente, GitHub toma los cambios y actualiza el pull request automáticamente.
12
Si esta todo bien y no hay conflictos podemos mergear nuestro branch a main clickeando en el
botón “Merge pull request” y de eso modo finaliza el ciclo del branch.
Finalmente tenemos la opción de aprobar los cambios para que el autor del pull request mergee
su cambio.
Una vez que unamos los cambios en nuestra ramas nos va a salir que la rama ha sido mergeada.
13
PDESCARGAR CONTENIDO DESDE UN REPOSITORIO REMOTOP
En la guía anterior vimos como clonar un repositorio, pero imaginemos que ya estamos trabajando
en dicho repositorio con un grupo de personas. A veces ocurre que las personas del equipo
generan sus propias ramas en remoto, donde trabajarán su parte del proyecto por ejemplo
cuando han sido creadas por otros usuarios y subidas al hosting de repositorios.
Ahora supongamos necesitamos acceder a las ramas y su contenido en local para verificar los
cambios o continuar el trabajo. En principio esas ramas en remoto creadas por otros usuarios no
están disponibles para nosotros en local, pero las podemos descargar.
GIT PULL
Git pull se utiliza para mantener el repositorio actualizado con los cambios que haya habido. No
siempre, pero en muchos casos hay más de una persona trabajando en un repositorio, por lo que
cuando una persona hace cambios en un repositorio remoto con un git push, nuestro repositorio
local estará desactualizado y tendremos que traernos los cambios que se hayan hecho.
Supongamos que un compañero nuestro hace un cambio y nosotros debemos seguir trabajando
sobre ese cambio, para esto nos sirve usar el git pull
Git pull comprueba si hay cambios en el repositorio remoto y, en caso de que los haya, se trae
esos archivos a tu repositorio local y actualiza tu espacio de trabajo (tu IDE, tus archivos).
Es uno de los cuatro comandos que solicita interacción de red por Git. Por default, git pull hace
dos cosas.
2. Actualiza las referencias de rama remota para todas las demás ramas.
git pull recupera (git fetch) los nuevos commits y las fusiona (git merge) en tu rama local.
Rama Remota
origin/main
Nuestra rama está en el commit inicial que es commit D, la rama de otra persona está en el commit
C y el Main está en el commit G.
En este caso, git pull descargará todos los cambios desde el punto de separación de la rama local
y la rama principal. En el ejemplo de arriba, ese punto es E. El comando git pull recuperará los
commits remotos divergentes, que son A, B y C. A continuación, el proceso de incorporación de
cambios creará otro de fusión local que incluya el contenido de las nuevas confirmaciones
remotas divergentes.
14
Rama Remota
origin/main
Rama Main
Principal
Ahora podemos ver que la incorporación mediante cambio de base no ha creado la confirmación
H, sino que el cambio de base ha copiado los commits remotos A, B y C y ha reescrito los commits
locales E, F y G para que aparezcan después de ellas en el historial de commits principales o de
origen locales.
Suelen referenciarse como (remoto)/(rama). Por ejemplo, si quieres saber cómo estaba la rama
main en el remoto origin, puedes revisar la rama origin/main. O si estás trabajando en un
problema con un compañero y este envía (push) una rama develop, tú tendrás tu propia rama de
trabajo local develop; pero la rama en el servidor apuntará a la última confirmación (commit) en la
rama origin/develop.
Esto puede ser un tanto confuso, pero intentemos aclararlo con un ejemplo. Supongamos que
tienes un servidor Git en tu red, en git.ourcompany.com. Si haces un clon desde ahí, Git
automáticamente lo denominará origin, traerá (pull) sus datos, creará un apuntador hacia donde
esté en ese momento su rama main y denominará la copia local origin/main. Git te proporcionará
también tu propia rama main, apuntando al mismo lugar que la rama main de origin; de manera
que tengas donde trabajar.
Por ejemplo:
Si tienes cambios no confirmados, la parte de fusión del comando git pull fallará y tu rama local
quedará intacta.
Por lo tanto, siempre deberías confirmar tus cambios en una rama antes de actualizar nuevas
confirmaciones de un repositorio remoto.
15
Revisemos lo aprendido hasta aquí
16
PINVITAR COLABORADORES A UN REPOSITORIO PERSONALP
Nosotros vimos como clonar un repositorio para poder usar su código y si quisiéramos hacer
cambios y subir esos cambios. Todos los usuarios de GitHub pueden ver y clonar tu repositorio,
siempre y cuando sea un repositorio público. Pero, no todas las personas que clonan tu
repositorio pueden subir sus cambios, ya que GitHub entiende que los repositorios son de nuestra
propiedad y somos los únicos que podemos modificarlo.
Ahora, como hacemos cuando queremos que varias personas trabajen en un mismo repositorio y
queremos que GitHub les deje subir esos cambios. Para ese dilema GitHub nos deja invitar
colaboradores a nuestro proyecto. Esto se hará de la siguiente manera:
17
7. Da clic en Añadir a nombreRepositorio.
8. El usuario recibirá un correo electrónico invitándolo al repositorio. Una vez que acepte la
invitación, tendrá acceso de colaborador a tu repositorio. Las invitaciones pendientes
caducarán después de 7 días. Esto restablecerá cualquier licencia sin reclamar.
18
PEJERCICIOS DE APRENDIZAJEP
Ahora es momento de poner en práctica todo lo visto en la guía.
VIDEOS: Te sugerimos ver los videos relacionados con este tema, antes de empezar los
ejercicios, los podrás encontrar en tu aula virtual o en nuestro canal de YouTube.
1. Para el siguiente ejercicio, van a tener que trabajar en equipo, con sus compañeros de
mesa.
b) Una vez creado el repositorio el facilitador debe invitar a los integrantes de su mesa al
mismo. Clickear en el botón Invite a collaborator y buscar a los miembros de su mesa
por username o email.
d) Clonar el repositorio. Cada miembro del equipo debe clonar el repositorio con el
archivo ReadMe. Luego de aceptar la invitación github te redirige al repositorio.
e) Cada miembro de la mesa, incluido el facilitador, debe crear su propia rama para
trabajar sobre el archivo ReadMe
g) Cuando todos los miembros de la mesa han agregado su nombre al archivo ReadMe,
de uno en uno, ir uniendo en la rama main todos vuestros cambios. Al final les debería
quedar un archivo ReadMe con todos sus nombres.
2. Ahora van a continuar trabajando como mesa. Vuestra tarea ahora es que cada miembro
de la mesa, incluido el facilitador, debe crear su branch y crear una de las siguientes
clases: Gato, Perro, Caballo, Conejo, Pájaro y Pato. Cada uno le va a poner los atributos
que desee.
El facilitador va a tener que crear el repositorio y subir un proyecto de Java vacio para que
los miembros de la mesa puedan clonar y crear su clase. Una vez que cada miembro haya
creado su clase en su respectiva rama, deberán unir todas las clases en la rama main, para
que quede el proyecto final.
19
GLOSARIO
1. Puntero: Un puntero no es más que una variable, en la cual se almacena una dirección
de memoria. Al ser una dirección de memoria, le podemos decir a un puntero que en ese
lugar donde apunta queremos almacenar un valor, por ejemplo, un número. En el caso de
git la rama va a almacenar la dirección de memoria de un commit de la rama main.
20