Control de versiones con GIT

(Do not) Use the git push --force Luke

Andrés Hernández - tonejito

Febrero 2025

Control de versiones con git

Información del curso

Nivel de especialización

Básico

Objetivo

El alumno conocerá el sistema de control de versiones git y aprenderá el uso de esta herramienta tanto desde línea de comandos, como desde un cliente de escritorio y vía web a través de Github.

Perfil del asistente

Estudiantes, pasantes o egresados de carreras afines a computación, desarrolladores y entusiastas de la programación.

Conocimientos previos

Conocimientos básicos de GNU/Linux y Windows a nivel usuario
Uso de internet
Cuenta de correo electrónico
Conocimientos básicos de inglés a nivel técnico

Temario

Introducción a los sistemas de control de versiones
1. Local
2. Centralizado
3. Distribuido

Temario (cont.)

Introducción a git
1. Inicializar un repositorio
2. Clonar un repositorio existente
3. Agregar archivos
4. Guardar cambios en el repositorio
5. Borrar archivos
6. Mover archivos
7. Enviar cambios al servidor
8. Revisar el estado de los archivos en el directorio de trabajo
9. Bitácora de revisiones del proyecto

Temario (cont.)

Configuración del cliente git
1. Datos del usuario
2. Reparar fin de línea en los archivos
3. Ignorar espacios en blanco

Temario (cont.)

Trabajando con repositorios existentes
1. Clonar un repositorio existente
2. Resolución de conflictos
3. Corregir el commit anterior

Temario (cont.)

Introducción a Github
1. Crear una cuenta en Github
2. Administración de repositorios via web
3. Cliente gráfico de git para Mac y Windows
4. Documentación en Markdown

Temario (cont.)

Trabajo colaborativo en Github
1. Fork
2. Pull requests
3. gist
4. Github Pages
5. Wikis

0. Configurar el nombre de usuario

Abrir el cuadro de diálogo de preferencias del sistema

Selecciona la opción Usuarios

Da clic en Facultad de Ciencias, introduce tu nombre y presiona <Enter>
Al terminar, cierra la ventana

Esto también puede cambiarse con el comando chfn(1)

root@debian-12:~# chfn --full-name "Andrés Hernández" mi-usuario

Se puede verificar con getent(1)

root@debian-12:~# getent passwd mi-usuario
mi-usuario:x:1000:1000:Andrés Hernández,,,:/home/mi-usuario:/bin/bash

1. Introducción a los sistemas de control de versiones

Sistema de control de versiones

Guarda las versiones del código fuente de un programa
Permite mostrar los cambios en el código
Trabaja principalmente con archivos de texto
Asocia el cambio con el autor
Tiene la capacidad de regresar a versiones anteriores

1.1. Control de versiones local

Guardar cambios en archivos separados

	prog.c prog1.c prog2.c ... prog<n>.c

Guardar cambios en carpetas separadas

  tarea/prog.c
  version_inicial/prog.c
  modificado2/prog.c
  vers-28sep/prog.c
  ProyectoFinal_2017-1_completo(Andres)/prog1.c

Desventajas del control de versiones local

Se tienen muchos archivos bastante similares
No se conoce cual es la última versión
Es necesario copiar el archivo de trabajo constantemente
Al modificar el archivo de trabajo se pierde la versión anterior
Cuando se borra el archivo de trabajo se pierde esa revisión

Enviar cambios por correo electrónico

Se genera un correo por cada versión enviada
Puede ser tedioso encontrar una versión anterior

Utilizar almacenamiento en la nube

Algunos servicios de almacenamiento en la nube permiten regresar a versiones anteriores
Muchos de los servicios gratuitos únicamente permiten un número finito de versiones anteriores
Algunas veces los servicios de almacenamiento quitan las versiones anteriores más antiguas

1.2. Centralizado - CVCS

Se basa en un modelo cliente-servidor
El servidor tiene una copia de todas las versiones del código
Los clientes clonan el repositorio y tienen una copia de trabajo que pueden modificar
Cuando los cambios están listos, los clientes los envían al servidor

Si el servidor falla, se pierden todas las versiones del proyecto

1.3. Distribuido - DVCS

Cada cliente tiene una copia de todas las versiones del proyecto
Si el servidor falla es posible copiar todas las versiones desde un cliente
Es posible establecer estructuras jerárquicas

2. Introducción a git

Breve historia de GIT

