¿A qué nos referimos con “control de versiones”?

Sistemas de control de versiones: git Se llama control de versiones a la gestión de los cambios que se realizan
sobre documentos, programas o cualquier colección de información.

Rodrigo Lugones
Ejemplos en la vida real:
• Cuaderno de laboratorio.
rlugones@[Link] • Ediciones y revisiones de un libro.

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 1 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 2 / 53

¿Por qué realizar un control de versiones? Curiosidad: ¿cuántas lı́neas de código manejamos?
• Script propio para calcular algunas cosas: ∼ 100
• Código grande propio: ∼ 1 mil
• Aplicación de celular: ∼ 30 mil
• Transbordador espacial: ∼ 400 mil
• Linux Kernel 2.2.0 (1999): ∼ 1,5 millones
• Telescopio Hubble: ∼ 2 millones
El control de versiones le da trazabilidad a nuestro trabajo.
• Google Chrome: ∼ 6,5 millones
¿Y? ¿Para qué queremos eso?
• Mozilla Firefox: ∼ 9,5 millones
• Android: ∼ 12 millones
• Linux Kernel 3.1 (2011): ∼ 15 millones
• Windows 7: ∼ 40 millones
• Large Hadron Collider: ∼ 50 millones
• Facebook: ∼ 60 millones
• Software de un auto: ∼ 100 millones
• Google: ∼ 2000 millones
Fuente
Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 3 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 4 / 53
Curiosidad: ¿cuántas lı́neas de código manejamos? Curiosidad: ¿cuántas lı́neas de código manejamos?
• Script propio para calcular algunas cosas: ∼ 100 • Script propio para calcular algunas cosas: ∼ 100
• Código grande propio: ∼ 1 mil • Código grande propio: ∼ 1 mil
• Aplicación de celular: ∼ 30 mil • Aplicación de celular: ∼ 30 mil
• Transbordador espacial: ∼ 400 mil • Transbordador espacial: ∼ 400 mil
• Linux Kernel 2.2.0 (1999): ∼ 1,5 millones • Linux Kernel 2.2.0 (1999): ∼ 1,5 millones
• Telescopio Hubble: ∼ 2 millones • Telescopio Hubble: ∼ 2 millones
• Google Chrome: ∼ 6,5 millones • Google Chrome: ∼ 6,5 millones
• Mozilla Firefox: ∼ 9,5 millones • Mozilla Firefox: ∼ 9,5 millones
• Android: ∼ 12 millones • Android: ∼ 12 millones
• Linux Kernel 3.1 (2011): ∼ 15 millones • Linux Kernel 3.1 (2011): ∼ 15 millones
• Windows 7: ∼ 40 millones • Windows 7: ∼ 40 millones
• Large Hadron Collider: ∼ 50 millones • Large Hadron Collider: ∼ 50 millones
• Facebook: ∼ 60 millones • Facebook: ∼ 60 millones
• Software de un auto: ∼ 100 millones • Software de un auto: ∼ 100 millones
• Google: ∼ 2000 millones • Google: ∼ 2000 millones
Fuente Fuente
Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 4 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 4 / 53

Un ejemplo concreto Un ejemplo concreto

- Queremos simular un canal de agua con una columna en el centro.

- Desarrollamos un programa NS_Solver que resuelve la ecuación de Opción 0: Modificar la carpeta en la que estamos trabajando.
Navier-Stokes con el método numérico de Euler en el paso temporal. El Pero si nos equivocamos y rompemos el código, ¿no querrı́amos poder
output del programa es, por ejemplo, la energı́a a cada tiempo. volver fácilmente a la versión original?
- Ahora queremos graficar la energı́a en función del tiempo. ¿Cómo
hacemos?

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 5 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 6 / 53
Un ejemplo concreto Un ejemplo concreto
Opción 1: Lo más común

Opción 0: Modificar la carpeta en la que estamos trabajando.

Pero si nos equivocamos y rompemos el código, ¿no querrı́amos poder
volver fácilmente a la versión original?
¿Qué contiene cada
versión?

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 6 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 7 / 53

