Guía básica para usar Git

Hola, te doy la bienvenida a mi “Guía básica para usar Git, escrita por alguien que nunca utilizó Git con anterioridad”.

O para abreviar la “Guía básica para usar Git”.

Al igual que la mayoría de los apuntes en esta página, estoy escribiendo todo esto para aprender un tema del que no conozco nada o casi nada.

Si entiendo que existe un sitio web llamado Github, donde muchas personas comparten sus proyectos. Y al parecer es un sitio muy popular. Pero eso es todo lo que conozco de Git, y solamente porque “Git” aparece al frente de la palabra “Github”.

Entonces… ¿Por qué estoy escribiendo una guía de algo que no conozco?

Bueno, es que intento valerme del antiguo truco de explicar algo para conseguir aprenderlo. Voy practicando el tema, y escribo de mi experiencia al mismo tiempo.

Así que si no te molesta acompañarme en el proceso de aprendizaje… te invito a seguir leyendo.

Vale agregar que todo este texto fue creado consultando el manual que acompaña a Git. Es posible consultar ese manual, una vez ya instalado el programa, con el comando:

git help git

Voy a usar la versión en idioma inglés del manual, traduciendo algunas partes puntuales para ayudar a comprender algunas ideas.

A modo de breve publicidad, quiero recordar que no es la primera vez que hago una experiencia como esta. Tambien escribí en otras oportunidades:

• Guía mínima para empezar con la terminal de Linux
• Guía inmediata para empezar con Arch Linux

Tal vez encuentres en esos otros apuntes información que pueda ayudarte para conocer algo nuevo.

Otra última cosa antes de empezar: estoy trabajando con un sistema operativo Linux mientras ensayo todo esto. Aunque se puede usar Git en otros sistemas operativos, algunos de los detalles que menciono en la escritura de los comandos puede ser específica para Linux.

Por ejemplo, en Linux puedo ver el manual de Git con el comando “man” (por “manual”) de este modo:

man git

¿Qué es git?

El ya mencionado manual nos dice lo siguiente:

NAME
git – the stupid content tracker

Manual de git

Bien… en que forma traducir esto… Según entiendo, la frase quiere decir lo siguiente:

NOMBRE: git – un rastreador de contenido muy fácil de usar.

Bueno, entonces Git sirve para “rastrear” contenido. Lo que sea que eso significa. Voy a suponer que se trata del contenido de una carpeta o proyecto.

Sigamos leyendo:

DESCRIPTION
Git is a fast, scalable, distributed revision control system with an
unusually rich command set that provides both high-level operations and full access to internals.

Manual de Git

O en mis palabras:

DESCIPCIÓN: Git es un sistema de revisión de control distribuible, rápido y escalable, con una inusualmente variada cantidad de comando que proveen la posibilidad de operaciones de alto nivel y acceso a su funcionamiento interno.

Voy a olvidar lo de la gran variedad de comandos, distribuible, rápido y escalable. Lo que más me interesa de todo el fragmentos puedo puedo resumirlo por la frase
“sistema de revisión de control”.

Si tengo “sistema de revisión de control” y lo sumo a la frase “rastreador de contenido”, voy a suponer que el programa permite hacer un seguimiento de los cambios en mis archivos a lo largo del tiempo.

Perfecto, creo que ya entiendo de que va la cosa. Git me va a dar la oportunidad de inventariar los cambios en un archivo a lo largo de sus distintas modificaciones.

Hay que admitir que es difícil imaginar cómo funciona el programa antes de empezar a usarlo. Al igual que ocurre con la mayoría de lo que aprendemos, hay que poner en práctica la información para poder interiorizar las ideas.

Con todo, esto parecer ser algo similar a lo que se conoce por un “checkpoint” o un punto de control en un videojuego.

Al avanzar en la historia de un videojuego, podemos grabar nuestra partida a medida que progresamos. Siempre podemos volver a experimentar cosas que ya jugamos en tanto que grabemos la informacipon en un punto determinado .

Eso nos permite regresar al pasado, regresar a ese punto por decirlo de algún modo.

Git parece obrar de una forma similar al checkpoint de un videojuego, pero con archivos en general. Una vez más, va a ser mejor poner todo esto en acción para entenderlo.

Cómo instalar GIT… en Linux

Bien, el sitio con los datos para la descarga e instalación de Git se encuentra en: https://git-scm.com/downloads

Ahí voy a poder encontrar instrucciones para instalar el programa en diferentes distribuciones de Linux. Lo mismo hay instrucciones para otros sistemas operativos.

Toda la instalación se realiza a través de la terminal. Para instalar el programa en Linux Mint, el sistema operativo que estoy usando ahora, escribí el siguiente comando:

sudo apt install git

Para saber si Git se instaló correctamente, o si te da curiosidad saber si ya lo tenías instalado de antemano, se puede utilizar este sencillo comando para conocer que version tenemos en la computadora:

git --version

Y para tener un pantallazo general de los comandos principales que voy a usar en el futuro próximo, puedo escribir en la terminal:

git --help

No hay que olvidar usar los dos guiones antes de cada opción. Help me brinda una versión mucho más resumida que el manual completo.

Cómo crear una repo con Git

Voy a crear una nueva carpeta, llamada nuevo_tutorial, generando la misma con el comando mkdir:

mkdir nuevo_tutorial

Ahora con la terminal establecida dentro del directorio que voy a usar como principal, ejecuto el comando:

git init

Lo que si todo va bien me da como respuesta:

Initialized empty Git Repository in /nuevo_tutorial/.git

O traducido: Se inicializó un repositorio vacío de Git (en el directorio de trabajo).

Eso va a generar una serie de archivos ocultos dentro de la carpeta. No puedo encontrar esos archivos a menos que expresamente pida mostrar los documentos ocultos en la carpeta (en inglés, “Shown Hidden Files”).

Es claro que no entiendo bien que es lo que hace cada uno de esos archivos por separado, pero entiendo que en su conjunto son lo que permiten que Git siga la pista de lo que ocurre en la carpeta.

Si tengo que describir lo acontecido, puedo entender que este directorio donde inicié el comando se convierte ahora en el repositorio de nuestro proyecto. O en la forma que comúnmente se lo llama, la “repo” del proyecto: el espacio donde Git va a seguir un control del progreso de los cambios.

Otra cosa importante es considerar que Git rastrea los datos de todos los subdirectorios que contenga la repo. Puede iniciarse git en un directorio que no contiene ningún archivo, como en el caso de nuestro ejemplo, pero también puede hacerse en un caso donde ya hay documentos creados.

