Git – Dr. Edu


		Estas notas son sólo para registrar la experiencia de uso de esta herramienta, no se busca sea una documentación formal ni un tutorial. Simplemente se trata de un registro espontáneo de cómo ha resultado el uso de este producto y un recordatorio para su autor de cosas útiles a tener presentes.

1. Antecedentes

Ya antes había explorado y usado algunas aplicaciones para el control de versiones. CVS no me gustó por la forma en la que creaba y desperdigaba directorios por doquier. En alguna vez supe de Perforce y me gustó pero sin tener proyectos de software a tomar en serio, no pasé de usarlo brevemente. En Banamex me tocó trabajar con PVCS (que no se usaba más que para cumplir con un requisito administrativo y por tanto se desperdiciaba lo que éste proveía) y con la adquisición por Citi toqué brevemente a Dimensions (que terminó en lo mismo, que con PVCS). Después supe de git y esto es lo que he aprendido.

1.1. Documentación

1.1.1. Convenciones

Mientras que al producto (y proyecto detrás de éste) debe hacérsele referencia como Git¹, estas notas están principalmente enfocadas al uso de la utilería que implementa el mecanismo de control de versiones, que lo materializa el comando git. El uso de negritas y fuente tipográfica deberá ser suficiente para denotar a qué se está haciendo referencia.

Elementos a substituir en ejemplos de comandos e instrucciones se denotan entre paréntesis angulares e itálicas, como <elemento>. Cadenas así indicadas pero que no tengan itálicas representan un actual resultado o salida a pantalla.

En la ejemplificación de comandos y sus resultados, aquello introducido por el usuario es mostrado en negritas. Para estos casos se mostrará también el prompt del sistema operativo, como una referencia distintiva adicional.

1.1.2. Recursos

Aunque hay una enorme cantidad de documentación en la web, incluyendo la que Git proporciona en su sitio oficial, como en línea (i.e. a través del comando man y con la utilería git misma), así como videos y tutoriales² por todos lados, yo encontré invaluable un libro³ que hallé en la web y cuya lectura es muy recomendable.

Buscando literatura de Git… Aquí hay un libro gratuito https://t.co/K7mQnESKXf… ¡574 páginas!

— Eduardo Rodríguez A. (@eravila_) January 7, 2015

Claro que, al final es simplemente adoptar un libro o video, el que a uno le agrade más, y seguirlo cabalmente de principio a fin.

1.2. Consideraciones

Con respecto a las fuentes de aprendizaje o documentación, pese a las enorme cantidad de ellas y lo bien explicado, ejemplificado o ilustrativo método de exposición empleado, lo cierto es que git no es una herramienta fácil de aprender, salvo más allá de los comandos básicos. Tiene una curva de aprendizaje pronunciada, especialmente en su utilización con proyectos grandes y entornos compartidos. Esto y algunas cosas (situaciones) más, que no se enseñan en cualquier parte, nos llevan a que sea experiencia adquirida con la práctica y la acumulación del conocimiento del uso de ésta, lo que poco a poco nos llevan a entender los beneficios y potencia de la herramienta. Este entendimiento no llega rápido ni es posible pronosticar cuándo ocurrirá. Al final es práctica.

Ese "momento dorado" en el que uno empieza a entender como es que funciona algo y lo que puede hacerse sin tener que leer un manual (me acaba de pasar con git).

— Dr. Edu 🐾 (@dreduphd) May 16, 2019

1.3. Entornos

Antes que hablar de versiones, prefiero referirme a «entornos», ya que la utilería busca ser la misma en los diferentes sistemas operativos para los cuales está disponible. Aquí sólo pongo mis experiencias de aquellos en los que la he usado.

1.3.1. Windows

Curiosamente en Windows funciona bien.

1.3.2. OS X

Las utilerías de línea de comando (CLI) para desarrollo en OS X (XCode) incluyen a git, por lo que aquí no describo la instalación de esta utilería para el caso particular de OS X 10.9. Al ya tenerlo instalado, sólo hay que hacer algunas cosas para configurarlo antes de usarlo (ver más adelante).

1.3.3. macOS