Un ejemplo concreto Un ejemplo concreto

Opción 1: Lo más común
Opción 2: Nombres descriptivos

1 NS_Solver_Euler
2 NS_Solver_Euler_y_grafico_E

Opción 2bis: Archivo [Link] que registre los cambios realizados.

¿Qué contiene cada
versión? 1 NS_Solver_1
2 NS_Solver_2
3 [Link]

1 $ cat [Link]
2 1: Navier-Stokes con metodo de Euler
3 2: Navier-Stokes con metodo de Euler y grafico de Energia.

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 7 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 8 / 53
Un ejemplo concreto Un ejemplo concreto

Este podrı́a considerarse un casero y primitivo sistema de control de Este podrı́a considerarse un casero y primitivo sistema de control de
versiones. versiones.
Ahora, ¿qué pasarı́a si en la versión 19 del programa encontráramos un Ahora, ¿qué pasarı́a si en la versión 19 del programa encontráramos un
bug que existı́a desde la versión 1? bug que existı́a desde la versión 1?
Si bien podrı́amos pensar soluciones, vemos que los problemas se Si bien podrı́amos pensar soluciones, vemos que los problemas se
multiplican a medida que el proyecto crece. La solución es utilizar alguna multiplican a medida que el proyecto crece. La solución es utilizar alguna
herramienta especializada en controlar versiones. herramienta especializada en controlar versiones.
Hay una infinidad de posibilidades (Mercurial, Subversion, etc). Nos vamos Hay una infinidad de posibilidades (Mercurial, Subversion, etc). Nos vamos
a concentrar en una, la más extendida: git a concentrar en una, la más extendida: git

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 9 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 9 / 53

Un ejemplo concreto Git: Una filosofı́a de trabajo

Este podrı́a considerarse un casero y primitivo sistema de control de La ventaja de utilizar las herramientas adecuadas para el objetivo que uno
versiones. quiere lograr es que, de alguna forma, favorecen (o hasta imponen) una
Ahora, ¿qué pasarı́a si en la versión 19 del programa encontráramos un filosofı́a de trabajo.
bug que existı́a desde la versión 1? Con git vamos a poder:
1 Hacer backup de estados consistentes del proyecto
Si bien podrı́amos pensar soluciones, vemos que los problemas se
multiplican a medida que el proyecto crece. La solución es utilizar alguna
2 Documentar cambios
herramienta especializada en controlar versiones. 3 Seguir los bugs a través de la historia del desarrollo
Hay una infinidad de posibilidades (Mercurial, Subversion, etc). Nos vamos
4 Compartir cambios
a concentrar en una, la más extendida: git 5 Distribuir el desarrollo a muchas personas

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 9 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 10 / 53
Git: Una filosofı́a de trabajo Git: Una filosofı́a de trabajo
¿Y cómo funciona git? ¿Y cómo funciona git?

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 11 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 11 / 53

Git: Una filosofı́a de trabajo Git: Una filosofı́a de trabajo

• Un archivo está en estado no-modificado cuando es exactamente

Entonces, para que no suceda esto, primero definamos algunos conceptos
claves. igual al archivo que está guardado en el último snapshot.
• Modificar un archivo (por ejemplo, cambiar el nombre de una
• Estados de un repositorio: Son análogos a las carpetas en el
variable) lo transforma, evidentemente, en un archivo modificado.
ejemplo del SCV casero. Cuando terminamos de trabajar en un estado
• Pero, y esto es muy importante, git no hace seguimiento a un archivo
y lo consolidamos (en nuestra analogı́a, serı́a decir que terminamos de
desarrollar la funcionalidad que querı́amos en la carpeta y, entonces, sólo porque está en estado modificado. Para que git se haga cargo
no modificamos más esa carpeta) lo llamamos snapshot. El snapshot del archivo modificado lo tenemos que actualizar (o, el término en
actual se llama HEAD. inglés, stage). Con todos los archivos actualizados, podemos
• Ciclo de vida de los archivos: En un repositorio de git, cada archivo consolidar el cambio y, en consecuencia, tomar un nuevo snapshot.
puede tener tres estados: • Al hacer esto, los archivos que estaban actualizados ahora forman
• No-modificado parte del nuevo snapshot, que pasa a ser el nuevo HEAD del repositorio.
• Modificado Es decir que consolidar cambios actualiza automáticamente el HEAD
• Actualizado del repositorio, y de esta manera los archivos que se encontraban en
el estado actualizado pasan al estado no-modificado.

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 12 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 13 / 53
Git: Una filosofı́a de trabajo Git: Una filosofı́a de trabajo