El desarrollo del kernel Linux entre los años 1991 - 2002 no utilizaba un control de versiones per-se
En 2002 se utilizó un DVCS propietario llamado BitKeeper, que se ofrecía sin costo a los miembros del proyecto
En 2005 la compañía quiso cobrar el uso del software

Breve historia de GIT (cont.)

La comunidad de desarrolladores, incluyendo a Linus Torvalds, optó por desarrollar su propia herramienta

⇒

2.0.1. Características de git

Velocidad
Diseño simple
Soporte para múltiples ramas
Enfoque distribuido
Capacidad de alojar grandes proyectos
Varios desarrolladores pueden trabajar en el mismo proyecto
Incluye verificación de integridad en los archivos

2.0.2. Áreas de trabajo

git presenta tres áreas de trabajo, asociadas con los estados que puede tener un archivo
Working Directory es el directorio de trabajo.
- En el se cr y borran los archivos del proyecto.
Staging Area es el área donde se preparan los cambios que serán versionados
El directorio .git guarda todas las versiones de los archivos del proyecto

2.0.2. Áreas de trabajo (cont.)

2.0.1.1. Estados de un archivo

Estado	Descripción	Comando
Modified	El archivo fue editado en el directorio de trabajo	`editor archivo`
Staged	El archivo (nuevo o modificado) fue agregado al área de staging	`git add archivo`

2.0.1.1. Estados de un archivo (cont.)

Estado	Descripción	Comando
Staged	El archivo se movió o renombró utilizando `git`	`git mv archivo1 archivo2`
Staged	El archivo se borró del área de staging utilizando `git`	`git rm archivo`

2.0.1.1. Estados de un archivo (cont.)

Estado	Descripción	Comando
Committed	Los cambios del archivo fueron guardados en el repositorio	`git commit archivo`

2.0.2. Instalar git en GNU/Linux

En Debian GNU/Linux utilizando apt-get o aptitude

root@debian:~# aptitude install git

En Red Hat, CentOS y Oracle Linux se utiliza yum

[root@centos ~]# yum install git

Para instalar en otras variantes de UNIX ver la documentación oficial

2.1. Inicializar un nuevo repositorio

Para crear un repositorio se utiliza el comando git init

$ man git-init

git-init - Create an empty Git repository or reinitialize an existing one

git init [-q | --quiet] [--bare] [--template=<template_directory>]
         [--separate-git-dir <git dir>] [--shared[=<permissions>]] [directory]

2.1. Inicializar un nuevo repositorio (cont.)

Es posible crear el directorio antes de inicializar

tonejito@linux:~$ mkdir repositorio
tonejito@linux:~$ cd repositorio
tonejito@linux:~/repositorio$ git init
Initialized empty Git repository in /home/tonejito/repositorio/.git/
tonejito@linux:~/repositorio$ ls -lA
total 0
drwxr-xr-x 7 tonejito users 147 Jun  3 17:16 .git

2.1. Inicializar un nuevo repositorio (cont.)

También se puede especificar el directorio de destino en el comando git init

tonejito@linux:~$ git init otro-repo
Initialized empty Git repository in /home/tonejito/otro-repo/.git/
tonejito@linux:~$ ls -lA otro-repo/
total 0
drwxr-xr-x 7 tonejito users 147 Jun  3 17:19 .git

2.1. Inicializar un nuevo repositorio (cont.)

Si el repositorio será compartido en un servidor, utilizar la opción --shared
No olvides ajustar los permisos del directorio

tonejito@linux:~$ git init --shared=group repo-compartido
Initialized empty shared Git repository in /home/tonejito/repo-compartido/.git/
tonejito@linux:~$ chmod -R g+rw repo-compartido/
tonejito@linux:~$ ls -la repo-compartido/
total 4
drwxrwsr-x  3 tonejito users   17 Jun  6 09:50 .
drwxr-xr-x 57 tonejito users 4096 Jun  6 09:50 ..
drwxrwsr-x  7 tonejito users  147 Jun  6 09:50 .git

2.1. Inicializar un nuevo repositorio (cont.)

Si tienes dudas, RTFM‼️

2.2. Clonar un repositorio existente

Se utiliza el comando git clone para guardar una copia de un repositorio existente
Es útil cuando se quiere trabajar de manera colaborativa en una aplicación (como el kernel Linux)
El código ṕuede ser modificado y se pueden seguir haciendo commits

2.2. Clonar un repositorio existente (cont.)