¿Qué hacer luego de crear mi repo?

Es una buena pregunta, si se me permite decirlo.

Realmente no hay nada muy aparatoso en la utilización de Git, y por ahora voy a seguir con la terminal de comandos. Se requiere de algo de imaginación de nuestra parte para que todo funcione, pero no es nada más que ganar experiencia usándolo.

Como ya dije, en este momento me encuentro en la carpeta “ nuevo_tutorial”. Ahí es hacia donde apunta mi terminal.

Lo primero que voy a hacer es generar un nombre para mi cuenta, en mi caso ese nombre es Gustavo. Eso lo hago con el comando:

git config --global user.name Gustavo

Si agrego más de un nombre, es decir con un espacio en el medio, tengo que ponerlo entre comillas. Luego puedo revisar que ni nombre se haya agregado correctamente al sistema con el comando:

git config user.name

Recordemos que Git se usa también para trabajar en equipo, y aunque en este momento estoy trabajando solo, no es mala idea completar estos pequeños detalles. Por lo mismo puedo agregar un correo electrónico de referencia por medio de:

git config --global user.email “nombre del correo”

Y puedo revisar ese dato también con:

git config user.email

Comando muy similar al que utilicé para revisar el nombre de mi cuenta.

Sobre esto de poner un nombre y un correo, puede parecer un detalle sin importancia pero no lo es. Si queda mal puesto, puede generar un error más adelante en el que Git pide reconocer nuestra cuenta una y otra vez…

Pero para terminar con esta parte, tambien es posible configurar estos datos desde antes de iniciar la repo. E incluso se puede usar nombres de cuenta diferentes en distintas repos, si no usamos la opción “–global” al agregarlo.

Por otra parte, tambien podemos ver estos datos con el comando:

git config --global -e

Ya que estamos, tal vez es una buena hacer todo esto utilizando un editor de textos dedicado.

Alguna de estas herramientas pueden ser por ejemplo: Atom, Visual Studio Code y VSCodium. Personalmente yo estoy utilizando VSCodium desde hace un tiempo, con excelentes resultados.

El editor puede abrir nuestro documento de texto, la terminal de comandos y nuestros directorios a la vez, nos va a permitir descubrir la forma en que git funciona de manera dinámica.

¿Qué hacer luego de crear mi repo en Git?

Entonces ya abrí mi carpeta “nuevo_tutorial” en VSCodium. Y ya empecé mi nueva repo con el comando

git init

Tambien ya le di un nombre de usuario y un mail de referencia a mi cuenta.

A continuación voy a crear mi documento de texto, la pieza central de mi trabajo llamado “apunte.txt”, y voy a hacerlo con el siguiente comando:

touch apunte.txt

Puedo notar algo interesante. El editor de texto presenta el archivo “apunte.txt” en color verde. Y cuando pongo el puntero arriba del nombre del mismo me dice que se encuentra “untracked” o “sin rastrear”.

Lo que me da a entender que Git esta al tanto de la creación del documento, es un documento que no existía antes. Esto ocurre tanto si utilicé un editor como VSCodium o no, pero el editor hace que sea más sencillo notar este cambio.

Empezar el seguimiento: pasando al nivel staged

Hasta este momento lo que hice fue hacer un cambio en mi repo, el de crear mi archivo de texto.

Voy a agregar algo de texto en “apunte.txt” para que no se sienta tan vacío:

Este es el primer renglón, para este apunte que forma parte de un ejemplo.

Ahora ya escribí algo en mi proyecto, y quiero que este sea un punto de control en la historia del documento. Eso va a necesitar de algunos pasos.

En resumen, Git tiene tres “momentos” (por llamarlos de algún modo) en el proceso de crear esos puntos de control. Estos tres momentos o niveles son los de:

• Modified
• Staged
• Commited.

Ahora me encuentro en lo que voy a considerar como el nivel uno, o el momento “modified”. El termino modified quiere decir modificado, e indica que existen cosas nuevas en la repo. Estas modificaciones pueden por ejemplo ser archivos nuevos, alterados o nuevo contenido en los documentos.

Como ya dije antes, estas modificaciones todavía no forman parte de ningún punto de control. Y el objetivo de todo esto es crear es crear esos puntos de control. Para hacerlo tengo que mover los cambios de “modified” al estado “staged”.

Según el manual tengo el siguiente comando:

git-status(1)
Show the working tree status.

Manual de Git

Invocando esta comando puedo ver el estado de mi trabajo. ¿Qué implica esto? Voy a revisarlo.

Entonces escribo:

git status

Y la terminal me devuelve:

On branch master
No commits yet
Untracked files:
(use "git add …" to include in what will be committed)
apunte.txt
nothing added to commit but untracked files present (use "git add" to track)

Puedo entender que me da una suerte de “inventario” de los puntos de control generado s hasta el momento. Yo se que no hay ninguno todavía.

Voy a revisar lo de “On branch master” en mayor profundidad luego, pero como adelanto puedo saber que me esta diciendo que me encuentro en la rama principal de la repo.

Por otra parte “No commits yet” me confirma lo que ya conocía, que no hay todavía ningún commit creado en esta repo.

Lo más importante en este instante se encuentra analizando:

Untracked files:
(use "git add …" to include in what will be committed)
apunte.txt
nothing added to commit but untracked files present (use "git add" to track)

Bien, volviendo a lo anterior esto me informa que hay un archivo incluido a la repo (apunte.txt) pero que todavía esta “untracked” o sin seguimiento.

Y también me dice que hacer para pasarlo al nivel “staged”, que se podría pensar como “subirlo al escenario” o empezar a seguirlo, usando el comando “git add”.
Voy a hacerlo:

git add apunte.txt

Nada parece ocurrir, pero si vuelvo a usar

git status

la terminal me dice:

On branch master
No commits yet
Changes to be committed:
(use "git rm --cached …" to unstage)
new file: apunte.txt

Esto viene a decirme que el nuevo archivo apunte.txt ya esta siendo seguido. Según el manual:

git-add(1)
Add file contents to the index.

Manual de Git

El archivo fue agregado al índice. Recordemos que este es el paso previo al commit, aun no hay puntos de control creados.

También puedo remover de este nivel al documento con el comando:

git rm --cached apunte.txt

Hacer esto devuelve mi documento al estado sin seguimiento en el que se encontraba anteriormente, por fuera del nivel staged.

Commits: un nuevo punto de control