• Un archivo está en estado no-modificado cuando es exactamente • Un archivo está en estado no-modificado cuando es exactamente
igual al archivo que está guardado en el último snapshot. igual al archivo que está guardado en el último snapshot.
• Modificar un archivo (por ejemplo, cambiar el nombre de una • Modificar un archivo (por ejemplo, cambiar el nombre de una
variable) lo transforma, evidentemente, en un archivo modificado. variable) lo transforma, evidentemente, en un archivo modificado.
• Pero, y esto es muy importante, git no hace seguimiento a un archivo • Pero, y esto es muy importante, git no hace seguimiento a un archivo
sólo porque está en estado modificado. Para que git se haga cargo sólo porque está en estado modificado. Para que git se haga cargo
del archivo modificado lo tenemos que actualizar (o, el término en del archivo modificado lo tenemos que actualizar (o, el término en
inglés, stage). Con todos los archivos actualizados, podemos inglés, stage). Con todos los archivos actualizados, podemos
consolidar el cambio y, en consecuencia, tomar un nuevo snapshot. consolidar el cambio y, en consecuencia, tomar un nuevo snapshot.
• Al hacer esto, los archivos que estaban actualizados ahora forman • Al hacer esto, los archivos que estaban actualizados ahora forman
parte del nuevo snapshot, que pasa a ser el nuevo HEAD del repositorio. parte del nuevo snapshot, que pasa a ser el nuevo HEAD del repositorio.
Es decir que consolidar cambios actualiza automáticamente el HEAD Es decir que consolidar cambios actualiza automáticamente el HEAD
del repositorio, y de esta manera los archivos que se encontraban en del repositorio, y de esta manera los archivos que se encontraban en
el estado actualizado pasan al estado no-modificado. el estado actualizado pasan al estado no-modificado.

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 13 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 13 / 53

Git: Una filosofı́a de trabajo Repositorios de git

• Finalmente, si creamos un archivo nuevo y le queremos hacer
seguimiento, tenemos que agregarlo al repositorio. De la misma
manera, podemos remover un archivo del repositorio para dejar de
seguirlo.

Retomemos nuestro proyecto original, NS_Solver, pero desde el comienzo

vamos a trabajar dentro de git.

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 14 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 15 / 53
 Repositorios de git: crear repositorio Repositorios de git: estado de un repositorio

Crear un repositorio
El primer paso es la ardua tarea de crear el repositorio. Para eso creamos Estado de un repositorio
una carpeta en la que queremos iniciar nuestro trabajo (y cambiamos el Para saber en qué estado se encuentra un repositorio:
directorio a esa carpeta) y ejecutamos:
1 $ git init . 1 $ git status
2 On branch master
Esta carpeta va a ser considerada un repositorio de git. 3 No commits yet
¿Y dónde está guardada toda la información del repositorio? 4 nothing to commit (create/copy files and use "git add" to track)

1 $ ls -a En este caso, tanto el repositorio como el directorio están vacı́os.

2 .git

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 16 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 17 / 53

Repositorios de git: agregar archivos Repositorios de git: agregar archivos

Agregar archivos al repositorio

Ahora creamos el archivo [Link], que resuelve el problema con el
método de Euler. Es decir, [Link] no está siendo seguido. Si agregamos el archivo
al repositorio (git add), pasa a estar actualizado:
1 $ ls
2 [Link]
3
1 $ git add [Link]
2
4 $ git status
5 On branch master 3 $ git status
6 No commits yet 4 On branch master
7 Untracked files: 5 No commits yet
8 (use "git add <file>..." to include in what will be committed) 6 Changes to be committed:
9 [Link] 7 (use "git rm --cached <file>..." to unstage)
10 nothing added to commit but untracked files present (use "git add" to 8 new file: [Link]
track)

