Sneak Git - All under control

Sneak Git

Transcript

1. SNEAK GIT http://alejandroelinformatico.com/slideshows/sneak­git/ Alejandro el informático(@ainformatico). 2012. Licencia Creative Commons by­nc­sa.
2. ¿QUÉ ES g i t ? "Git is a free & open source, distributed version control system." http://git­scm.com/
3. DISTRIBUTED VERSION CONTROL "distributed version control or decentralized version control (DVCS) keeps track of software revisions and allows many developers to work on a given project without necessarily being connected to a common network." http://en.wikipedia.org/wiki/Distributed_revision_control
4. DISTRIBUTED VERSION CONTROL II No hay servidor central Cada repositorio es una copia total independiente Portabilidad Acceso total a todo el repositorio Múltiples usuarios trabajando simultáneamente Poder viajar en el tiempo Libertad total en nuestro repositorio! Todo se referencia mediante hashes únicos Poder colaborar en diferentes proyectos Historial detallado, no como en VSS Ramas locales diferentes de las remotas
5. VIVIR AL LÍMITE final­bueno.zip final­bueno­2.zip final­bueno­final.zip el­ultimo.zip el­ultimo­de­verdad.zip el­bueno­final­2­de­verdad.zip el­bueno­final­2­de­verdad­001.zip el­bueno­final­2­de­verdad­001­ entregado­cliente­te­lo­juro.zip CONTROL DE VERSIONES I
6. AVENTUREROS SOLITARIOS Es un sistema que no está pensado para trabajo colaborativo, pero puede adaptarse a las necesidades de aventureros solitarios. CONTROL DE VERSIONES II
7. GUERREROS Usar un sistema de control de versiones pensado exclusivamente para esta tarea. CONTROL DE VERSIONES III
8. DISCLAIMER Todas las comparaciones y comentarios que vienen a continuación son puramente del autor de este documento y están basadas en su experiencia trabajando con las herramientas documentadas. No se pretende intentar cambiar la mentalidad ni la percepción de ninguna persona ni mucho menos desprestigiar alguna de estas herramientas. "No importa qué herramienta uses, importa que uses una y ésta se adapte a tus necesidades." ­ Alejandro el informático
9. g i t VS MERCURIAL VS SVN g i t tracks content, not files Más rápido No es un solo binario, sino que se trata de un binario que llama diferentes herramientas lo cual lo hace muy extensible s t a s h b l a m e r e b a s e Mejor algoritmo para manejar m e r g e De fácil configuración, tanto de servidor como cliente
10. g i t Pensado para trabajar con ramas Mejor gestión Menos espacio en disco h g Numeración consecutiva auxiliar Mejor clones que ramas Más lento Más espacio en disco No es tan "fácilmente" extensible "Más fácil de aprender" g i t VS h g
11. g i t :) s v n Mucho más lento Más difícil de configurar Únicamente centralizado Dependencia total del servidor Dependencia de la red, VPN Únicamente se obtienen los cambios, no el repositorio entero No podemos hacer commits si el repositorio no está actualizado Cada b r a n c h es en realidad un clon Más lento Mucho más espacio en disco g i t VS s v n
12. ENTONCES, ¿POR QUÉ g i t ? Muy extendido Muchas herramientas para trabajar Gestores de proyectos, tareas, tickets... Github Bitbucket Gitosis / Gitolite Muy potente De fácil configuración Mejor rendimiento
13. Sistema de copias de seguridad Directorio personal sincronizado Ficheros de configuración personales, .gitconfig, .hgrc, .vimrc, etc. Diferentes ficheros, PSD, DOC, ODT... Sistemas de logs Clon de Github, http://gitlabhq.com/ Sistemas de tickets distribuidos https://github.com/jeffWelling/ticgit http://ditz.rubyforge.org/ Ficheros de configuración Diferentes perfiles Originales deploys en servicios de terceros: Heroku Github pages Blogs Octopress Jekyll Bases de datos distribuidas http://code.google.com/p/gimd/ https://github.com/bestpractical/prophet Herramientas tipo dropbox con hosting propio http://sparkleshare.org/ Wikis http://atonie.org/2008/02/git­wiki http://ikiwiki.info/ http://gitit.net/ MÚLTIPLES USOS
14. g i t BÁSICO Configuración Crear repositorio El primer commit Ver el histórico Branches Checkout Merge Volver atrás c l o n e Workflows más usuales
15. ¿CÓMO CONFIGURARLO? Hay dos maneras de configurar g i t : El fichero ~/.gitconfig y el fichero /path/to/repo/.git/config Configuración por CLI Los dos métodos nos permiten tener configuraciones locales y generales.
16. CONFIGURACIÓN Alias Poder usar alias en los comandos de g i t , por ejemplo: $ g i t f i x como alias de $ g i t c h e c k o u t - b f i x Colores Definir los colores para los logs y los diff Archivos ignorados Ignorar ficheros a nivel personal/usuario o general Core Espacios, tabulaciones, terminaciones de línea Merge Definir la herramienta para usar
17. ~/.GITCONFIG Y /PATH/TO/REPO/.GIT/CONFIG [ u s e r ] n a m e = J o h n D o e e m a i l = j o h n @ d o e . c o m [ a l i a s ] f i x = g i t c h e c k o u t - b f i x [ d i f f ] t o o l = v i m d i f f [ c o l o r " d i f f " ] o l d = r e d n e w = b l u e
18. CONFIGURACIÓN POR CLI $ g i t c o n f i g [ - - g l o b a l ] u s e r . n a m e " J o h n D o e " $ g i t c o n f i g [ - - g l o b a l ] u s e r . e m a i l " j o h n @ d o e . c o m " $ g i t c o n f i g [ - - g l o b a l ] a l i a s . f i x c h e c k o u t - b f i x $ g i t c o n f i g [ - - g l o b a l ] c o l o r . d i f f a u t o $ g i t c o n f i g [ - - g l o b a l ] c o r e . e d i t o r v i m
19. UN MOMENTO
20. http://git­scm.com/downloads/guis g i t GUIS
21. CREAR REPOSITORIO Hay dos maneras dependiendo de si queremos tener un repositorio único y personal o compartido con otros desarrolladores(centralizado). Personal $ g i t i n i t { n a m e } compartido $ g i t i n i t - - b a r e { n a m e }
22. b a r e OR NOT TO b a r e El b a r e indica si se trata de un repositorio el cual permitirá que se hagan commits de otras personas. De esta manera diferentes personas pueden hacer p u s h /p u l l sin romper el working directory de otros desarrolladores. $ l s b r a n c h e s c o n f i g d e s c r i p t i o n H E A D h o o k s i n f o o b j e c t s r e f s
23. . g i t i g n o r e Fichero para definir los archivos o directorios que no queremos que se guarden en el repositorio. Por ejemplo, añadimos lo siguiente: $ v i m . g i t i g n o r e t m p / b i n / * . l o g
24. PRIMER COMMIT En g i t tenemos 3 estados que definen el estado de nuestros ficheros. Fichero no registrado $ g i t s t a t u s Añadir los cambios para registrarlos $ g i t a d d { f i l e } [ - a ] Commit $ g i t c o m m i t [ - m " A D D { f i l e } " ]
25. $ g i t s t a t u s # O n b r a n c h m a s t e r # # I n i t i a l c o m m i t # # U n t r a c k e d f i l e s : # ( u s e " g i t a d d < f i l e > . . . " t o i n c l u d e i n w h a t w i l l b e c o m m i t t e d ) # # m a i n . c n o t h i n g a d d e d t o c o m m i t b u t u n t r a c k e d f i l e s p r e s e n t ( u s e " g i t a d d " t o t r a c k )
26. $ g i t a d d m a i n . c Si queremos añadir solo algunas partes del fichero debemos ejecutar: # O n b r a n c h m a s t e r # # I n i t i a l c o m m i t # # C h a n g e s t o b e c o m m i t t e d : # ( u s e " g i t r m - - c a c h e d > f i l e > . . . " t o u n s t a g e ) # # n e w f i l e : m a i n . c # g i t a d d - p m a i n . c
27. $ g i t c o m m i t [ - m ] A D D m a i n . c f o r o u r f i r s t c o m m i t # P l e a s e e n t e r t h e c o m m i t m e s s a g e f o r y o u r c h a n g e s . # L i n e s s t a r t i n g w i t h ' # ' w i l l b e i g n o r e d , # a n d a n e m p t y m e s s a g e a b o r t s t h e c o m m i t . # O n b r a n c h m a s t e r # # I n i t i a l c o m m i t # # C h a n g e s t o b e c o m m i t t e d : # ( u s e " g i t r m - - c a c h e d > f i l e > . . . " t o u n s t a g e ) # # n e w f i l e : m a i n . c #
28. HISTÓRICO Podemos ver el histórico de nuestro repositorio con tal de ver qué cambios se han realizado y quién ha sido el autor. El histórico en modo gráfico siempre se ha de leer de abajo hacia arriba. H E A D hace referencia a la rama o estado en el que nos encontramos actualmente. $ g i t l o g c o m m i t 1 a 3 0 2 4 d f 8 5 5 6 0 d 6 b 6 1 5 a 7 a 3 9 5 c 4 2 a 9 9 1 8 0 e d 5 4 c b A u t h o r : J o h n D o e < j o h n @ d o e . c o m > D a t e : S a t O c t 1 5 1 8 : 0 0 : 0 0 2 0 1 1 + 0 2 0 0 A D D m a i n . c f o r o u r f i r s t c o m m i t 6 . * b c f b 7 b 1 - ( H E A D , m a s t e r ) M E R G E m e s s a g e d e s c r i p t i o n 5 . | \ 4 . | * 9 a 8 c 9 8 3 - ( d e v e l o p ) C H A N G E m e s s a g e t e x t 3 . * | c a 8 0 c c 9 - C H A N G E j u s t c h a n g e t h e m e s s a g e 2 . | / 1 . * c a f f 1 d 7 - A D D m a i n . c f o r o u r f i r s t c o m m i t
29. BRANCHES Las ramas (branches) nos permiten hacer un snapshot del repositorio para poder trabajar sin tocar el desarrollo principal, la rama master que es la rama por defecto que se crea. Por tanto podemos decir que todo en g i t son ramas. En g i t una rama no crea una copia entera del proyecto, g i t tracks content, not files. Remember?
30. $ g i t b r a n c h [ - d | - D ] { n a m e } Crear una rama $ g i t b r a n c h { n a m e } Eliminar una rama de manera segura, si ya hemos obtenido los cambios $ g i t b r a n c h - d { n a m e } Eliminar una rama definitivamente $ g i t b r a n c h - D { n a m e } * c a 8 0 c c 9 - ( H E A D , m a s t e r ) C H A N G E j u s t c h a n g e t h e m e s s a g e | * 9 a 8 c 9 8 3 - ( d e v e l o p ) C H A N G E m e s s a g e t e x t | / * c a f f 1 d 7 - A D D m a i n . c f o r o u r f i r s t c o m m i t
31. $ g i t c h e c k o u t Nos permite cambiar de rama o restaurar nuestro Working directory o fichero. Crear una rama y cambiar automáticamente $ g i t c h e c k o u t - b { n a m e } cambiar a una rama $ g i t c h e c k o u t { n a m e } Restaurar el Working directory o fichero. $ g i t c h e c k o u t - f [ f i l e n a m e ]
32. m e r g e "Merging (also called integration) in revision control, is a fundamental operation that reconciles multiple changes made to a revision­controlled collection of files." En la mayoría de casos únicamente hemos de ejecutar: $ g i t m e r g e t o o l
33. m e r g e II * c a 8 0 c c 9 - ( H E A D , m a s t e r ) C H A N G E j u s t c h a n g e t h e m e s s a g e | * 9 a 8 c 9 8 3 - ( d e v e l o p ) C H A N G E m e s s a g e t e x t | / * c a f f 1 d 7 - A D D m a i n . c f o r o u r f i r s t c o m m i t $ g i t m e r g e d e v e l o p A u t o - m e r g i n g m a i n . c C O N F L I C T ( c o n t e n t ) : M e r g e c o n f l i c t i n m a i n . A u t o m a t i c m e r g e f a i l e d ; f i x c o n f l i c t s a n d t h e n c o m m i t t h e r e s u l t .
34. m e r g e t o o l Usa la herramienta definida o la primera que encuentra que sea capaz de manejar situaciones de m e r g e $ g i t m e r g e t o o l * b c f b 7 b 1 - ( H E A D , m a s t e r ) M E R G E m e s s a g e d e s c r i p t i o n | \ | * 9 a 8 c 9 8 3 - ( d e v e l o p ) C H A N G E m e s s a g e t e x t * | c a 8 0 c c 9 - C H A N G E j u s t c h a n g e t h e m e s s a g e | / * c a f f 1 d 7 - A D D m a i n . c f o r o u r f i r s t c o m m i t
35. VOLVER ATRÁS Para volver atrás en los cambios que hemos realizado lo podemos hacer de diferentes maneras: Borrar el histórico Crear una rama temporal Revertir cambios
36. BORRAR EL HISTÓRICO Podemos borrar el histórico hasta { n } commits anteriores, perdiendo todo el que teníamos hasta ahora y dejando el repositorio en aquel estado. $ g i t r e s e t H E A D ^ { n } [ - - s o f t | - - h a r d ] * b c f b 7 b 1 - ( H E A D , m a s t e r ) M E R G E m e s s a g e d e s c r i p t i o n | \ | * 9 a 8 c 9 8 3 - C H A N G E m e s s a g e t e x t * | c a 8 0 c c 9 - C H A N G E j u s t c h a n g e t h e m e s s a g e | / * c a f f 1 d 7 - A D D m a i n . c f o r o u r f i r s t c o m m i t $ g i t r e s e t H E A D ^ 1 * c a 8 0 c c 9 - ( H E A D , m a s t e r ) C H A N G E j u s t c h a n g e t h e m e s s a g e | * 9 a 8 c 9 8 3 - ( d e v e l o p ) C H A N G E m e s s a g e t e x t | / * c a f f 1 d 7 - A D D m a i n . c f o r o u r f i r s t c o m m i t
37. CREAR UNA RAMA TEMPORAL Podemos crear una rama temporal para poder ver cómo estaba el repositorio en un commit determinado y hacer las acciones pertinentes. $ g i t c h e c k o u t { h a s h } * b c f b 7 b 1 - ( H E A D , m a s t e r ) M E R G E m e s s a g e d e s c r i p t i o n | \ | * 9 a 8 c 9 8 3 - C H A N G E m e s s a g e t e x t * | c a 8 0 c c 9 - C H A N G E j u s t c h a n g e t h e m e s s a g e | / * c a f f 1 d 7 - A D D m a i n . c f o r o u r f i r s t c o m m i t $ g i t c h e c k o u t - b c a 8 0 c c 9 * b c f b 7 b 1 - ( m a s t e r ) M E R G E m e s s a g e d e s c r i p t i o n | \ | * 9 a 8 c 9 8 3 - ( d e v e l o p ) C H A N G E m e s s a g e t e x t * | c a 8 0 c c 9 - ( H E A D , t e m p ) C H A N G E j u s t c h a n g e t h e m e s s a g e | / * c a f f 1 d 7 - A D D m a i n . c f o r o u r f i r s t c o m m i t
38. REVERTIR CAMBIOS Los cambios hechos en commits anteriores se pueden revertir y crear un nuevo commit con el estado de aquel commit. $ g i t r e v e r t { h a s h } $ g i t r e v e r t 1 9 6 e 3 f 4 * 5 6 6 8 7 4 d - ( H E A D , m a s t e r ) R e v e r t " A D D f 1 f i l e " * 1 f e 4 b 7 9 - A D D m o r e c o m m e n t s * 6 4 2 5 1 7 8 - A D D c o m m e n t s * 1 9 6 e 3 f 4 - A D D f 1 f i l e * b c f b 7 b 1 - M E R G E m e s s a g e d e s c r i p t i o n | \ | * 9 a 8 c 9 8 3 - ( d e v e l o p ) C H A N G E m e s s a g e t e x t * | c a 8 0 c c 9 - C H A N G E j u s t c h a n g e t h e m e s s a g e | / * c a f f 1 d 7 - A D D m a i n . c f o r o u r f i r s t c o m m i t
39. Nos permite clonar un repositorio local o remoto para poder empezar a trabajar. Tenemos diferentes sistemas, dependiendo del protocolo: s s h g i t h t t p [ s ] c l o n e g i t @ g i t h u b . c o m : a i n f o r m a t i c o / j e c o o k i e . g i t g i t c l o n e g i t : / / g i t h u b . c o m / a i n f o r m a t i c o / j e c o o k i e . g i t g i t c l o n e h t t p s : / / g i t h u b . c o m / a i n f o r m a t i c o / j e c o o k i e . g i t
40. WORKFLOWS MÁS USUALES Los workflows más usuales en g i t utilizan las ramas para poder separar el desarrollo en diferentes piezas. develop: el desarrollo continuo fix: hacer fixes en el desarrollo feature: crear nuevas funcionalidades master: la versión estable del proyecto, rama por defecto http://nvie.com/posts/a­successful­git­branching­model/
41. WORKFLOWS MÁS USUALES II Los workflows se aplican tanto a desarrollos locales como remotos. Cuando se desarrolla una nueva funcionalidad, se realiza un fix o un test, se piden los cambios de la rama master y si hace falta se hace un merge, se prueban los cambios y se suben a la rama principal. Normalmente se acostumbra a tener una persona encargada de hacer los m e r g e a master y controlar el flujo de commits de los desarrolladores.
42. g i t AVANZADO s t a s h t a g b u n d l e p a t c h b l a m e s u b m o d u l e r e b a s e c h e r r y - p i c k Hooks Trabajando en remoto Gitweb Gitosis / Gitolite Github Bitbucket
43. s t a s h
44. $ g i t s t a s h [ s a v e { d e s c } ] $ g i t s t a s h l i s t $ g i t s t a s h s h o w [ - p ] s t a s h @ { n } $ g i t s t a s h b r a n c h { n a m e } [ s t a s h @ { n } ] $ g i t s t a s h a p p l y [ s t a s h @ { n } ] $ g i t s t a s h p o p [ s t a s h @ { n } ] $ g i t s t a s h d r o p s t a s h @ { n } $ g i t s t a s h c l e a r s t a s h Guarda el estado del repositorio modificado en una pila de cambios que se pueden aplicar en cualquier momento.
45. $ g i t s t a s h [ s a v e { d e s c } ] Guardamos el estado actual del repositorio modificado. $ g i t s t a s h s a v e a d d m a i n d e c l a r a t i o n S a v e d w o r k i n g d i r e c t o r y a n d i n d e x s t a t e O n d e v e l o p : a d d m a i n d e c l a r a t i o n H E A D i s n o w a t 1 a 3 0 2 4 d A D D m a i n . c f o u r o u r f i r s t c o m m i t * T e n e m o s l o s c a m b i o s i n i c i a l e s m á s l o s u r g e n t e s m á s l o s g u a r d a d o s e n l a p i l a | * A p l i c a m o s l o s c a m b i o s d e l s t a s h | \ | | | | * | R e a l i z a m o s l o s c a m b i o s u r g e n t e s | * G u a r d a m o s l o s c a m b i o s e n e l s t a s h | / * C a m b i o s a c t u a l e s
46. $ g i t s t a s h l i s t Listamos el estado de la pila de cambios. $ g i t s t a s h l i s t s t a s h @ { 0 } : O n d e v e l o p : a d d m a i n d e c l a r a t i o n s t a s h @ { 1 } : O n f i x : f i x i n g b u g # 1 6 3 3 8 s t a s h @ { 2 } : O n t e s t : h o l d f o r s o c k e t s t e s t * 8 7 8 b 4 9 d - ( r e f s / s t a s h ) O n m a s t e r : s a v e a d d m a i n d e c l a r a t i o n | \ | * 1 0 b 9 1 6 6 - i n d e x o n m a s t e r : b c f b 7 b 1 M E R G E m e s s a g e d e s c r i p t i o n | / * b c f b 7 b 1 - ( H E A D , m a s t e r ) M E R G E m e s s a g e d e s c r i p t i o n | \ | * 9 a 8 c 9 8 3 - ( d e v e l o p ) C H A N G E m e s s a g e t e x t * | c a 8 0 c c 9 - C H A N G E j u s t c h a n g e t h e m e s s a g e | / * c a f f 1 d 7 - A D D m a i n . c f o r o u r f i r s t c o m m i t
47. $ g i t s t a s h s h o w [ - p ] s t a s h @ { n } Listamos los cambios hechos en el estado n de la pila. $ g i t s t a s h s h o w - p s t a s h @ { 0 } d i f f - - g i t a / m a i n . c b / m a i n . c i n d e x e 6 9 d e 2 9 . . 9 d 9 f 7 b e 1 0 0 6 4 4 - - - a / m a i n . c + + + b / m a i n . c @ @ - 0 , 0 + 1 , 7 @ @ + # i n c l u d e < s t d i o . h > + + i n t m a i n ( v o i d ) + { + p r i n t f ( " \ n H e l l o W o r l d . \ n " ) ; + r e t u r n 0 ; + } $ g i t s t a s h s h o w s t a s h @ { 0 } m a i n . c | 7 + + + + + + + 1 f i l e s c h a n g e d , 7 i n s e r t i o n s ( + ) , 0 d e l e t i o n s ( - )
48. $ g i t s t a s h b r a n c h { n a m e } [ s t a s h @ { n } ] Trasladamos los cambios del estado n a la rama { n a m e } y borramos el estado de la pila. $ g i t s t a s h b r a n c h t e s t s t a s h @ { 0 } S w i t c h e d t o a n e w b r a n c h ' t e s t ' # O n b r a n c h t e s t # C h a n g e d b u t n o t u p d a t e d : # ( u s e " g i t a d d > f i l e > . . . " t o u p d a t e w h a t w i l l b e c o m m i t t e d ) # ( u s e " g i t c h e c k o u t - - > f i l e > . . . " t o d i s c a r d c h a n g e s i n w o r k i n g d i r e c t o r y ) # # m o d i f i e d : m a i n . c # n o c h a n g e s a d d e d t o c o m m i t ( u s e " g i t a d d " a n d / o r " g i t c o m m i t - a " ) D r o p p e d s t a s h @ { 0 } ( 4 a 1 f b 8 c 4 1 1 9 8 a 8 9 6 6 a 7 7 b 5 0 6 b 4 5 4 7 4 5 f b a a 2 5 8 7 e )
49. $ g i t s t a s h a p p l y [ s t a s h @ { n } ] Aplicamos los cambios de el estado n . $ g i t s t a s h a p p l y # O n b r a n c h d e v e l o p # C h a n g e d b u t n o t u p d a t e d : # ( u s e " g i t a d d > f i l e > . . . " t o u p d a t e w h a t w i l l b e c o m m i t t e d ) # ( u s e " g i t c h e c k o u t - - > f i l e > . . . " t o d i s c a r d c h a n g e s i n w o r k i n g d i r e c t o r y ) # # m o d i f i e d : m a i n . c # n o c h a n g e s a d d e d t o c o m m i t ( u s e " g i t a d d " a n d / o r " g i t c o m m i t - a " )
50. $ g i t s t a s h p o p [ s t a s h @ { n } ] Igual que $ g i t s t a s h a p p l y [ s t a s h @ { n } ] pero elimina el estado de la pila $ g i t s t a s h p o p s t a s h @ { 0 } # O n b r a n c h d e v e l o p # C h a n g e d b u t n o t u p d a t e d : # ( u s e " g i t a d d > f i l e > . . . " t o u p d a t e w h a t w i l l b e c o m m i t t e d ) # ( u s e " g i t c h e c k o u t - - > f i l e > . . . " t o d i s c a r d c h a n g e s i n w o r k i n g d i r e c t o r y ) # # m o d i f i e d : m a i n . c # n o c h a n g e s a d d e d t o c o m m i t ( u s e " g i t a d d " a n d / o r " g i t c o m m i t - a " ) D r o p p e d s t a s h @ { 0 } ( 4 a 1 f b 8 c 4 1 1 9 8 a 8 9 6 6 a 7 7 b 5 0 6 b 4 5 4 7 4 5 f b a a 2 5 8 7 e )
51. $ g i t s t a s h d r o p s t a s h @ { n } Elimina el estado n de la pila. $ g i t s t a s h d r o p s t a s h @ { 0 } D r o p p e d s t a s h @ { 0 } ( 4 a 1 f b 8 c 4 1 1 9 8 a 8 9 6 6 a 7 7 b 5 0 6 b 4 5 4 7 4 5 f b a a 2 5 8 7 e )
52. $ g i t s t a s h c l e a r Elimina toda la pila. $ g i t s t a s h c l e a r
53. t a g Los tags o etiquetas nos permiten marcar e identificar un punto en concreto de todo el histórico de nuestro repositorio. Normalmente se usan para identificar releases. Tag identificable $ g i t t a g v 0 . 1 b 5 4 7 e 8 4 Tag con comentarios $ g i t t a g - a v 0 . 1 - m " T h e f i r s t s t a b l e v e r s i o n " b 5 4 7 e 8 4 Tag firmado con PGP $ g i t t a g - s v 0 . 1 - m " T h e f i r s t s t a b l e v e r s i o n " b 5 4 7 e 8 4
54. $ g i t t a g [ - l { p a t t e r n } ] $ g i t t a g - l v 0 . * v 0 . 1 v 0 . 2 $ g i t s h o w v 0 . 1 t a g v 0 . 1 T a g g e r : J o h n D o e < j o h n @ d o e . c o m > D a t e : S a t O c t 1 5 1 8 : 0 0 : 0 0 2 0 1 1 + 0 2 0 0 T h e f i r s t s t a b l e v e r s i o n c o m m i t b 5 4 7 e 8 4 6 9 4 e a d d 4 5 9 6 7 c 3 5 0 4 c 1 2 b b 1 9 b d 1 9 c e 7 8 3 A u t h o r : J o h n D o e < j o h n @ d o e . c o m > D a t e : S a t O c t 1 5 1 8 : 0 0 : 0 0 2 0 1 1 + 0 2 0 0 A D D b a s i c m a i n d e c l a r a t i o n t o m a i n f i l e d i f f - - g i t a / m a i n . c b / m a i n . c i n d e x e 6 9 d e 2 9 . . 9 d 9 f 7 b e 1 0 0 6 4 4 - - - a / m a i n . c + + + b / m a i n . c @ @ - 0 , 0 + 1 , 7 @ @ + # i n c l u d e < s t d i o . h > + + i n t m a i n ( v o i d ) + { + p r i n t f ( " \ n H e l l o W o r l d . \ n " ) ; + r e t u r n 0 ; + }
55. b u n d l e Un b u n d l e es un paquete que contiene todo o parte de nuestro repositorio y es fácil de transportar y clonar. 1. $ g i t b u n d l e c r e a t e { n a m e } [ - - a l l | { t a g } | { b r a n c h } | { g i t _ d a t e _ f o r m a t } ] 2. $ g i t p u l l | c l o n e { n a m e } [ { b r a n c h } ]
56. p a t c h Un p a t c h es un fichero que contiene los cambios de uno o más commits para aplicarlos en un repositorio. 1. $ g i t f o r m a t - p a t c h [ { t a g } | { h a s h } ] [ - - s t d o u t > f i l e ] 2. $ g i t a p p l y - - s t a t { n a m e } F r o m 5 7 7 8 6 9 2 5 2 e b d 0 c 3 c 0 5 3 7 1 5 f e 7 0 2 e 0 6 1 b 8 4 4 1 a 6 a 3 M o n S e p 1 7 0 0 : 0 0 : 0 0 2 0 0 1 F r o m : J o h n D o e < j o h n @ d o e . c o m > D a t e : S a t , 1 5 O c t 2 0 1 1 1 8 : 0 0 : 0 0 + 0 2 0 0 S u b j e c t : [ P A T C H ] A D D m a i n d e c l a r a t i o n d o c u m e n t a t i o n - - - m a i n . c | 8 + + + + + + + + 1 f i l e s c h a n g e d , 8 i n s e r t i o n s ( + ) , 0 d e l e t i o n s ( - ) d i f f - - g i t a / m a i n . c b / m a i n . c i n d e x 9 d 9 f 7 b e . . 6 a f 0 1 7 0 1 0 0 6 4 4 - - - a / m a i n . c + + + b / m a i n . c @ @ - 1 , 5 + 1 , 1 3 @ @ # i n c l u d e < s t d i o . h > + / * * + * T h e m a i n d e c l a r a t i o n + * + * @ a u t h o r J o h n D o e < j o h n @ d o e . c o m > + * + * @ r e t u r n i n t + * + * * / i n t m a i n ( v o i d ) { p r i n t f ( " \ n H e l l o W o r l d . \ n " ) ; }
57. b l a m e b l a m e nos permite ver por cada línea de código quién ha sido el autor o el último en modificar ésta. Se acabaron echar las culpas a otro. $ g i t b l a m e m a i n . c ^ c a f f 1 d 7 ( A l e j a n d r o E l I n f o r m á t i c o 2 0 1 2 - 0 9 - 2 7 0 0 : 0 0 : 0 0 + 0 2 0 0 1 ) # i n c l u d e < s t d i o . h > ^ c a f f 1 d 7 ( A l e j a n d r o E l I n f o r m á t i c o 2 0 1 2 - 0 9 - 2 7 0 0 : 0 0 : 0 0 + 0 2 0 0 2 ) ^ c a f f 1 d 7 ( J o h n D o e 2 0 1 2 - 0 9 - 2 6 0 0 : 0 0 : 0 0 + 0 2 0 0 3 ) i n t m a i n ( v o i d ) ^ c a f f 1 d 7 ( J o h n D o e 2 0 1 2 - 0 9 - 2 6 0 0 : 0 0 : 0 0 + 0 2 0 0 4 ) { b c f b 7 b 1 c ( J o h n D o e 2 0 1 2 - 0 9 - 2 5 0 0 : 0 0 : 0 0 + 0 2 0 0 5 ) p r i n t f ( " \ n ' H e l l o W o r l d ' i s j u s t a n e x a m . . . ^ c a f f 1 d 7 ( J o h n D o e 2 0 1 2 - 0 9 - 2 5 0 0 : 0 0 : 0 0 + 0 2 0 0 6 ) r e t u r n 0 ; ^ c a f f 1 d 7 ( A l e j a n d r o E l I n f o r m á t i c o 2 0 1 2 - 0 9 - 2 7 0 0 : 0 0 : 0 0 + 0 2 0 0 7 ) }
58. s u b m o d u l e Nos permite tener un repositorio g i t dentro de un otro repositorio, por ejemplo un proyecto principal para el cual se desarrollan plugins. Una nota importante sobre s u b m o d u l e es que estos no se mantienen sincronizados automáticamente, lo hemos de hacer manualmente y para cada cambio que se haga en el s u b m o d u l e hemos de hacer un commit en nuestro repositorio principal.
59. s u b m o d u l e II Añadir un s u b m o d u l e . $ g i t s u b m o d u l e a d d s s h : / / s e r v e r / p a t h / t o / r e p o { d e s t i n a t i o n } I n i t i a l i z e d e m p t y G i t r e p o s i t o r y i n / p a t h / t o / r e p o / { d e s t i n a t i o n } [ . . . ] $ g i t s t # O n b r a n c h d e v e l o p # C h a n g e s t o b e c o m m i t t e d : # ( u s e " g i t r e s e t H E A D < f i l e > . . . " t o u n s t a g e ) # # n e w f i l e : . g i t m o d u l e s # n e w f i l e : { d e s t i n a t i o n } #
60. s u b m o d u l e III Cuando hacemos un clon de un repositorio que tiene asociado uno o más s u b m o d u l e , estos no estarán inicializados por lo tanto hemos de: 1. $ g i t s u b m o d u l e i n i t 2. $ g i t s u b m o d u l e u p d a t e
61. r e b a s e Nos permite modificar el historial para combinar diferentes commits o reordenarlos. Por ejemplo: Podemos obtener: NOTA: no debemos usar r e b a s e en commits que ya hayan sido publicados. E - - - F - - - G f o o / b a r / A - - - B - - - C - - - D m a s t e r A - - - B - - - C - - - D - - - E - - - F m a s t e r
62. c h e r r y - p i c k Nos permite mover commits a lo largo del historial o entre diferentes ramas. Un uso común es mover algún commit de una rama a otra para poder continuar el desarrollo. Podemos obtener: E - - - F - - - G f o o / b a r / A - - - B - - - C - - - D m a s t e r E - - - F - - - G f o o / b a r / A - - - B - - - C - - - D - - - F ' m a s t e r
63. HOOKS Los hooks son scripts que se ejecutan cuando hay un determinado evento. Estos scripts es encuentran en el directorio . g i t / h o o k s de nuestro repositorio. podemos agrupar los hooks en: 1. Hooks del lado del cliente 2. Hooks del lado del servidor
64. HOOKS DEL LADO DEL CLIENTE Son únicamente del cliente, por lo tanto ninguna persona los puede modificar ni se transfieren en un clon, p u s h o p u l l . p r e - c o m m i t Se ejecuta antes de escribir el mensaje de commit. Líneas finales, lint... p r e p a r e - c o m m i t - m s g Se ejecuta antes del editor del mensaje y después del mensaje por defecto del commit. Podemos editar el mensaje por defecto c o m m i t - m s g Se ejecuta antes de guardar el mensaje. Nos permite verificar las directrices de los mensajes p o s t - c o m m i t Se ejecuta una vez acabado todo el proceso del commit. Normalmente para notificaciones
65. HOOKS DEL LADO DEL CLIENTE II a p p l y p a t c h - m s g Verificar las directrices de los mensajes p r e - a p p l y p a t c h Se ejecuta antes de aplicar un p a t c h p o s t - a p p l y p a t c h Se ejecuta después de aplicar el p a t c h
66. HOOKS DEL LADO DEL CLIENTE III otros hooks p r e - r e b a s e Se ejecuta antes de hacer r e b a s e . Evitar r e b a s e en commits que han estado subidos p o s t - c h e c k o u t Se ejecuta después de hacer c h e c k o u t . Para inicializar el working directory, compilar, documentación... p o s t - m e r g e Se ejecuta después de aplicar un m e r g e correctamente. Cambiar permisos, copiar ficheros...
67. HOOKS DEL LADO DEL SERVIDOR Se ejecutan en el servidor antes y después de hacer p u s h . p r e - r e c e i v e Se ejecuta antes de hacer p u s h . Normalmente para controlar permisos p o s t - r e c e i v e Se ejecuta una vez acabado el proceso de p u s h . Notificaciones, parsear el mensaje de commit y cerrar tickets... u p d a t e Igual que p r e - r e c e i v e pero controla los ramas para separado
68. http[s] git protocol s s h p a t c h TRABAJANDO EN REMOTO Cuando trabajamos en remoto hacemos p u s h a un repositorio de tipo b a r e cuando ya tenemos una posible versión final de nuestros cambios. Normalmente en local se trabaja en ramas y una vez acabado el trabajo hacemos m e r g e con nuestra rama master con tal de hacer p u s h desde ésta hacia a una rama de test o implementación que será revisada y después combinada con la rama master remota. Tenemos diferentes maneras de enviar los nuestros cambios:
69. VENTAJAS Acceso anónimo Fácil de configurar el repositorio en modo lectura Al tratarse de un protocolo muy usado, puede funcionar bajo cortafuegos corporativos INCONVENIENTES Muy ineficiente, genera mucho tráfico No hay control de credenciales TRABAJANDO EN REMOTO - HTTP[S] Pensado para repositorios de solo lectura, y en determinados casos en repositorios de escritura. g i t [ p u l l | p u s h ] h t t p [ s ] : / / s e r v i d o r / p a t h / t o / r e p o } [ { r a m a } ]
70. VENTAJAS Muy rápido No se necesitan credenciales para leer INCONVENIENTES Se necesita configurar un daemon g i t Difícil de configurar No hay autenticación, por tanto no hay control de acceso Puerto no estándar, 9418 TRABAJANDO EN REMOTO - GIT PROTOCOL Idealmente el git protocol está pensado para tener repositorios read­only, ya que no hay control de usuarios y permisos. g i t [ p u l l | p u s h ] g i t : / / { s e r v i d o r } / p a t h / t o / r e p o . g i t [ { b r a n c h } ]
71. VENTAJAS Cifrado Lee los parámetros de conexión desde ~/.ssh/config Únicamente necesita la configuración del s s h Control específico para cada usuario, mediante hooks INCONVENIENTES No hay acceso anónimo/público Sin configuración de acceso por repositorio, cualquier usuario puede hacer cambios en cualquier repositorio El usuario ha de tener un cuenta s s h en el servidor Vulnerabilidades del servicio Violaciones de políticas de seguridad TRABAJANDO EN REMOTO - s s h Podemos hacer p u l l o p u s h mediante el protocolo s s h . g i t [ p u l l | p u s h ] s s h : / / { [ u s u a r i o @ ] s e r v i d o r / p a t h / t o / r e p o } [ { r a m a } ]
72. TRABAJANDO EN REMOTO - GIT REMOTE Podemos guardar alias para los servidores que usamos, con el fin de facilitar nuestra gestión. $ g i t r e m o t e a d d { n a m e } s s h : / / s e r v e r / p a t h / t o / r e p o A partir de este momento podemos hacer: $ g i t p u s h { n a m e } { b r a n c h } Al clonar g i t automáticamente crea el remote origin, que es aquel destino desde el que nos hemos clonado el repositorio.
73. g i t nos permite crear un visualizador web de nuestro repositorio, normalmente para acceso local o de red local pero también puede servir de acceso público si se configura junto con nuestro servidor web. Nos permite ver los commits, d i f f , l o g , b r a n c h , t a g ... en nuestro navegador web. http://git.kernel.org GITWEB $ g i t i n s t a w e b [ - - h t t p d = l i g h t t p d | a p a c h e 2 | w e b r i c k ] [ - - s t o p ]
74. Un único usuario s s h Llave única por cliente Permisos específicos por usuario, grupo, b r a n c h , t a g y repositorio Alias para el path de cada repositorio Gitosis https://github.com/res0nat0r/gitosis Gitolite https://github.com/sitaramc/gitolite GITOSIS / GITOLITE Son un conjunto de scripts que nos permiten tener un control exhaustivo de los usuarios y sus permisos para cada repositorio.
75. Es un hosting de repositorios g i t gratuito centrado principalmente con el desarrollo Open Source, pero con características Premium. Muy extendido en la red Una gran de comunidad de desarrolladores detrás Se puede colaborar fácilmente con otros proyectos, Fork y Pull request Wiki, Issue tracking system Colaboradores, organizaciones Seguir continuamente los cambios de los proyectos Mejorar nuestro CV Se integra con muchos gestores de tareas o proyectos https://github.com/ @ainformatico GITHUB
76. Hosting de repositorios mercurial pero desde el 3 de octubre de 2011 proporciona soporte para g i t . Proporciona repositorios privados ilimitados Todavía poco conocido en el mundo git, pero contiene muchos proyectos importantes Wiki, Issue tracking system Fork y Pull request Dominios propios Colaboradores, organizaciones Se integra con otras herramientas de Atlassian https://bitbucket.org/ @ainformatico BITBUCKET
77. EL SIGUIENTE PASO Convertir h g a g i t , http://bit.ly/33872n Convertir s v n a g i t , http://bit.ly/qa7c0B Sistema de tickets distribuidos, https://github.com/jeffWelling/ticgit Más información, http://bit.ly/2V6CFi $ g i t i n i t n e w - p r o j e c t
78. LINKS ALEJANDRO EL INFORMÁTICO(@AINFORMATICO), HTTP://ALEJANDROELINFORMATICO.COM/SLIDESHOWS/ http://git­scm.com/ http://schacon.github.com/git/gittutorial.html http://progit.org/book/