Software de control de Versiones Git y GitHub

Protocolos de transporte
Autor:
Juan Carlos Cuevas Martínez
Dpto. de Ingeniería de Telecomunicación
Área de Ingeniería Telemática
Universidad de Jaén
Escuela Politécnica Superior de Linares
Versión 2.0
SEMINARIO
Software de control
de versiones
Introducción a Git y GitHub
para el control de proyectos
software

Software de control de versiones
2
Versión 2.0
A. Conocer las características básicas del software
de control de versiones.
B. Conocer las necesidades del desarrollo de
software en equipo.
C. Conocer las ventajas del empleo de software de
control de versiones.
D. Conocer el funcionamiento básico de Git y
GitHub.
Objetivos

3
Versión 2.0
Competencias
C7
Conocimiento y utilización de los fundamentos de la programación en redes, sistemas y
servicios de telecomunicación.
CG3
Conocimiento de materias básicas y tecnologías, que le capacite para el aprendizaje de
nuevos métodos y tecnologías, así como que le dote de una gran versatilidad para
adaptarse a nuevas situaciones.
CG4
Capacidad de resolver problemas con iniciativa, toma de decisiones, creatividad, y de
comunicar y transmitir conocimientos, habilidades y destrezas, comprendiendo la
responsabilidad ética y profesional de la actividad del Ingeniero Técnico de
Telecomunicación
CG6
Facilidad para el manejo de especificaciones, reglamentos y normas de obligado
cumplimiento.
TEL7 Capacidad de programación de servicios y aplicaciones telemáticas, en red y distribuidas

4
Versión 2.0
1. Introducción al software de control de versiones
(SCV)
2. Control de versiones con git
3. GitHub
4. Integración con plataformas de desarrollo
Índice

5
Versión 2.0
1. GitHub Guides. https://guides.github.com/. Último acceso
7/2021
2. HINOJSA, Pablo y JJ MELERO. Aprende GIT. Disponible a
través de https://github.com/JJ/aprende-git.
3. CHACON, Scott y STRAUB, Ben. Pro Git. Apress. 2014.
Disponible online
https://progit2.s3.amazonaws.com/en/2016-03-22-f3531/pro
git-en.1084.pdf
4. Documentación de git. https://git-scm.com/. Último acceso
7/2021
Referencias

6
Versión 2.0
¿Qué es el control de versiones?
El Control de Versiones, o también llamado Control del
Código Fuente, es un software o sistema que registra los
cambios realizados sobre un archivo o conjunto de
archivos a lo largo del tiempo, de modo que se
puedan recuperar versiones específicas más adelante,
o combinar los cambios realizados en los mismos
ficheros por personas diferentes.
Aunque normalmente se usen para el desarrollo software,
pueden emplearse para cualquier tipo de archivo,
generalmente de texto o similar, pero no necesariamente.
1. Introducción al software de control de versiones (SCV)

7
Versión 2.0
Ventajas
 Revertir archivos a un estado anterior.
 Revertir un proyecto entero a un estado anterior.
 Comparar cambios a lo largo del tiempo.
 Ver quién modificó por última vez algo que puede estar
causando un problema.
 Ver quién y cuando introdujo un error.
 Si se dañan o pierden archivos, pueden ser recuperados
fácilmente.
 Coste muy bajo, ya que no se necesitan infraestructuras
complejas ni altas prestaciones de cálculo.

8
Versión 2.0
Tipos
 Locales
 Desde la simple copia de seguridad al veterano Revision Control
System (rcs) de primeros de los años 80 del siglo XX para control de
archivos, pero no proyectos.
 No se puede colaborar entre varios desarrolladores.
 Centralizados
 Se crearon por la necesidad de colaborar entre varios
desarrolladores.
 Los cambios se almacenan en un servidor y con aplicaciones
cliente se suben y obtienen cambios.
 El principal problema es la caída del servidor.
 Ejemplos: CVS o Apache Subversion.