En el directorio aparece ese archivo, pero git no lo reconoce, pues nunca le

dijimos que lo siguiera.

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 18 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 19 / 53
 Repositorios de git: agregar archivos Repositorios de git: agregar archivos

Ahora consolidamos los archivos actualizados mediante git commit.

Si ahora miramos el estado del repositorio,

1 $ git commit -m "Agregado metodo de Euler"
2 [master (root-commit) 13aa40c] Agregado metodo de Euler 1 $ git status
3 1 file changed, 0 insertions(+), 0 deletions(-) 2 On branch master
4 create mode 100644 [Link] 3 nothing to commit, working tree clean

Noten dos cosas: El mensaje working directory clean nos dice que no hay archivos en estado
• El flag -m, seguido del mensaje de commit. El mensaje de commit es modificado, ya que el archivo [Link] (que no volvimos a tocar) es
obligatorio. igual al que está guardado en HEAD.
• El commit hash (número hexadecimal, 13aa40c), con el que podemos
referirnos a este snapshot.

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 20 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 21 / 53

Repositorios de git: continuar trabajando Repositorios de git: continuar trabajando

Por ejemplo, creamos el archivo graficar_E.py para graficar la energı́a y

modificamos el archivo [Link].
Si queremos ver qué diferencias entre la versión modificada de
A partir de acá, la tarea para generar un snapshot es siempre la misma: [Link] y la que se consolidó en último snapshot (o sea, la versión
1 Modificamos/creamos uno o varios archivos: pasan al working en HEAD), simplemente escribimos
directory
1 $ git diff [Link]
2 Los agregamos al staging area con git add 2 diff --git a/[Link] b/[Link]
3 Los consolidamos en un snapshot con git commit 3 index 219e905..eb3f118 100644
4 --- a/[Link]
5 +++ b/[Link]
6 @@ -1 +1 @@
7 -codigo viejo
8 +codigo nuevo

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 22 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 23 / 53
 Repositorios de git: continuar trabajando Repositorios de git: historia de los snapshots

Si queremos ver todos los commits que hemos hecho en el repositorio,

usamos git log.
Y si ahora queremos consolidar los nuevos cambios en un nuevo estado del
1 $ git log
repositorio (snapshot), hacemos: 2 commit 9b72f8bf4e05dd88ab8d365e712a3d6dfe372ca7 (HEAD -> master)
3 Author: Rodrigo Lugones <rodrigolugones@[Link]>
1 $ git add graficar_E.py [Link] 4 Date: Sun Feb 25 12:28:43 2018 -0300
2 $ git commit -m "Graficar energia" 5
3 [master 9b72f8b] Graficar energia 6 Graficar energia
4 1 file changed, 0 insertions(+), 0 deletions(-) 7
5 create mode 100644 graficar_E.py 8 commit 13aa40cbad74d2ecd8bb58452471cd79afb20e83
9 Author: Rodrigo Lugones <rodrigolugones@[Link]>
10 Date: Sun Feb 25 12:26:19 2018 -0300
11
12 Agregado metodo de Euler

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 24 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 25 / 53

Repositorios de git: visitar snapshots Repositorios de git: visitar snapshots

¿Y si queremos ir a un snapshots viejo? Simplemente ejecutamos Veamos qué hay en la carpeta.