En el caso de la sucesión de OS X, macOS, se experimentó el reemplazo de la utilería por la actualización que de ésta puede obtenerse de la página del proyecto Git (ver más adelante).

1.3.4. Linux

Muy similar a la experiencia con OS X, tanto en un linux de AWS como en Ubuntu (que en realidad es más bien un «Winbuntu»), es decir, la utilería ya viene instalada y es cosa de usarla.

2. Uso

De aquí al final de la página, las notas son sobre el uso de la utilería, independientemente del sistema operativo y versión. De haber alguna nota o consideración por versión o sistema operativo, se mencionará en su oportunidad.

2.1. Instalación y actualización

Como se señala en el libro mencionado³, lo primero y más importante es proceder a determinar la versión de git con que se cuente

$ git --version git version 2.17.1

Si por alguna razón se decide actualizar el producto. Existen varias alternativas. Por experiencia puedo decir que lo mejor es hacerlo de forma consistente a como se procedió con la instalación de éste. Por ejemplo, si el producto fue descargado e instalado desde un inicio con un administrador de paquetes o software (rpm, yum para el caso de un linux), desde un store (e.g. App Store, Homebrew o MacPorts para el caso de Mac), mediante un instalador (como el disponible en la página del proyecto), manualmente, o si este se encontraba precargado, lo más adecuado es continuar de esta forma. Si esto va a cambiar, conviene primero eliminar la versión previa y entonces proceder con la nueva «desde cero.» Para el caso de la actualización a 2.19 aquí descrita, se decidió dejar que el instalador sobre escribiera la versión anterior. Como control, para validar que esto realmente ocurriera, se procedió primero a tomar nota de la ubicación de la utilería con

$ which git /usr/local/bin/git

El comando type puede emplearse también para conocer la ubicación del programa.

2.2. Configuración

La configuración inicial, la revisión del estado de la configuración después de una actualización o el reiniciar ésta, comprende algunos pasos. Antes es necesario entender los tres niveles de configuración que Git comprende: a nivel sistema, usuario y repositorio. Detalles de éstos y los archivos en los que se apoya para guardar los valores de configuración están claramente explicados en la sección 1.6 del libro de Chanon y Starub³.

Habiendo procedido con lo anterior, lo esencial es:

Validar la versión con la que se está trabajando.
Establecer la identidad, y quizás el editor a usar por defecto (esto es más que nada por comodidad), desde la linea de comando, cosa que se logra con los comando siguientes o editando el correspondiente archivo de configuración (descritos en en la sección 1.6 del libro de Chanon y Starub³)

$ git config --global user.name "usuario" $ git config --global user.email buzon@dominio.tld $ git config --global core.editor editor

Los parámetros que hayan sido puestos pueden verificarse con

$ git config --list

2.3. Utilización

Aquí es donde se pone bueno el asunto. Hacer uso de la herramienta. Hay muchos escenarios y formas de empleo. Igualmente hay muchas formas y situaciones en las que las cosas pueden ir val, y verdaderemente mal. Cubrir cada una de ellas es imposible. Así que, sin algún orden en particular pero sí buscando que sea de forma lógica, mis notas de uso.

2.3.1. Creando un depósito

En el ramo le decimos «repositorio» (mala traducción y empleo de «repository«) al depósito de archivos sobre el que queremos dar seguimiento de su modificación y administración. En términos prácticos éste no es más que un directorio en nuestro equipo, el cual es inicializado de cierta manera para que git pueda dar seguimiento a lo que ocurre en éste.

La cosa se complica un poco con la presencia de GitHub, GitLab y servicios similares. Estos dos son servicios puestos en la web para hacer lo que también puede hacerse en una instalación local (vía una intranet, por ejemplo), por lo que debemos ahora considerar una variable adicional en el proceso de creación del depósito de archivos. Usualmente en estos servicios se habla de «proyectos» (aunque no necesariamente se puede hablar de una única relación 1:1 entre proyectos y depósitos, pero digamos que es lo más usual y menos complicado). Los siguientes dos apartados describen las dos posibilidades en la creación de los depósitos y ambas descripciones se complementan.