9
Versión 2.0
Tipos
 Distribuidos
 Los clientes replican completamente el repositorio,
por lo que se salvaguarda la caída de alguno de los
participantes.
 Ejemplos: Git, Mercurial, Bazaar o Darcs.
 Evidentemente el tiempo de actualización puede ser
mayor, pero es mucho más seguro.

10
Versión 2.0
El lenguaje del control de versiones
 Repositorio (repository): es el conjunto de documentos
y archivos de trabajo junto con los ficheros de
configuración y bases de datos necesarias para el SCV.
 Branch, rama o ramal: es una de las diferentes
versiones que se tienen de un repositorio a la vez.
 Commit changes o confirmar cambios: es la forma en
la que se guardan y documentan los cambios.
Normalmente se requiere de un título y una descripción
de los mismos.
 Merge o fusionar: es la operación por la que dos
ramales pueden unificarse.

11
Versión 2.0
El lenguaje del control de versiones
 Push o sincronizar: es la acción por la que actualizan las referencias remotas
con los cambios locales.
 Fetch: descarga lo últimos cambios de una rama, pero no los fusiona (no
hace un merge)
 Pull: incorpora los cambios de un repositorio remoto en la rama actual (es
una forma de hacer un fetch y un merge a la vez)
 Clonar: se crea una copia local de un repositorio remoto que no existiera ya
previamente.
Figura 1-1. Ejemplo del ciclo de vida de un repositorio GitHub

12
Versión 2.0
 Git modela sus datos como un conjunto de
instantáneas de un mini sistema de archivos.
 Cada vez que se confirma un cambio, o se guarda
el estado de tu proyecto en Git, se hace una “foto”
del aspecto de todos tus archivos en ese momento,
y guarda una referencia a esa instantánea.
Git surgió en 2005
desde la comunidad
de desarrollo de
Linux y del propio
creador de Linux,
Linus Torvalds como
respuesta a la rotura
de relaciones con la
empresa que
mantenía su anterior
SCV, BitKeeper.
Reseña histórica
Otros sistemas, como
CVS, Subversion,
Perforce o Bazaar
almacenan la
información como una
lista de cambios.
Figura 2-1. Git almacena la información como instantáneas del
proyecto a lo largo del tiempo. Fuente [4].

13
Versión 2.0
Características
 Casi todas las operaciones son locales.
 La mayoría de operaciones de Git solo necesitan archivos y recursos locales
para operar, no necesitándose, por lo general, información de ningún otro
ordenador de la red.
 Se puede revisar la historia.
 Confirmar cambios (commit).
 Solo la subida de cambios necesita de conexión.
 Aporta un sistema de integridad.
 Todo en Git es verificado e identificado por compendio de mensaje o hash
SHA-1.
 No emplea nombres de archivos, sino el propio hash.
 Generalmente solo añade información.
 El funcionamiento de Git normalmente solo implica añadir información, por lo
que es muy difícil que algo se pierda o no sea recuperable.
 Es conveniente realizar push a menudo para tener así almacenada la
evolución del proyecto con más detalle.

14
Versión 2.0
Características – Los tres estados
 Los archivos en Git se pueden
encontrar en tres estados
principales:
 Confirmado (committed): los datos
están almacenados de manera
segura en la base de datos local.
 Modificado (modified): el archivo se
ha modificado pero aún no se ha
almacenado de manera segura en
la base de datos local.
 Preparado (staged): un archivo
modificado se ha marcado para
que guarde en la próxima
confirmación.
Figura 2-2. Directorio de trabajo,
área de preparación y directorio
de Git. Fuente [4]

15
Versión 2.0
Características – Los tres estados
 Estructura de un proyecto Git:
 Directorio de trabajo: es una copia de la versión del
proyecto para poder trabajar con ella.
 Directorio Git: dentro del directorio de trabajo se
encuentra una carpeta oculta “.git” que es donde se
almacenan los metadatos y base de datos de
objetos del proyecto.
 Área de preparación (staging área): es un archivo,