git checkout <commit hash>
1 $ ls
1 $ git checkout 13aa 2 [Link]
2 Note: checking out ’13aa’.
3 ¿¡CÓMO!? ¿¡Y DÓNDE ESTÁ graficar_E.py!? ¡Perdı́ dos semanas
4 You are in ’detached HEAD’ state. You can look around, make escribiendo el script para graficar!
5 experimental changes and commit them, and you can discard any commits Recordemos que el archivo graficar_E.py no existı́a en este snapshot. El
6 you make in this state without impacting any branches by performing
HEAD dejó de ser 9b72f8b y pasó a ser 13aa40c.
7 another checkout.
8
Si ahora queremos volver al snapshot donde está implementado el gráfico
9 If you want to create a new branch to retain commits you create, you de la energı́a, ejecutamos
10 may do so (now or later) by using -b with the checkout command
11 again. Example: 1 $ git checkout 9b72
12 2 Previous HEAD position was 13aa40c Agregado metodo de Euler
13 git checkout -b <new-branch-name> 3 HEAD is now at 9b72f8b Graficar energia
14 4 $ ls
15 HEAD is now at 13aa40c Agregado metodo de Euler 5 [Link] graficar_E.py

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 26 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 27 / 53
 Repositorios de git: visitar snapshots Repositorios de git: visitar snapshots
Veamos qué hay en la carpeta. Veamos qué hay en la carpeta.

1 $ ls 1 $ ls
2 [Link] 2 [Link]

¿¡CÓMO!? ¿¡Y DÓNDE ESTÁ graficar_E.py!? ¡Perdı́ dos semanas ¿¡CÓMO!? ¿¡Y DÓNDE ESTÁ graficar_E.py!? ¡Perdı́ dos semanas
escribiendo el script para graficar! escribiendo el script para graficar!
Recordemos que el archivo graficar_E.py no existı́a en este snapshot. El Recordemos que el archivo graficar_E.py no existı́a en este snapshot. El
HEAD dejó de ser 9b72f8b y pasó a ser 13aa40c. HEAD dejó de ser 9b72f8b y pasó a ser 13aa40c.
Si ahora queremos volver al snapshot donde está implementado el gráfico Si ahora queremos volver al snapshot donde está implementado el gráfico
de la energı́a, ejecutamos de la energı́a, ejecutamos

1 $ git checkout 9b72 1 $ git checkout 9b72

2 Previous HEAD position was 13aa40c Agregado metodo de Euler 2 Previous HEAD position was 13aa40c Agregado metodo de Euler
3 HEAD is now at 9b72f8b Graficar energia 3 HEAD is now at 9b72f8b Graficar energia
4 $ ls 4 $ ls
5 [Link] graficar_E.py 5 [Link] graficar_E.py

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 27 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 27 / 53

Repositorios de git: comentarios antes de continuar Repositorios de git: comentarios antes de continuar

• Los commits son análogos a nuestro SCV casero: Desarrollar una • Los commits son análogos a nuestro SCV casero: Desarrollar una
nueva funcionalidad (consolidar una nueva carpeta en el SCV casero) nueva funcionalidad (consolidar una nueva carpeta en el SCV casero)
lleva mucho tiempo. Entonces, tiene sentido hacer commits lleva mucho tiempo. Entonces, tiene sentido hacer commits
intermedios (no los hacı́amos con el SCV casero porque es mucho intermedios (no los hacı́amos con el SCV casero porque es mucho
laburo). laburo).
• Identifiquen commits “interesantes”: Vamos a tener ciertos • Identifiquen commits “interesantes”: Vamos a tener ciertos
commits que vamos a querer destacar (por ejemplo, nueva commits que vamos a querer destacar (por ejemplo, nueva
funcionalidad totalmente implementada). Para acceder a ellos funcionalidad totalmente implementada). Para acceder a ellos
fácilmente sin necesidad de recordar el hash, podemos etiquetarlos: fácilmente sin necesidad de recordar el hash, podemos etiquetarlos:
git tag v1.0 9b72 git tag v1.0 9b72

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 28 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 28 / 53
 Repositorios de git: comentarios antes de continuar Repositorios de git: comentarios antes de continuar

• Sean descriptivos con los commit messages: • Sean descriptivos con los commit messages:

• No hagan un seguimiento de todos los archivos: Los archivos que • No hagan un seguimiento de todos los archivos: Los archivos que
seguimos son los archivos fuente (el código, algún archivo de seguimos son los archivos fuente (el código, algún archivo de
configuración), y no los archivos que se generan a través de la configuración), y no los archivos que se generan a través de la
compilación o ejecución del programa. ¿Y cómo hacemos eso? compilación o ejecución del programa. ¿Y cómo hacemos eso?
Mediante la creación de un archivo, .gitignore Mediante la creación de un archivo, .gitignore

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 29 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 29 / 53