Caso 1: empezando desde un servicio

Supongamos que hemos creado ya un proyecto en GitHub o en GitLab. El siguiente paso lógico es cómo lo «mapeamos» contra un directorio en nuestro equipo, donde realmente trabajaremos en sus componentes (algunas imágenes o resultados en pantalla pueden variar). En la imagen inferior, el diálogo principal al crear un proyecto en GitLab.

El siguiente paso es inicializar (o reinicializar) el directorio (asumiendo está vacío o es de reciente creación) con el que trabajaremos. La secuencia de comandos sería:

cd /<path>/<to>/<my>/<local>/<project>
git init
git remote add origin https://<myLogin>@<url>/<myLogin>/<myproject>

Algunos elementos a substituir no del todo evidentes son: <URL> debe ser substituido por el URL del servicio empleado (para este ejemplo, bien podría ser gitlab.com, substituirlo por el apropiado); <myLogin> el nombre de usuario empleado para acceder al servicio donde se creó el proyecto.

El siguiente paso para entrar en sincronía es git pull, que obligará a firmarse en el servicio. Por continuidad con las instrucciones mostradas antes, se continua mostrando con elementos a substituir la salida en pantalla.

$ git pull
Username for 'https://<url>': <myLogin>
Password for 'https://<myLogin>@<url>':
warning: redirecting to https://<url>/<myLogin>/<myProjectName>.git/
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From https://<url>/<myLogin>/<myProjectName>
* [new branch] master -> origin/master
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.
git pull <remote> <branch>
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream-to=origin/<branch> master

En este punto, si el directorio local está vacío, así continuará. Es una confusión general el esperar que los posibles archivos que ya tenga nuestro proyecto en el servicio remoto paarezcan aquí. Como se muestra arriba, pese al «pull«, git(1) indica que no se tiene conocimiento de una «rama» con la que deba hacerse un seguimiento (literalmente, la revisión de componentes que se piensa hacer, el «checkout«). Para esto es necesario hacer:

git checkout master

con lo que ya podremos ver los archivos del proyecto en el directorio local.

Caso 2: Iniciando en un directorio

Ya sea que se cree un directorio, o que éste ya exista y tenga un determinado contenido, el primer paso es su inicialización, cosa que se hace con el comando git init. Esto inicializará a dicho directorio como repositorio, creando el directorio oculto .git.

En el caso de que hubiera un repositorio remoto al cual hacer push, es necesario asociar nuestro directorio con dicho repositorio. Para esto se emplea:

$ git remote add origin <url>

donde <url> es la URI del repositorio, como puede ser el caso de los servicios expuestos en el apartado previo. Adicionalmente, antes de cualquier otra acción, es conveniente (para el caso en el que la rama es «master»):

$ git pull $ git branch --set-upstream-to=origin/master master

A partir de aquí, git add, git commit y git push deberán funcionar sin problema.

Sí, por otra parte, se está iniciando en una rama nueva de forma local, la secuencia de acciones es:
$ git checkout -b <branch name> $ git push --set-upstream origin <branch name>

2.3.2. Forks

Un fork es una derivación de un repositorio, una copia que se hace para poder trabajar a la par del proyecto original, sin que esto implique hacer un merge posterior con el origen. En GitLab se puede mantener un fork en sincronía con el depósito original. En GitHub, uno debe manualmente hacerlo, mediante una serie de pasos muy similares a cuando se crea el depósito en forma local primero y luego se enlaza con el depósito remoto (ver punto previo, caso 2)⁶.

Ambos enfoques tienen sus pros y contras.

2.3.3. Hooks

Cada vez que se inicializa un directorio como repositorio Git, un directorio oculto con nombre .git se crea en éste. El directori0 oculto funge como «base de datos» de la utilería y es donde se conserva todo lo que ésta necesita para trabajar, en forma de archivos y directorios.

Uno de los directorios en .git es hooks. En éste se encuentran scripts de ejemplo que muestran o dan una idea de lo que puede hacerse para que se disparen o realicen ciertas acciones ante ciertos eventos git.

2.3.4. Recipes

Algunos oneliners, hacks o meras recetas para acciones comunes y rutinarias.