generalmente en el directorio Git, que almacena la
información relativa a la próxima confirmación.

16
Versión 2.0
Características – Los tres árboles
 Los tres árboles o índices están
estrechamente vinculados con las zonas de
trabajo antes comentadas:
 HEAD: Última instantánea del commit,
próximo padre.
 Índice: Siguiente instantánea del commit
propuesta.
 Directorio de Trabajo: caja de Arena

17
Versión 2.0
HEAD
 HEAD es el puntero a la referencia de
bifurcación actual, que es, a su vez, un puntero
al último commit realizado en esa rama.
 Eso significa que HEAD será el padre del próximo
commit que se cree. En general, es más simple
pensar en HEAD como la instantánea de tu
último commit.
 Para ver el contenido de HEAD se puede
ejecutar: git cat-file -p HEAD

18
Versión 2.0
Índice
 El índice es el siguiente commit propuesto. También nos hemos
estado refiriendo a este concepto como el “Área de
Preparación” de Git ya que esto es lo que Git ve cuando se
ejecuta git commit.
 Git rellena este índice con una lista de todos los contenidos del archivo
que fueron revisados por última vez en tu directorio de trabajo y cómo
se veían cuando fueron revisados originalmente. A continuación,
reemplaza algunos de esos archivos con nuevas versiones de ellos, y git
commit los convierte en el árbol para un nuevo commit.
 Con el comando git ls-files –s se puede ver lo que se está
en el índice en ese momento.
Nota: git cat-file y git ls-files son comandos para información, no son
necesarios normalmente para operar el repositorio.

19
Versión 2.0
Directorio de trabajo
 Los otros dos árboles almacenan su contenido de
manera eficiente pero inconveniente, dentro de la
carpeta .git.
 El Directorio de trabajo los descomprime en
archivos reales, lo que hace que sea mucho más
fácil editarlos.
 Se puede imaginar el Directorio de Trabajo como una
caja de arena, donde se pueden probar los cambios
antes de enviarlos a tu área de ensayo (índice) y
luego al historial.

20
Versión 2.0
Comandos básicos
 Inicializar un directorio vacío como repositorio Git:
$ git init
 Añadir a un repositorio archivos existentes:
$ git add *.c
$ git add README
 Añadir un punto de confirmación:
$ git commit –m 'versión inicial del proyecto‘
 Ver el registro de cambios:
$ git log
$ git log -4 (ver las cuatro últimas entradas)
$ git log --graph (ayuda gráfica que muestra las ramas y
fusiones entre ellas)

21
Versión 2.0
Configuración y operación básica de un repositorio
 Primero debemos crear un repositorio
ejecutando git init en la carpeta
que se va a emplear.
 Cuando se crea un repositorio con git
init, en una carpeta cualquiera, Git
crea una carpeta oculta, denominada
“.git”, donde guarda toda la
información para la gestión del
repositorio.
 Esta carpeta no se debe manipular.
 Si se borra, se elimina el repositorio
completamente.
 Dentro de la carpeta donde se ha
creado el repositorio se puede
encontrar también el archivo de texto
“.gitignore”

22
Versión 2.0
Archivo .gitignore
 Permite definir qué archivos o carpetas no deben ser tenidos
en cuenta por Git en el repositorio.
 Se suele añadir archivos de código objeto, archivos con claves,
bibliotecas de funciones o módulos usados que pueden
obtenerse de sus propios repositorios y no se modifican en un
proyecto, etc.
 Cada línea en el fichero .gitignore especifica un patrón para
ignorar carpetas y/o archivos que cumplan con el patrón.
 Las líneas que comienzan con # son comentarios.
 Todas las rutas con relativas al donde se encuentre el
fichero .gitignore.

23
Versión 2.0
Archivo .gitignore
 Patrones
 Filtro para ignorar el archivo TODO: /TODO
 Filtro para ignorar todos los archivos .class:
*.class
 Filtro para rastrear el archivo a.class a pesar de
