Introducción a Git

Ruben Egiguren (keopx)
30/10/2015
WorkShop
Introducción a Git

Acerca de keopx
Drupal Developer, Software Libre enthusiast, new technologies and geek
Ruben Egiguren a.k.a. keopx
Profesional: www.isarea.com
Blog: www.keopx.net
Drupal: www.drupal.org/u/keopx
Miembro de:
• Drupal Association
• Asociación Española de Drupal
• G.D.O Basque Country
• …
Freelance
Drupal Developer

Índice
➢ Introducción
➢ Teoría Git
➢ Git básico
➢ Veamos un ejemplo
➢ Git intermedio

Qué es git
Wikipedia
Git es un software de control de versiones diseñado por Linus
Torvalds, pensando en la eficiencia y la confiabilidad del
mantenimiento de versiones de aplicaciones cuando éstas tienen un
gran número de archivos de código fuente.
Página oficial
Git es un software libre y gratuito. Se trata de un sistema de control
de versiones distribuido diseñado para manejar todo, desde
pequeños proyectos a proyectos muy grandes con velocidad y
eficiencia.
Introducción
5

Un poco de historia
Linus Torvalds
2005
Comunidad
Linux
Introducción
6
Fuente: http://es.wikipedia.org/wiki/Linus_Torvalds

Un poco de historia
Sistemas de Control de Versiones Centralizados (CVCS)
● SCCS -> 1972.
● RCS -> 1982.
● CVS -> 1986.
● TeamWare -> 1990
● VSS -> 1994
● SVN -> 2000
Sistemas de Control de Versiones Distribuidos (DVCS)
● HG -> 2005
● Bazaar -> 2005
● Git -> 2005
Introducción
7

Definición de git
● Distribuido/centralizado
● Diferencias/snapshots
● Varios datos
● Zona
● Estados
● Tipos de archivos
● Protocolos
● Instalación
Introducción
8
Fuente: http://git-scm.com/downloads/logos

Quién lo usa
● Linux
● KDE
● Android
● Drupal
● Ruby onRails
● Eclipse
● Gnome
● Postgres
● Blizzard
● Facebook
● RedHat
● Microsoft
● Yahoo
● VMWare
● Twitter
● ...
Introducción
9

Pro Git book
http://git-scm.com/book/en/v2
● Creative Commons Attribution Non Commercial
Share Alike 3.0 license.
○ .epub
○ .pdf
○ .mobi
○ .html
http://git-scm.com/book/es/v1 (spanish completo)
http://git-scm.com/book/es/v2 (spanish parcial)
Introducción
10

Sistemas de Control de Versiones Centralizados
(CVCS)
Ejemplos: CVS, Subversion, Perforce, SourceSafe, ...
Fuente: http://git-scm.com/book
Teoría de git
12

Sistemas de Control de Versiones Distribuidos (DVCS)
Ejemplos: git, Mercurial, Bazaar, BitKeeper,...
Teoría de git
13

Centralizado vs. Distribuido
DVCS
● Git
● Mercurial
● Bazaar
● BitKeeper
● ...
CVCS
● CVS
● Subversion
● Perforce
● SourceSafe
● ...
Teoría de git
14

(Algunas) características de git
● La mayoría de las operaciones son locales.
● Git tiene integridad fuerte gracias a SHA1.
○ Git lleva control del checksum SHA1 de cada archivo,
commit...
● Git (generalmente) sólo añade datos.
○ Casi nunca borra nada, por tanto, todo queda registrado y
todo es recuperable.
Teoría de git
15

Los tres espacios y tres estados
En local, Git se basa en "3 zonas" y "3 estados". Existe un área
intermedia antes del commit que otros SCV no tienen.
Modified* Staged Committed
Teoría de git
16

Las 3 Zonas de Git
● Lugar de trabajo: Donde trabajamos (realizamos las
modificaciones).
● Área intermedia (Staging area): Donde estarán las
modificaciones que después irán en el commit (Git realiza un
seguimiento de los archivos antes de confirmar).
● Área confirmada: Una vez realizado el commit, tenemos el
repositorio con una revisión nueva y por tanto, pasaremos
automáticamente a "Lugar de trabajo" para hacer el siguiente
ciclo de trabajo.
Teoría de git
17