**+ Evitando listar archivos no seguidos (untracked)**

$ git status -uno

+ Listando los archivos modificados entre ramas

$ git diff --name-only <branch1> <branch2>

+ Eliminando ramas

Localmente:

$ git branch -d <branch>

Remotas

$ git push origin --delete <branch>

+ Listando los cambios de un archivo modificado

git diff <file>

+ Comparando actividad en una rama/qué ha sido modificado en una rama/cuando se inició una rama

Localmente:

git diff --name-status master..<branch>

git whatchanged --name-only --pretty="" origin..HEAD

En GitLab, del menú del lado derecho: Repository > Compare. Seleccionar qué se compara (rama a revisar) contra cuál será la base (usualmente master). Click en Compare. Se listan delprimer al último commit y los archivos tocados.

2.3.5. Troubleshooting

A reserva de que estas notas se coloquen en un lugar más apropiado, coloco aquí algunas cosas sueltas a las que he recurrido ante un problema con o mensajes de error (o advertencia) de git.

– Git refusing to merge unrelated histories on rebase

Al hacer uso de git(1), este mensaje puede aparecer:

fatal: refusing to merge unrelated histories

para resolver este problema he recurrido a:

git pull origin master --allow-unrelated-histories

– fatal: .git/index: index file open failed: Permission denied

En algún punto, con diversos comandos (git fetch, git status) este mensaje llega a mostrarse. La explicación es, si hacemos ls -al .git, que el archivo index sus permisos «han desparecido». Esto es lo que el comando anterior nos mostraría:

$ ls -al
total 228
drwxrwxrwx 1 evasd evasd   4096 Jun 12 11:23 .
drwxrwxrwx 1 evasd evasd   4096 Jun 12 10:56 ..
drwxrwxrwx 1 evasd evasd   4096 Jun 10 17:06 branches
-rw-rw-rw- 1 evasd evasd     12 Jun 12 11:23 COMMIT_EDITMSG
-rw-rw-rw- 1 evasd evasd    341 Jun 10 17:40 config
-rw-rw-rw- 1 evasd evasd     73 Jun 10 17:06 description
-rw-rw-rw- 1 evasd evasd   2612 Jun 12 15:33 FETCH_HEAD
-rw-rw-rw- 1 evasd evasd     28 Jun 10 17:09 HEAD
drwxrwxrwx 1 evasd evasd   4096 Jun 12 11:01 hooks
---------- 1 evasd evasd 224377 Jun 12 15:17 index
drwxrwxrwx 1 evasd evasd   4096 Jun 10 17:06 info
drwxrwxrwx 1 evasd evasd   4096 Jun 10 17:08 logs
drwxrwxrwx 1 evasd evasd   4096 Jun 11 18:53 objects
-rw-rw-rw- 1 evasd evasd     41 Jun 10 17:09 ORIG_HEAD
-rw-rw-rw- 1 evasd evasd   1564 Jun 10 17:08 packed-refs
drwxrwxrwx 1 evasd evasd   4096 Jun 10 17:08 refs

La solución se alcanza con el comando:

$ chmod 666 .git/index

– fatal: unable to read config file ‘/Users/<user>/.gitconfig’: No such file or directory

Si al emplear un comando como git config --global --list se reporta la inexistencia de /Users/evasd/.gitconfig es probable a que sea por no tener valores de configuración generales. Ver las anotaciones de configuración al respecto.

– error: pathspec ‘branch1’ did not match any file(s) known to git

Si no se reconoce una rama al tratar de cambiarse a ella (git checkout <branch>), esto es porque localmente no se tiene conocimiento de su existencia. Bastará un git pull para descargar las referfencias necesarias.

$ git checkout master M src/__pycache__/__init__.cpython-36.pyc M src/__pycache__/imageLoad.cpython-36.pyc M src/__pycache__/params.cpython-36.pyc M src/features/__pycache__/nonspatial.cpython-36.pyc M src/features/__pycache__/util.cpython-36.pyc Switched to branch 'master' Your branch is up-to-date with 'origin/master'. $ git pull remote: Enumerating objects: 4, done. remote: Counting objects: 100% (4/4), done. remote: Compressing objects: 100% (4/4), done. remote: Total 4 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (4/4), done. From https://gitlab.com/repository/project 5069be7..fe58927 branch1 -> origin/branch1 Updating 5069be7..fe58927 Fast-forward scripts/model_search.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) $ git checkout branch1 Already on 'branch1' Your branch is up to date with 'origin/branch1'