Por lo que entiendo hasta ahora, los cambios que hice en la repo están casi listos para entrar al tercer y último nivel. Ya casi son parte de los commits.

Estos commits son los puntos de control propiamente dichos. Similar a poner una marca en la hoja de un libro, para poder recuperar la lectura luego. Dejamos una marca en el camino, y podemos recuperarla para ver como estaba el proyecto en ese momento.

Para conseguir esto utilizo el comando que en la terminal aparece por:

git-commit(1)
Record changes to the repository.

manual de git

Lo que me dice el manual es que este comando guarda o graba los cambios en el repositorio. Es justo lo que necesito.

Otra cosa que puedo hacer, aunque es más bien una formalidad, es acompañar de la opción -m al comando para poder agregarle un comentario.

Este comentario va a decir lo que hice con el archivo, y me va a servir como referencia para poder entender lo que hice con mayor facilidad.

Entonces el comando terminado me queda:

git commit -m "[archivo apunte.txt creado y primer párrafo agregado]"

Y con eso termino de crear mi primer commit en el proyecto.

Error “Please tell me who you are” en Git:

Si lo anterior no funcionó bien, es posible que me encuentre un error como este:

*** Please tell me who you are.
Run
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
to set your account's default identity.
Omit --global to set the identity only in this repository.

Esto significa que Git me pregunta: “¿Por favor, decime quién esta realizando estos cambios?”.

Es posible que olvidáramos agregar el nombre de nuestra cuenta al principio. Podemos hacerlo ahora, incluso omitiendo la opción “–global” para que el nombre solo aplique a este repositorio.

Lo siguiente que pudo pasar es que cuando originalmente intentamos agregar estos datos, escribimos el comando:

git config --global user.mail “nuestro correo”

En lugar de:

git config --global user.email “nuestro correo”

Sin agregar la “e” en “email”. Si, fue el primer error que cometí. Al volver a agregar mi correo agregando la letra flatante el problema se resolvió.

Listo, eso quedó solucionado.

Commit, otra vez:

¿Que habia hecho antes? Ya recuerdo, escribí el comando:

git commit -m "[archivo apunte.txt creado y primer párrafo agregado]"

Al salir sin ningun error, recibo por respuesta:

[master (root-commit) 1c88802] [archivo apunte.txt creado y primer párrafo agregado]
1 file changed, 1 insertion(+)
create mode 100644 apunte.txt

Y principalmente me dice que un archivo fue cambiado (“apunte.txt” fue agregado) y que existió una inserción. Por esto entiendo que se refiere al primer párrafo que escribí en el texto.

Entonces con el comando

git commit 

conseguí hacer mi punto de control.

Pero hasta este momento este es mi único commit, por lo que no puedo moverme entre ellos. Voy a agregar un párrafo más a mi “apunte.txt” y luego voy a generar otro commit para luego poder alternar entre los mismos.

Entonces escribo dentro del archivo:

Este es el segundo párrafo para un ejemplo bastante poco creativo de lo que es la creación de un apunte.

Pero esto ya lo revisé antes, no puedo hacer el commit directamente sin antes pasar por el nivel de staged. Entonces si hago:

git status

Me dice que:

On branch master
Changes not staged for commit:
(use "git add …" to update what will be committed)
(use "git restore …" to discard changes in working directory)
modified: apunte.txt
no changes added to commit (use "git add" and/or "git commit -a")

Una vez más hay un cambio que agregar, por el nuevo párrafo. Por eso vuelvo a pasar al documento al nivel de staged con el comando:

git add apunte.txt

Alternativamente si tuviera que registrar cambios en múltiples documentos en lugar de uno solo, puedo escribir

git add .

El punto funciona como una wildcard global, que incluye a todos los archivos que pueden ser movidos a staged dentro de la repo.

Y ahora si hago el commit con:

git commit -m "[segundo párrafo agregado en apunte.txt]"

Con esto ya tengo un segundo punto de control en mi repo.

Modificar la descripción de un punto de control en Git:

Si necesito modificar la descripción de un commit dispongo del comando:

git commit --amend -m [“nuevo comentario”]

Y con eso modifico el texto descriptivo de un punto de control.

Es bueno notar que esto cambia la descripción del punto de control que me encuentre revisando al momento de aplicar el comando.

El comando git-log:

Lo que sigue es revisar que commits existe hasta el momento en esta repo. Eso lo hago con el comando git-log, del que el manual me dice:

git-log(1)

Show commit logs.

Manual de Git

Este comando nos muestra un registro de los commits. Entonces escribo en la terminal:

git log

Y me devuelve:

commit 4e656205fa6d6e82a1f915e3020045f1c9d47ddf (HEAD -> master)
Author: Gustavo <mail@mail>
Date:   Wed Nov...
commit 4e656205fa6d6e82a1f915e3020045f1c9d47ddf (HEAD -> master)
Author: Gustavo <mail@mail>
Date:   Wed Nov 30 14:41:00 2022 -0300

    [segundo párrafo agregado en apunte.txt]

commit d1429b20d0260e0ffc0cc37616d58e4ddbba5e15
Author: Gustavo <mail@mail>
Date:   Wed Nov...

    [archivo apunte.txt creado y primer párrafo agregado]

Y ahí me aparecen de forma descendente los dos puntos de control que hice.

Cada uno tiene su propio registro particular, el nombre de cuenta y el comentario explicativo que lo acompaña.

Para salir de esta lista presiono la letra “q” en el teclado.

Redirigir el resultado de los comandos en Git:

Es posible redirigir el resultado de algunos de estos comandos a un archivo de texto. De esta forma puedo guardar la información, o compartirla en caso de que sea necesario.

Por ejemplo, el comando:

git log > info.txt

consigue redirigir la información de “git log” a un documento llamado “info.txt”.

Y puedo hacer lo mismo con otros comandos. Por ejemplo “git status” redirigido hacia el nombre de otro nuevo archivo para crear, me va a dar el mismo resultado.

Git status > info2.txt

Escrito de este modo, el nuevo archivo se crea en el directorio donde estoy trabajando.

Con todo esto completado, puedo tomar un pequeño descanso y volver luego con…

Más commits, nuevos y no tan nuevos

¿En qué momento tengo que hacer un nuevo commit? Hoy me encuentro realizando estos puntos de control según los ejemplos me lo demanda, para poder entender como funcionan.

De hecho, al momento de trabajar en el proyecto, voy a notar que si uso el comando “git status”, Git me avisa que hay cambios realizados.

