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
[Música]
imagina que tienes una computadora que
tiene solamente un editor de texto y un
sistema de archivos
ahora imagina que has tenido una idea
que resuelve un problema específico y
has decidido escribir un nuevo software
utilizando el sistema que tienes en tu
computadora sabes que este nuevo
software tendrá un tamaño considerable
por lo que necesitas una manera
confiable de hacer un seguimiento de
todas las versiones del sistema de forma
tal que puedas volver fácilmente a una
versión anterior en la cual has
modificado o eliminado algo
en otras palabras necesitas un sistema
de control de versiones o en inglés
versión control system imagina por un
segundo que esto todavía no existe y te
decides a intentarlo
lo que sigue es la parábola de git o la
historia hipotética de cómo diseñar y
'las este sistema de control de
versiones qué decisiones deberías tomar
y por qué las tomaría esta parábola te
ayudará a entender git de una manera
orgánica sin entrar para nada en los
comandos ni en los recursos prácticos
inicialmente desarrollada por tom pérez
tom werner que ahora adaptada por mí
para ustedes en este curso la parábola
de git forma parte de mi curso de git
que puedes encontrar en la descripción
de este vídeo
tu amigo alfred trabaja como fotógrafo
en una casa de fotografía y se dedica a
sacar las famosas fotos de estudio en
donde las familias van a un estudio de
fotografía en determinados eventos
especiales y todos juntos posan delante
de una pantalla verde que luego se
transformará en un bosque una playa o
cualquier otro fondo al frente cuenta la
historia de una mujer que trae a su hija
todos los años en el mismo día para
hacerle un portarretrato y ya trae todas
las fotos de todos los años pasados dice
alfred porque le gusta recordar cómo era
su hija en cada etapa de la vida
cada foto instantánea realmente le
dejara viajar en el tiempo hacia esos
recuerdos almacenados
las palabras de alfred suenan perfectas
para resolver el dilema de tu sistema de
control de versiones fotos instantáneas
o snapshots en inglés como si fueran los
puntos de guardado de un videojuego son
todo lo que te interesa cuando necesitas
interactuar con tu sistema de control de
versiones entonces piensas qué pasaría
si pudiera tomar fotos instantáneas
snapshots de tu código en cualquier
momento y luego fueras capaz de leer y
volver a esas fotos instantáneas siempre
que lo necesites probablemente esa sería
la solución perfecta a tu problema así
que te decides implementarla así que
empiezas tu proyecto en un nuevo
directorio llamado working mientras
escribes el código de tu nueva
aplicación intentas ir despacio y
escribir una funcionalidad a la vez
cuando completan la primera
funcionalidad te aseguras de que has
guardado los cambios en todos los
archivos y ese es una copia del
directorio working completo
a esta copia le pones un nombre que lo
identifique snapshot 0 una vez que la
copia ha finalizado te aseguras de no
cambiar nunca más los archivos dentro de
este nuevo directorio ya con la copia
lista procede es a seguir trabajando en
tu aplicación y agrega el próximo set de
cambios hasta que completas una nueva
funcionalidad entonces haces lo mismo
copias el directorio working completo en
un nuevo directorio que esta vez
llamarás snapshot 1
de ahora en más repite este mismo
proceso para cada funcionalidad que va
agregando creas una copia del directorio
y le pones un nombre que luego puedes
identificar fácilmente pero a medida que
vas agregando más y más snapshots te das
cuenta de que sólo con el nombre no es
suficiente para identificarlas así que
decides agregar un archivo especial en
tus snapshots y las llamas mesas o
mensaje este mensaje contiene un resumen
de los cambios contenidos en este
snapshot además de la fecha en la que
los completaste al agregar este nuevo
archivo llamado mensaje se vuelve mucho
más sencillo encontrar un cambio
específico que hiciste en el pasado en
caso de que necesites volver a una
versión anterior del código porque de un
simple vistazo puedes leer el resumen de
los cambios y la fecha en la que los
completaste
luego de un tiempo trabajando en el
proyecto y creando snapshots comienza a
aparecer una potencia el release después
de muchas horas de código creas el
directorio snapshot 99 que se convertirá
luego en la primera versión a ser
desplegada release versión 1.0 empaque
estás de esta versión y de liberes al
público para que empiecen a usarlo a los
usuarios la primera versión de tu
aplicación es tan bien aceptada por los
usuarios que en el entusiasmo se sientas
escribir más código para que las
próximas versiones sean todavía más
exitosas hasta ahora tu sistema de
control de versiones ha funcionado bien
puedes acceder fácilmente a versiones
anteriores de tu código y además sabes
exactamente qué hay en cada snapshot
pero no mucho tiempo después de haber
desplegado la release sucede lo que
siempre sucede cuando entregas software
tus usuarios comienzan a reportar
algunos bugs nada grave todo se puede
solucionar con unos cuantos fixes pero
aquí te enfrentas a un dilema desde la
release has creado 10 snapshots pero aún
no has terminado de probarlas en
profundidad por lo cual no puedes
entregarla a los usuarios lo lógico
sería arreglar los bugs directamente
sobre el snapshot 99 que es la versión
que tienen los usuarios así que decides
hacer eso aplicar los cambios sobre
snapshot 99 para esto copias snapshot 99
a tu directorio de trabajo y sobre esa
versión aplican los cambios que
rápidamente solucionan los problemas que
experimentaban los usuarios aquí es en
donde el problema se vuelve aparente tu
sistema de control de cambios funciona
muy bien cuando el desarrollo es lineal
porque puedes ir hacia adelante y hacia
atrás entonces snapshots sin problemas
pero ahora por primera vez necesitas
crear un snapshot que no desciende
directamente de tu última snapshot
creada si llamas a tu nuevo snapshot 110
entonces estaría rompiendo el proceso
porque snapshot 110 no incluye los
últimos 10 cambios que agregaste y
además no desciende directamente
snapshot 109 evidentemente necesitas un
sistema un poco más eficiente para
recargar energías y pensar en
profundidad en este nuevo problema
decides dejar la computadora y salir un
poco a la naturaleza porque está
comprobado que te ayuda a conectarte con
tu versión más creativa una caminata por
la montaña rápidamente te desconecta de
tu preocupación y te quedas mirando un
árbol gigante del costado del camino
está bien adentrado el otoño por lo que
el árbol no tiene casi hojas y deja al
descubierto un complejo entramado de
ramas que te hipnotiza en un largo rato
te detienes en una de las miles de ramas
y casi como un juego te propones a
seguir la traza de la rama desde el
extremo más alejado del tronco en donde
luego crecerán las hojas por todo su
camino de vuelta al tronco entonces
descubres que lo que en principio
parecía complicado ahora resulta muy
sencillo y natural la rama por más
complejo que su patrón sea sigue una
línea clara y directa hasta el tronco es
ahí cuando entiendes que esta es la idea
perfecta este patrón de ramas soporta
gran complejidad pero a la vez permite
que el camino de vuelta al tronco sea
sencillo por lo que es perfecto para
hacer un seguimiento de múltiples líneas
de desarrollo tal cual el que necesitas
si miras la historia de tu código como
un árbol resolver el problema del
ancestro de cada snapshot se vuelve
trivial todo lo que necesitas hacer es
agregar un nuevo campo en el archivo
mensaje de cada snapshot indicando cuál
es su padre agregar este puntero te
permite realizar un seguimiento simple y
efectivo de la historia completa de cada
una de tus snapshots todo el camino
hasta el tronco o la rama principal por
lo cual el historial de tu código ahora
es un árbol y en lugar de tener una
única snapshot como la última snapshot
ahora tienes dos una por cada branch
cuando el sistema de control de
versiones era lineal el sistema de
numeración secuencial que usabas tenía
sentido porque rápidamente podías
identificar cuál era la última versión
de tu código pero esa habilidad ahora
está perdida así que comienzas a nombrar
más con nombres representativos
crear nuevas ramas de desarrollo se ha
vuelto tan sencillo que de pronto
sientes la necesidad de hacerlo todo el
tiempo así que creas ramas o en inglés
branch es para todo para arreglar un bar
para hacer experimentos que quizás nunca
salgan a la luz para nuevas
funcionalidades que quieres agregar a la
aplicación etcétera pero con esto
aparece un nuevo problema cada vez que
creas un snapshot debes recordar que
este snapshot es la última en su propia
rama sin esta información ir moviéndote
entre ramas se vuelve un proceso
complicado porque no solo tienes que
recordar el nombre de la rama y lo que
contiene sino que también tienes que
recordar cuál es su última estancia
entonces te decides a crear un nuevo
archivo en la raíz de tu directorio por
fuera de todas tus snapshots y llamas a
este archivo branch es en este archivo
branch es almacenar una lista con los
pares nombre de la branch y último
snapshot porque esta es la menor
cantidad de información necesaria para
identificar una branch
si necesitas conocer la lista de
snapshots que componen una branch sabes
que puedes hacerlo fácilmente porque
cada snapshot tiene puntero acceso
snapshot predecesora con este agregado
ahora para moverte entre ramas solo
tienes que buscar el nombre de la rama a
la que quieres acceder y allí mismo
encontrarás su último snapshot claro que
esto significa que cada vez que crees
una nueva snapshot dentro de una rama
tienes que actualizar el nombre de la
última estación un pequeño precio que
pagar por un gran beneficio pero como
bien sabes el desarrollo de software es
un trabajo cooperativo trabajar en
soledad pronto se vuelve aburrido y
piensas en invitar a alguien a trabajar
en tu proyecto por suerte su amiga show
tiene un setup padecido el tuyo y tiene
ganas de ayudarte a construir esta
aplicación además le entusiasma probar
tu nuevo sistema de control de versiones
y gracias a que has creado este sistema
de versiones puedes enviar a xavi una
copia completa de todo el historial de
snapshots y ramas de tu aplicación tener
a xavi en tu equipo es genial pero ella
tiene el hábito de salir de viaje
seguido a lugares que no tienen mucho
acceso a internet
así que en cuanto tiene el historial de
snapshots en su computadora toma un
vuelo directo a la patagonia y no sabrás
nada de ella por un par de semanas en
estas semanas en las que su vista de
viaje los dos escriben mucho código cada
uno en su entorno y cuando ella
finalmente vuelve descubres que hay una
falla crítica en tu sistema de control
de versiones porque los dos utilizan el
mismo sistema de números para nombrar
snapshots los dos ahora tienen
directorios llamados 113 y 114
solo que estos directorios son
obviamente distintos entre sí además ni
siquiera tienes una manera de
identificar quién es el autor de cada
snapshot pero como todo en la industria
del software el proceso es interactivo
así que te sientas con sobisch y los dos
juntos piensan en una posible solución
para estos problemas
primero que nada hay que hacer un
pequeño ajuste en el archivo mensaje y
agregar ahora el autor del snapshot en
la forma nombre y medio además de la
información que ya almacenamos antes
con ese cambio en el archivo mensaje
ahora al menos podemos identificar con
claridad a quién corresponde cada
snapshot el segundo cambio que necesitas
hacer es alrededor del nombre de las
estampas ya no pueden ser nombradas
utilizando números secuenciales sino que
debes asegurarte de que el nombre de
cada snapshot es único para eliminar
toda confusión para esto decides crear
un hash a partir del contenido del
archivo message un hash te garantiza que
será único para cada snapshot porque
nunca tendrás dos snapshots con la misma
fecha autor samari y parent snapshot
para asegurarte de que el hash se cree
exitosamente ambos concuerdan en
utilizar sha1 que es un algoritmo que
toma el contenido de un archivo y a
partir de ese contenido produce una
cadena de 40 caracteres hexadecimal es
tanto tú como zoey actualizan su
historial con esta técnica y ahora en
lugar de tener dos directorios llamados
113 y 114 tienen dos directorios con dos
nombres completamente distintos
ahora que los nombres de las snapshots
han sido actualizados se vuelve más
sencillo para ti traer las snapshots de
show y ubicarlas junto a tus propios
snapshots y porque cada snapshot
especifica su par en el historial del
código de tu aplicación sigue siendo un
árbol solo que el árbol ahora también
incluye snapshots de show
en resumen ahora cada snapshot es
identificada gracias a un hash sha1
único y además incluye un puntero a su
parent snapshot que también se
identifica con un sha1 estos snapshots
pueden ser creadas y trasladadas de
computadora a computadora sin perder en
absoluto su identidad oa quién
pertenecen dentro del historial del
árbol de la aplicación incluso snapshots
pueden ser compartidas o también pueden
ser privadas es decir que se haya
escrito una funcionalidad experimental
que no está seguro de querer mostrar a
otros todavía simplemente no le hagas
disponible y nadie más que tú podrá
verla
antes de seguir adelante vamos a cambiar
la representación del árbol por una más
conveniente ahora cada snapshot es un
punto del árbol y cada rama se
representa como un conjunto de puntos a
la rama principal la llamaremos master y
a partir de ella se desprenden las otras
ramas trabajar con show es genial así
que creas una nueva branch llamada más
para agregar una nueva funcionalidad a
tu aplicación y le pides a xavi que te
ayude a trabajar en esa rama show y se
va de viaje a un lugar tan remoto que se
queda sin conexión a internet durante
todo el viaje y se ve obligada a
trabajar en la nueva rama más
completamente offline al mismo tiempo
mientras hoy no está tú también realizas
cambios en la rama más porque quieres
agregar ciertas funciones genéricas que
crees que pueden ser importantes en el
futuro una vez que se ha vuelto de viaje
te muestra los cambios que ya he hecho y
se presenta una de las preguntas más
comunes a la hora de trabajar en equipo
cómo combinar los cambios que hizo xabi
con los que hiciste tú aquí es en donde
descubres que tu sistema de control de
versiones necesita algún tipo de proceso
para realizar un merge o para combinar
ramas la estructura de árbol que has
diseñado para tu sistema de control de
versiones lo hace fácil sólo tienes que
crear una nueva snapshot que incluye las
modificaciones necesarias para integrar
los cambios de xavi con los tuyos
propios
este snapshot será algo especial por
primera vez tendrás dos padres es decir
que en su archivo message apuntará a dos
snapshots en lugar de a una por un lado
apuntará a la última de los snapshots en
las que tú trabajaste y por el otro a la
última vez snapshots en la que soy
trabajo en la rama más ahora esta nueva
snapshot que combina los cambios se ha
convertido en la snap show más reciente
de la rama más y has definido un proceso
que te permite trabajar en equipo
offline y luego combinar los cambios sin
problemas
el próximo lugar en donde descubres que
todavía hay espacio para mejorar el
proceso es en tu directorio de trabajo
también conocido como working director y
por mucho que tratas de que todas las
modificaciones que haces a una
funcionalidad estén 100% relacionadas
con esta funcionalidad muchas veces te
pasa que terminas haciendo otros cambios
en lugares no directamente relacionados
con esa funcionalidad y que tienen que
ver más con otra entonces te das cuenta
de que tu working director y ahora
contiene lo que realmente deberían ser
dos snapshots separadas en lugar de una
aquí es en donde surge el concepto de
staying de director y este directorio
funciona como un paso intermedio entre
tu directorio de trabajo y tu snapshot
ahora cada vez que terminas de crear
editar o eliminar un archivo puedes
decidir si quieres que ese cambio forme
parte de tu siguiente snapshot o no
cuando si quieres que forme parte de tu
próxima snapshot simplemente lo copias
al directorio de stage y si no quieres
que forme parte lo dejas en el
directorio de trabajo
esta nueva separación hace fácil
especificar que está incluido y que no
está incluido en la próxima snapshot ya
no tienes que preocuparte por
potenciales accidentes que terminen en
tu snapshot porque ahora debes
manualmente elegir qué cosas formarán
parte de esa es nacho tu próxima
snapshot será entonces creada a partir
del directorio staging el sistema de
control de versiones que has construido
hasta aquí se parece mucho a git la gran
diferencia es que git proporciona una
gran variedad de herramientas de línea
de comandos para manejar situaciones
como las que hemos visto además de
muchas otras lo que hasta aquí hemos
llamado snapshot en git se conoce por el
término commit a medida que estudia hits
a lo largo de este curso ten presente
todo lo que hemos visto en esta parábola
de git y te recomiendo que vuelvas a
verla siempre que algún concepto no
quede claro una última cosa antes de
terminar recuerda que es muy difícil
casi imposible perder nada de tu trabajo
con git incluso cuando eliminas una rama
lo que realmente sucede es que el
puntero hacia este comité se elimina
todas las snapshots están todavía en los
objetos del directorio sólo necesitarás
encontrar el sha1 del comit a lo largo
del curso te voy a mostrar herramientas
para resolver esta y muchas otras
situaciones que te encontrarás
trabajando con mid si este vídeo te
gustó te invito que le dejes un like así
llega a muchas más personas en general
los programadores y las programadoras
conocen git conocen los comandos y saben
manejarse con los procedimientos básicos
del control de versiones pero no
entienden qué pasa de fondo y cuáles son
los fundamentos de un sistema de control
de versiones como git para ver contenido
como éste y muchas otras cosas más te
invito a que te suscribas al canal si
todavía no lo hiciste déjame en
comentarios qué te pareció este vídeo y
que otra cosa quieres ver en este canal
muchísimas gracias y nos vemos la
próxima
[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)