Para clonar el repositorio es necesario conocer la URL donde se aloja el proyecto
- /path/to/repo.git/
- file:///path/to/repo.git/
- http[s]://host.xz[:port]/path/to/repo.git/
- ftp[s]://host.xz[:port]/path/to/repo.git/
- ssh://[user@]host.xz[:port]/path/to/repo.git/
- ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/
- git://host.xz[:port]/path/to/repo.git/
- git://host.xz[:port]/~[user]/path/to/repo.git/
- [user@]host.xz:path/to/repo.git/
- [user@]host.xz:/~[user]/path/to/repo.git/

2.2.1. Ejemplo de `git-clone(1)`

Para clonar el repositorio de git de este curso se utiliza el comando git clone de la siguiente manera

tonejito@linux:~$ git clone https://github.com/tonejito/curso-git.git
Cloning into 'curso-git'...
remote: Counting objects: 108, done.
remote: Compressing objects: 100% (42/42), done.
remote: Total 108 (delta 24), reused 0 (delta 0), pack-reused 65
Receiving objects: 100% (108/108), 429.40 KiB | 0 bytes/s, done.
Resolving deltas: 100% (45/45), done.
Checking connectivity... done.

2.2.1. Ejemplo de `git-clone(1)` (cont.)

El repositorio se clona en el directorio curso-git
Contiene los archivos del proyecto y el directorio .git

tonejito@linux:~$ ls -A curso-git/
.git  .gitignore  LICENSE.md  presentation.md
img   index.html  Makefile    README.md

<coff> Ejemplo recursivo 😁 </coff>

2.3. Agregar archivos con `git-add(1)`

El comando git add se utiliza para especificar qué archivos incluirá git en el control de versiones
Los cambios del Directorio de trabajo se incluyen en el Área de Staging, es decir, se marcan para ser enviados en un commit
El Área de Staging también es conocida como index

2.3. Agregar archivos con `git-add(1)` (cont.)

La página de man de git add muestra las opciones de línea de comandos

git-add - Add file contents to the index

git add [-n]  [-v]  [--force | -f]  [--interactive | -i]  [--patch | -p]
        [--edit | -e]  [--[no-]all | --[no-]ignore-removal | [--update | -u]]
        [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing]
        [--]  [<pathspec>...]

Agregar contenido al repositorio

Crear un archivo de texto con el nombre README.md y escribir algún mensaje simple en el
Muchos repositorios utilizan Markdown para el archivo README de sus repositorios
Github tiene una versión especial de Markdown
Existen varios editores en línea como Dillinger y StackEdit

Archivo `README.md`

Editar el archivo README.md

tonejito@linux:~/repositorio$ editor README.md

Contenido de ejemplo

# Mi repositorio de git

Andrés Hernández

Revisar el estado del repositorio con `git-status(1)`

Ejecutar el comando git status para revisar si hay cambios

tonejito@linux:~/repositorio$ git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	README.md

nothing added to commit but untracked files present (use "git add" to track)

Agregar el archivo con `git-add(1)`

Agregar el archivo README.md al repositorio con el comando git add

tonejito@linux:~/repositorio$ git add README.md

Ejecutar una vez mas git status para revisar si hay cambios

On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

	new file:   README.md

Agregar el archivo con `git-add(1)` (cont.)

Desapareció el mensaje que sugería utilizar git add (comparar con la lámina anterior)
El cambio aún no está guardado, ver siguiente sección

2.4. Guardar cambios en el repositorio

Para enviar un cambio del Área de Staging al directorio .git se utiliza el comando git commit
Cada revisión generada guarda una entrada en la bitácora del repositorio

2.4. Guardar cambios en el repositorio (cont.)

La página de man de git commit muestra las opciones de línea de comandos

git-commit - Record changes to the repository

git commit [-a | --interactive | --patch]  [-s]  [-v]  [-u<mode>]  [--amend]
           [--dry-run]  [(-c | -C | --fixup | --squash) <commit>]
           [-F <file> | -m <msg>]  [--reset-author]  [--allow-empty]
           [--allow-empty-message]  [--no-verify]  [-e]  [--author=<author>]
           [--date=<date>]  [--cleanup=<mode>]  [--[no-]status]
           [-i | -o]  [-S[<key-id>]]  [--]  [<file>...]

2.4.1. git-commit interactivo

Para guardar el archivo recién creado en la sección anterior se ejecuta git commit

tonejito@linux:~/repositorio$ git commit README.md