Los 3 estados de Git
● Existen 3 estados, uno por cada zona.
● Commited: sin cambio o confirmado (zona 1 y 3).
● Modified: con cambios (entre las zonas 1 y 2 ) justo antes del
staging area.
● Staged: preparado para el commit (tracked by Git).
● Una vez hecho commit estaríamos en "commited".
Teoría de git
18

El estado + 1 de Git
Git no sabe qué ficheros existen en el repositorio hasta que se añaden
(la primera vez sólo), untracked.
El estado
+1
Teoría de git
19

Tipos de archivos en Git
Git contiene 5 tipos de archivos diferentes:
● Object Unidad de almacenamiento SHA1 -> inmutable.
● Commit (Metadatos, tree...): Contiene información de la revisión.
● Tag Identifica otros objetos de Git.
● Tree Referencia blob, permisos...
● Blob Un fichero.
Teoría de git
20

Punteros en Git
Si hacemos un cambios y realizamos un commit, en nuevo commit
almacena un puntero que apunta al commit anterior.
Teoría de git
21

Entendiendo los punteros en Git
En Git todo va sobre punteros. Cuando hacemos reset, revert, branching.... todo son
punteros que apuntan a revisiones. Esto hace especial a Git.
Uno de los punteros más importantes es HEAD que apunta al último commit de la rama donde
estemos situados. Además, cada rama tiene un puntero propio que apunta al último commit
de dicha rama.
En este ejemplo vemos como hay 2 ramas y estamos situados en la rama master (HEAD).
Teoría de git
22

Protocolos de Git
● Local
○ Pros: Cómodo y simple.
○ Cons: Compartición difícil, no necesariamente ha de ser rápido.
● HTTP/S
○ Pros: Fácil de poner y no da problemas con firewall.
○ Cons: Lento.
● SSH (el más común)
○ Pros: Seguro, rápido, eficiente, común.
○ Cons: No tiene acceso anónimo.
● Git
○ Pros: El más rápido.
○ Cons: Sin autenticación.
Teoría de git
23
Fuente: http://git-scm.com/book/es/Git-en-un-servidor-Los-Protocolos

● commit: información de una revisión dada. Incluye:
○ Los padres del objeto.
○ La persona que ha realizado el commit de la revisión.
○ El autor de la revisión.
○ La fecha.
○ Un mensaje asociado.
○ El objeto tree que corresponde al directorio raíz de la revisión.
● revisión:
○ El estado de una serie de ficheros y directorios que ha sido almacenado en la base de datos
de objetos. Se hace referencia a él por medio de un objeto commit.
● padre:
○ un objeto commit contiene una lista (potencialmente vacía) de objetos commit que
representan a sus predecesores lógicos en la línea de desarrollo, esto es, sus ancestros.
Aclarando conceptos
Teoría de git
24

Introducción a GIT
Git básico

Configuración
La configuración de Git puede realizarse a tres niveles diferentes.
● Sistema: --system
○ Para todos los usuarios
○ Archivo: "/etc/gitconfig"
● Usuario: --global
○ Por usuario
○ El más usado
○ Archivo: "~/.gitconfig"
● Repositorio
○ Diferente configuración por repositorio
○ Archivo: "$GIT_REPO/.git/config"
Con configurarlo una vez es suficiente.
Podemos configurar de todo: Usuario, email, editor de mensajes de
commit, diffs...
Git básico
26

● Personalizar el commiter, esto es muy importante.
● Para ello usaremos git config:
git config
$ git config --global user.name "Ruben Egiguren"
$ git config --global user.email keopx@keopx.net
Es recomendable configurar coloreado de sintaxis:
$ git config --global color.ui true
Ver la configuración:
$ git config --list
user.name=Ruben Egiguren
user.email=keopx@keopx.net
color.ui=true
Git básico
27

