qué cosa es git para explicártelo te voy a poner una sencilla analogía ese cuadernito de ahí es un

diario en mis tiempos ya soy un poco viejo se acostumbraba a llevar un diario que era un
cuadernito donde tú ibas apuntando tus memorias por ejemplo querido diario hoy fue mi primer
día en el colegio mi primer día en la universidad hoy es la fiesta dónde va a ir la chica que me gusta
y espero que la pasemos bien etcétera y vas anotando las cosas importantes de tu vida y era muy
bonito porque podías abrir tu diario y ver lo que pasó en alguna fecha determinada e ir
recorriendo tu vida es muy chévere imagina que yo te preguntara que hiciste como interrogatorio
policial no que hiciste la noche del 5 de septiembre del 2005 te acuerdas yo no me acuerdo tú
tampoco ese historial también puede llevarse en el mundo del software porque un software no es
algo que se crea en un día no escribes dos líneas de código y ya está el software tiene la versión
alfa beta la 1.0 1.1 2.0 es decir el software tiene una vida las aplicaciones tienen una vida y en esa
vida le añadimos nuevas funciones corregimos errores sacamos una nueva versión se integran
nuevas personas al proyecto a trabajar entonces es necesario también llevar un diario en el que se
registre todo lo que ha pasado en la vida del proyecto que se hizo la noche del 5 de septiembre del
2005 entonces para registrar la vida de un proyecto se usa algo llamado sistema de control de
versiones o vice es en inglés un sistema de control de versiones en esencia es lo mismo que el
diario de hace un momento solo que no es un cuaderno es un software obviamente y además
permite trabajar en grupo entonces cada desarrollador que está en este proyecto puede agregar a
ese historial los trabajos que él está haciendo los cambios que le está aportando el proyecto las
correcciones las nuevas características entonces este sistema de control de versiones tiene un
historial de todo lo que se ha hecho en el proyecto y quién ha hecho eso es git un sistema de
control de versiones así que antes de meternos de cabeza aquí vamos a hablar de la terminología
esas palabras técnicas que tú escuchas cuando la gente habla de git como a mí cuando me dijeron
clon el repositorio y decía clonar repositorio y me hizo explosión la cabeza para que eso no te
ocurra vamos con los términos en primer lugar git se pronuncia git git es un sistema de control de
versiones lo que acabamos de decir es decir un software que permite registrar todo el historial de
cambios de un proyecto un repositorio es todo proyecto que está siendo seguido por git es decir
que ya tiene un historial de git en el que se están registrando sus cambios un cómic es cada uno de
los cambios registrados en el historial de git cada uno de los desarrolladores manda los cómics de
los cambios que ha hecho esto no es automático el desarrollador tiene que decirle oye yo he
hecho esto y lo he hecho por tal motivo las ramas como su nombre lo dice son ramificaciones
bifurcaciones nuevos caminos que tome el proyecto y todo se trabaja por ramas hay una rama que
es la principal que suele llamarse máster donde está el proyecto digamos que sale al público no la
versión en producción cada vez que se quiere trabajar en alguna característica nueva o corregir
algo se saca una rama de tal manera que puedes trabajar en un ambiente aislado es una copia
exacta del proyecto pero separada entonces trabajas en ese ambiente aislado si algo se rompe no
comprometes al proyecto no rompes el proyecto y si todo va bien luego esa rama la unifica con el
proyecto principal y si va mal puedes eliminar la rama sin ningún problema un clon es una copia
exacta del repositorio cuando un programador se integra a un equipo de trabajo lo primero que
debe hacer es clonar el repositorio en su equipo local entonces cada uno de los desarrolladores
tiene un clon del repositorio en su equipo local un fork a diferencia de un clon y a diferencia de
una rama es un proyecto completa diferente que se crea a partir de otro por ejemplo las
distribuciones de linux todas se basan en el mismo kernel pero a partir de ahí cada una toma su
diferente camino entonces cada vez que veas que este proyecto es un fork de otro es que se basó
en lo que había trabajado este otro proyecto dicho eso vamos a ponernos un poco ocultos y
vamos a hablar de la historia de git rapidito nada más porque esta no es una clase de historia ese
hombre que ustedes ven allí se llama linus torvalds y este hombre fue el creador de linux o bueno
el kernel de linux es una historia que ya será para otro vídeo el punto es que él también crea git es
sorprendente porque ha creado dos de los más grandes aportes a la tecnología en la historia en el
año 2005 él estaba trabajando en el kernel de linux y ya había una gran comunidad trabajando
junto con él haciendo sus aportes entonces imagínate controlar los aportes de muchísima gente se
usaba un sistema de control de versiones llamado beat keeper pero beat keeper dejó de ser
gratuito y él no quería pagar por la licencia porque linux es un proyecto open source así que
decidió crear su propio sistema de control de versiones al que llamó get smart al instante
santander pasemos a las características porque git es el sistema de control de versiones más usado
en el mundo habiendo otros en primer lugar git es distribuido como vimos hace un momento cada
uno de los desarrolladores tienen una copia idéntica del repositorio en su equipo local lo que
significa que no necesitan conectarse a un servidor central tampoco necesitan conexión a internet
para trabajar pueden trabajar en cualquier momento otra ventaja interesante es que es más
rápido no requiere conexión a internet y cosa curiosa cada desarrollador tiene un backup del
proyecto o se hacía algo pasará si algo se complicará si algo explotará cada uno tiene una copia del
proyecto lo cual lo pone a salvo el otro detalle son las ramas y las fusiones como vimos hace un
momento en las ramas son nuevos caminos bifurcaciones ramificaciones que toma el proyecto
para no comprometer a la rama principal para tener integridad de la rama principal entonces para
nuevas características para corregir cosas para hacer pruebas se van creando diferentes ramas
para cada desarrollador también etcétera pero esas ramas luego tienen que integrarse a la rama
principal es decir salen toman su camino el programador está trabajando en alguna característica y
una vez que la termina tiene que integrar esa rama con la rama principal es una fusión o merge
obviamente en ese mes podrían haber problemas podrían haber conflictos busca memes en
google sobre y te vas a dar cuenta la cantidad de cosas que pueden ocurrir el detalle es que así
funciona aquí ramas que toman su camino y vuelven a la rama principal otro detalle interesante
de guinness la integridad de datos git agrega un check son una suma de comprobación a cada uno
de los archivos y de los comités de tal manera que hay una seguridad total de que cada uno de los
desarrolladores tenga los mismos datos que los demás porque si no se habría datos corruptos el
proyecto podría entrar en graves problemas muy bien ya sabemos que es git es un sistema de
control de versiones ya conocimos los términos más usados de guinea sabemos que es un comité
que es una rama que es un repositorio que es un clon que es un fork ya sabemos que es
distribuido y que cada desarrollador tiene una copia del repositorio etcétera y aquí viene la
pregunta más importante cómo se trabaja con git cómo se hace un software con guita hay muchas
ramas clones repositorios cómics cada desarrollador tiene una copia cómo se trabaja bueno el
flujo básico básico básico es el siguiente llega un desarrollador va a trabajar con el proyecto y lo
primero que tiene que hacer es crear el repositorio de acuerdo que es un repositorio un proyecto
que está siendo seguido con git que tiene un historial de git hay dos formas de crear este
repositorio kit init el comando git in it en la terminal si es un repositorio nuevo desde cero o git
clone si es un repositorio que ya existe ejemplo si tú llegas a un trabajo a integrarte a un proyecto
obviamente no vas a hacer git init es un proyecto que ya existe entonces te dirán clon al
repositorio lo que me dijo a que el programador hace unos años y yo no sabía no clone el
repositorio entonces el programador o la programadora va abre su terminal y escribe git clone y la
url del repositorio y entonces se clona y se crea una copia en su equipo local de esa manera el
programador o la programadora ya tiene su repositorio eso es lo primero ahora que ya tiene su
repositorio local lo siguiente que tiene que hacer es empezar a trabajar y mandar sus cambios al
repositorio de cómics cada vez que el programador hace un cambio no se guarda en el repositorio
manualmente hay que enviar los cómics porque cada cómic debería representar una funcionalidad
específica por ejemplo un cambio en la interfaz una nueva funcionalidad la corrección de un
problema pero cada cómic debe representar algo específico entonces el programador debe
escribir de qué se trata este cómic pero los cambios del programador no van directamente al
repositorio sino que hay una etapa intermedia llamada este gene área o área de preparación
entonces cuando yo estoy haciendo cambios por ejemplo para corregir un error en el código tengo
que tocar cuatro o cinco archivos entonces tocó el primer archivo toco el segundo toco el tercero y
todos ellos los voy mandando al stage en área con el comando git y no los mando directo al
repositorio hasta que esté absolutamente seguro de que ya hice las modificaciones en todos
necesarios mientras tanto están en espera en el stay in área por ejemplo yo creo que ya lo corregí
pero acabo de darme cuenta que debo manipular otro archivo entonces lo añado al stay in área
una vez que estoy ahí ya mando los cambios al repositorio con el comando git commit y con el
comando git commit le agregó un mensaje donde digo en este comité estoy corrigiendo tal error
por ejemplo y listo ese es el flujo super básico guitar git commit tres áreas del área de trabajo
donde está el desarrollador el área de preparación que es el área intermedia y el repositorio esas
son las tres áreas que debes conocer ahora bien vamos un trabajo en equipo acá la cosa es más
compleja no lo anterior es muy sencillo cuando se trabaja en equipo lo usual porque hay
muchísimos flujos de trabajo muchísimas formas diferentes mucho más complejas que ésta pero
digamos que esta es la básica cuando trabajas en equipo lo normal es tener dos ramas una rama
llamada master que como dijimos hace rato es el proyecto principal donde no se debe jugar no se
debe tocar master y le sacamos una rama llamada def con esta rama debe es con la que vamos a
trabajar no vamos a trabajar con master master se cuida master está prohibida para todo el
mundo salvo para los líderes del proyecto desde la rama de cada uno de los desarrolladores va a
sacar sus propias ramas para trabajar en lo que le toca cada uno ahora bien recuerda las ramas no
es que salga y ahí se queden las ramas deben volver cuando el trabajo se complete las ramas
deben volver e integrarse al momento de estas ramas integrarse a depp hay que ver que nada se
rompa recuerda que esta integración se llama merge y en los march podrían haber conflictos cosas
que fallen y eso es riesgoso entonces normalmente puede haber un líder de proyecto revisando
que no haya conflictos devolviendo los trabajos a los programadores y diciéndole hoy hay
conflictos resuelve lo o en flujos más avanzados tenemos sistemas de integración continua que a
través de test automatizados revisan y si hay conflicto no le dejan al programador hacer merge y le
dicen oye corrige ese conflicto porque si no no te voy a aceptar el march lo importante es que
todo eso se hace en def no se hace en master imagínate que hubiera conflictos en master y master
se rompa el caos que sería por eso master se protege ya corregimos todos los conflictos ya hicimos
merz ya integramos el trabajo en def y ahora nos toca integrar de a master ahora sí master está
actualizado y tiene todos los cambios que han hecho los programadores y ahora es el momento de
mandar esto a producción y si todo va bien funcionará y si no se caerá ese tipo muy bien ya sabes
qué cosa es guix ya conocen los términos más usuales ya sabes que es un repositorio una ramón
comet ya conoce los flujos de trabajo guau estás muy adelantado ahora fíjate ahora hablemos de
las herramientas que herramientas nos ayudan a trabajar con git la herramienta más importante
para trabajar con git es la terminal o línea de comandos hay gente que viene y dice quiero que me
enseñes git en una interfaz gráfica no quiero aprender git con línea de comandos es comprensible
porque puede intimidar un poco la línea de comandos a mí también me pasó pero te soy
absolutamente sincero no se aprende git con una interfaz gráfica no así no se aprende los
programas con interfaz gráfica sirven para agilizar el trabajo cuando tú y entiendes cómo funciona
aquí pero tú tienes que aprender sí o sí con la terminal haciendo los comandos como push pull
gamers y check out with branch etcétera y muchos comandos que te los vas a aprender en el día a
día una vez que entiendes el flujo una vez que entiendes a la terminal ya puedes acelerar tu
trabajo con clientes gráficos que ya con figuritas como hemos visto hace un rato no te muestra la
rama los cómics el historial es mucho más fácil pero no los vas a aprovechar si es que no sabes
cómo funciona git hasta este momento hemos visto repositorios en nuestro equipo local cada
desarrollador tiene sus repositorios luego los juntan los mandan a producción pero como hacemos
por ejemplo en un equipo distribuido alrededor del mundo como de tim que estamos en 6 países
lo que usamos son repositorios en la nube existen empresas que nos dan toda una plataforma
para usar git en la nube y estos repositorios son ramas a eso le llamamos ramas remotas por
ejemplo tenemos la rama local que es máster y la rama remota suele llamarse origin y ese origen
puede apuntar a git hub avid baquet y aquí pero ojo estas tres empresas son las más importantes
para tener nuestros repositorios en la nube algunos pueden ser públicos cuando son open source
angular rack view por poner ejemplos son 'open source' están abiertos para todo el público pero
obviamente también hay repositorios privados porque las empresas no quieren pues que los
demás miren su código mucha gente se confunde y piensa que el quit hub y kits son lo mismo no
git hub es una empresa que da un servicio en la nube para que tengas repositorios alojados en la
nube pero git es la tecnología que está por debajo entonces recuerda su rama remota está en la
nube y suele llamarse origin entonces tu origin puede estar en github feedback et que son los
mismos creadores de sus tree que vimos hace un momento eso y git labrit lava entrado con mucha
fuerza git lab es la opción que usamos en el etim pero al final cada empresa escoge la que mejor se
acomode a su flujo de trabajo y también git está integrado en muchos editores e ides de código
visual studio court por ejemplo el editor que ha venido a destronar a todo el mundo integra muy
fácil además git hub por qué visual studio desde microsoft microsoft compró kitkat microsoft
compró link ding tus repos luego van a poder estar en link o sea tiene un plan para dominar al
mundo obviamente en lo importante es que visual studio code está integrado con git y git hub
recuerda que el hub no es lo mismo ir hub es una de las tantas empresas que dan reposo en la
nube ok todos los y desde intelligent aid y atraen integración con una integración realmente muy
bonita inteligencia webstorm php storm gowland rubymine etcétera todos los líderes de
intelligent de jetbrains la empresa que está detrás son muy chéveres y su integración con guita es
muy bonita tienen un cliente en terminal tiene un cliente gráfico integrado en el mismo y de para
que tú veas cómo ha ido avanzando el proyecto y también está a tomar como es el proyecto de git
hub que se ha desinflado un poquito luego de que microsoft compró github y y le ha dado mucho
más fuerza visual studio copero a ton todavía está ahí entonces cómo ves debes aprender git es
indispensable así que tienes que aprender git.