Se abre un editor de texto donde debe escribirse el título y la descripción del commit
Todas las líneas que inicien con el símbolo # serán ignoradas
Si se guarda un mensaje vacío, se cancela el proceso de commit

2.4.1. git-commit interactivo (cont.)

El editor de texto se toma de las variables $GIT_EDITOR, core.editor, $VISUAL o $EDITOR

Commit inicial del proyecto

+ Se agrega el archivo README.md
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# Explicit paths specified without -i or -o; assuming --only paths...
# On branch master
#
# Initial commit
#
# Changes to be committed:
#       new file:   README.md
#

2.4.2. Estructura del mensaje de un commit

Se recomienda que la estructura del mensaje de un commit tenga los siguientes elementos
El único elemento requerido es el título

Línea	Elemento
1	Título del commit
2	Línea en blanco
3	Descripción del commit

2.4.2.1. Título del commit

Es el único elemento requerido en un commit

Línea	Elemento	Contenido
1	Título del commit	Descripción breve y concreta del cambio aplicado, menos de 50 caracteres

2.4.2.1. Línea en blanco

Línea	Elemento	Contenido
2	Línea en blanco	Se utiliza para separar el título del cuerpo

2.4.2.1. Descripción del commit

Línea	Elemento	Contenido
3	Descripción del commit	Mensaje que explica el cambio aplicado a profundidad
…	✓	Puede abarcar varias líneas de texto
…	✓	Es posible insertar elementos de sintáxis de Markdown
…	✓	Se pueden utilizar listas para enumerar elementos de manera vertical

2.4.3. `git-commit(1)` - one liner

Es posible ejecutar git commit y especificar el título del commit en el mismo comando
No se guarda la descripción del commit
Puede ser utilizado en scripts o procesos automatizados

2.4.3. `git-commit(1)` - one liner (cont.)

La bitácora del repositorio se puede visualizar con el comando git log

tonejito@linux:~/repositorio$ touch archivo-para-borrar
tonejito@linux:~/repositorio$ git add archivo-para-borrar
tonejito@linux:~/repositorio$ git commit -m "Archivo de prueba para probar git-rm"
tonejito@linux:~/repositorio$ git log -n 1
commit f552622d1a526ed0471ea260e3b99d1cef0c72f3
Author: Andrés Hernández <andres.hernandez@ciencias.unam.mx>
Date:   Wed Jun 8 13:52:04 2016 -0500

    Archivo vacío para probar git-rm

2.5. Borrar archivos

Para borrar archivos del repositorio se utiliza el comando git rm
No utilizar rm o borrar mediante el navegador de archivos
Para borrar archivos del directorio .git se utiliza el comando git rm
Esta operación guarda una entrada en la bitácora del repositorio
El archivo también se borra del Directorio de trabajo

2.5. Borrar archivos (cont.)

Se conservan las versiones anteriores en el repositorio
La página de man de git rm muestra las opciones de línea de comandos

git-rm - Remove files from the working tree and from the index

git rm [-f | --force] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>...

2.5.1. Ejemplo de `git-rm(1)`

git rm borra el archivo del Directorio de trabajo y marca el cambio en el Área de Staging

tonejito@linux:~/repositorio$ ls -l
total 4
-rw-r--r-- 1 tonejito users  0 Jun  8 13:45 archivo-para-borrar
-rw-r--r-- 1 tonejito users 44 Jun  6 18:01 README.md
tonejito@linux:~/repositorio$ git rm archivo-para-borrar
rm 'archivo-para-borrar'
tonejito@linux:~/repositorio$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	deleted:    archivo-para-borrar

2.5.1. Ejemplo de `git-rm(1)` (cont.)

Es necesario guardar el cambio en el directorio .git con git commit

tonejito@linux:~/repositorio$ git commit -m "Prueba de git-rm" archivo-para-borrar
[master 1f6d57a] Prueba de git-rm
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 archivo-para-borrar

2.6. Mover archivos

El comando git mv se utiliza para mover o renombrar archivos del repositorio
No utilizar mv o renombrar desde el navegador de archivos
La página de man de git mv muestra las opciones de línea de comandos

git-mv - Move or rename a file, a directory, or a symlink

git mv [-v] [-f] [-n] [-k] <source>     <destination>
git mv [-v] [-f] [-n] [-k] <source> ... <destination directory>

2.6.1. Ejemplo de `git-mv(1)`

Creación de archivos de prueba