– .gitignore cannot be ignored

El archivo .gitignore debe estar en el repositorio, para empezar. Tiene que ser parte del árbol del repositorio, para que los cambios puedan identificarse o ser ignorados. De lo contrario, debe agregarse y confirmarse por lo que no puede ser ignorado.

– remote: HTTP Basic: Access denied or fatal: Authentication failed for <URL>

Si se está tratando de clonar un repositorio por primera vez, es posible que este mensaje de error ocurra. La solución consiste en usar el URL del repositorio de la forma: http://<user>:<password>@<original-url-without-http://>.

2.4. Herramientas y servicios

Los siguientes apartados son un breve recuento de algunos servicios y herramientas (propias de Git o de terceros) que pueden ser populares y estar marcando una tendencia pero que sobre todo son muy útiles.

2.4.1. GitHub

GitHub, ahora una subsidiaria de Microsoft, es un servicio de alojamiento basado en web para el control de versiones empleando Git. Se utiliza principalmente para código (de programación) pero puede ser empleado para cualquier otro tipo de archivo. Ofrece todas las funciones de control de versiones distribuidas y administración de código fuente de Git, más algunas características adicionales que le confieren un cierto valor agregado.

2.4.2. Gitlab

GitLab es una herramienta de ciclo de vida de desarrollo de software basada en web que proporciona un administrador Git con características de wiki, seguimiento de problemas y canalización de CI/CD.

2.4.3. gitk

gitk es una herramienta de entorno gráfico para presentar y explorar (algunos la llamn mini browser) la bitácora e historial de cambios de Git. Esta no necesariamente es incluida en todas las distribuciones y debe ser instalada posteriormente. El proceso de instalación se ilustra a continuación:

$ gitk Command 'gitk' not found, but can be installed with:
sudo apt install gitk
$ sudo apt install gitk [sudo] password for user: Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages:
git-doc
The following NEW packages will be installed: gitk 0 upgraded, 1 newly installed, 0 to remove and 260 not upgraded. Need to get 137 kB of archives. After this operation, 1,530 kB of additional disk space will be used. Get:1 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 gitk all 1: 2.17.1-1ubuntu0.4 [137 kB] Fetched 137 kB in 1s (154 kB/s) Selecting previously unselected package gitk. (Reading database ... 43900 files and directories currently installed.) Preparing to unpack .../gitk_1%3a2.17.1-1ubuntu0.4_all.deb ... Unpacking gitk (1:2.17.1-1ubuntu0.4) ... Setting up gitk (1:2.17.1-1ubuntu0.4) ... Processing triggers for man-db (2.8.3-2) ... $

Como parte de la configuración necesaria, está la definición de una variable de ambiente.

$ gitk application-specific initialization failed: no display name and no $DISPLAY environment variable Error in startup script: no display name and no $DISPLAY environment variable while executing "load /home/evasd/miniconda3/envs/ir-models/lib/libtk8.6.so Tk" ("package ifneeded Tk 8.6.8" script) invoked from within "package require Tk" (file "/usr/bin/gitk" line 10)
$ export DISPLAY=:0.0 $ gitk application-specific initialization failed: couldn't connect to display ":0.0" Error in startup script: couldn't connect to display ":0.0" while executing "load /home/evasd/miniconda3/envs/ir-models/lib/libtk8.6.so Tk" ("package ifneeded Tk 8.6.8" script) invoked from within "package require Tk" (file "/usr/bin/gitk" line 10)

En el ejemplo anterior, podemos ver que tras la definición de la variable elproblema persiste y aparentemente es atribuible a la ausencia del paquete Tk.

$ sudo apt install tk Reading package lists... Done Building dependency tree Reading state information... Done tk is already the newest version (8.6.0+9). tk set to manually installed. 0 upgraded, 0 newly installed, 0 to remove and 260 not upgraded.