Estos cambios pueden haber sido guardados en el archivo, guardados por medio del programa que estoy utilizando para trabajar. Pero estas modificaciones todavía no fueron rastreados por Git, no forman parte aun de ningún punto de control.

Segun empiezo a comprender, guardar algo y crear un commit no es lo mismo. Tengo que pensar en eso. Más aun, puedo guardar varias veces, agregar algunas de esas modificaciones al nivel staged y luego todas dentro de un commit.

Solo coincide que hasta ahora solo estoy haciendo un cambio por commit. Y hasta ahora no me metí a hablar sobre las “ramas”, algo que va a ampliar esto mucho más.

Pero lo que ahora me interesa es conocer como moverme entre estos commits, para poder usarlos efectivamente como una linea de tiempo que puedo ver.

No voy a repasar de nuevo los pasos por los tres niveles, pero si voy a agregar otro párrafo: Bueno, si voy a pasar por los tres niveles. No esta de más repasarlo.

El primer nivel ocurre cuando hago un cambio, en mi caso agrego un nuevo párrafo:

Un nuevo párrafo (el número 3), no muy original pero si muy valioso.

El segundo nivel ocurre cuando paso ese cambio al nivel “staged”. Es decir, cuando subo (por expresarlo de algún modo) lo guardado al escenario y lo preparo para que Git lo tenga en cuenta.

Eso lo consigo con el comando:

git add apunte.txt

Y para finalizar, el tercer nivel creando el commit. Para eso en mi caso utilizo este comando:

git commit -m "[tercer párrafo agregado]"

Reviso todos mis puntos de control hasta el momento con el comando:

git log

Ya tengo tres puntos de control, aunque lo que me devuelve este comando es algo difícil de leer. Puedo mejorarlo con el agregado de la opción “–oneline”, lo que va a conseguir que cada punto de control y comentario aparezca resumido en una única linea de texto.

git log --oneline

Y eso me devuelve:

b701a95 (HEAD -> master) [tercer párrafo agregado]
4e65620 [segundo párrafo agregado en apunte.txt]
d1429b2 [archivo apunte.txt creado y primer párrafo agregado]

Mucho más fácil de leer.

Entonces, voy a volver al primero de ellos: el momento en el que solamente había un párrafo creado. El código que necesito aparece al principio del log, en este caso es: d1429b2.

Puedo volver a este punto de control con el comando “git checkout”, que según el manual dice:

git-checkout(1)
Switch branches or restore working tree files.

manual de git

Lo que entiendo es que “checkout” me permite revisar un commit anterior. En principio solo revisarlo en modo lectua, no modificarlo ni abrir una rama nueva.

Para usarlo, le agrego el código de identificación del commit a revisar:

git checkout d1429b2

Y si reviso el texto, puedo ver que me esta mostrando el documento como lo tenía en ese párrafo.

Por su parte la terminal me devuelve el mensaje:

Note: switching to 'd1429b2'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at d1429b2 [archivo apunte.txt creado y primer párrafo agregado]

Todo esto es bastante… lo suficiente como para pensar en analizarlo en otra seccion.

Por lo pronto e alcanza con saber que puedo regresar a la “rama original” de mi proyecto usando el comando:

git switch -

Lo que también me trae en la terminal el mensaje:

Previous HEAD position was d1429b2 [archivo apunte.txt creado y primer párrafo agregado]
Switched to branch 'master'

Pero más importante todavía, me devuelve al archivo de texto con los tres renglones (¡o párrafos!) que había escrito con anterioridad.

Intermedio: repasando lo ensayado

¿Por dónde iba?

Un detalle interesante (o tal vez preocupante) es que no escribo todas las secciones de este texto de corrido.

A veces transcurren días entre cada ocasión en la que me siento a escribir. Eso implica que muchas veces tengo que recordar todo desde cero, o que pierdo la práctica de escribir y las oraciones no salen tan fluidas.

Y eso no es buena idea, hace que se vuelva difícil aprender con facilidad. Pero avanzando, y en un ultra resumen de los repasado anteriormente, los comandos para crear un commit son:

Trabajo en algún cambio. En mi caso agrego el párrafo:

Cuarto párrafo y el apunte empieza a ponerse más completo.

Luego ejecuto el comando:

git status

Me dice si hay cambios para agregar, o dicho de otro modo, algún cambio esperando para pasar al estado “staged”.

git add apunte.txt

Prepara el commit que va a registrarse en el documento.

git commit -m "[un cuarto párrafo fue escrito en apunte.txt]"

El comando “git commit” agrega el punto de control al registro del documento, acompañado de un comentario descriptivo.

git log --oneline

Me da una lista de los commits o puntos de control realizados, que en este caso es:

ef8292d (HEAD -> master) [un cuarto párrafo fue escrito en apunte.txt]
b701a95 [tercer párrafo agregado]
4e65620 [segundo párrafo agregado en apunte.txt]
d1429b2 [archivo apunte.txt creado y primer párrafo agregado]

Y para seguir dando vueltas con el tema, quiero mencionar algo que considero importante:

– Antes de empezar a usar Git, me imaginaba que era una herramienta solamente dedicada a la colaboración entre equipos. Pero ahora me doy cuenta que el asunto de “sistemas de control” es algo que realmente no conocía, y puede ser aplicada a mis proyectos personales

Todo lo que estuve practicando hasta ahora ocurrió dentro de mi computadora, aprendiendo mientras escribía sobre la marcha, y sin necesidad de compartir los archivos con nadie más.

Próximamente voy a revisar Github, donde la idea es la de “subir” nuestro proyecto para que pueda ser compartido de forma pública (o privada) entre otras personas. Esto nos va a permitir compartir nuestro código, pero también sumarnos a otros grupos que trabajan utilizándolo para colaborar.

Pero retornando a lo anterior, voy a regresar a mi ejemplo con el comando:

git log --oneline

Me devuelve los commits de lo que, quiero entender, es ahora mi rama principal:

ef8292d (HEAD -> master) [un cuarto párrafo fue escrito en apunte.txt]
b701a95 [tercer párrafo agregado]
4e65620 [segundo párrafo agregado en apunte.txt]
d1429b2 [archivo apunte.txt creado y primer párrafo agregado]

Ya tengo cuatro commits, cuatro puntos de control en el tiempo.

Pero sin embargo si reviso la carpeta donde se encuentra guardado el documento, solamente encuentro un archivo. Antes, si hubiera querido tener tres versiones distintas de mi “apunte.txt” hubiera necesitado tres documentos diferentes.