tonejito@linux:~/repositorio$ touch archivo-para-mover archivo-para-renombrar
tonejito@linux:~/repositorio$ git add archivo-para-mover archivo-para-renombrar
tonejito@linux:~/repositorio$ git commit -m "Archivos vacíos para prueba de git-rm" archivo-para-*
[master 657aa04] Archivos vacíos para prueba de git-rm
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 archivo-para-mover
 create mode 100644 archivo-para-renombrar

2.6.1. Ejemplo de `git-mv(1)` (cont.)

Prueba de git mv moviendo un archivo a otro directorio y renombrando otro archivo

tonejito@linux:~/repositorio$ mkdir -v directorio
mkdir: created directory ‘directorio’
tonejito@linux:~/repositorio$ git mv archivo-para-mover directorio/
tonejito@linux:~/repositorio$ git mv archivo-para-renombrar archivo-con-otro-nombre
tonejito@linux:~/repositorio$ git commit -m "Prueba de git-mv"
[master 4f30937] Prueba de git-mv
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename archivo-para-renombrar => archivo-con-otro-nombre (100%)
 rename archivo-para-mover => directorio/archivo-para-mover (100%)

2.7. Enviar cambios al servidor

En los repositorios que se han clonado, es común tener una URL para descargar (fetch) y otra para enviar (push)
El repositorio remoto se llama origin y la rama por defecto se llama master
Cuando la URL remota ya esta configurada, es posible enviar los cambios a un repositorio remoto

2.7.1. Listar la URL del repositorio remoto

Para enviar cambios al servidor es necesario tener configurada una URL remota para envío o push
Es posible listar las URL de los repositorios remotos con git remote

2.7.1. Listar la URL del repositorio remoto (cont.)

En un nuevo repositorio es necesario establecer la URL remota

tonejito@linux:~/repositorio$ git remote add origin https://github.com/tonejito/repositorio.git
tonejito@linux:~/repositorio$ git remote -v
origin	https://github.com/tonejito/repositorio.git (fetch)
origin	https://github.com/tonejito/repositorio.git (push)

2.7.2. Enviar cambios con `git-push(1)`

Para enviar los cambios al servidor la primera vez se ejecuta git push de la siguiente manera

tonejito@linux:~/repositorio$ git push -u origin master
Username for 'https://github.com': tonejito
Password for 'https://tonejito@github.com':
Counting objects: 12, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (12/12), 1.35 KiB | 0 bytes/s, done.
Total 12 (delta 1), reused 0 (delta 0)
To https://github.com/tonejito/repositorio.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

2.7.2. Enviar cambios con `git-push(1)` (cont.)

Las demás veces sólo es necesario utilizar git push

tonejito@linux:~/repositorio$ git push
Username for 'https://github.com': tonejito
Password for 'https://tonejito@github.com':
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 462 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/tonejito/repositorio.git
   4f30937..be47c1b  master -> master

2.7.2. Enviar cambios con `git-push(1)` (cont.)

Dependiendo de la versión y configuración de git, puede aparecer una advertencia sobre push.default

2.8. Revisar el estado de los archivos en el directorio de trabajo

git reconoce cuando se realizan cambios en los archivos del Directorio de trabajo
Para guardar los cambios en el repositorio del directorio .git es necesario ejecutar git commit

Estado del archivo	Comando	Descripción
Untracked	`touch <file>`	Se creó un nuevo archivo en el Directorio de trabajo Aún no se agrega al control de versiones

Estado del archivo	Comando	Descripción
new file	`git add <file>`	Se agregó un nuevo archivo para ser versionado

Estado del archivo	Comando	Descripción
deleted	`git rm <file>`	El archivo se borró del repositorio

Estado del archivo	Comando	Descripción
renamed	`git mv <src> <dst>`	El archivo cambió de nombre o fue movido

Estado del archivo	Comando	Descripción
modified	`gedit <file>`	El contenido del archivo fue modificado

Estado del archivo	Comando	Descripción
both modified	😅 🔫 😡	Es necesario hacer `merge` 😱

2.8.1. Untracked files - Archivos nuevos sin versionar

Cuando se crea un archivo nuevo, se marca como Untracked
Para agregar el archivo al repositorio se utiliza git add (ver siguiente sección)

tonejito@linux:~/repositorio$ touch archivo-externo
tonejito@linux:~/repositorio$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
  (use "git add <file>..." to include in what will be committed)

	archivo-externo

nothing added to commit but untracked files present (use "git add" to track)

2.8.2. `git add` ⇨ new file

