Git y Github básico para diseñadores, estudiantes visuales y todos los demás.

1. Qué es el control de versiones: Entonces hablemos un poco de Git. ¿ Qué es Git? Git es control de versiones y ¿qué es el control de versiones? El control de versiones es esencialmente un control de historia. Es como un deshacer. Te permite volver a entrar en tu proyecto si has hecho algo que deseabas no haber hecho y quieres volver a la forma en que era. control de versiones te permite hacer eso. Es una máquina del tiempo en ese sentido. Si nunca has visto a los clásicos 80s retroceder al futuro, esta es la máquina del tiempo que tienen y esa película. Estaré referenciándolo tal vez una o dos veces y así si no lo has visto, tienes que ir a verlo. Lo que Git va a hacer es dejarte volver atrás en el tiempo. Se va a almacenar instantáneas de tu proyecto en un momento dado y luego a medida que avanzas por tu proyecto y te comprometes cada vez más instantáneas, tienes estos diferentes puntos en el tiempo como puedes volver a, caso de que decide que quieres deshacer algo. Eso no es todo, ese control de versiones sí sin embargo. qué es realmente genial el control de versiones es administrar la forma en que múltiples contribuyentes interactúan en un proyecto. Entonces aquí tenemos tres contribuyentes. Todos están empujando contribuciones a una base de código central o a cualquier proyecto realmente o se llama el repositorio y esta es la versión perfecta o al menos la última de tu proyecto. Algo que puedes ver de este modelo aquí es que está muy de izquierda a derecha. Es unidireccional y estos contribuyentes realmente no tienen una gran manera de interactuar unos con otros y compartir código y cosas así. Como colaborador, si quieres experimentar un poco con tu proyecto, tendrías que hacer una copia completa del mismo y jugar con él y luego volver y empujar tus contribuciones a la versión perfecta. Git como respuesta a eso, establece esta idea de control de versiones distribuidas y qué es esto, es una forma de romper ese flujo lineal e introducir algo que es un poco más colaborativo. Entonces aquí tienes tres contribuyentes y no solo son capaces de empujar su código hasta el repositorio, sino que también pueden compartirlo entre sí. Se pueden compartir entre sí, pueden empujar hasta el repositorio, incluso pueden tirar del repositorio, pueden jalar el uno del otro pero como pueden ver, esto puede ponerse bastante confuso. Las cosas van por todo el lugar y sin alguna forma de manejar esto, puedes meterte en muchos problemas en un proyecto. Ahí es donde entra este flujo de trabajo, y ahí es donde vamos a estar llegando sobre este tema y lecciones. 2. Consigue git y jugar: Lo que te voy a mostrar ahora mismo es cómo bajar a tu máquina. Probablemente la forma más fácil de hacerlo es si vas a Mac.Github.com. GitHub está diseñado para realmente gran cliente para usar con git. Voy a pasar por una forma más sencilla de usarlo, porque aquí está pasando mucho y si no entiendes exactamente lo que estás haciendo, puede volverse bastante loco. Te voy a guiar paso a paso en la terminal, que es la ventana hacia el funcionamiento interno de tu computadora. Si alguna vez viste películas de hackers de los 80, esto es lo que solían hackear en el mainframe. Pero la forma más fácil de instalarse es descargar el cliente de GitHub desde Mac. No te preocupes por abrir la app, siéntete libre de entrar ahí y meter por ahí. Si ya no tienes ninguna configuración de repos de Git, realmente no verás que pase nada interesante, pero sí aglupa todo el software de Git con él, así que adelante e instala eso. Si no quieres descargar eso, solo puedes ir al sitio web oficial de Git, git.scm.com y descargarlo allí también, sigue las instrucciones, es bastante fácil ponerlo en marcha. Una vez que lo tengas descárgalo, podrías abrir terminal. Puedes mandar espacio para tirar hacia arriba del Buscador rápido ahí, o puedes ir por tus aplicaciones por la terminal, ver el terminal de utilidades justo ahí, y abrir eso. Por defecto, te va a dejar caer en tu carpeta de usuario. Hago un directorio llamado espacio de trabajo, para sostener muchos de mis proyectos activos. Vamos ahí ahora mismo, está despejado para esta demo, pero normalmente habría un montón de proyectos aquí. Entonces vamos a crear un nuevo directorio y lo llamaremos primero repo, ahí vamos y solo voy a poner algo ahí. Vamos a abrir texto editar, y vamos a poner un hola mundo, guarde eso. Hello.txt, ahí vamos, y todo lo que realmente está haciendo es poner algo en este directorio para que podamos hacer un repositorio de Git para ello. La forma más fácil de hacer un repositorio de Git es escribir Git init, y eso es abreviado de inicializado. Lo primero que voy a querer hacer es meterme en ese directorio que creé. Si nunca has usado la terminal antes, hay muchos comandos que te permiten hacer directorios, eliminar directorios, hacer archivos, eliminar archivos, saltar alrededor de la estructura de directorios. Te daré un par de lo básico en el transcurso de esta lección, y estas son cosas que vienen muy bien. El primero del que les voy a contar es el CD, que ha cambiado de directorio. Entonces voy a CD al espacio de trabajo, y lo que acabo de hacer ahí fue básicamente dicho de mi usuario. Entonces si vuelvo al usuario aquí, usuario ¿dónde estás? Ver esto es tilde, ese es el garabato ahí. Tilde es tu carpeta de inicio, testy es el nombre de usuario para mi cuenta de prueba aquí en la que estoy trabajando para esta demo, y ahí estoy casita y ahí está mi espacio de trabajo y creé primer repo. Entonces cuando dije espacio de trabajo de CD, estaba en tilde, que es mi directorio de inicio aquí, y dije cambiar directorio a espacio de trabajo y ahí estoy, y ahora voy a CD en primer repositorio. CD, primer repositorio, sin espacio. Una vez que estoy ahí, puedo escribir ls, lo que significa lista y puedo ver mi archivo hola que creé, y ahora tengo un lugar para iniciar mi Git Repo. Lo primero que voy a hacer es decir git init. Siempre que estoy escribiendo comandos que se supone que Git reconozca, voy a prefaciarlos con la palabra clave Git allí. Estaré haciendo cosas como git add, git clone, git commit, la mayoría de las cosas que solo funcionan en el programa Git. Git init es el primero que vas a usar. Se inicializó el repositorio de Git vacío, por lo que con ese comando, estamos rastreando un archivo. Ahora si voy y hago cambios a ese archivo, lo va a rastrear Git y ese es el comienzo mismo de tu experiencia en Git. 3. Escena y compromiso: Analicemos algunos de los pasos básicos que vas a usar mientras estás pidiendo a GIT que te ayude a guardar los cambios en tu proyecto. Hablamos de esta idea de tomar instantáneas a tiempo de tus proyectos en caso de que quieras volver a ellos. Cada vez que tomas una de esas instantáneas, estás comprometiendo tus cambios a este repo de GitHub. Entonces echemos un vistazo a lo que sucede. Son algunos pasos que suceden en este proceso de licitación. Entonces primero escribes tu código, estás creando contenido nuevo, sea lo que sea que estés haciendo. Juntas varios archivos, digamos que decides que estás listo para comprometerte. Has llegado a un lugar donde tu proyecto está funcionando, o estás en un escenario donde estás listo para trazar una línea en la arena por así decirlo y tomar una instantánea a tiempo. Ya has llegado a la parte de puesta en escena de tu proyecto, que vas a hacer es decir, hey GIT, tengo estos archivos en particular que me gustaría prepararme para comprometerme. Es posible que no quieras comprometer todos tus archivos. Por lo que el proceso de puesta en escena te permite agregar selectivamente lo que te gustaría comprometer. Entonces pasarás a comprometerlo realmente. A mí me gusta en estas dos etapas preparar algo para el envío donde lo estás empacando en una caja, y cuando te comprometes tu techo arriba y estás diciendo: “Recuerda todas estas cosas, toma una instantánea de este punto en tiempo”. Entonces cada vez que estás pasando y haciendo uno de esos commits, estás empaquetando un punto en el tiempo y teniendo a GIT para recordarlo por ti. Entonces ahora hemos hablado un poco de ese proceso de adición, puesta en escena, compromiso, echemos un vistazo a cómo se ve eso mientras estás en la terminal trabajando con GIT. He hecho una actualización al archivo Helloworld. Entonces hagamos un estado de Git y veamos qué tiene que decir Git sobre nuestro proyecto aquí. Entonces ves que estas dos entradas rojas son el archivo hello.rtf, que esperarías que se modifique desde que hemos estado trabajando en ello, y luego este otro archivo sin seguimiento, .ds store, que es un archivo del sistema que Apple usa para rastrear la forma en que tienes configuración de tu carpeta y cuando la miras en la ventana del Finder, todos modos, no es el archivo que normalmente enviarías a un repo. No hay necesidad de pasar eso a otros desarrolladores. Aquí es donde ese proceso de adición es útil. Te va a dejar agregar cosas selectivamente a tu repo en lugar de solo lo que haya en la carpeta porque puede haber este es un archivo que normalmente no verías, va a punto antes de él, hay otros invisibles archivos que normalmente no ves que podrían comprometerse sin que tú lo sepas. Así que vamos a hacer un git add hello.rtf, hacer un status git, ver qué pasa. Entonces aquí vamos. Se puede ver que hello.rtf está en verde ahora y ds stores todavía en rojo, está listado como un archivo sin seguimiento. Entonces eso es bueno. No queremos rastrear a esa. El que sí queremos rastrear se ha agregado en puesta en escena para ser comprometidos. Entonces ahora, sigamos adelante y cometamos ese expediente. Cuando cometes un archivo, necesitamos dejar algún mensaje, necesitas decir lo que hiciste, qué código estás agregando, quiero decir, no necesariamente codificar, en nuestro ejemplo, podría ser una receta, it podrían incluso ser archivos de Photoshop. Puedes conseguir casi cualquier cosa a tu repo, cual dejas un mensaje, por lo que dash m es taquigrafía para el mensaje. El mensaje tiene que estar entre comillas, actualizado hola mensaje.Entonces voy a golpear retorno. Me devuelven un montón de cosas de Git. Realmente no tienes que poner demasiada atención a eso siempre y cuando no haya un error entonces así de bien, así que ahora puedo hacer el status de Git. Todo lo que veo es por archivo de la tienda ds, está por buen camino. Entonces ese es pequeño paso por ahí, trabajé en ello, lo agregué, y luego lo cometí, tengo este archivo está atascado el archivo en una caja diciendo, oye, esto es lo que pretendo comprometer. Esto es lo que pretendo dejar atrás y luego envuelvo esa caja y dejé un mensaje en ella, y se toma como una instantánea, es un punto en el tiempo que Git va a recordar para mí. Hay otra cosa a la que quiero llamar su atención. Si vas a hacer un commit, digamos que agregamos algo más aquí, volvemos a pasar por nuestro proceso. Ahí vamos. Yo sí Git commit, si me olvido de escribir la taquigrafía dash m, Git todavía va a querer un mensaje para mí y esto es lo que va a pasar. Voy a entrar en esta cosa llamada VIM y este es uno de los editores de texto más antiguos por ahí, va mucho atrás, y puede ser un poco raro de usar. Por lo que empiezas con este mensaje, dice por favor introduce el mensaje de confirmación para tus cambios. Eso se puede leer bastante bien. Lo que harías es, algo como esto dices fechado [inaudible] Notarás que soy un modo de inserción. Esta es inserto de palabra en la parte inferior. Eso te va a dejar teclear. Cuando te alejas de eso, solo estás en modo de lectura. Para salir, escribes un colon. Oops no ahí aunque. Presionas la tecla de escape para salir del modo de inserción. Ahí vamos. Escriba dos puntos y escriba w para escribir, y q para dejar de fumar. Es posible que quieras anotar eso porque si alguna vez te deforma en este VimWorld, no funciona. Si no has pasado el tiempo, puede ser difícil volver a salir, y puede ser frustrante. Así que anota colon WQ. Recuerda eso, vamos a presionar enter, me llevan de vuelta a la ventana de mi terminal, y me sale ese mismo mensaje que estoy acostumbrado a ver cuando hago un git commit dash mSolo quiero hacerte consciente de que en caso de que tú accidentalmente se deforma en ese universo VIM, queremos escapar de colon WQ, volver. Eso te sacará. 4. Creación de futuros alternativos - la presentación y la fusión en Git: Hasta ahora, hemos hablado de qué es el control de versiones, qué es Git, cómo instalarlo, cómo escenificar y comprometer archivos. Vamos a seguir adelante y hablar con algunas de las realmente grandes características clave de Git, el concepto de cabeza, y luego la práctica de ramificar y fusionar. Esto nos da la oportunidad de utilizar también nuestras excelentes metáforas de viajes en el tiempo “Regreso al Futuro”. Entonces aquí vamos. Estás familiarizado con esto. Vamos adelante, estamos haciendo instantáneas en puntos clave de nuestro proyecto para que podamos preservar esos estados. Si echamos un vistazo a esta línea de tiempo, se llama maestro. Es la línea de tiempo predeterminada que obtienes al inicializar un repositorio de Git. Puedes ver aquí si hago un status de Git en rama master. Entonces a medida que avanzamos y hacemos estos cambios y los comprometemos, estamos seguros contra una verdadera pegatina por la capacidad de Git de dejarnos volver a un punto anterior en el tiempo de nuestro proyecto y empezar de nuevo. Ahora ves el pequeño triángulo que salí. Ahí es donde estamos en esta línea de tiempo. Ese es concepto de cabeza en Git, es tu máquina del tiempo, es donde ahora estás en tu proyecto. A medida que avanzas, haces cambios. En la cabeza está donde estás ahora mismo. Entonces hablemos de ramificación. Aquí es donde nos metemos en nuestras metáforas de Regreso al Futuro. Volver al Futuro se concentra alrededor de Marty McFly, una adolescente en 1985. Sus padres son shmacks y las cosas no van tan bien. Quiere pedir prestado el auto para sacar a su novia, pero el jefe de su papá lo ha tomado prestado y lo ha destrozado. Entonces en la película, lo que pasa es que Marty se remonta en el tiempo a 1955 porque todo esto podría haberse evitado si su papá sólo le hubiera pedido a su madre el encantamiento bajo el baile del mar y se hubieran enamorado. Viaja de regreso a 1955 y establece un conjunto de circunstancias en las que sí se reúnen en el baile bajo el mar y tuvieron su primer beso y enamorarse. Establece un futuro alternativo y luego cuando regrese a 1985, todo es impresionante. Entonces en nuestros proyectos, hacemos cosas así. Empezamos una nueva sucursal y en esta sucursal está nuestro futuro alternativo. Trabajamos en nuestro proyecto, todo va muy bien y cuando estamos en un punto donde queremos fusionarlo de nuevo en la rama maestra, que es nuestra rama perfecta, lo hacemos usando una fusión. Entonces ahora en Regreso al Futuro, estamos de vuelta a 1985, todo va muy bien. George es un escritor exitoso, Loraine sigue enamorada de George, y Marty tiene un camión impresionante ahora. Este patrón de ramificación y fusión está en el núcleo del buen flujo de trabajo de Git. Te permite tener la libertad de experimentar, probar estas nuevas características sin fusionar tu línea de tiempo maestra. Puedes ver este patrón donde subes, intentas algo nuevo, funciona, lo vuelves a meter, subes, añades la siguiente característica, funciona, lo vuelves a meter. Ese es prácticamente el núcleo del buen flujo de trabajo de Git. 5. Viaje de tiempo de terminación: te de la que y la fusión: Aquí estamos. Vamos a echar un vistazo práctico a lo que acabamos de aprender. Nos fijaremos en mover la cabeza alrededor, en hacer ramificaciones, y hacer fusión. Lo primero que voy a hacer es, vamos a ver aquí. Haz un git init y configura este repositorio git. Empecé con uno fresco para este ejemplo y voy a hacer un archivo hello.txt. Digo toque hello.txt y se puede ver aquí en la ventana del Finder que tengo para git repo y hello.txt. Ahora puede que no veas esto.git y esta.DS_Store. He elegido mostrar archivos ocultos, hay archivos del sistema que normalmente no verás como usuario. Si Google eso, hay un realmente fácil si puedes copiar pegar ese comando en ventana de tu terminal y te mostrará esos archivos. A mí me gusta tenerlo puesto. Lo primero que voy a hacer es configurar un archivo.gitignore. Ahí vamos. Ahora, puedo abrir ambos estos en Sublime Text. Ahí vamos. Sublime Text es un gran editor de texto, tienen muchos plugins para ello. También es gratis para una descarga de prueba y te recomiendo usarlo si solo quieres probar algo. Empieza con gitignore. Lo primero que pongo en un archivo gitignore y lo que hace este archivo es que le dice a git que no rastree los archivos que explícitamente listan aquí. Por lo general agrego gitignore dos el archivo gitignore. Entonces en segundo lugar, esta.ds_store, ese es un archivo de sistema que Macs usó para realizar un seguimiento los cambios en la carpeta y es de los cambios en la carpeta y es suficiente una explicación para decir que no necesitas rastrearlo en tu repo de GitHub. Tengo esas dos cosas ahí dentro y ahora voy a empezar con mi hello.txt. Lo que voy a ilustrar es una serie de commits y luego cómo puedes moverte en esos. Digamos que tengo una gran idea para un poema y voy a guardar esto. A mí me gustan mucho estas dos líneas. Hagamos un pequeño diagrama aquí abajo. Vamos a decir que este es nuestro primer compromiso. Básicamente voy a empezar a construir una pequeña línea de tiempo sólo para ilustrar dónde estamos en esta cosa. Yo lo guardaré, voy por aquí, hacer status git, y dice que estoy en rama master. Es mi primer commit y es un hello.txt es el archivo sin seguimiento. Haremos git add hello.txt. Ahora podemos comprometernos, git commit - m para mensaje. Voy a decir, sumando las dos primeras líneas de mi nuevo poema. Ahí vamos, así que lo he comprometido. Ahora puedo comprobar esto y ver git tiene un comando llamado log. Si haces git log, verás el commit que acabas de hacer. Tiene este loco número de compromiso largo que es único de ese commit y dice quién lo hizo, cuándo lo hicieron, y luego da el mensaje de commit. Esto es genial cuando estás trabajando en un grupo porque puedes rastrear todos los diferentes commits y echar un vistazo a la historia. Hagamos un poco más en el poema aquí. “ Mundo tan alto”. Sí, esto realmente se siente bien, me está gustando este poema. Vamos a comprometernos de nuevo, hagamos un segundo compromiso. Voy a llamar a este B y voy a hacer una flechaita para mostrar dónde estamos aquí. Agrega este, haz estado git. Modificado hello.txt, así que haremos git add hello.txt, git commit -m para mensaje, agregando la tercera línea y luego nos comprometemos eso. Vamos a git volver a registrarlo y a ver qué tenemos. Ahí está nuestro primer compromiso aquí, sumando las dos primeras líneas de mi nuevo poema. Entonces aquí se ve el que acabamos de hacer, por lo que los enumera desde el más reciente hacia abajo. Todo, está bien. Por ahora, tan bien, sigamos adelante. Tenemos otra línea del poema. Voy a comprometer este aquí, pasará por el estado habitual de git, git add, git commit. Vamos a git log it y veamos lo que tenemos aquí. Tenemos los tres. Todo esto debería tener sentido y realmente probablemente conseguir un poco aburrido escribir ahora. Digamos aunque que estoy teniendo segundas reflexiones sobre esta última línea. A lo mejor me gustaría cambiarlo, pero ya lo he comprometido. No, ¿qué puedo hacer para retroceder más allá de este compromiso? Bueno, puedo ir a reiniciarme y luego aquí hay un término que reconocerás HEAD. Podría tomar la HEAD y restablecerla a un punto diferente en esta línea de tiempo. Yo muestro eso diciendo [inaudible] que es un poco ardiente arriba en la esquina superior izquierda por el muesca ESC en Mac, en cualquier lugar. Eso dice, toma la cabeza y retrocede una, retrocede hacia el último compromiso. Ahí voy, ahora mis cambios están en el escenario después de ese reinicio, y se puede ver que nada realmente cambió aquí sin embargo. Pero si miramos el git log, verán que tengo el que dice agregar las dos primeras líneas y agregar tercera línea. Pero ese compromiso se ha ido. Entonces hemos deshecho ese compromiso. Hemos retrocedido en el tiempo en nuestra pequeña máquina del tiempo llamada cabeza. Ahora digamos que no quiero mantener esa última línea para nada. Hagámoslo. Cambiaremos esto por algo que tenga un poco más de sentido. Ahí vamos. Yo lo guardo. Entonces yo git add y yo git commit y yo git log y lo puedes ver. A la cuarta línea, ahí vamos. Ahora digamos que tampoco estoy contento con eso. Si quiero volar toda esta última línea, todo este C se compromete que he hecho. No me preocupa guardar ningún expediente. Puedo hacer un git reset - -hard, y luego darle un índice para la cabeza, HEAD~1. Lo que esto va a hacer es volar todo en este commit y mover la cabeza de nuevo al último commit. Por lo que una vez que golpee volver aquí, verá el texto cambiar en la almohadilla de texto o texto sublime. Haz eso y cuando voy por aquí, boom, ido, borrado de la historia. Probemos la suma de ramificación ahora. Obviamente, estoy teniendo muchos problemas con esta siguiente línea y estoy usando un ejemplo ridículamente demasiado simplificado aquí. Pero esto se debe principalmente a que quiero enfocarme en cómo moverme con esta línea de tiempo en lugar de aplicaciones prácticas de cometer código en este momento. Hagamos una sucursal. Este es un ejemplo perfecto de cuándo podrías querer usar una rama si estás tratando evitar estropear las tres líneas perfectas que tienes hasta ahora. Vamos a abrir una sucursal aquí. Haz esto, haz un git checkout -b. Todavía no hemos revisado la caja, así que vamos a revisar la caja. Checkout es cómo te mueves entre las ramas y git. También se puede utilizar como un comando abreviado para crear una nueva rama. Entonces si digo git checkout -b, que es taquigrafía para rama, y le doy un nombre. Lo llamaremos de cuarta línea. Mira esto, he cambiado a una nueva sucursal, de cuarta línea. Aquí estoy, escribe aquí. De hecho, llamemos a eso A, guárdelo y hagamos un status git. Demuestra que se modifica principalmente porque acabo de cambiar eso de una C a una A. Así que sumemos, miren eso, eso se siente bastante bien. Sigamos adelante y cometamos esto. Ahorra primero. Ya vemos, está bien. Voy a enviar un texto git add hello.txt, git commit -m, “¡ Creo que lo tengo resuelto!” Ahí vamos. Hagamos git log. Aquí verás todos mis últimos commits, incluyendo el de la nueva sucursal. Ahora estamos contentos con el poema. Pero estamos arriba en una nueva sucursal. Por qué no lo fusionamos en la rama maestra. Nosotros hacemos esto, ahora voy a poner este diagrama vale la pena el esperado. Vamos a tratar de traer esto de vuelta aquí abajo y fusionarlo y luego podemos seguir adelante. Este patrón podría parecer familiar dos ustedes sin embargo, porque esto es exactamente lo que miramos en las diapositivas de ahí. Nos vamos a ir justo aquí. Guarda eso. Hagamos git. Bueno, ahora hemos hecho cambios, así que va a querer que nos comprometamos de nuevo. Agregar git commit, ese es un mensaje de commit bastante cojo. No hagas eso. Ahora podemos git checkout master. A ver vamos a cambiar a maestro de sucursal. Ahora mira lo que pasa cuando voy a hello.txt. Va a cambiar de nuevo a donde lo dejamos cuando iniciamos nuestra sucursal. Boom. ¿Ves eso? Por lo que el maestro no está al tanto de lo que hemos estado haciendo en esa otra rama, en nuestra línea de tiempo alterna. Para juntar estas dos cosas, vamos a hacer un git. Hicimos un checkout, vamos a hacer una fusión git. ¿ Cómo llamamos a esa última sucursal, cuarta línea. De lo que eso va a hacer, git va a ir a hacer una copia de esa rama y fusionarla en master. Esto es lo que haría si estuviera contento con lo que había hecho en mi sucursal. Vamos a probarlo. Ahora cuando vaya por aquí. Boom, tenemos todo en master. Entonces el círculo de la vida continúa. Puedo seguir aquí y etcétera Ese es el básico del flujo de trabajo de git justo ahí. Creas algo, lo comprometes, acción, copia de seguridad. Te ramificas, creas algo, lo comprometes, lo vuelves a fusionar. Si iba a seguir adelante de esta manera, podría subir aquí y empezar otra sucursal aquí. Entiendes la idea y sigues así. Eso es lo básico del flujo de trabajo. Simplemente se involucra un poco más cuando empezamos a agregar GitHub y cosas más tarde. Aunque no mucho. Si consigues esto, obtienes git. ¿ Cómo es eso a media o una línea para envolverlo todo. 6. Configura tu cuenta de GitHub: Es hora de obtener tu propia cuenta de GitHub. Acabo de ir al sitio web de GitHub y rellené mi información aquí. Ahora tengo mi cuenta incipiente. Tan solo consigue el gratis por ahora. Si lo deseas, puedes conseguir una micro cuenta. No se puede tener ninguna cuenta privada en la libre, todas tienen que ser públicamente visibles. Si vas a estar trabajando en algo que tenga algún material confidencial o algo que no tengas, que te gustaría poder esconder del mundo exterior, entonces vas a tener que pagarlo. Pero por ahora, sólo voy a terminar esto aquí arriba. Aquí estoy. A ver de esto, digamos: “No gracias”. Este es tu panel que obtienes, y tiene un pequeño paso por aquí que solo te lleva a los docs y dice así es como haces esta función, así es como haces esto. Vamos a hacer eso ahora mismo. Vale la pena jalar definitivamente. Ciertamente aprende algo. Lo primero que vamos a hacer es caminar por cómo se crea un nuevo repositorio. Ahora lo hiciste localmente antes con Git init en tu directorio y espacio de trabajo. Ahora vamos a hacer esto arriba en la Nube en GitHub y mostrarte cómo puedes bajarlo a tu computadora. También puedes comenzar localmente y luego empujarlo hasta tu GitHub. Empezó repo de esa manera. Eso lo cubriré en un minuto. Pero esta es probablemente la forma más fácil de ponerse en marcha. Haces clic en el botón verde grande y el buen viejo GitHub dice: “¿Cómo quieres llamarlo?” Este va a ser el repositorio para nuestro proyecto. Yo lo voy a llamar libro de cocina. Esto tiene que ser público y voy a dar clic en “Inicializar este repositorio con un README”. Te mostraré por qué en un minuto. Ahí vamos. Aquí está mi nuevo repositorio de libros de cocina. Este es el archivo README de forma predeterminada, al llegar a la página de su cuenta de GitHub. Puedes echar un vistazo a esto yendo a cualquier otro repositorio de GitHub por ahí en Internet. Muestra este archivo Léme.md y MD significa rebaja. Markdown es una forma abreviada de escribir HTML. GitHub lo entiende y lo analizará y lo escribirá así. Vamos a estar trabajando en este archivo README para esta clase. Adelante, consigue una configuración de cuenta de GitHub, y vamos a volver a las diapositivas y hablar un poco sobre las formas en que interactuaremos con GitHub y empezaremos a compartir contenido entre sí. En realidad, nos estamos acercando al final de la lección, tenemos unas unidades más que ir, pero yo diría que ya hemos pasado el punto medio y aquí es donde realmente se va a divertir. Consigue tu cuenta y te veré en el siguiente video. 7. Cloning y de forjado - una descripción del flujo de trabajo de GitHub: Aquí vamos. Vamos a echar un vistazo a GitHub. GitHub es esencialmente solo un repositorio de Git que está arriba en github.com. GitHub ha reunido un conjunto de características que te ayudan a trabajar en proyectos basados en equipo. También es una red social para proyectos de código abierto también. Dos de los principales componentes del flujo de trabajo de GitHub son la clonación y la bifurcación. La clonación es básicamente solo hacer una copia. Es como lo que suena, lo que quieres hacer es sacar cosas de tu repositorio de GitHub a tu entorno de desarrollo local para que puedas trabajar en ellas. Cuando haces esta copia, GitHub nombra automáticamente ese origen del repositorio. Es un mando a distancia. Como puedes ver, está lejos de tu entorno de desarrollo local. Ahora, aún tienes un repositorio de Git como lo hemos visto antes localmente y puedes contarlo sobre cualquier número de mandos a distancia. En un proyecto, podría tener un control remoto para implementar código de puesta en escena, podría tener uno para implementar código de producción, incluso puede darle a otros equipos miembros del equipo una dirección remota y código push a ellos. Estos se llaman mandos a distancia. Aquí verás una versión un poco diferente de esa rama, crear, comprometer, fusionar, ciclo que hemos visto antes. Cuando lleguemos a nuestro compromiso y estamos listos para fusionarlo, en lugar de fusionarlo de nuevo en nuestra rama maestra, lo que vamos a hacer es empujar ese contenido hasta nuestro control remoto y fusionarlo ahí arriba. Cuando eso se haya fusionado con la rama maestra, entonces tiraremos esa nueva rama maestra de nuevo a nuestro proyecto e iniciaremos ese ciclo de nuevo. ¿ Y si se trata de alguien más repositorio de GitHub? No tendrás acceso a ella. A menos, por supuesto, que seas un administrador en ese proyecto. ¿ Qué pasa cuando intentas empujar contenido hasta ese repositorio? Bueno, no podrás hacerlo porque no tienes derechos de acceso. En esta condición, deberá presentar lo que se denomina solicitud de pull. Esencialmente, una solicitud de pull es solo un aviso que le das a quien sea dueño de ese repositorio que dice: “Oye, he creado este contenido. ¿ Lo meterás en el proyecto?” La función que sirven es que esencialmente mantiene a todos en el mundo de empujar contenido al proyecto de un propietario sin su permiso. En un proyecto basado en equipos, también da un conjunto extra de ojos al código que se está aportando que generalmente codificará contenido. Alguien más tendrá que revisar lo que se va a enviar y bien para su inclusión. Por lo que es un buen filtro para mantener las cosas limpias. Una pequeña nota; cuando envíes solicitudes de pull, intenta mantenerlas lo más concisas que puedas. No hagas una tonelada de trabajo para quien vaya a tener que revisar esta solicitud de pull. Esperemos que los demás integrantes de tu equipo te extiendan la misma cortesía para que no estés teniendo leer a través de una gigantesca solicitud de pull solo para incluirla en el proyecto. Ahora bien, si se aprueba esa solicitud de pull, el proceso continúa de la misma manera que hemos visto. Se fusionaría en la rama maestra y tirarías ese nuevo maestro hacia abajo e incorporarlo a tu proyecto. Sólo ahora, podría contener presentaciones de otros miembros del equipo. Por lo que conseguirías no solo tu función, sino cualesquiera otras características que se hayan desarrollado mientras has estado trabajando en la tuya. bifurcación es un poco como la clonación. Es solo hacer una copia de otra persona repo allá arriba en GitHub. Empiezas con su repositorio de GitHub, lo bifurcas, y ahora tienes su repositorio de GitHub y tu repositorio de GitHub. bifurcación funciona bien cuando quieres tomar un proyecto de código abierto, hacerlo tuyo, y tomarlo en tu propia dirección. En un proyecto, muchas veces tenderé el repositorio para que tenga esta medida añadida de revisión. Empujaré mi sucursal ahí arriba, revisaré, y luego enviaré una solicitud de pull al repositorio principal. Obtienes un poco de magia de GitHub cuando haces esto. Los dos repos estarán conscientes el uno del otro. GitHub ha desarrollado varias características que hacen revisar y fusionar código o un contenido. Yo uso el código y el contenido indistintamente. Hará cosas, como hacerte saber si las peticiones pobres se pueden fusionar fácilmente o si hay algún problema. Verás un poco más de eso cuando te acompañe por el ejemplo en vivo. Vamos a armar todo esto y ya verás cómo funciona, lo local y lo remoto. Se va a incorporar todas las cosas de las que hemos hablado hasta ahora. Hemos hablado de Git, de control de versiones distribuidas, hemos instalado Git, hemos inicializado un repositorio de Git localmente. Hemos mirado la ramificación, la puesta en escena y el compromiso. Sabemos lo que es HEAD y sabemos lo que es la fusión. Hemos hablado de empujar, qué son los remotos, clonación, bifurcación, y solicitudes de pull. Veamos cómo funciona todo eso en conjunto. Vamos a empezar con un repositorio de proyecto maestro. Vamos a bifurcar eso y tener nuestro propio repositorio, que luego clonaremos a nuestros entornos locales para que podamos trabajar en ello. Haremos nuestro trabajo, empujaremos hasta nuestra bifurcación, y luego enviaremos una solicitud de pull al repositorio principal del proyecto. Una vez que eso esté bien, podemos tirarlo de nuevo a nivel local con cualquier cambio que haya sido presentado por otros miembros del equipo. Ese ciclo sólo se repite y repite. Entonces prepárate. Vamos a hacer esto en vivo ahora. Después de este siguiente video, debes estar listo para contribuir a nuestro proyecto. 8. Clonar un repo de GitHub - demo en vivo: Empecemos con una demo en vivo. Aquí estoy en mi repositorio GitHub fresco que configuré, sobre todo para este proyecto. Yo lo estoy llamando 'cocinarconmarc'. Aquí es donde voy a guardar algunas de mis recetas. No tengo ningún repositorio, así que empecemos uno nuevo ahora mismo. Llamaremos a este brindis, y voy a poner mi receta de tostadas aquí. Se va a dar por defecto a público. Si quieres un repositorio privado, tienes que pagarlo. Entonces nos vamos a hacer público ya que quiero compartir mi receta de tostadas con el mundo. Voy a inicializar esto con un archivo README, lo cual es una buena idea. Al menos el repositorio tiene algo en él. Después basta con hacer clic en el botón verde grande, y ahí vamos. Ahora, vamos a ir por aquí. Voy a clonar esto hacia abajo en mi entorno de desarrollo local. Obtienes clon y pegas esa dirección ahí. ¿ Recuerdas el control remoto de la última serie de diapositivas? Este es el remoto aquí en el que estoy. Así que tuve que clonar esto hasta mi escritorio, y en cuanto haga esto, Git va a escribir en su dirección remota. Déjame hacerlo, tendrá más sentido. Entonces lo ha bajado, vamos a revisar la ventana del Finder aquí, y debería decirnos, seguro, hay tostadas. Entonces si digo git remote, necesito cambiar los directorios al repositorio real ahora. Hago esto cada proyecto. CD en brindis. Ahora hago git remote, y me va a mostrar origen. Entonces ese es el mando que lo tengo, nombres en origen por defecto, puedes cambiarlo por lo que quieras. me gusta seguir la convención de nomenclatura de origen y aguas arriba, sólo porque me ayuda a mantenerlo claro en mi mente hacia dónde exactamente estoy empujando el contenido para más adelante. Ahora puedo hacer un git remote -v para verbose. Esa bandera significa ser verbosa, dime más. Entonces verás que origen tiene esta dirección, cocinarconmarc/toast.git, que es lo que copiamos pegado. Por lo que puedes usar estos orígenes o estos mandos a distancia. Le dices a tu repositorio de GitHub estas direcciones, y te permitirá empujar contenido hacia ellas. Puedo empujar hasta mi repositorio de GitHub. Puedo poner ahí la dirección del repositorio de otra persona, y empujar hacia ella. Esa es una manera realmente ordenada. Está en el núcleo de esa noción de control de versiones distribuidas. Echemos un vistazo al archivo README, vamos a hacer algunas ediciones aquí. Se trata de un archivo Markdown, md significa Markdown. Es una forma de escribir HTML en taquigrafía. Entonces si estás familiarizado con H1, H2, H3 como niveles de encabezado, aunque solo hayas trabajado antes en una aplicación de documento de procesamiento de textos, estás familiarizado con esa idea. que puedas decirle a Markdown que renderice un H1 con un hashtag, dos hashtags como un H2, tres como H3 etc. Aquí están mis ingredientes. Hagamos eso como un H3. Cualquier lugar que tenga un salto de línea, se va a renderizar como un nuevo párrafo. A ver, ¿tengo aquí mi dirección de brindis? Yo guardo eso. Vamos por aquí, y vamos a hacer todo este proceso de creación de etapa de compromiso toda esta rama. Ya empecé a crear sin iniciar una nueva sucursal. Entonces, empecemos una nueva sucursal. Llamaremos a esta salida de receta. Git checkout -b para receta de sucursal. Entonces si hacemos un status git, dice que el README ha sido modificado, y se puede ver aquí mismo cuando iniciamos la rama, llevamos ese README modificado a ella. Entonces voy a decir git add, readme.Markdown, haz un git commit -m para mensaje. Estado de git rápido hasta que todo esté bien. Entonces ahora voy a empujar esto hasta mi repositorio de origen. Entonces voy a decir git push to origin. ¿ Cómo llamamos a esta sucursal? Receta. Ahí vamos. GitHub me va a pedir que autentica con el nombre de usuario y contraseña cada vez que empuje. A menos que tenga configuración SSH, que es un nivel agregado de seguridad. No voy a entrar en ello ahora mismo, eso podría ser un tema para otra clase. Llegaste a Google cómo configurar SSH, no es tan difícil. Entonces si estás escribiendo tu nombre de usuario y contraseña una y otra vez, google eso arriba y ver si puedes conseguir que funcione. Eso suele ser lo que uso. Así que vamos ahora a la cuenta de GitHub. Ya verás que tengo una solicitud de jaleo aquí. Entonces en cuanto empujo ese contenido, GitHub reconoció que era una nueva sucursal entrante, y dice: “¿Quieres hacer una solicitud de pull por eso?” Seguro. Vamos a crear la solicitud de pull. Entonces ahora me va a decir, puedes fusionar esto automáticamente. Eso es genial, hagámoslo. Vamos a fusionarlo, firmarlo. Genial. Entonces lo que se hace es lo mismo que haríamos localmente cuando volveríamos a fusionarnos. Subirás en esa pequeña rama y luego cuando termines de comprometerte, te fusionaste de nuevo en amo. Acabamos de hacer eso aquí arriba en la Nube en nuestro repositorio de GitHub. puedas eliminar esa rama que empujas porque ha sido jalada en tu amo. Ahora, bajemos aquí. Si decimos git, quiero mostrarles esto. Nuestra receta de tostadas es todo en una sola pieza. Seguimos en la rama de tostadas. Entonces si digo git checkout, maestro, mira lo que pasa. Wow, se ha ido todo. Para que esa rama tenga todos esos cambios, maestro no lo tiene. Si estuviéramos trabajando localmente, fusionaríamos la rama de recetas en master. Bueno, vamos a hacer eso desde el repositorio de GitHub en su lugar. Entonces digo git pull, y lo que hace pull, es que sube, mira alrededor para cualquier cosa nueva, lo baja y lo fusiona con cualquier rama aquí en. Entonces git pull origin, maestro. Ahí vamos, y ahora deberíamos tener todos esos cambios. Entonces hay un bucle por el agujero, creando un repositorio, clonándolo hacia abajo, creando contenido, empujándolo hacia arriba, fusionándolo y bajándolo, y completando ese bucle que viste en las diapositivas. Entonces para el siguiente video, voy a hacer lo mismo con bifurcación. Es solo un poco más añadido nivel de complejidad honestamente. Lo que quiero que hagas es ir a probar esto, y conseguir que todo este circuito funcione para ti. Este es tu flujo de trabajo básico de GitHub y Git que utilizarías en cualquier tipo de proyecto web, o proyecto de código abierto, o cualquier cosa por el estilo. Entonces si puedes hacer esto, lo tienes, y la siguiente lección sólo va a ser un poco extra. Así que ten en ello y buena suerte. Nos vemos en un minuto. 9. Forjar un repo de GitHub - demo en vivo: Ahora, vamos a ver bifurcación en GitHub. Esto es típico del proceso por el que pasarías si quisieras contribuir a un proyecto que no poseías. Este es mi repositorio personal arriba en GitHub. Tengo otro navegador abierto con nuestro repositorio de libros de cocina. Si bien estoy conectado aquí como administrador en este navegador, no lo estoy, pero puedo navegar a él. Vayamos a github.com/gitforvisual. Puedo seguir a esta persona aquí, y también puedo mirar los repositorios que tienen. Ya que esto es público, lo puedo bifurcar. Aquí está el ícono del tenedor por aquí. Cuando hago eso, me encanta esta animación aquí. Obtengo un tenedor de GitHub. Ahí vamos. CocinarconMARC/Libro de cocina. Esto va a ser una copia de lo que hay por aquí. A ver cómo igualan. Ahora, necesito seguir el mismo procedimiento que hice cuando estaba clonando. Yo copio esa URL, vuelvo aquí, me aseguro de que estoy en el espacio de trabajo y digamos conseguir clon, pon eso en. Ahí vamos. Ahora debería tener libro de cocina en el espacio de trabajo. Ahí está. Ahora puedo tomar este archivo README y editarlo. Esto en realidad va a ser parte de nuestro proyecto. Una vez más, he hecho lo que se supone que no debes hacer, que es empezar a crear antes de crear una rama. Déjame hacer eso ahora. Nos va a mostrar un status de git rápido. Llegó a ver en el libro de cocina. Ahí vamos. Estado de Git. Git checkout-b, llamaremos a esta rama tortilla. Git agrega el archivo Readme.Markdown, git lo compromete con un mensaje. Ahí vamos. Ahora puedo hacer una tortilla git push origin. Esto va a empujar mi sucursal localmente hasta mi repositorio de GitHub. Aquí es donde vamos a ver entrar la magia de GitHub con el tenedor. Yo hago esto. Ahora vamos a mirar. Suficiente seguro. Ahí está mi sucursal que empujé ahí arriba. Cuando digo comparar y tirar solicitud, me da la opción de crear una solicitud de extracción. Aquí no veo nada que diga cómo fusionarlo. Porque ahora estoy en Git para visual/libro de cocina. Sigue ese enlace mágico desde mi repositorio de GitHub hasta el que me bifurqué. Ahora si voy aquí al Git real para repo visual cookbook en el que estoy logueado como administrador y miro en la solicitud pull, ahí es donde aparece la solicitud pull. Ahora puedo revisarlo y lo puedo fusionar. Se convierte en parte de este repositorio. Volvamos aquí. Ahí vas. Al igual que antes, si voy git checkout master, todo esto debería desaparecer. Boom. Tenemos que tirar esa versión más actualizada de master hacia abajo en nuestro repositorio. Git, tira. Espera un minuto. Aguanta un segundo. Echemos un vistazo a nuestros controles remotos. Sólo tenemos un origen. Necesitamos agregar un mando a distancia para ese repositorio original de libros de cocina. Volvamos ahí atrás. Copia la URL del clon y di, “Git remote add upstream” y pega eso en. Lo que digo es: “Oye git, quiero agregar un mando a distancia, quiero llamarlo aguas arriba”. De nuevo, podría llamarlo todo lo que quiera. Pero aguas arriba y origen son dos convenciones de nomenclatura a las que me apego y a las que mucha gente se adhiere porque te ayuda a separarte en tu mente donde estás empujando estas cosas. El origen es mío y aguas arriba es el principal repo canónico de GitHub. Voy a decir “Enter”. Ahora si digo git remote-b, me muestra mi origen y mis mandos a distancia aguas arriba. Si digo git pull upstream master, va a subir a upstream, va a mirar alrededor para cualquier cosa nueva, lo va a tirar hacia abajo y lo va a fusionar con mi rama maestra. Cuando vuelva aquí, debería tenerlo ahora. Boom, ahí vamos. Ahora, puedo empezar de nuevo todo el ciclo. Si pulsa Comando K, borra la pantalla. A mí me gusta hacer eso con bastante frecuencia. Voy git checkout-b. Digamos que quiero hacer algunos ajustes a la forma en que escribí mi receta. Cuando empiezo esta rama de ajustes, tengo el último y el mayor maestro. Si estuviera colaborando y esto sucederá conforme colaboramos, jalaré todos los cambios que se han agregado por otros integrantes del equipo, así como solo los míos. Cuando empiezo una nueva sucursal, traigo a todos aquellos con ella. Siempre tengo la versión más actualizada. Tengo un nuevo retoques de sucursal. Vayamos aquí. Yo sólo voy a hacer de esto una pequeña actualización. Te diré qué, también voy a poner una línea aquí para separar mi receta de la de todos los demás. Esos son mis ajustes. Git add es un truco. Git add. agrega todos tus documentos en el escenario. Si tienes un montón de cosas abiertas, se puede poner un poco complicado. Pero si normalmente estás trabajando en tres o cuatro archivos, que lo serás si estás haciendo desarrollo web, esto es ordenado y es una taquigrafía que te permite agregar varios a la vez sin escribir todo el nombre del archivo. Git commit m para mensaje, cambió algún texto. Es un mensaje de compromiso bastante pobre, pero vamos a ir con él. Ahora puedo hacer un git push origin. Vamos a llamar a este uno retoques. Yo empujé eso hacia arriba, vamos a echar un vistazo. ¿ Dónde está mi repositorio? Si solicito ajustes, me rebota por aquí, creo la solicitud pull, solo puede ser fusionado por colaboradores del proyecto. Bueno, vayamos por aquí donde soy colaborador y miremos las peticiones de pull. Ahí está. Lo estoy fusionando como administrador por aquí. Ahora puedo decir git checkout master. Yo puedo git pull. Vamos a volver a comprobar esto realmente rápido. Yo soy maestro, así que mis cambios no deberían estar aquí y no lo están. Ya que hago git pull upstream master, va a obtener los últimos cambios y esto ahora debería reflejar los pequeños cambios que hice. Hay un par de bucles a través de la bifurcación. Básicamente eso es todo. Estás al final de esta clase. Has cubierto bastante material y ahora deberías poder configurar tu propio repositorio de Git localmente. Set subió en GitHub y clon y fork. Esas son las habilidades básicas que necesitas para colaborar en un proyecto de equipo usando Git. Enhorabuena, definitivamente corre por esto un par de veces. Entonces vamos a hacer el video final sobre qué presentar para tu proyecto de receta, que prácticamente acabas de ver. Si puedes poner una receta ahí arriba, entonces la has hecho. Ese es todo el objetivo. No mucho trabajo duro real en cuanto a crear algún artefacto, mayor parte del trabajo duro que has hecho en esta clase es solo aprender. Aprender cómo funcionan las cosas y aprender la sintaxis y el protocolo para contribuir. Enhorabuena y nos vemos en el video final. 10. fusionar los conflictos y el proyecto final: Muy bien, todo el mundo. Bienvenido al último video para Git y GitHub para alumnos visuales. Voy a cubrir algo realmente rápido que probablemente no te encuentres en el transcurso de este proyecto. Pero si comienzas a usar Git de cualquier forma basada en equipo, hay una buena posibilidad de que te encuentres con lo que se llama un conflicto de fusión. Se puede ver que entré y estropeé el archivo para que pudiera crear este conflicto de fusión. Básicamente lo que pasa es que, cuando tienes gente contribuyendo y luego retrocediendo y volviendo a contribuir y retrocediendo en ese ciclo, tarde o temprano alguien va a alterar algún código en una línea que alguien más hizo, y podría confundir a Git. Git podría no saber qué versión de los dos cambios diferentes tomar. Por lo que te da un conflicto de fusión. Pero te hará algo útil, señalará dónde está la confusión. Entonces aquí mismo se ve una selección, donde en un caso alguien presentó el nombre de Marc Nischan Esquire, y el otro Marc Nischan PhD. Por lo que Git ha envuelto esto en un pequeño comentario. Verás estos distintivos patrones de mayores thans y menos thans divididos por una línea sólida. Por lo que Git está diciendo que este gran número es el ID real del commit. Entonces Git está diciendo, entre estos dos, ¿cuál quieres conservar, esencialmente? Entonces todo lo que tienes que hacer es arreglar esto. Voy a quedarme con Esquire. Si bien, no soy ni Esquire ni doctorado. Pero esa es una historia completamente diferente. Entonces emparejo esto para que sean solo los textos que quiero guardar, y había otro aquí abajo, parece que estos espacios fueron alterados. Eso no tiene mucho sentido, sólo nos desharemos de eso también. Entonces ahora puedo guardar esto. Hagamos un estatus de Git y veamos qué obtengo. Genial. Git add. Git commit -M, mensaje, resolver un conflicto de fusión. Ahí vamos. Entonces es una mirada rápida a los conflictos de fusión. Otra opción que tienes es descargar una herramienta de fusión. Yo uso P4Merge, es gratis. Está bastante bien. puede ver en esta imagen de aquí, Sepuede ver en esta imagen de aquí,básicamente alinea lo que hay en el mando a distancia, lo que hay en tu computadora, y lo que hay en la rama que has derribado. Te pide que elijas entre las diferentes versiones, y ahorra la que elijas. Entonces esta es una manera visual realmente ordenada de pasar por estas cosas. Te permite desplazarte por todo el documento, y te muestra todos estos diferentes lugares donde están los errores. No quiero entrar en instalarlo. Hay unos grandes tutoriales por ahí sobre cómo instalar esta cosa. Hay muchas herramientas de fusión gratuitas. Así que mira a tu alrededor, elige uno que te guste, y puedes conseguir que funcione, estoy seguro bastante rápido. Entonces ahora lo que quiero hacer es correr por todo un ciclo. Básicamente, este es tu proyecto final. Todo el ciclo de agregar una receta, y comprometerla localmente y empujarla hacia arriba para su inclusión en el libro de cocina maestro. Entonces aquí vamos. Entonces aquí está mi proyecto, proyecto de libro de cocina. Voy a añadir otra receta. Esto es más o menos lo que harías. Empezarías bifurcando, clonando, y luego empezando en una nueva rama. Entonces estoy en maestro ahora mismo. Eso puedo comprobar yendo al estado de Git. Hagamos un checkout de Git -B y llamaremos a esta nueva sucursal, ajo. Porque voy a agregar receta de ajo asado. Entonces bajemos al final de mi último. Aquí mismo, consiguió un montón de formateado en Markdown. Por lo que no tendremos que perder tiempo alguno. Ahí vamos. Entonces guárdelo, y necesito agregarlo, cometerlo. Ahora voy a empujar eso hasta mi versión bifurcada de esto. Estoy usando la convención de nomenclatura de origen y aguas arriba. Upstream siendo el original, y el origen siendo el que bifurqué. Entonces vamos a empujar estos cambios hacia arriba Git. Empuje cabeza origen. Entonces empuja al origen donde estoy ahora mismo. Ahí vamos. Ahora como voy a mi repo, aquí, libro de cocina, tengo la opción de hacer una solicitud de comparar y tirar, que voy a hacer. Genial. Está al día con la sucursal base, así que no debería tener ningún problema para fusionar esto en. Entonces ahora vuelvo a este otro navegador donde estoy logueado como el administrador, y miraré las solicitudes de pull, y ahí está. Entonces esto es lo que estaré haciendo cuando reciba su solicitud de pull. Voy a mirarlo, revisar los archivos, asegurarme de que no haya nada loco ahí dentro. Ahora notarás estos iconos aquí. Te dejan ver el expediente completo. Básicamente esconde cosas que no tienen ningún conflicto, cosas que has visto antes. Hace que sea más fácil escanear los cambios y no tener que preocuparse por todo el texto intermedio. Bueno, todo esto se ve bien. Volvamos atrás y fusionemos eso. Eso es todo. Entonces ni siquiera tendrás que hacer este paso, todo lo que realmente tienes que hacer es empujarlo hacia arriba, y dejar que la solicitud de pull pase a este repo, momento en el que realmente lo agrego al libro de cocina. Pero lo que puedes hacer cuando vas a Skillshare para tu proyecto final, es solo tomar una captura de pantalla de tu versión, tu perfil de esto. Tan solo toma una captura de pantalla y publica eso como el proyecto final. Eso debería hacerlo. Muchas gracias por tomar esta clase, de verdad lo aprecio. Si te resultó útil, una crítica positiva realmente hace que esta clase sea más fácil para otras personas encontrarla, la deja flotar un poco hasta la cima. Entonces, si lo encontraste útil, por favor dale una revisión positiva, y ayuda a otras personas a encontrarlo. Por supuesto, si tienes alguna retroalimentación, positiva o negativa, me encantaría escucharla. Entonces tal vez pueda hacer que esta clase sea un poco mejor. Gracias de nuevo y la mejor de las suertes. Una última cosa que quiero decirte es que, puse gitforvisual.com. Como puedes ver, no hay mucho ahí ahora mismo. Pero lo que sí tiene, es este PDF que puedes descargar. Básicamente es una hoja de tramposos que camina por todo este proceso por el que hemos pasado juntos aquí en la clase. Eso es algo que puedes tener a mano si solo quieres una referencia rápida para el flujo de trabajo que hemos descrito. Entonces ahí lo tienes. Una vez más, muchas gracias. Agradezco tus comentarios, y disfruto de Skillshare, y Git. Muchas gracias. Adiós.