Otra cosa que quiero mencionar es que los puntos de control son presentados en orden. El último commit realizado aparece arriba de la lista, acompañado de la frase: (HEAD -> master).

Si tengo que descifrar esto por mi cuenta, voy a suponer que HEAD implica que estoy en la “cabeza” o parte superior de la lista. Y “master” se refiere a que estoy revisando los puntos de control en la rama maestra o principal del proyecto.

Seguido de esto, el primer commit se encuentra en la base.

Alternar (o destruir) commits:

Ahora bien, puedo moverme por la linea de tiempo del proyecto. Pero puedo hacer otras cosas también. Y por eso voy a ocuparme de revisar algunas de las formas en la que puedo interactuar con los puntos de control.

Checkout commit

Tal como su nombre nos lo indica, este comando nos permite “chequear” o revisar un punto de control en la historia del documento.

Lo que puedo hacer con esto es revisar el código en el estado en el que se encontraba durante los distintos commits que hice.

Nada mal, es como viajar mirando una suerte de vidriera del proyecto. Lo más importante es que todo esto ocurre en lo que se conoce como “modo lectura”, por lo que no voy a poder intervenir directamente en el código.

Este comando ya lo revisé antes, pero voy a revisarlo de vuelta. Y luego voy a revisarlo en mayor profundidad, con al menos un experimento que tengo en mente. Pero eso queda para más adelante.

Para concentrarme en el momento, puedo decir que tengo un punto de control que dice:

4e65620 [segundo párrafo agregado en apunte.txt]

El número del principio es su número de identificado o “id”. Puedo usar ese código para revisar el punto de control por medio del comando:

git checkout 4e65620

Listo, ya estoy explorando ese commit. No puedo intervenir en el, pero puedo revisarlo. Luego si quiero regresar a la rama principal o “master branch” lo hago con el comando:

git switch -

O también puedo volver a la rama principal con el comando:

git checkout master

Revert commit:

Una vez más, el nombre del comando nos informa que esperar. Voy a revisar que dice el manual de Git:

Lo que hace entonces el comando revert es “revertir” un punto de control.

git-revert(1) Revert some existing commits.

Manual de git

Otra forma de decirlo es que el comando deshace un commit, lo remueve de la linea de tiempo.

Y por “resetear” quiero decir que elimina de forma permanente el commit que marquemos en la historia de nuestro documento.

Voy a aplicarlo para entender como funciona. Una vez más, tengo el número “ef8292d” que representa a un commit específico. Ese commit dice:

ef8292d (HEAD -> master) [cuarto párrafo ahora agregado en apunte.txt]

Algo importante: voy a revertir el último punto de control realizado. Intentar revertir cualquier otro punto de control abre un nuevo abanico de problemas… es algo que aprendí del modo dificil.

Voy a volver sobre eso más adelante.

En este instante voy a conformarme con remover el último punto de control, para acostumbrarme a la idea. Entonces ejecuto el comando git revert:

git revert ef8292d

Lo que me devuelve el mensaje:

Revert "[cuarto párrafo ahora agregado en apunte.txt]"
This reverts commit ef8292d0af272e2eb29f95cb51a57cb74af79319.
#Please enter the commit message for your changes. Lines starting with '#' will be #ignored,and an empty message aborts the commit.
#On branch master
#Changes to be committed:
#modified: apunte.txt

Este nuevo mensaje se abre en la terminal, dentro de un editor de texto. ¿Qué editor de texto? Depende de cual tengas instalado como principal en el sistema. En este momento yo me encuentro usando Nano.

Pero la idea es que este archivo de texto me permite escribir una nueva descripción, que va a acompañar un nuevo punto de control explicando lo que ocurrió con el anterior. Básicamente tengo que escribir un mensaje, o en este caso dejar:

Revert "[cuarto párrafo ahora agregado en apunte.txt]"

Siendo ese el mensaje recomendado, y el que mejor aclara la situación. Básicamente repite la descripción del antiguo commit, agregando que en este punto se realizó la acción del Revert.

Vale agregar ademas que cualquier mensaje que aparezca en ese archivo de texto acompañado del numeral # es considerado como un comentario, y no es leído por el programa.

¿Cómo salir de esta pantalla? Una vez más, eso depende de tu editor. En Nano es lo básico es siempre igual, escribir el mensaje, guardar (Ctrl + o) y salir (Ctrl + x). Esto me devuelve a la terminal.

Si ahora reviso mis puntos de control con “git log –oneline”, obtengo:

2f741a2 (HEAD -> master) Revert "[cuarto párrafo ahora agregado en apunte.txt]"
ef8292d [cuarto párrafo ahora agregado en apunte.txt]
b701a95 [tercer párrafo agregado]
4e65620 [segundo párrafo agregado en apunte.txt]
d1429b2 [archivo apunte.txt creado y primer párrafo agregado]

Puedo notar que lo que anteriormente era mi último commit sigue ahí:

ef8292d [cuarto párrafo ahora agregado en apunte.txt]

Ese punto no fue borrado de la lista, pero si apareció un nuevo commit que lo revierte:

2f741a2 (HEAD -> master) Revert "[cuarto párrafo ahora agregado en apunte.txt]"

Y de hecho si voy a leer mi documento de texto puedo ver que el cuarto párrafo ya no existe, se borré cuando revertí el commit que lo acompañaba.

Lo que hace el agregado de la opción Revert entonces es remover nuestro commit antiguo, y a su vez el trabajo correspondiente en nuestro proyecto. Y en su lugar se genera un nuevo punto de control con otro mensaje indicando lo que ocurrió.

Reset commit:

El comando Reset aparece en el manual de Git por:

git-reset(1) Reset current HEAD to the specified state.

manual de git

En una traducción rápida, git-reset regresa el estado del proyecto al de un punto de control específico en la linea de tiempo.

Una metáfora para explicarlo supongo que puede ser la de podar un árbol. Cortamos una parte de la rama principal, y las hojas que se pierden vienen a ser los puntos de control.

Pero… ¿en qué se diferencia este comando con el de Revert, que revisamos hace unos segundos?

Bueno, según entiendo en este momento, reset es como un revert múltiple. Lo que hago en este caso es mencionar un punto de control específico, y desde ese punto en adelante el comando se encarga de eliminar todos los puntos subsecuentes.

Hay al menos dos tipos de reset.

El primero de ellos elimina los puntos de control, pero retiene los cambios en el documento. El segundo elimina tanto los puntos de control como los cambios que esos puntos registraban dentro del documento.