Aquí puede verse que el paquete ya está instalado y lo que se requiere es un compoenete adicional:

Procedemos a descargar el Xming X Server for Windows
La instalación con los parámetros y opciones por defecto parece funcionar bien.
$ gitk

con lo que se deberá mostrar:

2.4.4. GitHub Desktop

Una aplicación práctica que ayuda una vez que uno ya domina los comandos git.

2.4.5. Fork

2.4.6. VS Code

2.5. Two-factor authentication

Cuando se activa la opción de verificación por un segundo elemento (two-factor authentication). el acceso por línea de comando puede complicarse. GitHub provee instrucciones al respecto, que esencialmente consisten en generar un token de autenticación personal que se emplea en lugar del password.

2.6. Preguntas abiertas

Éstas son algunas preguntas que no me he podido responder o para las cuales no me convence la respuesta que he logrado encontrar. He habilitado la sección de comentarios de esta página para tener la oportunidad de que alguien más pueda ayudarme a responderlas.

#1.VS Code cuenta con la capacidad de ejecutar acciones de control de versiones con git, también puede desplegar una terminal dentro del editor (como un panel adicional). Dentro de esta terminal, por tanto, es posible ejecutar acciones con el comando git. Uno esperaría que el estado de git fuera, por comando, el mismo que mostrara VS Code pero parece que no es así (la lista de archivos no reconocidos es grande y eso no lo reporta VS Code).: .
#2. ¿Qué es mejor realmente: hacer un merge o hacer un rebase?: .

3. Referencias

Git, web site. Visited: 2018.10.24. URL: https://git-scm.com.
Mary Rose Cook, «Git in six hundred words,» blog, consulted: 2015.01.25. URL: http://maryrosecook.com/blog/post/git-in-six-hundred-words.
Scott Chacon and Ben Straub, «Pro Git«, Apress, 2nd edition, 2014. USA. URL: https://git-scm.com/book/en/v2.
Tushar Agrawal, «How to Use Git Hooks in Your Development Workflow«, Hackernoon, web. Published: 2019.02.07; consulted: 2019.06.11. URL: https://hackernoon.com/how-to-use-git-hooks-in-your-development-workflow-a94e66a0f3eb.
Will Hay Jr.»The Architecture and History of Git: A Distributed Version Control System«, Medium, web. Published: 2018.12.07; Visited: 2019.06.20. URL: https://medium.com/@willhayjr/the-architecture-and-history-of-git-a-distributed-version-control-system-62b17dd37742
«Configuring a remote for a fork,» GitHub, web; Visited: 2020.03.14. URL: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork.
Vincent Driessen, «A successful Git branching model«, nvie.com, web. Published: 2010.01.05; visited: 2022.07.12. URL: https://nvie.com/posts/a-successful-git-branching-model/.

4. Recursos

Completion scripts, Git, web site. Visited: 2019.06.12. URL: https://git.kernel.org/pub/scm/git/git.git/plain/contrib/completion/.

Creación: 2015.01.09
Última actualización: 2022.07.12

El contenido de este sitio puede ser copiado y reproducido libremente mientras no sea alterado y se cite su origen. Marcas y productos registrados son citados por referencia y sin fines de lucro o dolo. Todas las opiniones son a título personal del o los autores de éstas y, salvo sea expresado de otro modo, deben considerarse como registro y expresión de la experiencia de uso de aquello que es tratado. Para conocer más sobre la posición de privacidad y responsabilidad de lo que se presenta en este sitio web y como ha sido obtenido, consulte la declaración al respecto.

Deja una respuesta Cancelar la respuesta

Introduce aquí tu comentario...

Introduce tus datos o haz clic en un icono para iniciar sesión:

Correo electrónico (obligatorio) (La dirección no se hará pública)

Nombre (obligatorio)

Web

Estás comentando usando tu cuenta de WordPress.com. ( Salir / Cambiar )

Estás comentando usando tu cuenta de Facebook. ( Salir / Cambiar )

Cancelar

Conectando a %s

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.