Para agregar un archivo nuevo al repositorio se utiliza git add
No olvidar ejecutar git commit para guardar el cambio

tonejito@linux:~/repositorio$ git add archivo-nuevo
tonejito@linux:~/repositorio$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   archivo-nuevo

2.8.3. `git rm` ⇨ deleted

Para borrar un archivo del repositorio se utiliza git rm
No olvidar ejecutar git commit para guardar el cambio

tonejito@linux:~/repositorio$ git rm archivo-para-borrar
rm 'archivo-para-borrar'
tonejito@linux:~/repositorio$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	deleted:    archivo-para-borrar

2.8.4. `git mv` ⇨ renamed

Para mover un archivo del repositorio a otra carpeta se utiliza git rm
También se utiliza para cambiar de nombre a los archivos

2.8.4. `git mv` ⇨ renamed (cont.)

No olvidar ejecutar git commit para guardar el cambio

tonejito@linux:~/repositorio$ git mv archivo-para-mover directorio/
tonejito@linux:~/repositorio$ git mv archivo-para-renombrar archivo-con-otro-nombre
tonejito@linux:~/repositorio$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	renamed:    archivo-para-renombrar -> archivo-con-otro-nombre
	renamed:    archivo-para-mover -> directorio/archivo-para-mover

2.8.5. modified - Archivos editados

Al editar un archivo, git lo marca como modified
No olvidar ejecutar git commit para guardar el cambio

2.8.5. modified - Archivos editados (cont.)

Si se desea regresar a la última versión conocida, ejecutar git checkout <archivo>

tonejito@linux:~/repositorio$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   pagina.html

no changes added to commit (use "git add" and/or "git commit -a")

2.9. Bitácora de revisiones del proyecto

El comando git log se utiliza para visualizar la bitácora de revisiones del proyecto
En la bitácora se muestra cada commit realizado en la rama actual

tonejito@linux:~/repositorio$ git log
commit be47c1b99c212c0b25d7351c1d9bd8de33c06dd8
Author: Andrés Hernández <andres.hernandez@ciencias.unam.mx>
Date:   Thu Jun 9 10:53:34 2016 -0500

    Página de prueba para `curso-git`

    + Código base `html5` sin estilos

...	...	...	...	...	...	más entradas del log	...

2.9. Bitácora de revisiones del proyecto (cont.)

...	...	...	...	...	...	más entradas del log	...

commit 1b75a81323d5a6befff5d4ddfd3ad3254914c8da
Author: Andrés Hernández <andres.hernandez@ciencias.unam.mx>
Date:   Wed Jun 8 13:46:21 2016 -0500

    Commit inicial del proyecto

    + Se agrega el archivo README.md

3. Configuración del cliente git

Hasta ahora los mensajes del commit han sido atribuidos a un autor anónimo
¿Qué pasa si trabajo con más de una cuenta de correo asociada a git?
¿Cómo puedo cambiar el campo Author en la bitácora del repositorio?

commit f020486f071bf11053547a86f4a7153b3c950f4b
Author: Facultad de Ciencias <ciencias@debian8.local>
Date:   Tue 19 Jan 03:14:08 2038 +0000

    Título del commit

    Mensaje del commit

3.0.1. Secciones de configuración de git

Existen tres ubicaciones donde se puede configurar el cliente git
El cliente de git toma en cuenta los valores más específicos

Ubicación	Directorio	Descripción
System-wide Sistema	`/etc/gitconfig`	Archivo de configuración global para todos los repositorios presentes en el sistema

Ubicación	Directorio	Descripción
Global Usuario	`~/.gitconfig`	Archivo de configuración que aplica para todos los repositorios del usuario

Ubicación	Directorio	Descripción
Local Repositorio	`$GIT_DIR/config`	Aplica únicamente para el repositorio actual

3.1. Datos del usuario

3.1.1. Configuración global para el usuario

Es útil establecer la configuración global para todos los repositorios de git del usuario actual

tonejito@linux:~$ git config --global user.name  'Andrés Hernández'
tonejito@linux:~$ git config --global user.email 'andres.hernandez@unam.mx'
tonejito@linux:~$ cat ~/.gitconfig
[user]
	name  = Andrés Hernández
	email = andres.hernandez@unam.mx

3.1.2. Configuración local para el repositorio

Para un repositorio donde se necesite realizar commits con otra cuenta de correo utilizar la configuración local