Inicializar un repositorio (vacío por defecto) con git init:
git init & git clone
$ mkdir mi_repo && cd mi_repo
$ git init
Initialized empty Git repository in /Proyectos/mi_repo/.git/
$ git clone https://github.com/keopx/Test.git
Cloning into 'Test'...
remote: Counting objects: 12, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 12 (delta 0), reused 9 (delta 0)
Unpacking objects: 100% (12/12), done.
Clonar repositorio HTTPs (existente) con git clone:
● Recordar que se pueden utilizar múltiples protocolos.
Git básico
28

git init & git clone
$ git clone https://{usuario}@{ip_maquina}:{puerto}/gitdemo/ejemplo.git
Clonar repositorio HTTPs con git clone:
● En este caso usaremos un usuario y un puerto concreto
Inicializar repositorio y sincronizar con repositorio HTTPs
remoto:
● Usaremos un usuario y un puerto concreto
$ git init
$ touch README
$ git add README
$ git commit -m 'First commit'
$ git remote add origin https://{usuario}@{ip_maquina}:{puerto}/gitdemo/ejemplo.git
$ git push origin master
Git básico
29
Referencia: https://help.github.com/articles/create-a-repo

Operaciones con ficheros
$ git add README
● Añadir un archivo al repositorio (Git podrá seguirle la pista -> Tracked).
● Estado de archivos del repositorio.
$ git status
# On branch 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: README
#
no changes added to commit (use "git add" and/or "git commit -a") git add README
● Borrar un archivo del repositorio (Git ya no podrá seguirle la pista ->
Untracked).$ git rm README
● Mover un archivo del repositorio (Git le sigue llevando la pista).
$ git mv README README2
Git básico
30

● Ahora si creamos un fichero nuevo vemos que nos lo indica.
$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# hello.txt
nothing added to commit but untracked files present (use "git add" to track)
$ git add hello.txt
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: hello.txt
#
● Añadimos con git add, git ya sabe que existe
31
Git básico

● Ahora si creamos un fichero nuevo vemos que nos lo indica.
$ git commit -m "Nuestro fichero hello"
# On branch master
#
# Initial commit
#
# Untracked files:
#
# hello.txt
$ git commit -m "Nuestro fichero hello"
[master cc99bd2] Nuestro fichero hello
1 file changed, 1 insertion(+)
create mode 100644 hello.txt
$ git status
# On branch master
nothing to commit (working directory clean)
● Añadir con git add, git ya sabe que existe.
● Ahora tenemos Git sin cambios. Ahora ya podemos seguirle la
pista al fichero hello.txt. git add solo se realiza una única vez.
32
Git básico

● Mover un fichero, git mv (cambiar nombre del fichero).
$ git mv hello.txt hello
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
#
# renamed: hello.txt -> hello
#
$ git rm hello
rm 'hello'
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 2 commits.
#
#
# deleted: hello
#
● Borrar un fichero, git rm (cambiar nombre del fichero).
Para añadir más de un fichero a la vez podemos utilizar git add . de esta
añadirás múltiples ficheros a la vez.
33
Git básico