que se ignorasen todos con *.class: !a.class
 Filtro para ignorar todos los archivos en la
carpeta modules: modules/
 Entre corchetes se pueden poner una especie
de expresiones regulares: [Dd]ebug/ quiere
decir que sería válido para Debug/ y para
debug/
# User-specific
files
*.rsuser
*.suo
*.user
*.userosscache
*.sln.docstates
# Build results
[Dd]ebug/
[Dd]ebugPublic/
[Rr]elease/
[Rr]eleases/
Ejemplo de
fichero .gitignore

24
Versión 2.0
Añadir archivos al repositorio
 Después, lo normal es ir creando archivos o copiándolos, y
añadirlos al repositorio con git add –archivo- (todas las
opciones en https://git-scm.com/docs/git-add).
 No basta con copiarlos al directorio, hay que añadirlos con el git
add.
 Nota: es posible que cuando se vea el uso con entornos de
desarrollo, estas operaciones se hagan automáticamente,
ocultando los comandos que realmente se emplean.

25
Versión 2.0
Hacer un commit
 Hacer commit es la operación básica de la gestión
de un repositorio con Git.
 Evidentemente antes tenemos que tenerlo instalado
y el repositorio creado y añadido algún fichero.
 Hacer commit implica hacer una nueva instantánea
del repositorio con los cambios que están en el Área
de preparación.
 Se le debe añadir un mensaje.
 Ejemplo: git commit -m "Primer commit"

26
Versión 2.0
Revertir un commit
 Con Git es posible volver atrás en la historia de
nuestro repositorio, teniendo dos opciones:
 git reset para deshacer commits locales sin
subirlos al repositorio.
 git revert para crear un nuevo commit que anula
un commit específico, especialmente si ya ha sido
compartido

27
Versión 2.0
Revertir un commit
 git reset tiene tres comportamientos fundamentales:
 git reset --soft HEAD~1: mantiene los cambios. Mueve la
referencia del último commit sin perder los cambios realizados en él.
Esto significa que solo cambias la referencia del HEAD, pero los
cambios siguen en el área de preparación (staging).Es como
deshacer el commit, pero dejar todo listo para volver a hacer commit.
 git reset --mixed HEAD~1: mantiene cambios, pero mueve el
índice, es decir, saca los cambios del área de preparación, pero los
ficheros mantienen dichos cambios. También saca los archivos
añadidos con git add.
 git reset --hard HEAD~1: descarta los cambios. Usado para mover
la referencia del último commit y descartar todos los cambios
realizados en ese commit, incluso borrando los archivos.

28
Versión 2.0
Manejo de un repositorio remoto
 Aunque, como se ha comentado, podemos trabajar
siempre en local con un repositorio Git, hoy en día es
habitual que empleemos repositorios que se alojan
en servidores para facilitar su compartición.
 Al servidor remoto se le conoce como origen(origin).
 Así, si el repositorio ya existe en el servidor remoto,
debemos clonarlo:
$ git clone
https://github.com/jccuevas/SM_EJEMPLOS_TEMA2.git
$ git clone git://github.com/jccuevas/prac1.git miproyecto

29
Versión 2.0
 Mostrar los repositorios remotos:
$ git remote -v
origin https://github.com/jccuevas/practica1 (fetch)
origin https://github.com/jccuevas/practica1 (push)
origin es el nombre por defecto que le da Git al servidor desde donde
clonas un repositorio. Se puede tener más de un repositorio remoto.
 Ver información sobre un repositorio remoto:
$ git remote show origin
Operaciones de información del servidor remoto

30
Versión 2.0
 Actualizar la información local desde un repositorio remoto,
pero no se fusiona (merge) con el local:
$ git fetch [remote-name]
 Actualizar la información desde una rama de repositorio
remoto y fusionarla con la rama actual:
$ git pull [remote-name]
Sería equivalente a:
$ git fetch [remote-name]
$ git merge origin/[current-branch]
 Actualizar un repositorio remoto desde local:
$ git push [remote-name] [branch-name]

31
Versión 2.0
Herramientas
 Git suele operarse a través de una consola de comandos o
con un sencillo software con interfaz de usuario gráfica (GUI).
 Entre ellos está GitHub Desktop, que se recomienda usar en este
curso, además de la integración con los editores de código.
Figura 2-3. Aplicación Git GUI
$ git help <comando>
$ git <comando> --help
$ man git-<comando>

32
Versión 2.0
 GitHub es un software de control
de versiones que emplea Git,
además del nombre de la
empresa que desarrolla el software
y la página web GitHub.com.
 Además es una plataforma para el
almacenamiento remoto de
repositorios y colaboración.
 ¿Qué hacemos?
 Primer paso: crear una cuenta en
gitHub.com con el correo de
estudiante de la Universidad de
Jaén.
 Segundo paso: Descargar e instalar
la aplicación de escritorio de
GitHub.
3.
GitHub

33
Versión 2.0
Aplicación de escritorio
 La aplicación de escritorio de GitHub evita el tener que
configurar conexiones SSH o emplear la línea de comandos,
aunque también proporciona la consola.
 Para empezar a trabajar se debe crear un repositorio. Esto se
puede hacer de diversas maneras:
 Añadiendo un repositorio ya existente.
 Creando uno nuevo.
 Clonar un repositorio remoto.
3.
GitHub

34
Versión 2.0
 La aplicación de escritorio permite la edición del proyecto con
cualquier entorno de desarrollo, aunque éste no tenga soporte para
control de versiones.
 Desde la aplicación se podrá hacer toda la gestión de control de
versiones:
 Revisar la historia del proyecto.
 Preparar los ficheros para hacer commits.
 Crear ramales.
 Realizar peticiones pull.
 Sincronizar con el repositorio remoto.
 Revertir cambios.
 No se pueden editar los archivos del proyecto, que se hará a través de
la herramienta adecuada.
 En la página web de GitHub SÍ se pueden editar los archivos del proyecto,
claro está, sin el respaldo de la aplicación de desarrollo.
3.
GitHub

35
Versión 2.0
Creando un proyecto
 Una vez se tiene una cuenta de GitHub, ya sea desde la aplicación
de escritorio, o desde la web: icono “+”.
Revisar la guía en la web: https://docs.github.com/es/get-started/quickstart/hello-world
3.
GitHub

36
Versión 2.0
Añadir un repositorio GitHub a un repositorio Git local
Git y GitHub
$ git remote add origin https://github.com/user/repo.git
$ git branch -M main
$ git push -u origin main
NOTA: según el software empleado para crear un repositorio podemos encontrar que la
rama principal se llama master (por ejemplo MS Visual Studio 2022) o main (MS Visual Studio
Code), pero conceptualmente es lo mismo.
3.
GitHub

37
Versión 2.0
 Git y GitHub, además de otros SCV,
están integrados en muchas
plataformas de desarrollo, como
Eclipse, con el plugin eGit, MS Visual
Studio, NetBeans y Android Studio,
entre otros.
 Suelen aparecer como herramientas
de colaboración de equipos en
secciones denominadas TEAM o CVS.

38
Versión 2.0
Microsoft Visual Studio 2022
 El soporte para Git es nativo ya en MS Visual Studio 2022, además del de
GitHub (adquirido por MicroSoft en 2018), aunque debe instalarse su
componente (normalmente marcado por defecto en la instalación).
 Junto con la instalación inicial de Visual
Studio en la pestaña de Componentes
Individuales (se puede modificar la
instalación ejecutando el Visual Studio
Installer.
 Una vez elegidas se acepta la instalación y se
espera a que el proceso termine.

39
Versión 2.0
Iniciar Visual Studio
 Al iniciar Visual
Studio, igual que
podremos abrir un
proyecto anterior o
crear uno nuevo,
podremos clonar un
repositorio.
 Podremos hacerlo
de una ruta local o
remota con GitHub
(y también con
Azude DevOps)

40
Versión 2.0
Vista “Cambios GIT”
 Para ver las opciones disponibles para
la gestión del control de código fuente
se tiene la vista “Cambios de GIT”
 Para mostrarla seleccionarla del menú
“Ver”.
 Nos muestra las dos opciones para
gestionar nuestros repositorios remotos
y los repositorios locales con GIT.
 Las operaciones sobre el repositorio
también se pueden acceder desde el
menú GIT.

41
Versión 2.0
Trabajar con GitHub
 Para trabajar con GitHub hay dos formas típicas:
crear un nuevo repositorio y subirlo a GitHub, o
clonar uno ya existente.
 Previamente necesitamos una cuenta del servicio
que se consigue en https://github.com/.
 Puede ser de utilidad revisar la web
Acerca de Git en Visual Studio.

42
Versión 2.0
 Ventana
para crear un
repositorio.
 Para crearlo
en GitHub
nos pedirá
nuestras
credenciales
de acceso.
Trabajar con GitHub

43
Versión 2.0
Trabajar con GitHub – Crear un repositorio
 Aspectos a tener en cuenta:
 Elegir la plantilla de .gitignore (se
proporciona una por defecto)
 Elegir una licencia del software (no
necesario para nuestras prácticas)
 Elegir un nombre apropiado: siga las
indicaciones de la práctica.
 Añadir una descripción significativa,
aunque no demasiado larga.
 Establecer la visibilidad, en pública o
privada. En este caso, para la
práctica establecerla en privada.

44
Versión 2.0
Trabajar con GitHub – Operaciones básicas en la barra de Git
 Ver cambios: permite además de
visualizar los ficheros que han cambiado.
 Inserciones pendientes de insertar:
muestra los commits que están pendientes
de actualizar en el repositorio remoto y
acceder a las opciones para actualizarlos.
 Repositorio local: se puede ver en la vista
“Cambios de GIT”
 Rama actual de trabajo: controla las ramas del
proyecto y muestra información sobre las mismas.

45
Versión 2.0
Operaciones básicas – Confirmaciones (commits)
 Cuando se hace un
cambio en cualquier
fichero del proyecto
dentro del repositorio
aparecerá reflejado en
la vista “Cambios de
GIT”.

46
Versión 2.0
 Para incluirlos en un
commit primero se debe
añadir al stage a través
del símbolo “+” en
cambios (elige todos los
cambios) ose puede
hacer individualmente.
 También se pueden revertir
los cambios: con el botón:

47
Versión 2.0
 Una vez añadidos al stage ya se
puede proceder al commit,
pudiendo elegir la rama que nos
interese.
 Es obligatorio añadir el comentario.
 Se debe ser explícito y claro, ya
que es lo que permite seguir la
evolución del proyecto.
 El botón rectificar permite
modificar el último commit, antes
de subirlo, por si nos hemos dado
cuenta de un error o de que
faltaba un mínimo cambio por
hacer (ver git commit –amend).

48
Versión 2.0
Operaciones básicas – Manejar el repositorio remoto
 Como se ha comentado, con Git
podemos trabajar
completamente en local, pero si
hemos publicado el repositorio en
GitHub debemos actualizar los
cambios en el origen.
 En la de “Cambios de GIT” nos
aparecerán los commits sin
insertar (en la barra inferior
también).
 Junto a la elección de rama
están todas las opciones
disponibles, unas con un botón y
otras en el menú. Fetch Pull Push Pull/Push

49
Versión 2.0
Operaciones básicas – Ver la historia
 En el menú de Git se encuentra la opción “Ver historial de ramas” en la
que podemos ver toda la evolución del repositorio.
 Con el botón derecho en cada commit podemos hacer operaciones sobre él.
 Con doble clic en cada commit podemos ver los cambios que implicó, e
incluso revertirlo (reset o revert).

Software de control de Versiones Git y GitHub

Más contenido relacionado

Similar a Software de control de Versiones Git y GitHub

Software de control de Versiones Git y GitHub