tonejito@linux:~/repositorio$ git config --local user.name  'Andrés Hernández'
tonejito@linux:~/repositorio$ git config --local user.email 'andres.hernandez@ciencias.unam.mx'
tonejito@linux:~/repositorio$ cat .git/config
[user]
	name  = Andrés Hernández
	email = andres.hernandez@ciencias.unam.mx

3.2. Reparar fin de línea en los archivos

El retorno de línea cambia dependiendo del sistema operativo 😕

Sistema operativo	Retorno de línea	Descripción
UNIX / BSD / Solaris / MacOSX / Linux	`LF`	El salto de línea se representa con el caracter `\n`

Sistema operativo	Retorno de línea	Descripción
MacOS <= 9.2.2 Classic	`CR`	El salto de línea se representa con el caracter `\r`

Sistema operativo	Retorno de línea	Descripción
Windows	`CR-LF`	El salto de línea se representa con el caracter `\r` seguido de `\n`

Por fortuna git config puede corregir esto de manera adecuada 😁
Escribir lo siguiente para escribir la configuración de manera global para el usuario

tonejito@linux:~$ git config --global core.autocrlf input
tonejito@linux:~$ cat .gitconfig
[core]
   ...
	autocrlf = input

3.3. Ignorar espacios en blanco

Un problema común con algunos editores es que agregan espacios en blanco sin que el usuario se de cuenta

Elemento	Activo por defecto	Descripción
`blank-at-eol`	SI	Quita espacios en blanco al final de la línea

Elemento	Activo por defecto	Descripción
`blank-at-eof`	SI	Quita lineas vacías al final del archivo

Elemento	Activo por defecto	Descripción
`space-before-tab`	SI	Quita espacios antes de un caracter `<TAB>` en el principio de la línea

Elemento	Activo por defecto	Descripción
`indent-with-non-tab`	NO	Busca lineas que estan identadas con espacios, se controla con la directiva `tabwidth`

Elemento	Activo por defecto	Descripción
`tab-in-indent`	NO	Busca `<TAB>` en la identación de las lineas

Elemento	Activo por defecto	Descripción
`cr-at-eol`	NO	Identifica el caracter `<CR>` como válido al final de la linea

Ejemplo de `core.whitespace`

Para establecer estos valores se utiliza git config para modificar la directiva core.whitespace
Los elementos especificados se activan al incluirlos en el valor de la directiva
Los elementos que no se especifican o que comienzan con un símbolo - son excluidos

Para establecer el valor de core.whitespace utilizaremos las siguientes características:

Se desean los elementos blank-at-eol, blank-at-eof y space-before-tab
Desactivamos explícitamente indent-with-non-tab y tab-in-indent
Desactivamos implícitamente cr-at-eol ya que no se especifica en el valor

tonejito@linux:~$ git config core.whitespace blank-at-eol,blank-at-eof,space-before-tab,-indent-with-non-tab,-tab-in-indent
tonejito@linux:~$ cat .gitconfig
[core]
   ...
	whitespace = blank-at-eol,blank-at-eof,space-before-tab,-indent-with-non-tab,-tab-in-indent

4. Trabajando con repositorios existentes

4.1. Clonar un repositorio existente

4.2. Resolución de conflictos

4.3. Corregir el commit anterior

5. Introducción a Github

5.1. Crear una cuenta en Github

5.2. Administración de repositorios via web

5.3. Cliente gráfico de git para Mac y Windows

5.4. Documentación en Markdown

6. Trabajo colaborativo en Github

6.1. Fork

6.2. Pull requests

6.3. gist

6.4. Github Pages

6.5. Wikis

Referencias

https://git-scm.com/docs
https://git-scm.com/book/en/v2
https://try.github.io/
https://help.github.com/
https://help.github.com/articles/associating-text-editors-with-git/
https://help.github.com/articles/github-flow-in-the-browser/
https://github.com/github/training-kit
https://guides.github.com/introduction/flow/
https://services.github.com/kit/
https://services.github.com/resources/
https://github.com/papadako/git-a-little-tale/
https://wiki.openstack.org/wiki/GitCommitMessages
https://git-scm.com/book/ch5-2.html#Commit-Guidelines
http://chris.beams.io/posts/git-commit/
http://marklodato.github.io/visual-git-guide/index-en.html
http://think-like-a-git.net/
https://rogerdudler.github.io/git-guide/

Control de versiones con GIT

Control de versiones con git

Información del curso

Nivel de especialización

Objetivo

Perfil del asistente

Conocimientos previos

Temario

Temario (cont.)

Temario (cont.)