Repasemos mi lista de commits, creada específicamente para este ejemplo:

2f741a2 (HEAD -> master) Revert "[cuarto párrafo ahora agregado en apunte.txt]"
ef8292d [cuarto párrafo ahora agregado en apunte.txt]
b701a95 [tercer párrafo agregado]
4e65620 [segundo párrafo agregado en apunte.txt]
d1429b2 [archivo apunte.txt creado y primer párrafo agregado]

Yo voy a elegir el punto de control “b701a95”, lo que al aplicarlo con reset va a eliminar a todos los posteriores. Entonces ejecuto el comando:

git reset b701a95

En el texto nada se modificó. Ahora bien, si hago:

git log --oneline

Me devuelve:

b701a95 (HEAD -> master) [tercer párrafo agregado]
4e65620 [segundo párrafo agregado en apunte.txt]
d1429b2 [archivo apunte.txt creado y primer párrafo agregado]

Puedo ver que esos puntos de control por arriba de “b701a95” (los más nuevos) ya no existen.

Sin embargo si reviso el texto, este sigue igual. El contenido de mi documento se mantiene del mismo modo, retiene todo lo que le estuve agregando. Pero el registro de los puntos de control es distinto.

¿Para que sirve esto? Puede ayudarme a despejar un poco mi linea de tiempo. O también puedo usar la oportunidad para unir varios puntos de control en un solo, ayudando a agregar muchos pequeños cambios del proyecto en uno solo.

Pero es posible hacer un reset todavía más profundo. Este tipo de reset no solamente borra los puntos de control, sino que también elimina los cambios correspondientes a cada uno de los mismos.

Para hacerlo voy a concertarme en el punto de control d1429b2:

d1429b2 [archivo apunte.txt creado y primer párrafo agregado]

Si elimino todo commit por encima de ese, el resultado tendría que ser que solamente voy a retener mi archivo original y el primer párrafo que escribí. Voy a volver realmente al pasado del proyecto, eliminando todo el trabajo por delante de ese punto de control.

El comando que tengo que usar en ese caso es “git reset”:

git reset d1429b2 --hard

Lo que me regresa en la terminal:

HEAD is now at d1429b2 [archivo apunte.txt creado y primer párrafo agregado]

Ahora puedo notar que todo el texto en el documento, mi amado nuevo tutorial, ya no existe. El mismo pasó de esto:

Este es el primer renglón, para este apunte que forma parte de un ejemplo.
Este es el segundo párrafo para un ejemplo bastante poco creativo de lo que es la creación de un apunte.
Un nuevo párrafo (el número 3), no muy original pero si muy valioso.

A esto otro:

Este es el primer renglón, para este apunte que forma parte de un ejemplo.

Y esto no se puede revertir. Lo que se borró al hacer uno de estos “re-inicios duros” podemos darlo por perdido.

Para más, si reviso los puntos de control, puedo ver que:

git log --oneline

d1429b2 (HEAD -> master) [archivo apunte.txt creado y primer párrafo agregado]

Si, exactamente, todos los commits más nuevos que el original fueron borrados.

Experimentado de este modo, este tipo de comando puede realmente hacer que toda una rama de un proyecto se borre. Incluyendo con eso todo el trabajo realizado en el medio.

De todas maneras, este pequeño proyecto experimental es excelente para probar hacer algo como esto. Facil de romper, facil de arreglar.

Entonces voy a dedicarme ahora a reconstruir el proyecto, para recuperar su antigua gloria pasada de cuatro párrafos. Eso va a permitirme seguir aprendiendo cosas nuevas.

Pero antes, un error intermedio:

Demasiados cambios fueron detectados…

¿Ya mencioné que estoy trabajando con el editor de código llamado VSCodium? VSCodium es una alternativa al editor “Visual Studio code”.

Según entiendo, VSCodium es Visual Studio Code sin el código de seguimiento agregado. Dicho de otra forma, con la telemetría desactivada.

Pero cualquiera sea la versión que estés usando, es posible que te encuentres con este problema. De hecho es un error que no es motivado por el editor de texto, pero el editor de texto hace que sea más sencillo notarlo.

¿Qué me ocurrió? Bueno, al tiempo de instalar Git en la carpeta de mi proyecto comencé a recibie el mensaje de error:

Too Many Change were detected: Only the first 10000 changes will be shown bellow.

mensaje de vscodium

Y traducido al vuelo:

Demasiados cambios fueron detectados. Solamente los primeros 10000 cambios van a ser mostrados debajo.

¿¡Los primeros diez mil cambios!? Pero si mi proyecto tiene apenas cuatro o cinco modificaciones…

Para peor, el mensaje me invitaba a registrar esos cambios como commits. ¿Pero cúal es el sentido? No se de que puntos de control me esta hablando.

Respuesta. Lo que ocurrió fue lo siguiente: existía una garpeta .git de la que yo no sabia nada.

Al iniciar un proyecto se crea una carpeta de .git donde se van registrando nuestros puntos de control a medida que los generamos. Esa carpeta solamente controla lo que ocurre dentro del directorio donde fue creada y no es visible a menos que exploremos los archivos ocultos del directorio.

Lo que yo no sabia es que existía otra carpeta .git, en un directorio de un nivel superior. Esa carpeta se encontraba en mi directorio personal o “Home”.

No estoy seguro de como se creó o en que momento lo hizo, pero eso era lo que generaba el problema. Incluso cuando trabajaba en algo sin invocar a Git, al estar trabajando en un subdirectorio el programa me seguía pidiendo que registre los cambios.

Al borrar esa carpeta .git externa al proyecto, el problema se solucionó.

Hay otras causas que este problema ocurra, pero esta es al menos la que yo me encontré personalmente hasta el momento.

Branches: el asunto de las ramas

Antes, al revisar el estado de seguimiento de mi proyecto, encontré ejemplos de lo siguiente:

On branch master

O también:

(HEAD -> master)

¿Por qué “master”? ¿A qué se refiere Git con la frase “On branch master”?

Conseguir estas respuestas nos pone en el plano de lo que supongo es una de las funcionalidades más importantes del programa.

Git utiliza la idea de “ramas” al momento de organizar las distintas versiones de un proyecto.

Voy a tratar de explicarlo según lo entiendo. Un proyecto cualquiera tiene una rama principal, o en inglés una “Master Branch”. Esta rama se genera automáticamente, al iniciar Git en el directorio a seguir.

Cuando Git me menciona que me encuentro “On branch master” quiere decirme que me encuentro en la rama principal. Por lo que podrían existir también otras ramas.