Repositorios de git: ignorar archivos Repositorios de git: la historia como un grafo

Algunas reglas para poner dentro de .gitignore:

1 $ cat .gitignore
2 # Un comentario. Esta linea es ignorada.
3 # Ningun archivo *.a
4 *.a
5
6 # Pero trackear lib.a, aunque este ignorando los archivos *.a Los grafos de git
7 !lib.a
8
9 # Ignorar archivo TODO, pero no los subdir/TODO
10 /TODO
11
12 # Ignorar todos los archivos en el directorio build/
13 build/
14 # Ignorar archivos doc/*.txt, pero no los doc/server/[Link]
15 doc/*.txt
16 # Ignorar archivos .txt en el directorio doc/ y los subdirectorios
17 doc/**/*.txt

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 30 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 31 / 53
 Repositorios de git: la historia como un grafo Repositorios de git: ramas

Ramas
Compliquemos las cosas. Ahora queremos implementar dos funcionalidades
Con estas herramientas y conceptos fundamentales, podemos avanzar un “al mismo tiempo”:
poco más en el entendimiento y la visualización de la historia de un • Crear una pelı́cula que grafique el paso del agua
repositorio.
• Implementar el método numérico Runge-Kutta de orden 4 (en lugar
Usualmente, para ver la historia de un repositorio se utilizan grafos. En
de Euler)
nuestro ejemplo, tendrı́amos la siguiente situación
HEAD
Gráficamente, podemos pensarlo ası́.
13aa ....... 9b72 ????
RK4
NS Euler Graficar E HEAD

Esta visualización del repositorio nos da una mejor idea del desarrollo del 13aa ....... 9b72
código. Para visualizarla en la consola, escribimos git log --graph NS Euler Graficar E

????
Película

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 32 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 33 / 53

Repositorios de git: ramas Repositorios de git: ramas

Ahora bien, ¿cómo lo hacemos? Mediante la utilización de ramas (branch). Para posicionarnos en la nueva rama, simplemente ejecutamos
Para crear una rama llamada rungekutta4, ejecutamos
1 $ git checkout rungekutta4
1 $ git branch rungekutta4 2 $ git branch
2 $ git branch #esto imprime las ramas existentes 3
3 4 master
4 * master 5 * rungekutta4
5 rungekutta4
master rungekutta4*
master* rungekutta4
13aa ....... 9b72
13aa ....... 9b72 NS Euler Graficar E
NS Euler Graficar E

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 34 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 35 / 53
 Repositorios de git: ramas Repositorios de git: ramas

Continuemos con el desarrollo de nuestro código. Creamos el archivo

[Link] y empezamos a implementar el método. Observen que todos los Volvemos a la rama master (git checkout master) y desarrollamos el código
commits los hemos hecho parados en la rama rungekutta4. Mientras, la para que genere la pelı́cula.
rama master no ha tenido commits. rungekutta4
HEAD
rungekutta4*
58d2 3dd1
58d2 3dd1 master* HEAD

master 13aa 9b72 4a11 223d

NS Euler Graficar E Película
13aa 9b72
NS Euler Graficar E

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 36 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 37 / 53

Repositorios de git: unir ramas Repositorios de git: unir ramas

Entonces, conseguimos partir el desarrollo del código e implementar RK4,
sin romper el desarrollo de la pelı́cula.
El siguiente paso será juntar estar dos implementaciones (al fin y al cabo,
es lo que queremos). Para eso, debemos unir las dos ramas.
1 $ git merge master rungekutta4
2 Merge made by the ’recursive’ strategy. ¿Pero cómo supo cómo unirlas? Las lı́neas en las que no hay duda de
3 [Link] | 0
cómo unir, las une sin preguntar. Si, en cambio, puede llegar a haber
4 1 file changed, 0 insertions(+), 0 deletions(-)
5 create mode 100644 [Link] conflicto, pregunta.