Temario (cont.)

Temario (cont.)

Temario (cont.)

0. Configurar el nombre de usuario

1. Introducción a los sistemas de control de versiones

Sistema de control de versiones

1.1. Control de versiones local

Desventajas del control de versiones local

Enviar cambios por correo electrónico

Utilizar almacenamiento en la nube

1.2. Centralizado - CVCS

1.3. Distribuido - DVCS

2. Introducción a git

Breve historia de GIT

Breve historia de GIT (cont.)

2.0.1. Características de git

2.0.2. Áreas de trabajo

2.0.2. Áreas de trabajo (cont.)

2.0.1.1. Estados de un archivo

2.0.1.1. Estados de un archivo (cont.)

2.0.1.1. Estados de un archivo (cont.)

2.0.2. Instalar git en GNU/Linux

2.1. Inicializar un nuevo repositorio

2.1. Inicializar un nuevo repositorio (cont.)

2.1. Inicializar un nuevo repositorio (cont.)

2.1. Inicializar un nuevo repositorio (cont.)

2.1. Inicializar un nuevo repositorio (cont.)

2.2. Clonar un repositorio existente

2.2. Clonar un repositorio existente (cont.)

2.2.1. Ejemplo de git-clone(1)

2.2.1. Ejemplo de git-clone(1) (cont.)

2.3. Agregar archivos con git-add(1)

2.3. Agregar archivos con git-add(1) (cont.)

Agregar contenido al repositorio

Archivo README.md

Revisar el estado del repositorio con git-status(1)

Agregar el archivo con git-add(1)

Agregar el archivo con git-add(1) (cont.)

2.4. Guardar cambios en el repositorio

2.4. Guardar cambios en el repositorio (cont.)

2.4.1. git-commit interactivo

2.4.1. git-commit interactivo (cont.)

2.4.2. Estructura del mensaje de un commit

2.4.2.1. Título del commit

2.4.2.1. Línea en blanco

2.4.2.1. Descripción del commit

2.4.3. git-commit(1) - one liner

2.4.3. git-commit(1) - one liner (cont.)

2.5. Borrar archivos

2.5. Borrar archivos (cont.)

2.5.1. Ejemplo de git-rm(1)

2.5.1. Ejemplo de git-rm(1) (cont.)

2.6. Mover archivos

2.6.1. Ejemplo de git-mv(1)

2.6.1. Ejemplo de git-mv(1) (cont.)

2.7. Enviar cambios al servidor

2.7.1. Listar la URL del repositorio remoto

2.7.1. Listar la URL del repositorio remoto (cont.)

2.7.2. Enviar cambios con git-push(1)

2.7.2. Enviar cambios con git-push(1) (cont.)

2.7.2. Enviar cambios con git-push(1) (cont.)

2.8. Revisar el estado de los archivos en el directorio de trabajo

2.8.1. Untracked files - Archivos nuevos sin versionar

2.8.2. git add ⇨ new file

2.8.3. git rm ⇨ deleted

2.8.4. git mv ⇨ renamed

2.8.4. git mv ⇨ renamed (cont.)

2.8.5. modified - Archivos editados

2.8.5. modified - Archivos editados (cont.)

2.9. Bitácora de revisiones del proyecto

2.2.1. Ejemplo de `git-clone(1)`

2.2.1. Ejemplo de `git-clone(1)` (cont.)

2.3. Agregar archivos con `git-add(1)`

2.3. Agregar archivos con `git-add(1)` (cont.)

Archivo `README.md`

Revisar el estado del repositorio con `git-status(1)`

Agregar el archivo con `git-add(1)`

Agregar el archivo con `git-add(1)` (cont.)

2.4.3. `git-commit(1)` - one liner

2.4.3. `git-commit(1)` - one liner (cont.)

2.5.1. Ejemplo de `git-rm(1)`

2.5.1. Ejemplo de `git-rm(1)` (cont.)

2.6.1. Ejemplo de `git-mv(1)`

2.6.1. Ejemplo de `git-mv(1)` (cont.)

2.7.2. Enviar cambios con `git-push(1)`

2.7.2. Enviar cambios con `git-push(1)` (cont.)

2.7.2. Enviar cambios con `git-push(1)` (cont.)

2.8.2. `git add` ⇨ new file

2.8.3. `git rm` ⇨ deleted

2.8.4. `git mv` ⇨ renamed

2.8.4. `git mv` ⇨ renamed (cont.)

Ejemplo de `core.whitespace`