Para volver al ejemplo de mi documento de texto, mi tutorial tiene un texto central que ya estuve ampliando. Ese texto constituye la rama principal, el proyecto a completar.

Digamos que quiero agregar una nueva sección al texto. Podemos pensar que esa es una nueva funcionalidad para el proyecto, como añadir una nueva página en un sitio web o un buscador en un programa.

Siendo que me interesa seguir aplicado en mi trabajo, digamos que voy a añadir una nueva sección a mi tutorial. Y esa nueva sección va a consistir en un poema experimental de dudoso calidad.

Realmente no puedo saber si ese poema va a funcionar en el proyecto. Y no quiero modificar mi tutorial, porque tengo miedo de volverlo muy extenso o de romper su formato. Dicho de ogra forma, me interesa que la rama principal se mantenga estable.

Establezco entonces una nueva rama o “branch”, que podemos imaginar se desprende de la master branch. Puedo llamar a esa nueva branch como la “rama_experimento”.
En esta nueva rama puedo escribir a gusto sin miedo de alterar el texto original.

Por otra parte, mi proyecto principal existe ahora de manera independiente. Vive por separado en la master branch.

Luego si el resultado final me gusta, puedo fusionar la “rama_ experimento” con la master branch. Con esto obtengo por resultado una nueva master branch, que contiene el tutorial original más el poema agregado.

Pero si decido borrar la poesía, incluso si la misma encuentra en un archivo diferente, esto es muy fácil de hacer porque no tengo que preocuparme por afectar el núcleo de mi tutorial.

En lo que sigue, voy a revisar todo esto de manera práctica. Pero no te preocupes, no voy a hacerlo escribiendo poesía de dudoso gusto.

Ahora vamos a interiorizarnos en una serie de comandos que nos permiten crear, destruir y movernos entre las ramas del trabajo que estemos monitoreando en Git.

Cómo crear una nueva rama en Git

Voy a continuar con el tema de las ramas. Lo primero que voy a hacer es crear una nueva rama.

Luego del anterior intermedio, pude reconstruir algo de mi proyecto. Si, lo borré para un ejemplo y ahora volví a reconstruirlo.

Por suerte se trata de un proyecto pequeño. Y ahora es más pequeño. No tiene cuatro puntos de control como antes, solamente tiene dos commits realizados.

Una vez más, puedo revisar los checkpoints que incluye mi rama con el comando:

git log --oneline

38025bd (HEAD -> master) [segundo párrafo agregado en apunte.txt]
d1429b2 [archivo apunte.txt creado y primer párrafo agregado]

Al leer esto entiendo que (HEAD -> master) me avisa que me encuentro en la master branch. Pero yo quiero empezar una nueva rama dentro de este proyecto.

Para esto voy a poner en práctica un comando que nunca utilicé hasta el momento. Se trata del comando “git-branch”, cuya entrada en el manual de Git me dice:

git-branch(1)
List, create, or delete branches.

manual de git

Esto quiere decir que git-branch va a permitirme listar, crear o eliminar ramas según la forma que vaya a darle al escribirlo.

Voy a empezar creando una nueva rama, a la que voy a llamar “experimental”. De esta forma, el comando simplemente va acompañado del nombre de la rama que estoy creando.

git branch experimental

Aunque parece que nada sucedió, una nueva rama acaba de ser generada para el árbol de mi proyecto. Para poder listar las ramas existentes hasta el momento, agrego la opción “-a” del siguiente modo:

git branch -a

experimental
* master

Eso me devuelve las ramas existentes en este momento.

Puedo notar que la palabra “master” se muestra resaltada en color verde(eso en mi consola). Y además la palabra viene acompañada con un asterisco que la señala. Eso me informa que me encuentro trabajando en la rama “master”.

Pero lo que me interesa es moverme a la nueva sub-rama. Para esto voy a usar el comando “git checkout”, un comando que ya revisé con anterioridad. La diferencia es que antes lo utilicé para revisar un commit dentro de una rama, y ahora lo voy a usar para ver entrar a una rama distinta.

Por lo demás el comando se escribe igual, acompañado con el nombre del punto al que nos dirigimos.

git checkout experimental

Switched to branch 'experimental'

Con este mensaje Git me indica que ahora me encuentro trabajando en mi nueva rama, bien llamada “experimental”. En la pantalla el texto del tutorial no se modificó para nada.

Como se puede notar “experimental” no es más que una copia idéntica del contenido en la rama maestra. Es una buena forma de trabajar en un entorno que funciona igual al que conocía, sin el miedo de romper o destruir nada que afecte al original.

Puede parecer obvio pero no está de más recordarlo: sabiendo lo anterior, puedo pensar que si en el futuro decido integrar las dos ramas, el resultado va a ser el contenido de la master branch más lo nuevo que vaya a agregar en la rama experimental.

Si ahora hago:

git branch -a

* experimental
master

El comando me informa que ahora estoy en una rama diferente. Y esa rama es la que se llama “experimental” que viene señalada por un asterisco.

Lo que sigue viene directamente de lo anterior, y todo se encuentra en empezar a hacer alguna modificación en esta nueva rama. Y a partir de eso, se me aparecen dos caminos posibles.

Entonces voy a agregar un nuevo párrafo al tutorial del ejemplo:

Este es un párrafo experimental. Por lo tanto, fue escrito en la rama experimental. No es un problema, por lo que no tengo que buscar rimas con “mental”.

Lo siguiente es seguir los pasos que ya conozco para transformar esta modificación en un punto de control creando un nuevo commit. Ya repasé bastante esos comandos antes, por lo que no voy a repetir de nuevo todo el camino.

Recordemos que me encuentro en la… si, la rama experimental. Si me muevo de vuelta a la rama maestra, este nuevo párrafo no aparece. Puedo decir entonces que la nueva modificación se encuentra “aislada” dentro de su propia rama.

Sin embargo es interesante revisar lo siguiente. Si reviso el log de puntos de control desde la rama experimental, obtengo por resultado:

git log --oneline

143e963 (HEAD -> experimental) [párrafo experimental agregado en apunte.txt]
38025bd (master) [segundo párrafo agregado en apunte.txt]
d1429b2 [archivo apunte.txt creado y primer párrafo agregado]

Pero si lo reviso desde la rama maestra obtengo:

git log --oneline

38025bd (HEAD -> master) [segundo párrafo agregado en apunte.txt]
d1429b2 [archivo apunte.txt creado y primer párrafo agregado]

