GIT COMO NUNCA TE LO EXPLICARON: Qué es GIT y como usar un sistema de control de versiones.
Summary
TLDRLa parábola de Git es una narrativa hipotética que ilustra cómo diseñar un sistema de control de versiones. La historia comienza con la idea de tomar 'fotos instantáneas' o snapshots del código, lo que permite volver a versiones anteriores fácilmente. A medida que se desarrolla, se introducen conceptos clave como los directorios de trabajo, snapshots con nombres identificativos y el uso de mensajes para describir cambios. La historia evoluciona para abordar la necesidad de rastrear múltiples líneas de desarrollo, lo que lleva a la creación de un historial de código en forma de árbol. Se exploran soluciones para problemas de colaboración y se destaca la importancia de la identificación única de snapshots mediante hashes SHA1. Finalmente, se introduce el directorio staging para una mejor gestión de cambios y se compara el sistema resultante con Git, destacando las herramientas adicionales que ofrece Git para gestionar situaciones complejas. Este resumen ofrece una visión general del proceso creativo y los fundamentos de un sistema de control de versiones como Git.
Takeaways
- 💡 La idea de un sistema de control de versiones surge al necesitar un método confiable para hacer seguimiento de las versiones del software y poder volver a versiones anteriores fácilmente.
- 📸 La metáfora de las fotos instantáneas o 'snapshots' en inglés, se utiliza para ilustrar cómo tomar 'fotos' de un estado del código en un momento dado y poder regresar a ellas cuando sea necesario.
- 📁 Se crea un directorio llamado 'working' para trabajar en el desarrollo del software y se realizan copias completas de este directorio llamadas 'snapshots' cada vez que se completa una funcionalidad.
- 🗒️ Se introduce un archivo especial llamado 'mensaje' dentro de cada snapshot que contiene un resumen de los cambios y la fecha de creación, facilitando la identificación y búsqueda de versiones específicas.
- 🌟 La versión 1.0 del software se despliega y es bien recibida por los usuarios, lo que motiva a desarrollar nuevas versiones y mejoras.
- 🔄 Se enfrenta el problema de tener que crear un snapshot que no sea una continuación directa de la última versión, lo que lleva a la idea de ramificaciones o 'branches' en el desarrollo.
- 🌿 Al caminar en la naturaleza y observar el patrón de las ramas de un árbol, se inspira la idea de modelar el historial del código como un árbol con múltiples ramas para manejar diferentes líneas de desarrollo.
- 🔗 Se implementa un nuevo campo en el archivo 'mensaje' de cada snapshot que indica su padre, permitiendo realizar un seguimiento de la historia completa de cada snapshot hasta la rama principal.
- 🔄 Se crea un archivo llamado 'branch' que almacena la información de las ramas y sus últimas snapshots, facilitando la navegación entre diferentes ramas de desarrollo.
- 👥 Se introduce la colaboración en equipo, lo que requiere adaptar el sistema de control de versiones para permitir la identificación de quién es el autor de cada snapshot y la creación de nombres únicos para evitar conflictos.
- 🔧 Se implementa un directorio de 'staging' que actúa como un intermediario entre el directorio de trabajo y el snapshot, permitiendo una selección más precisa de qué cambios incluir en el siguiente snapshot.
Q & A
¿Qué problema específico resuelve la idea del nuevo software que el usuario imagina en el script?
-El nuevo software resuelve el problema de hacer un seguimiento confiable de todas las versiones del sistema de archivos, permitiendo volver fácilmente a una versión anterior en la que se hayan modificado o eliminado elementos.
¿Cómo se llama la solución que el usuario imagina para su problema de control de versiones?
-La solución que el usuario imagina se llama 'snapshots', que son copias instantáneas del código en puntos específicos del tiempo.
¿Qué es un 'snapshot' en el contexto del script?
-Un 'snapshot' es una copia del directorio working completo que se toma cuando se completa una funcionalidad, y que luego se nombra para su identificación futura.
¿Por qué decide el usuario agregar un archivo especial llamado 'mensaje' a sus snapshots?
-Decide agregar un archivo especial llamado 'mensaje' para incluir un resumen de los cambios contenidos en el snapshot y la fecha en la que se completaron, lo que facilita la identificación y búsqueda de cambios específicos en el pasado.
¿Cómo se resuelve el problema de identificación de snapshots creciendo en número?
-Se resuelve agregando un archivo llamado 'mensaje' que contiene información adicional como un resumen de los cambios y la fecha, y posteriormente se utiliza un hash SHA1 único para identificar cada snapshot.
¿Cómo se representa la estructura del historial de código después de la implementación de la solución snapshots?
-El historial de código se representa como un árbol, donde cada snapshot es un nodo y los padres de cada nodo son los snapshots anteriores desde los cuales se derivó.
¿Qué es una 'branch' en el contexto del script?
-Una 'branch' es una rama de desarrollo en el historial del código que permite trabajar en paralelo en diferentes funcionalidades o cambios sin afectar la rama principal.
¿Cómo se resuelve el problema de la identificación de quién es el autor de cada snapshot?
-Se resuelve agregando el nombre y el apellido del autor en el archivo 'mensaje' de cada snapshot, lo que permite identificar claramente a quién corresponde cada snapshot.
¿Por qué deciden utilizar SHA1 para nombrar las snapshots?
-Deciden utilizar SHA1 para asegurar que el nombre de cada snapshot sea único y para eliminar cualquier confusión, ya que un hash SHA1 es único para cada contenido del archivo message.
¿Cómo se mejora el proceso de trabajo en equipo y combinación de cambios en el sistema de control de versiones?
-Se mejora creando un nuevo snapshot que incluye los cambios de ambas partes y tiene dos padres, apuntando a las últimas snapshots de cada uno de los colaboradores, lo que permite combinar cambios sin problemas.
¿Qué es el directorio 'staging' y cómo ayuda a organizar el proceso de creación de snapshots?
-El directorio 'staging' es un intermediario entre el directorio de trabajo y el snapshot, donde se pueden decidir qué cambios incluirán en el siguiente snapshot, facilitando la especificación de los cambios que se quieren capturar.
¿Cómo garantiza Git que es difícil perder trabajo, incluso cuando se elimina una rama?
-Git garantiza que el trabajo no se pierde al eliminar una rama porque simplemente se elimina el puntero hacia el commit, pero las snapshots o commits siguen existiendo en el objeto del directorio; se puede recuperar utilizando el SHA1 del commit.
Outlines
🌱 Introducción al Control de Versiones
Este párrafo introduce la idea de un sistema de control de versiones, ilustrando el concepto con la analogía de tomar fotos instantáneas (snapshots) de un proyecto en desarrollo. Describe cómo, al principio, el proceso es lineal y cómo el desarrollador decide tomar 'fotos' de su código en momentos clave para poder regresar a versiones anteriores si es necesario. Se destaca la importancia de tener un registro confiable de las versiones del software y cómo esto puede ser útil para el desarrollo y la depuración.
🔄 Desarrollo y Problemas del Control de Versiones
El párrafo 2 aborda los desafíos que surgen al manejar múltiples versiones de un software en desarrollo. Se describe cómo, después de la entrega de una versión, los usuarios informan de bugs que necesitan ser solucionados rápidamente. Esto lleva al desarrollador a enfrentarse a la necesidad de crear una nueva versión (snapshot) que no sea una continuación directa de la última versión, lo que complica el seguimiento de las mismas. La historia utiliza la analogía de un árbol para explicar cómo manejar múltiples ramas de desarrollo y cómo el historial de código puede ser visualizado como tal.
🤝 Colaboración y Desarrollo en Equipo
Este segmento explora cómo el control de versiones puede ser una herramienta valiosa para el trabajo en equipo. Se presenta la situación hipotética de un colaborador que, después de recibir una copia del historial de snapshots y ramas, viaja y trabaja en una rama separada. Se discuten los problemas que surgen cuando dos desarrolladores trabajan en la misma rama sin conexión y cómo se resuelven mediante la creación de nombres de snapshots únicos y la actualización del historial de manera colaborativa.
🔍 Refinando el Proceso de Control de Versiones
El cuarto párrafo profundiza en la mejora del proceso de control de versiones. Se destaca la necesidad de un directorio de 'stage' que actúe como un intermediario entre el directorio de trabajo y los snapshots finales. Esto permite al desarrollador decidir qué cambios incluirán en la siguiente versión. Además, se introduce el concepto de 'merge' para combinar cambios de diferentes ramas y se compara el sistema descrito con Git, destacando las herramientas adicionales que ofrece Git para manejar situaciones complejas.
Mindmap
Keywords
💡Control de versiones
💡Snapshot
💡Branch
💡Merge
💡SHA1
💡Working Directory
💡Staging Area
💡Commit
💡Master Branch
💡Push
💡Pull
Highlights
Imagina una computadora con solo un editor de texto y un sistema de archivos, donde se necesita un sistema de control de versiones.
La idea de usar 'snapshots' o fotos instantáneas del código para rastrear versiones.
Cada snapshot se identifica con un nombre y un archivo especial llamado 'mensaje' que incluye un resumen de los cambios y la fecha.
La creación de un directorio 'snapshot 99' que se convierte en la primera versión desplegada (release versión 1.0).
El desafío de rastrear snapshots cuando el desarrollo no es lineal y se necesitan múltiples líneas de desarrollo.
La inspiración de la estructura de un árbol para manejar múltiples ramas en el historial de desarrollo del código.
La adición de un nuevo campo en el archivo 'mensaje' de cada snapshot que indica su padre, permitiendo un seguimiento lineal.
El uso de nombres representativos en lugar de números secuenciales para las ramas de desarrollo.
La creación del archivo 'branch' en la raíz del directorio para almacenar la información de las ramas y sus últimos snapshots.
La colaboración en equipo y el problema de nombres de snapshots duplicados cuando trabajan varios desarrolladores.
La solución de incluir el autor del snapshot en el archivo 'mensaje' y el uso de un hash SHA1 único para nombrar snapshots.
La representación gráfica del historial de código como un árbol con 'master' como la rama principal y otras ramas derivadas.
La creación de una nueva 'branch' llamada 'más' para desarrollar nuevas funcionalidades.
El concepto de 'staging' o área de preparación para decidir qué cambios incluirán en el siguiente snapshot.
La necesidad de un proceso de 'merge' para combinar cambios de diferentes ramas o desarrolladores.
La eficiencia del sistema de control de versiones construido, comparado con Git, y su capacidad para manejar herramientas de línea de comandos.
La seguridad de los datos en Git, donde incluso al eliminar una rama, los datos de los commits siguen estando almacenados y pueden ser recuperados.
Transcripts
00:00[Música]
00:04imagina que tienes una computadora que
00:07tiene solamente un editor de texto y un
00:09sistema de archivos
00:11ahora imagina que has tenido una idea
00:14que resuelve un problema específico y
00:16has decidido escribir un nuevo software
00:18utilizando el sistema que tienes en tu
00:20computadora sabes que este nuevo
00:22software tendrá un tamaño considerable
00:25por lo que necesitas una manera
00:27confiable de hacer un seguimiento de
00:29todas las versiones del sistema de forma
00:31tal que puedas volver fácilmente a una
00:34versión anterior en la cual has
00:35modificado o eliminado algo
00:38en otras palabras necesitas un sistema
00:41de control de versiones o en inglés
00:43versión control system imagina por un
00:46segundo que esto todavía no existe y te
00:48decides a intentarlo
00:50lo que sigue es la parábola de git o la
00:53historia hipotética de cómo diseñar y
00:55'las este sistema de control de
00:57versiones qué decisiones deberías tomar
00:59y por qué las tomaría esta parábola te
01:02ayudará a entender git de una manera
01:04orgánica sin entrar para nada en los
01:07comandos ni en los recursos prácticos
01:09inicialmente desarrollada por tom pérez
01:12tom werner que ahora adaptada por mí
01:14para ustedes en este curso la parábola
01:17de git forma parte de mi curso de git
01:19que puedes encontrar en la descripción
01:21de este vídeo
01:23tu amigo alfred trabaja como fotógrafo
01:26en una casa de fotografía y se dedica a
01:28sacar las famosas fotos de estudio en
01:30donde las familias van a un estudio de
01:32fotografía en determinados eventos
01:33especiales y todos juntos posan delante
01:36de una pantalla verde que luego se
01:38transformará en un bosque una playa o
01:40cualquier otro fondo al frente cuenta la
01:42historia de una mujer que trae a su hija
01:44todos los años en el mismo día para
01:47hacerle un portarretrato y ya trae todas
01:50las fotos de todos los años pasados dice
01:52alfred porque le gusta recordar cómo era
01:54su hija en cada etapa de la vida
01:57cada foto instantánea realmente le
01:59dejara viajar en el tiempo hacia esos
02:01recuerdos almacenados
02:02las palabras de alfred suenan perfectas
02:06para resolver el dilema de tu sistema de
02:08control de versiones fotos instantáneas
02:10o snapshots en inglés como si fueran los
02:13puntos de guardado de un videojuego son
02:15todo lo que te interesa cuando necesitas
02:17interactuar con tu sistema de control de
02:19versiones entonces piensas qué pasaría
02:22si pudiera tomar fotos instantáneas
02:24snapshots de tu código en cualquier
02:27momento y luego fueras capaz de leer y
02:30volver a esas fotos instantáneas siempre
02:32que lo necesites probablemente esa sería
02:35la solución perfecta a tu problema así
02:38que te decides implementarla así que
02:40empiezas tu proyecto en un nuevo
02:42directorio llamado working mientras
02:45escribes el código de tu nueva
02:46aplicación intentas ir despacio y
02:48escribir una funcionalidad a la vez
02:50cuando completan la primera
02:52funcionalidad te aseguras de que has
02:54guardado los cambios en todos los
02:56archivos y ese es una copia del
02:58directorio working completo
03:00a esta copia le pones un nombre que lo
03:02identifique snapshot 0 una vez que la
03:06copia ha finalizado te aseguras de no
03:08cambiar nunca más los archivos dentro de
03:10este nuevo directorio ya con la copia
03:12lista procede es a seguir trabajando en
03:14tu aplicación y agrega el próximo set de
03:16cambios hasta que completas una nueva
03:18funcionalidad entonces haces lo mismo
03:21copias el directorio working completo en
03:24un nuevo directorio que esta vez
03:26llamarás snapshot 1
03:28de ahora en más repite este mismo
03:31proceso para cada funcionalidad que va
03:33agregando creas una copia del directorio
03:35y le pones un nombre que luego puedes
03:37identificar fácilmente pero a medida que
03:40vas agregando más y más snapshots te das
03:42cuenta de que sólo con el nombre no es
03:44suficiente para identificarlas así que
03:46decides agregar un archivo especial en
03:49tus snapshots y las llamas mesas o
03:52mensaje este mensaje contiene un resumen
03:54de los cambios contenidos en este
03:57snapshot además de la fecha en la que
03:59los completaste al agregar este nuevo
04:01archivo llamado mensaje se vuelve mucho
04:03más sencillo encontrar un cambio
04:05específico que hiciste en el pasado en
04:07caso de que necesites volver a una
04:09versión anterior del código porque de un
04:11simple vistazo puedes leer el resumen de
04:13los cambios y la fecha en la que los
04:15completaste
04:17luego de un tiempo trabajando en el
04:18proyecto y creando snapshots comienza a
04:20aparecer una potencia el release después
04:24de muchas horas de código creas el
04:25directorio snapshot 99 que se convertirá
04:28luego en la primera versión a ser
04:30desplegada release versión 1.0 empaque
04:34estás de esta versión y de liberes al
04:36público para que empiecen a usarlo a los
04:38usuarios la primera versión de tu
04:40aplicación es tan bien aceptada por los
04:42usuarios que en el entusiasmo se sientas
04:44escribir más código para que las
04:46próximas versiones sean todavía más
04:48exitosas hasta ahora tu sistema de
04:50control de versiones ha funcionado bien
04:52puedes acceder fácilmente a versiones
04:54anteriores de tu código y además sabes
04:56exactamente qué hay en cada snapshot
04:58pero no mucho tiempo después de haber
05:00desplegado la release sucede lo que
05:02siempre sucede cuando entregas software
05:04tus usuarios comienzan a reportar
05:07algunos bugs nada grave todo se puede
05:10solucionar con unos cuantos fixes pero
05:12aquí te enfrentas a un dilema desde la
05:14release has creado 10 snapshots pero aún
05:17no has terminado de probarlas en
05:18profundidad por lo cual no puedes
05:20entregarla a los usuarios lo lógico
05:22sería arreglar los bugs directamente
05:25sobre el snapshot 99 que es la versión
05:27que tienen los usuarios así que decides
05:30hacer eso aplicar los cambios sobre
05:32snapshot 99 para esto copias snapshot 99
05:36a tu directorio de trabajo y sobre esa
05:39versión aplican los cambios que
05:40rápidamente solucionan los problemas que
05:43experimentaban los usuarios aquí es en
05:45donde el problema se vuelve aparente tu
05:47sistema de control de cambios funciona
05:49muy bien cuando el desarrollo es lineal
05:51porque puedes ir hacia adelante y hacia
05:53atrás entonces snapshots sin problemas
05:55pero ahora por primera vez necesitas
05:58crear un snapshot que no desciende
05:59directamente de tu última snapshot
06:01creada si llamas a tu nuevo snapshot 110
06:05entonces estaría rompiendo el proceso
06:07porque snapshot 110 no incluye los
06:10últimos 10 cambios que agregaste y
06:13además no desciende directamente
06:14snapshot 109 evidentemente necesitas un
06:18sistema un poco más eficiente para
06:21recargar energías y pensar en
06:22profundidad en este nuevo problema
06:24decides dejar la computadora y salir un
06:26poco a la naturaleza porque está
06:28comprobado que te ayuda a conectarte con
06:30tu versión más creativa una caminata por
06:33la montaña rápidamente te desconecta de
06:35tu preocupación y te quedas mirando un
06:37árbol gigante del costado del camino
06:39está bien adentrado el otoño por lo que
06:42el árbol no tiene casi hojas y deja al
06:44descubierto un complejo entramado de
06:46ramas que te hipnotiza en un largo rato
06:48te detienes en una de las miles de ramas
06:51y casi como un juego te propones a
06:53seguir la traza de la rama desde el
06:55extremo más alejado del tronco en donde
06:58luego crecerán las hojas por todo su
07:00camino de vuelta al tronco entonces
07:02descubres que lo que en principio
07:03parecía complicado ahora resulta muy
07:06sencillo y natural la rama por más
07:09complejo que su patrón sea sigue una
07:11línea clara y directa hasta el tronco es
07:14ahí cuando entiendes que esta es la idea
07:16perfecta este patrón de ramas soporta
07:20gran complejidad pero a la vez permite
07:22que el camino de vuelta al tronco sea
07:24sencillo por lo que es perfecto para
07:27hacer un seguimiento de múltiples líneas
07:29de desarrollo tal cual el que necesitas
07:32si miras la historia de tu código como
07:34un árbol resolver el problema del
07:36ancestro de cada snapshot se vuelve
07:38trivial todo lo que necesitas hacer es
07:40agregar un nuevo campo en el archivo
07:43mensaje de cada snapshot indicando cuál
07:45es su padre agregar este puntero te
07:48permite realizar un seguimiento simple y
07:50efectivo de la historia completa de cada
07:53una de tus snapshots todo el camino
07:55hasta el tronco o la rama principal por
07:58lo cual el historial de tu código ahora
08:00es un árbol y en lugar de tener una
08:03única snapshot como la última snapshot
08:05ahora tienes dos una por cada branch
08:08cuando el sistema de control de
08:09versiones era lineal el sistema de
08:12numeración secuencial que usabas tenía
08:14sentido porque rápidamente podías
08:16identificar cuál era la última versión
08:18de tu código pero esa habilidad ahora
08:20está perdida así que comienzas a nombrar
08:23más con nombres representativos
08:27crear nuevas ramas de desarrollo se ha
08:29vuelto tan sencillo que de pronto
08:31sientes la necesidad de hacerlo todo el
08:33tiempo así que creas ramas o en inglés
08:35branch es para todo para arreglar un bar
08:39para hacer experimentos que quizás nunca
08:40salgan a la luz para nuevas
08:42funcionalidades que quieres agregar a la
08:44aplicación etcétera pero con esto
08:46aparece un nuevo problema cada vez que
08:48creas un snapshot debes recordar que
08:51este snapshot es la última en su propia
08:53rama sin esta información ir moviéndote
08:56entre ramas se vuelve un proceso
08:58complicado porque no solo tienes que
08:59recordar el nombre de la rama y lo que
09:01contiene sino que también tienes que
09:03recordar cuál es su última estancia
09:05entonces te decides a crear un nuevo
09:07archivo en la raíz de tu directorio por
09:10fuera de todas tus snapshots y llamas a
09:12este archivo branch es en este archivo
09:15branch es almacenar una lista con los
09:18pares nombre de la branch y último
09:20snapshot porque esta es la menor
09:22cantidad de información necesaria para
09:24identificar una branch
09:26si necesitas conocer la lista de
09:28snapshots que componen una branch sabes
09:30que puedes hacerlo fácilmente porque
09:32cada snapshot tiene puntero acceso
09:35snapshot predecesora con este agregado
09:37ahora para moverte entre ramas solo
09:40tienes que buscar el nombre de la rama a
09:41la que quieres acceder y allí mismo
09:43encontrarás su último snapshot claro que
09:47esto significa que cada vez que crees
09:49una nueva snapshot dentro de una rama
09:50tienes que actualizar el nombre de la
09:52última estación un pequeño precio que
09:55pagar por un gran beneficio pero como
09:58bien sabes el desarrollo de software es
10:00un trabajo cooperativo trabajar en
10:02soledad pronto se vuelve aburrido y
10:05piensas en invitar a alguien a trabajar
10:06en tu proyecto por suerte su amiga show
10:09tiene un setup padecido el tuyo y tiene
10:12ganas de ayudarte a construir esta
10:13aplicación además le entusiasma probar
10:16tu nuevo sistema de control de versiones
10:17y gracias a que has creado este sistema
10:20de versiones puedes enviar a xavi una
10:22copia completa de todo el historial de
10:24snapshots y ramas de tu aplicación tener
10:27a xavi en tu equipo es genial pero ella
10:30tiene el hábito de salir de viaje
10:31seguido a lugares que no tienen mucho
10:33acceso a internet
10:35así que en cuanto tiene el historial de
10:37snapshots en su computadora toma un
10:39vuelo directo a la patagonia y no sabrás
10:42nada de ella por un par de semanas en
10:44estas semanas en las que su vista de
10:46viaje los dos escriben mucho código cada
10:49uno en su entorno y cuando ella
10:50finalmente vuelve descubres que hay una
10:53falla crítica en tu sistema de control
10:55de versiones porque los dos utilizan el
10:57mismo sistema de números para nombrar
10:59snapshots los dos ahora tienen
11:01directorios llamados 113 y 114
11:05solo que estos directorios son
11:07obviamente distintos entre sí además ni
11:10siquiera tienes una manera de
11:12identificar quién es el autor de cada
11:13snapshot pero como todo en la industria
11:16del software el proceso es interactivo
11:18así que te sientas con sobisch y los dos
11:20juntos piensan en una posible solución
11:22para estos problemas
11:23primero que nada hay que hacer un
11:26pequeño ajuste en el archivo mensaje y
11:28agregar ahora el autor del snapshot en
11:31la forma nombre y medio además de la
11:34información que ya almacenamos antes
11:36con ese cambio en el archivo mensaje
11:38ahora al menos podemos identificar con
11:41claridad a quién corresponde cada
11:43snapshot el segundo cambio que necesitas
11:45hacer es alrededor del nombre de las
11:47estampas ya no pueden ser nombradas
11:50utilizando números secuenciales sino que
11:52debes asegurarte de que el nombre de
11:54cada snapshot es único para eliminar
11:57toda confusión para esto decides crear
11:59un hash a partir del contenido del
12:01archivo message un hash te garantiza que
12:04será único para cada snapshot porque
12:06nunca tendrás dos snapshots con la misma
12:09fecha autor samari y parent snapshot
12:12para asegurarte de que el hash se cree
12:14exitosamente ambos concuerdan en
12:16utilizar sha1 que es un algoritmo que
12:20toma el contenido de un archivo y a
12:22partir de ese contenido produce una
12:24cadena de 40 caracteres hexadecimal es
12:27tanto tú como zoey actualizan su
12:30historial con esta técnica y ahora en
12:32lugar de tener dos directorios llamados
12:34113 y 114 tienen dos directorios con dos
12:38nombres completamente distintos
12:40ahora que los nombres de las snapshots
12:43han sido actualizados se vuelve más
12:45sencillo para ti traer las snapshots de
12:47show y ubicarlas junto a tus propios
12:49snapshots y porque cada snapshot
12:52especifica su par en el historial del
12:54código de tu aplicación sigue siendo un
12:56árbol solo que el árbol ahora también
12:58incluye snapshots de show
13:01en resumen ahora cada snapshot es
13:04identificada gracias a un hash sha1
13:07único y además incluye un puntero a su
13:10parent snapshot que también se
13:12identifica con un sha1 estos snapshots
13:15pueden ser creadas y trasladadas de
13:17computadora a computadora sin perder en
13:20absoluto su identidad oa quién
13:22pertenecen dentro del historial del
13:24árbol de la aplicación incluso snapshots
13:26pueden ser compartidas o también pueden
13:28ser privadas es decir que se haya
13:30escrito una funcionalidad experimental
13:32que no está seguro de querer mostrar a
13:34otros todavía simplemente no le hagas
13:37disponible y nadie más que tú podrá
13:38verla
13:39antes de seguir adelante vamos a cambiar
13:42la representación del árbol por una más
13:44conveniente ahora cada snapshot es un
13:47punto del árbol y cada rama se
13:49representa como un conjunto de puntos a
13:52la rama principal la llamaremos master y
13:54a partir de ella se desprenden las otras
13:56ramas trabajar con show es genial así
14:00que creas una nueva branch llamada más
14:02para agregar una nueva funcionalidad a
14:05tu aplicación y le pides a xavi que te
14:07ayude a trabajar en esa rama show y se
14:10va de viaje a un lugar tan remoto que se
14:12queda sin conexión a internet durante
14:14todo el viaje y se ve obligada a
14:16trabajar en la nueva rama más
14:18completamente offline al mismo tiempo
14:21mientras hoy no está tú también realizas
14:24cambios en la rama más porque quieres
14:26agregar ciertas funciones genéricas que
14:28crees que pueden ser importantes en el
14:30futuro una vez que se ha vuelto de viaje
14:33te muestra los cambios que ya he hecho y
14:35se presenta una de las preguntas más
14:37comunes a la hora de trabajar en equipo
14:40cómo combinar los cambios que hizo xabi
14:42con los que hiciste tú aquí es en donde
14:44descubres que tu sistema de control de
14:47versiones necesita algún tipo de proceso
14:49para realizar un merge o para combinar
14:53ramas la estructura de árbol que has
14:55diseñado para tu sistema de control de
14:57versiones lo hace fácil sólo tienes que
15:00crear una nueva snapshot que incluye las
15:02modificaciones necesarias para integrar
15:04los cambios de xavi con los tuyos
15:06propios
15:07este snapshot será algo especial por
15:09primera vez tendrás dos padres es decir
15:12que en su archivo message apuntará a dos
15:14snapshots en lugar de a una por un lado
15:17apuntará a la última de los snapshots en
15:20las que tú trabajaste y por el otro a la
15:22última vez snapshots en la que soy
15:24trabajo en la rama más ahora esta nueva
15:27snapshot que combina los cambios se ha
15:29convertido en la snap show más reciente
15:31de la rama más y has definido un proceso
15:33que te permite trabajar en equipo
15:35offline y luego combinar los cambios sin
15:38problemas
15:40el próximo lugar en donde descubres que
15:42todavía hay espacio para mejorar el
15:44proceso es en tu directorio de trabajo
15:46también conocido como working director y
15:49por mucho que tratas de que todas las
15:51modificaciones que haces a una
15:53funcionalidad estén 100% relacionadas
15:56con esta funcionalidad muchas veces te
15:58pasa que terminas haciendo otros cambios
16:00en lugares no directamente relacionados
16:02con esa funcionalidad y que tienen que
16:04ver más con otra entonces te das cuenta
16:07de que tu working director y ahora
16:09contiene lo que realmente deberían ser
16:11dos snapshots separadas en lugar de una
16:14aquí es en donde surge el concepto de
16:16staying de director y este directorio
16:20funciona como un paso intermedio entre
16:22tu directorio de trabajo y tu snapshot
16:25ahora cada vez que terminas de crear
16:27editar o eliminar un archivo puedes
16:30decidir si quieres que ese cambio forme
16:32parte de tu siguiente snapshot o no
16:34cuando si quieres que forme parte de tu
16:36próxima snapshot simplemente lo copias
16:39al directorio de stage y si no quieres
16:41que forme parte lo dejas en el
16:43directorio de trabajo
16:45esta nueva separación hace fácil
16:47especificar que está incluido y que no
16:50está incluido en la próxima snapshot ya
16:52no tienes que preocuparte por
16:53potenciales accidentes que terminen en
16:55tu snapshot porque ahora debes
16:57manualmente elegir qué cosas formarán
16:59parte de esa es nacho tu próxima
17:02snapshot será entonces creada a partir
17:04del directorio staging el sistema de
17:07control de versiones que has construido
17:08hasta aquí se parece mucho a git la gran
17:11diferencia es que git proporciona una
17:13gran variedad de herramientas de línea
17:14de comandos para manejar situaciones
17:16como las que hemos visto además de
17:18muchas otras lo que hasta aquí hemos
17:20llamado snapshot en git se conoce por el
17:23término commit a medida que estudia hits
17:26a lo largo de este curso ten presente
17:28todo lo que hemos visto en esta parábola
17:29de git y te recomiendo que vuelvas a
17:31verla siempre que algún concepto no
17:33quede claro una última cosa antes de
17:36terminar recuerda que es muy difícil
17:38casi imposible perder nada de tu trabajo
17:41con git incluso cuando eliminas una rama
17:43lo que realmente sucede es que el
17:45puntero hacia este comité se elimina
17:48todas las snapshots están todavía en los
17:50objetos del directorio sólo necesitarás
17:53encontrar el sha1 del comit a lo largo
17:58del curso te voy a mostrar herramientas
17:59para resolver esta y muchas otras
18:02situaciones que te encontrarás
18:03trabajando con mid si este vídeo te
18:06gustó te invito que le dejes un like así
18:08llega a muchas más personas en general
18:10los programadores y las programadoras
18:12conocen git conocen los comandos y saben
18:15manejarse con los procedimientos básicos
18:17del control de versiones pero no
18:19entienden qué pasa de fondo y cuáles son
18:21los fundamentos de un sistema de control
18:23de versiones como git para ver contenido
18:26como éste y muchas otras cosas más te
18:28invito a que te suscribas al canal si
18:29todavía no lo hiciste déjame en
18:31comentarios qué te pareció este vídeo y
18:33que otra cosa quieres ver en este canal
18:35muchísimas gracias y nos vemos la
18:38próxima
18:39[Música]
Посмотреть больше похожих видео
¿Por qué Facebook NO UTILIZA Git?
Las 8 mejores extensiones para potenciar tu experiencia en Visual Studio Code
Flet Curso: 3 Microsoft Visual Studio Code Como Editor de Código Oficial para Serie de Aprendizaje
🔴Elementos y Etapas de la Comunicación[2024]✅
La Teoria Cinetico Molecular y los cambios de estado
7 herramientas que se utilizan en el desarrollo de software
5.0 / 5 (0 votes)