Unir las ramas exige un nuevo snapshot. O sea, cuando hacemos merge nos
pide un commit message.
58d2 3dd1 HEAD
RK4 master*
rungekutta4

13aa 9b72 4a11 223d 1e47

NS Euler Graficar E Película Merge

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 38 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 39 / 53
 Repositorios de git: unir ramas Repositorios de git

Es buena costumbre borrar las ramas una vez que se dejaron de utilizar:

1 $ git branch -d rungekutta4

Veamos rápidamente todo esto en práctica.
58d2 3dd1
RK4 HEAD
master*

13aa 9b72 4a11 223d 1e47

NS Euler Graficar E Película Merge

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 40 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 41 / 53

Repositorios de git: Resumen Flujo de trabajo...

... o cómo pensar el desarrollo del software

• git init # crea repositorio
• git status # estado del repositorio
• git add # agrega a stage
• git commit # guarda en repositorio lo que está en stage
• git branch <rama> # crea nueva rama
• git branch # lista las ramas existentes
• git checkout <id> # visita un determinado snapshot
• git diff # indica diferencias
• git log # muestra los commits hechos
• git tag <new_tag> <hash> # permite cambiar tags de los snapshots

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 42 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 43 / 53
Flujo de trabajo Flujo de trabajo

El ciclo de vida de una release de un programa se asemeja bastante al

siguiente grafo. Analicémoslo un poco ¿Y por qué se trabaja de esa manera? Simplificadamente, porque los merge
son complicados: puede surgir bugs al unir, y es más fácil encontrarlos y
arreglarlos si los dos códigos que mergeamos son parecidos.
master

1 2 6'
main dev

2' 3' 4' 5'

exp. feat.

4''

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 44 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 45 / 53

Flujo de trabajo Flujo de trabajo: bugs

¿Y si en la versión 19 del programa nos damos cuenta de que arrastramos

un bug desde la versión 1?

2.1

2.1.1

Creo una nueva rama para corregir el bug, y lo corrijo en donde

aparece por primera vez. De esta forma, cuando uno ve la historia del
repositorio, sabe entre qué versiones estaba presente el bug.

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 46 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 47 / 53
Flujo de trabajo: bugs Flujo de trabajo: bugs

¿Y si en la versión 19 del programa nos damos cuenta de que arrastramos ¿Y si en la versión 19 del programa nos damos cuenta de que arrastramos
un bug desde la versión 1? un bug desde la versión 1?

! 2.1 ! 2.1
Bug Bug

2.1.1 2.1.1 2.1.2

Creo una nueva rama para corregir el bug, y lo corrijo en donde Creo una nueva rama para corregir el bug, y lo corrijo en donde
aparece por primera vez. De esta forma, cuando uno ve la historia del aparece por primera vez. De esta forma, cuando uno ve la historia del
repositorio, sabe entre qué versiones estaba presente el bug. repositorio, sabe entre qué versiones estaba presente el bug.

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 47 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 47 / 53

Repositorios remotos Repositorios remotos

Antes de hablar propiamente de los repositorios remotos, hablemos de
cómo forkear un repositorio.
Un fork es una copia de un repositorio. Forkear un repositorio nos permite
experimentar libremente con él sin afectar el proyecto original.
Generalmente, los forks se utilizan para proponer cambios en el repositorio
de otra persona o para utilizar el proyecto de otro como punto de partida
Trabajando a distancia para una idea propia.

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 48 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 49 / 53
 Repositorios remotos Repositorios remotos
Flujo de trabajo

¿Y cómo se hacen?

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 50 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 51 / 53

Repositorios remotos

Los comandos para comunicarse con un repositorio remoto son simples:

Sistemas de control de versiones: git

1 $ git clone [Link]

1 $ git push Rodrigo Lugones

1 $ git pull
rlugones@[Link]
Una observación: git pull incorpora cambios de un repositorio remoto en
la rama actual. En su implementación por defecto, git pull es
simplemente git fetch seguido de git merge FETCH_HEAD

Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 52 / 53 Rodrigo Lugones Sistemas de control de versiones rlugones@[Link] 53 / 53