.gitignore
# Bootstrap
app/bootstrap*
# Symfony directories
vendor/*
*/logs/*
*/cache/*
web/uploads/*
web/bundles/*
# Configuration files
app/config/parameters.ini
app/config/parameters.yml
.gitignore es un archivo que usado para excluir archivos, directorios... con una sintaxis
concreta. Para ello hace uso de expresiones regulares.
El archivo .gitignore se puede poner en cualquier directorio (normalmente en la raíz del
proyecto) y los directorios inferiores sobrescriben los superiores.
Las reglas para los patrones que pueden ser incluidos en el archivo .gitignore son:
● Las líneas en blanco, o que comienzan por #, son ignoradas.
● Puedes usar patrones glob estándar.
● Puedes indicar un directorio añadiendo una barra hacia delante (/) al final.
● Puedes negar un patrón añadiendo una exclamación (!) al principio.
Repositorio con .gitignore de los proyectos más comunes: https://github.com/github/gitignore
Ejemplo .gitignore para symfony:
34
Git básico
Referencia: http://git-scm.com/book/es/Fundamentos-de-Git-Guardando-cambios-en-el-repositorio#Ignorando-archivos

git diff
$ git diff
diff --git a/hello.txt b/hello.txt
index e3f7297..eecc2a1 100644
--- a/hello.txt
+++ b/hello.txt
@@ -1,3 +1,4 @@
-Nada mas, ver cambios
+Nada mas, ver cambios.
+Añadimos mas lineas
git diff nos muestra el formato "diff" los cambios realizados.
Sirve para ver los cambios que hay desde la última revisión (o
una anterior).
En este ejemplo se ha añadido la línea "Añadimos mas lineas" al
final del fichero hello.txt.
35
Git básico
Referencia: http://git-scm.com/book/es/Fundamentos-de-Git-Guardando-cambios-en-el-repositorio#Viendo-tus-cambios-preparados-y-no-preparados

git commit
$ cp hello.txt hello2.txt
$ git status -s
?? hello2.txt
$ git commit -m "Nuevo fichero"
# On branch master
#
# Untracked files:
#
# hello2.txt
$ git add .
$ git status -s
A hello2.txt
$ git commit -m "Nuevo fichero"
[master 0c254ac] Nuevo fichero
1 file changed, 4 insertions(+)
create mode 100644 hello2.txt
git commit hace que los cambios que estén en la Staging Area pasen a ser una
revisión (es decir, confirmar los cambios). Todos los cambios que no hayan sido
pasados a la zona de stage no estarán "commiteados" pero no se perderán esos
cambios.
En este ejemplo vemos que si no hay nada en el stage el commit no se hace. Una
vez añadido, el commit se realiza sin problema.
36
Git básico
Referencia: http://git-scm.com/book/es/Fundamentos-de-Git-Guardando-cambios-en-el-repositorio#Confirmando-tus-cambios

git commit -a
Fuente: http://codingdomain.com/git/partial-commits/ & http://git-scm.com/book/es/Fundamentos-de-Git-Guardando-cambios-en-el-
repositorio#Confirmando-tus-cambios
$ echo "Editamos hello" >> hello.txt && echo "Editamos hello2" >> hello2.txt
$ git status
# On branch 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: hello.txt
# modified: hello2.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git commit -a -m 'added new line'
[master 7b579f4] added new line
2 files changed, 2 insertions(+)
Staging Area es en ocasiones demasiado complejo para tu flujo de trabajo. Para ahorrarnos
este paso usamos git commit -a, que hace que Git prepare todo archivo que estuviese en
seguimiento antes de la confirmación, permitiéndote obviar la parte de git add. Podemos
decir que es casi igual que git add . + git commit:
37
Git básico

git commit -avm
$ echo "Añadimos mas texto" >> hello.tx
$ git status -s
M hello2.txt
$ git commit -avm "probando -avm"
[master b9d89d5] probando -avm
1 file changed, 1 insertion(+)
Existen más opciones. Haciendo commit sin ningún parámetro (git
commit) o con el parámetro -a (git commit -a), Git abrirá el editor
de texto para que añadamos el comentario del commit (recordamos
git config).
Para pasarle el comentario directamente, usamos "-m".
Para que de más información que de lo habitual tras hacer el
commit (verbose), usaremos "-v".
Existen muchos más parámetros para el commit, pero el comando
usado suele ser: git commit -avm "comentario del commit"
38
Git básico
Referencia: http://git-scm.com/book/es/Fundamentos-de-Git-Guardando-cambios-en-el-repositorio#Confirmando-tus-cambios

git log
git log da información formateada de los commits.
Se puede visualizar mucha información, poca, formateada estilo
grafo, con las ramas…
● --graph: Pone en formato grafo los commits.
● --oneline: Formato simple de commit en una línea.
● --decorate: Con colores para cada rama, checksum, branches...
● --all: Visualiza información de todas las ramas.
Existen muchos parámetros más. Un comando que puede aportarnos
bastante información puede ser:
git log --graph --decorate --oneline --all
39
Git básico
Referencia: http://git-scm.com/book/es/Fundamentos-de-Git-Viendo-el-hist%C3%B3rico-de-confirmaciones

git log
$ git log --graph --decorate --oneline --all
* 01d3778 (HEAD, origin/master, origin/HEAD, master) Merge branch 'devel'
|
| * 1e122cc (origin/devel, devel) mas cambios
| * e120650 commit con cambios
* | 58a938b cambios para merge
|/
* b9d89d5 probando -avm
* 7b579f4 added new line
* 0c254ac Nuevo fichero
* e3cce4c Cambios commiteados
git log es muy potente y flexible a la vez. De nosotros dependerá la
información a mostrar.
Existen programas con interfaz gráfica como Gitk, Giggle, Qgit,
Gitx...
Aquí vemos un ejemplo de:
git log --graph --decorate --oneline --all
40
Git básico
Referencia: http://git-scm.com/book/es/Fundamentos-de-Git-Viendo-el-hist%C3%B3rico-de-confirmaciones

gitk
Gitk es una interfaz gráfica que viene con Git. Por defecto, Gitk no
visualiza todas las ramas. Para ver las ramas usarlo así: gitk --all
41
Git básico

git commit --amend
$ git log --oneline -n 3 --decorate
34b59db (HEAD, master) Añadimos file1
8ec710f (origin/master, origin/HEAD,) Git reset y revert
01d3778 Merge branch 'devel'
$ git add file2
$ git commit --amend -m "Añadimos file1 y file2"
[master eadd46c] Añadimos file1 y file2
0 files changed
create mode 100644 file1
create mode 100644 file2
eadd46c (HEAD, master) Añadimos file1 y file2
8ec710f (origin/master, origin/HEAD,) Git reset y revert
01d3778 Merge branch 'devel
git commit --amend hablados de reescribir un commit. No es
aconsejable, no es buena idea reescribir el historial (sobre todo si
ha sido publicado).
Se podría usar después de haber hecho un commit y darnos cuenta
que se nos ha olvidado añadir un archivo. (pero sin el push).
Referencia: http://git-scm.com/book/es/Fundamentos-de-Git-Deshaciendo-cosas 42
Git básico

git reset
8ec710f (HEAD, origin/master, origin/HEAD, master) Git reset y revert
58a938b cambios para merge
$ echo "reset en hello" >> hello.txt
$ git status -s
M hello.txt
$ git reset --hard HEAD
HEAD is now at 8ec710f Git reset y revert
$ git status -s
8ec710f (HEAD, origin/master, origin/HEAD, master) Git reset y revert
58a938b cambios para merge
git reset se usa para limpiar el repositorio (volver a revisiones
anteriores). Los cambios que no estén en la Staging Area seguirán en
estado "modified" a no ser que usemos --hard. Se le puede
especificar a qué momento queremos volver (commit concreto, tag,
etc...) de muchas formas. Nombre, hash...
Git básico

git revert
git revert sirve para deshacer cambios pero de forma
menos intrusiva.
Con revert, se revierte los cambios de un commit concreto
realizando otro commit nuevo (aplicar el diff de ese
commit pero al revés).
También se le puede especificar que no haga commit
después de revertir (--no-commit).
Git básico

git checkout (reverting)
git checkout tiene diferentes usos. En este caso hablamos de
git checkout para deshacer cambios (este comando aparecerá
de nuevo cuando se hable de las ramas).
Con git checkout podemos revertir archivos individuales o
repositorios enteros a revisiones anteriores.
Si usamos git checkout -- FICHERO hace lo mismo, pero si
tenemos ese archivo en la Staging Area (git add .) y se ha
modificado posteriormente, se revierte a la revisión del staging
area.
En resumen, sería revertir los cambios hechos en el fichero al
estado de después de haberlo metido en el stage.
Git básico

Introducción a GIT
Veamos un ejemplo

Introducción a GIT
https://vimeo.com/82408340

Introducción a GIT
Git intermedio

Introducción a GIT
Siguiente charla ;)

GRACIAS POR SU ATENCIÓN
Ruben Egiguren aka keopx
GNU/GPL Licence
50

Introducción a Git

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Introducción a Git

Similar a Introducción a Git (20)

Más de Keopx

Más de Keopx (20)

Introducción a Git