Hay algo para pensar en todo esto, aunque todavía no se bien que es.

En todo caso, como dije antes, pienso que ahora tengo dos opciones. Una de esas ideas es “fusionar” las dos ramas. La otra opción es borrar la rama experimental.

Cómo fusionar dos ramas en Git

Voy a empezar por hacer un “merge” de las dos ramas. Esto puedo pensarlo como unirlas, fusionarlas, o cualquier otro sinónimo que se me ocurra.

Primero voy a volver a la master branch:

git checkout master

Switched to branch 'master'

Acto seguido voy a usar un nuevo comando, que según el manual de Git dice:

git-merge(1) Join two or more development histories together.

manual de git

Esto es “unir dos o más historias de desarrollo juntas”. Esto es interesante, podemos explicarnos que es una rama pensándola como una historia (una linea de tiempo) del desarrollo del proyecto.

Entonces escribo el comando “git merge”, acompañado del nombre de la rama que voy a unir en la master branch.

git merge experimental

Updating 38025bd..143e963
Fast-forward
apunte.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

Y si ahora reviso el log:

git log --oneline

143e963 (HEAD -> master, experimental) [párrafo experimental agregado en apunte.txt]
38025bd [segundo párrafo agregado en apunte.txt]
d1429b2 [archivo apunte.txt creado y primer párrafo agregado]

Momento… dice: (HEAD -> master, experimental) ¿Qué significa eso?

Al parecer las dos ramas se unieron, por lo que la rama “master” contiene ahora lo que había puesto en la rama “experimental”. Pero experimental continua existiendo. De hecho puedo volver a esa rama, para seguir usándola:

git checkout experimental
Switched to branch 'experimental'

¿Qué ocurre ahora si me decido a borrar la sub rama, volviendo a quedarme con una única rama principal?

Cómo eliminar una rama en Git

Para eliminar una rama, le agrego la opción “-d” al comando “git branch”.

Ejemplo. Si quiero eliminar la rama llamada como “experimental” en mi proyecto, hago uso del comando:

git branch -d experimental

Alternativamente puedo agregar la opción “-D” para forzar el borrado de la rama. Esto va a hacer que mi branch se elimine, incluso si tiene puntos de control que todavía me falta confirmar.

git branch -D experimental

Puedo eliminar una rama incluso luego de hacer una fusión.

Solucionar conflictos al unir ramas en Git

Existe una situación en Git que se conoce como “merging conflicts” o “conflictos de fusión”.

Al hacer mi ejemplo anterior, describí las dos ramas en mi proyecto. Una de esas ramas era la master branch y la otra era la rama llamada “experimental”.

En un primer momento, la sub-rama no era otra cosa que una copia de la rama principal. Solamente al agregar texto en la rama experimental fue que las dos empezaron a diferenciarse en algo.

Por eso, al unir las dos vertientes, la rama master solamente tuvo que agregar lo nuevo que le traía la rama experimental. El resto era igual en ambas, no había ningún conflicto al fusionarlas.

Pero ahora supongamos que la master branch es modificada luego de ser crear la rama experimental. Ahora la sub-rama no es solamente distinta a la principal en la nueva información agregada, también es diferente en otros puntos donde no van a coincidir.

En el momento de hacer el merge ¿En qué forma resuelve Git estas discrepancias? ¿Cual de las dos ramas contiene los cambios definitivos?

Del mismo modo que hice antes, voy a hacer un merge de la rama Master con la experimental.

git merge experimental

En mi breve experiencia hasta el momento, pueden ocurrir tres cosas:

1) El merge de las ramas se concreta sin inconvenientes. Todo bien, no puedo continuar con lo que estaba haciendo.

2) Ocurre algún tipo de conflicto y en la terminal se abre un mensaje pidiendo que explique la razón de la fusión.

Este mensaje aparece dentro del editor de texto que uso en la terminal, por ejemplo en mi caso se abre con el programa Nano.

Puedo escribir un comentario para explicar la resolución del problema o no. Lo importante es creo yo que, al cerrar este mensaje, la fusión se completa.

En este momento voy a retener la master branch, y voy a fusionar la rama experimental solo para agregar los datos nuevos que esta contenía.

Puedo revisarlo con el comando

git log --oneline

3) Al encontrarme con uno de estos conflictos, recibo un mensaje similar al siguiente:

Auto-merging apunte.txt
CONFLICT (content): Merge conflict in apunte.txt
Automatic merge failed; fix conflicts and then commit the result.

Si reviso esto detenidamente, me dice que hay un conflicto y que ese conflicto se refiere al contenido (content) de un documento. Ese documento específico es “apunte.txt y puedo revisar las diferencias en el proyecto.

Me aparecen estas cuatro opciones:

• Accept Current Change: esto es, aceptar la modificación en el documento.
• Accept Incoming Change: Aceptar la modificación que se avecina.
• Accept Both Changes: Aceptar ambas modificaciones.
• Compare changes: comparar ambas modificaciones.

¿Qué hacer entonces?

Bueno… lamento decir que todavía estoy tratando de entender como funciona esta situación. Voy a expandir el tema cuando lo comprenda mejor.

Es importante notar que lo que estoy haciendo es generando este tipo de errores por mi cuenta, para poder aprender un poco más del tema. En un contexto de trabajo diario seguramente podemos encontrar conflictos más complejos, en especial cuando muchas personas trabajan en un mismo proyecto.

Pero aun de este modo, trabajando solo, creo que lo importante es no tener miedo cuando aparece alguno de estos conflictos.

Conclusión:

Espero que esta “Guía Básica para usar Git” te resulte de utilidad al momento de empezar a usar este programa.

No soy un experto en el tema, y no pretendo ser uno en este lugar. Hice todo lo posible por transmitir mi experiencia en lo que fue mi primera aproximación al programa.

Es por eso que hay que tener en cuenta dos cosas para las que te pido tu ayuda:

1- No considero que esta guía se encuentre completa. Le estoy dando una conclusión para poder empezar a hacer otros proyectos, pero prometo volver para expandir este material mientras aprendo cosas nuevas en Git.

Si encontrás que alguna parte del texto puede mejorar, por favor avisame en los comentarios o escribime un correo electrónico compartiendo tu opinión.

2- Si encontrás algún error en el material, por favor avisame para que pueda corregirlo. Lo mismo si te parece que alguna sección es difícil de entender, enviame un mensaje o comentario para que pueda solucionarlo.

En resumen… la seguimos en el próximo apunte.