Introducción a Git

1

¿Por qué usar un sistema de control de versiones como Git?

2

¿Qué es Git?

3

Instalando GitBash en Windows

4

Instalando Git en OSX

5

Instalando Git en Linux

6

Editores de código, archivos binarios y de texto plano

7

Introducción a la terminal y línea de comandos

Comandos básicos en Git

8

Crea un repositorio de Git y haz tu primer commit

9

Analizar cambios en los archivos de tu proyecto con Git

10

¿Qué es el staging?

11

¿Qué es branch (rama) y cómo funciona un Merge en Git?

12

Volver en el tiempo en nuestro repositorio utilizando reset y checkout

13

Git reset vs. Git rm

Flujo de trabajo básico en Git

14

Flujo de trabajo básico con un repositorio remoto

15

Introducción a las ramas o branches de Git

16

Fusión de ramas con Git merge

17

Resolución de conflictos al hacer un merge

Trabajando con repositorios remotos en GitHub

18

Cómo funcionan las llaves públicas y privadas

19

Configura tus llaves SSH en local

20

Uso de GitHub

21

Cambios en GitHub: de master a main

22

Tu primer push

23

Git tag y versiones en Github

24

Manejo de ramas en GitHub

25

Configurar múltiples colaboradores en un repositorio de GitHub

Flujos de trabajo profesionales

26

Flujo de trabajo profesional: Haciendo merge de ramas de desarrollo a master

27

Flujo de trabajo profesional con Pull requests

28

Utilizando Pull Requests en GitHub

29

Creando un Fork, contribuyendo a un repositorio

30

Haciendo deployment a un servidor

31

Hazme un pull request

32

Ignorar archivos en el repositorio con .gitignore

33

Readme.md es una excelente práctica

34

Tu sitio web público con GitHub Pages

Multiples entornos de trabajo en Git

35

Git Rebase: reorganizando el trabajo realizado

36

Cómo usar Git Stash: guarda cambios temporalmente

37

Git Clean: limpiar tu proyecto de archivos no deseados

38

Git cherry-pick: traer commits antiguos al head del branch

Comandos de Git para casos de emergencia

39

Git Reset y Reflog: úsese en caso de emergencia

40

Reconstruir commits en Git con amend

41

Buscar en archivos y commits de Git con Grep y log

Bonus sobre Git y Github

42

Comandos y recursos colaborativos en Git y GitHub

43

Tu futuro con Git y GitHub

Crea una cuenta o inicia sesión

¡Continúa aprendiendo sin ningún costo! Únete y comienza a potenciar tu carrera

¿Qué es branch (rama) y cómo funciona un Merge en Git?

11/43
Recursos

Una rama o branch es una versión del código del proyecto sobre el que estás trabajando. Estas ramas ayudan a mantener el orden en el control de versiones y manipular el código de forma segura.

En otras palabras, un branch o rama en Git es una rama que proviene de otra. Imagina un árbol, que tiene una rama gruesa, y otra más fina, en la rama más gruesa tenemos los commits principales y en la rama fina tenemos otros commits que pueden ser de hotfixdevlopment entre otros.ㅤ

https://static.platzi.com/media/user_upload/ramas-branch-en-git-7e72b407-90cc-4b90-8de1-738b155764eb.jpg

Clases de branches o ramas en Git

Estas son las ramas base de un proyecto en Git:

1. Rama main (Master)

Por defecto, el proyecto se crea en una rama llamada Main (anteriormente conocida como Master). Cada vez que añades código y guardas los cambios, estás haciendo un commit, que es añadir el nuevo código a una rama. Esto genera nuevas versiones de esta rama o branch, hasta llegar a la versión actual de la rama Main.

2. Rama development

Cuando decides hacer experimentos, puedes generar ramas experimentales (usualmente llamadas development), que están basadas en alguna rama main, pero sobre las cuales puedes hacer cambios a tu gusto sin necesidad de afectar directamente al código principal.

3. Rama hotfix

En otros casos, si encuentras un bug o error de código en la rama Main (que afecta al proyecto en producción), tendrás que crear una nueva rama (que usualmente se llaman bug fixing o hot fix) para hacer los arreglos necesarios. Cuando los cambios estén listos, los tendrás que fusionar con la rama Main para que los cambios sean aplicados. Para esto, se usa un comando llamado Merge, que mezcla los cambios de la rama que originaste a la rama Main.

Todos los commits se aplican sobre una rama. Por defecto, siempre empezamos en la rama Main (pero puedes cambiarle el nombre si no te gusta) y generamos nuevas ramas, a partir de esta, para crear flujos de trabajo independientes.

Cómo crear un branch o rama en Git

El comando git branch permite crear una rama nueva. Si quieres empezar a trabajar en una nueva función, puedes crear una rama nueva a partir de la rama master con git branch new_branch. Una vez creada, puedes usar git checkout new_branch para cambiar a esa rama.

Recuerda que todas tus versiones salen de la rama principal o Master y de allí puedes tomar una versión específica para crear otra rama de versiones.

Cómo hacer merge

Producir una nueva rama se conoce como Checkout. Unir dos ramas lo conocemos como Merge.

Cuando haces merge de estas ramas con el código principal, su código se fusiona originando una nueva versión de la rama master (o main) que ya tiene todos los cambios que aplicaste en tus experimentos o arreglos de errores.

Podemos generar todas las ramas y commits que queramos. De hecho, podemos aprovechar el registro de cambios de Git para producir ramas, traer versiones viejas del código, arreglarlas y combinarlas de nuevo para mejorar el proyecto.

Descubre qué son los git tags

Solo ten en cuenta que combinar estas ramas (hacer “merge”) puede generar conflictos. Algunos archivos pueden ser diferentes en ambas ramas. Git es muy inteligente y puede intentar unir estos cambios automáticamente, pero no siempre funciona. En algunos casos, somos nosotros los que debemos resolver estos conflictos a mano.

Contribución creada con los aportes de: Diego García, Andres Avalos, Jessica Ortiz y Edgar Rodriguez.

Aportes 540

Preguntas 59

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Esto es lo que entendi de la clase, espero les ayude 😄

Usar git es cómo ser un Dr. Strange del desarrollo. Movernos entre branches es como moverse en realidades alternas. Hacer merge es unir esas realidades.

| Apuntes|

Como trabajar con Git Flow
Git flow workflow - Historical Branches

Feature Branches

Release Branches

Hotfix Branches

Fuente: . Atlassian

🚨🚨🚨 IMPORTANTE! 🚨🚨🚨
A partir del 1 de Octubre del 2020 en los nuevos repositorios la rama principal deja de llamarse MASTER. Ahora es nombrada como MAIN.

Más detalles acá: https://github.com/github/renaming

Ramas base de un proyecto en git

Ahora entiendo la Sagrada Linea de Tiempo de Loki. en Marvel. jajaja… Me volveré un Guardián de ella gracias al Universo Platzi.

Compañeros, les comparto un poco de lo visto en clase + mis notas escritas, espero les sirva…#NuncaParemosdeAprender - Compartamos +Y+Conocimiento

Conceptos Básicos:

Un Bug es un error en programación que ocasiona un resultado inseperado.

Merge: Se da cuando los cambios se unen en una rama corta con respecto a la otra.

![](

Hola compañeros, para todos aquellos que esten tomando el curso despues de octubre del 2020, les cuento que debido a una actualización de GitHub, la rama “Master” ha cambiado su nombre por defecto a “Main”. Les informo para que no se lleven sorpresas mas adelante. Un saludo y recuerden nunca parar de aprender ❤️.

Resumen de clase:
Master: Esta es la rama donde se inicia siempre por defecto (se le puede asignar cualquier nombre), a partir de esta rama se crean todas las ramas, en esta rama estan todos los cambios de tus archivos.

Commit: Cada vez que haces una nueva rama lo único que se hace es que copias un commit, que pasa a la rama de a lado, en la cual puedes continuar trabajando sin afectar el flujo de trabajo principal que esta en la rama master.

Development (o rama experimental): Esta es una versión copiada de la rama master, donde experimentás, observás características, featueres entre otros. Para finalmente unirlas a la rama master cuando estén listas.

Bugfixing o Hotfix: Esta rama se encarga de repara cualquier bug, issues (errores) o fallas que surjan en la rama experimental, aquí puedes hacer cualquier clase de cambios para después probarlo en tu rama master.

Checkout: Crea una nueva rama.

Merge: Es una brecha que une dos ramas

Head: Es a donde llevás todo cuando ya tienes tu versión final.

Resumen de la clase

Estoy volviendo a ver el curso. Para repasar y tomar notas con Notion

Aqui hay una guia que use para entender git por primera vez… sinceramente les recomiendo que la lean…
https://rogerdudler.github.io/git-guide/index.es.html

Estándar común entre desarrolladores de git:

  1. Master – Para producción.
  2. Feature – Para las nuevas características.
  3. Development – Para las pruebas o experimentos.
  4. Hotfix – Para solucionar los errores y unirlas a la rama master.

🤗

Wait... Entonces el Master existe en el entorno local y el servidor. ¿Correcto? ... Es decir hay un local master y un remote master.

En Learn Git Branching es posible practicar y aprender más sobre ramificación, chéquenlo… 😛

Yo lo veo así, como una forma de entenderlo mejor:

  • Nueva tarea: nueva rama
  • cada paso para completar la tarea: es un commit
  • unir tu tarea completada con las tareas de los demas: merge

Git checkout NO es para crear ramas! es para moverte entre ramas
la creacion de una rama es Git branch + nombre de la rama!

pd: lo digo porque en la descripcion freddy hace referencia a que checkout es para crear una nueva rama!

espero su feedback ❤️

¡Atómico! A-tó-mi-co.

La rama/repositorio por defecto de git es master
Cada commit es una versión en git, y cada versión tiene su código identificador
Crear ramas con el comando checkout
Unir ramas a master con el comando merge

Con la práctica te convertirás en un profesional destacado

He quedado enramada 😃

Mis apuntes
Una rama representa una línea independiente de desarrollo, es como crear un nuevo área de trabajo con su área de ensayo y su historial. Los nuevos commits se registrarán de forma independiente en el historial la rama, lo que se conoce como forks en el historial del proyecto (término muy empleado en github).

Listar, crear y manejar ramas, git branch
git branch
Este comando lista las ramas locales que existen. La rama en la que estás trabajando actualmente se señala con un asterisco *. La rama master es la rama con la que se comienza en cualquier proyecto, y es la que se utiliza como rama principal donde se encuentra el proyecto en su estado final.

git branch [rama]
Este comando crea una rama con el nombre que elijas.

git checkout experimento
Si hemos nombrado a la rama “experimento”, este comando nos sitúa en esa rama.

Si estábamos en la rama master, teníamos archivos modificados sin añadir o añadidos en el área de ensayo, y nos situamos en la rama experimento con git checkout, éstos cambios se verán en la rama experimento. Hasta que no se haga un commit, los cambios no pertenecerán a ninguna rama.

git branch -v
Este comando muestra el último commit en cada rama.

git checkout -b [rama]
Este código crea una rama y hace checkout directamente en la misma. Es el código que se suele usar ya que cuando se crea una rama normalmente se suele hacer checkout en ella.

Es bastante frecuente crear una rama, hacer los cambios que sean necesarios, unirla a una rama principal y después eliminar la rama que se había creado. De esta forma si has estado haciendo cambios que realmente no han resultado ser buenos puedes deshacerte de la rama con facilidad.

git branch -d [rama]
Este código elimina una rama.

Unir una rama a la rama actual, git merge
Una vez que has trabajado en una rama, lo normal es querer incorporar los cambios a la rama principal. Para unir una rama a la actual se utiliza el siguiente comando:

git merge
Cuando sólo se han añadido o eliminado archivos en una rama, es fácil unirla a la principal. El resultado simplemente será la suma o resta de esos archivos en la principal. Cuando se hacen modificaciones en archivos, incluyendo cambios en los nombres de los archivos, git detecta esos cambios y los adapta automáticamente, pero a veces surgen conflictos.

espero les pueda servir mis apuntes jejeje si hay errores me comentan 😃

Me encanta el formato de explicación, los detalles y la forma de expresarse John Freddy Vega

Como recomendación, es importante que nunca se trabaje o se hagan cambios directamente sobre la rama master, en la rama master solo debería existir la versión mas estable de nuestro proyecto o (lo que está en producción). Mientras estemos agregando nuevas caracteristicas, todo debería estar en una rama de desarrollo o development

Freddy tienes un don para explicar las cosas, Excelente! 😄

Como recomendación personal, revisen periódicamente sus repositorios, me he topado con repositorios internos donde tenemos mas de 60 ramas de las cuales solo el 5 o 10% son útiles, el resto son funcionalidades que se abandonaron o que se rechazaron,

Hola compañeros, para los que se encuentren realizando este curso para despues de mediados de octubre del 2020, les cuento que debido a una actualización de Git, la rama “Master” ha cambiado su nombre por defecto a “Main”. Les aviso para que no se lleven sorpresas creando repositorios mas adelante. Un saludo y #NuncaParenDeAprender ❤️

Branch y Merge en Git

En cada repositorio de git vamos a tener una rama (branch) llamada
Master esta rama tiene el resultado final de nuestro proyecto (es decir todos los commit)
En git podemos agregar ramas que no necesariamente sus commits van a ser enviados a Master.
Podriamos tener una rama llamada Development donde tomamos una version especifica del Master para poder trabajar sobre ella en un proyecto que aun no sabemos si lo vamos a unir al proyecto final.

Al momento de unir nuestra rama Development con la rama Master debemos de hacer un MERGE que crea una nueva version final uniendo todo.

NOTA Puede haber problemas de compatibilidad entre una rama y la otra.

3 ramas a considerar en los proyectos:

  • Master
  • Development (Desarrollo)
  • Hotfixing (bugfixing)

Buena explicación.

Realice esto según lo que entendí.
Pd: Acepto correcciones.

¿Qué es un Branch (rama) y cómo funciona un Merge en Git?
Git es una base de datos muy precisa con todos los cambios y crecimiento que ha tenido nuestro proyecto. Los commits son la única forma de tener un registro de los cambios. Pero las ramas amplifican mucho más el potencial de Git.

Todos los commits se aplican sobre una rama. Por defecto, siempre empezamos en la rama master (pero puedes cambiarle el nombre si no te gusta) y creamos nuevas ramas, a partir de esta, para crear flujos de trabajo independientes.

Crear una nueva rama se trata de copiar un commit (de cualquier rama), pasarlo a otro lado (a otra rama) y continuar el trabajo de una parte específica de nuestro proyecto sin afectar el flujo de trabajo principal (que continúa en la rama master o la rama principal).

Los equipos de desarrollo tienen un estándar: Todo lo que esté en la rama master va a producción, las nuevas features, características y experimentos van en una rama “development” (para unirse a master cuando estén definitivamente listas) y los issues o errores se solucionan en una rama “hotfix” para unirse a master tan pronto como sea posible.

Crear una nueva rama lo conocemos como Checkout. Unir dos ramas lo conocemos como Merge.

Podemos crear todas las ramas y commits que queramos. De hecho, podemos aprovechar el registro de cambios de Git para crear ramas, traer versiones viejas del código, arreglarlas y combinarlas de nuevo para mejorar el proyecto.

Solo ten en cuenta que combinar estas ramas (sí, hacer “merge”) puede generar conflictos. Algunos archivos pueden ser diferentes en ambas ramas. Git es muy inteligente y puede intentar unir estos cambios automáticamente, pero no siempre funciona. En algunos casos, somos nosotros los que debemos resolver estos conflictos “a mano”.

😊

🤗

Es una herramienta obligatoria entonces de aprender

Mis apuntes de la clase:

Clase 11 – ¿Qué es Branch (rama) y cómo funciona un Merge en Git?


¿Cómo se llama la rama principal por defecto en Git?

  • Master.

¿Qué representan los commits que hacemos en nuestra rama Master?

  • Diferentes versiones de la rama Master.

¿Qué debemos hacer cuando queremos tener una copia de nuestra versión actual de la rama Master y queremos hacer unos cambios sin que necesariamente afectemos nuestra versión actual?

  • Crear una rama.

¿Qué debemos hacer cuando surge un Bug en nuestra versión actual de la rama Master?

  • Crear una rama para poder arreglar el Bug.

¿Cuál es el nombre por defecto que tiene la rama que creamos para arreglar los Bugs?

  • HotFix.

¿Qué es un Merge?

  • Es la acción de fusionar dos ramas en una.

¿Cuál es el nombre por defecto que tiene la rama que usamos para realizar experimentos en nuestro proyecto?

  • Development.

¿Podemos tener todas las ramas que queramos en un mismo repositorio de Git?

  • Sí.

¿Qué es un conflicto?

  • Es el momento en el que surge un error al hacer un merge.

bug = bəɡ 😉

Definitivamente es muy importante practicar, practicar y practicar. Como dice Freddy, solo con ver el video no es suficiente.

La convención de llamar a “Master” a la rama principal del proyecto cambió hace poco, ahora se le llama “Main”

Tip: Podemos usar git bash directamente desde visual studio code

git es amor

Si quieren profundizar un poco sobre la forma en que se realizan estos merges les dejo este artículo: https://www.atlassian.com/es/git/tutorials/using-branches/merge-strategy

Commit

Un commit es un cambio rastreable (de 1 o varios archivos), es confirmar un conjunto de cambios provisionales de forma permanente y tenemos el superpoder de ponerle nombre a este cambio.

La historia de tu desarrollo se van guardando mediante commits, ya que cada cambio confirmado tiene modificaciones importantes hasta llegar al cambio actual.

Para hacer un commit, es muy sencillo, tenemos que tener agregado en el staging (git add -A) y usar el comando commit

Git commit -m 'commit'

Si trabajamos en algo experimental o que no queremos que sea parte del flujo principal, podemos hacer una nueva rama (branch), recordemos que la rama principal suela llamarse master, por lo tanto ésta branch nueva tendrá su propia historia (posterior al punto donde se creó).

Para crear una rama nueva con la información de la rama actual usamos el comando

git checkout -b nombre-del-branch

Si los cambios que realizaste en tu rama nueva son un avance en el código, puedes fusionarlo a la rama master (o a otra), para ésto tienes que cambiarte a master y hacer el comando es merge

git checkout master # nos cambiamos a la rama master
git merge rama-nueva # Fusionamos los cambios de la 'rama-nueva' en master

git merge => Mezclar Ramas (En escencia)

Apuntes del curso 👉🏻 acá
Apuntes de la clase 👇🏻

Llevo un tiempo utilizando Git en distintos proyectos, pero en ningún momento me había detenido a estructurar su funcionamiento, definitivamente es impresionante!

Es excelente la forma en la que se explica este tema, en realidad en una empresa las ramas (la mayoría de las veces) se llaman así como menciona Freddy). Por acá dejó links de la documentación oficial de Git donde se hablan sobre estos temas.
¿Qué es una rama?
Procedimientos básicos para ramificar y fusionar

Git-merge Une dos o más historiales de desarrollo.

GIT FLOW ❤️

Muy buena explicación, aunque Freddier debe mejorar su técnica de dibujo jaja

Braches y Git Flow 🚀

Les dejo un tutorial de Atlassian en la que profundizan sobre los distintos tipos de flujo que podemos usar con Git:

https://www.atlassian.com/es/git/tutorials/comparing-workflows

📝 Las ramas nos permiten llevar un mejor control del código. Crea un nuevo camino de cara a la evolución del código, en paralelo a otras ramas que se puedan generar.

No se imaginan el tiempo que ahorro cuando los apuntes ya estan hechos dentro del curso, me preocupo mucho más por entender el video y experimentar y no por resumir. Así deberían ser todos los cursos!!!.

Un consejo que Freddy repite y estoy seguro que muchos no escuchamos: “Asegúrense de ir practicando lo que ven”. No basta con solo ver videos. Voy por la lección 30, y hoy por fin estoy practicando en un repo y aquí estoy, regresando a la lección 11, porque en su momento no iba practicando.

No cometan el mismo error. Aunque sea con archivos de texto como propone Freddy, vayan practicando"

Un ejemplo de lo que nos mostró Freddy:

Git puede funcionar como un árbol para organizar sus versiones.

  • La rama principal se llama Main (antes Master), pueden identificarse dos ramas que salen de ella, la Development (experimental) y HotFix (Bug Fixing).
  • La development sirve para experimentar o probar cosas sin afectar al código principal.
  • La rama HotFix se usa para corregir algún error que se encuentre en la rama Main. Al final se fucionan las dos ramas cono los arreglos hechos.

Crear una nueva rama se conoce como “checkout” y unir dos ramas se llama “Merge”.
Se debe mantener el orden entre versiones y ramas para evitar conflictos al hacer un merge. Algunos de estos nesecitan que los resolvamos a mano, ya que git no siempre puede unirlos automáticamente.

Mi resumen:
Por defecto estamos en la rama master que es donde se guardan los cambios de mis archivos y donde se crean las diferentes versiones a medida que aplicamos commit.
Rama Development: consiste en copiar la versión que deseamos (actual o anterior) de la rama master con un nombre diferente, para realizar pruebas en una rama diferente la cual a medida que le apliquemos commit generará sus propias versiones.
Si tenemos que solucionar problemas de la rama actual (master), como un bug, debemos crear una rama especial llamada hotfix y en esta rama realizamos los cambios para posteriormente probarlos con la rama actual, esa prueba o esa conexión con la rama actual es conocida como un merge.
En definitiva el merge nos permite traer los cambios realizados en otras ramas a la versión actual.
Podemos tener tantas ramas y repositorios como queramos.

Este articulo interesante muestra algunas estrategias para manejo de ramas y las compara entre ellas https://dev.to/arbitrarybytes/comparing-git-branching-strategies-dl4

Muy bien explicado!

11. ¿Qué es un Branch (rama) y cómo funciona un Merge en Git?


Este flow de git me ha ayudado mucho a como moverme entre ramas. Este tema ha sido de muchas discuciones; ya que, es aquí donde puedes dañar tu codigo.
https://nvie.com/posts/a-successful-git-branching-model/

conflicto: Cuando al hacer un merge los cambios de una rama rompan los cambios de la otra.

https://www.youtube.com/watch?v=VdGzPZ31ts8

ME GUSTA COMO EXPLICA FREDDY PERO POR ACA DEJO UN VIDEO DONDE HAY UNA EXPLICACION MUY BUENA DE TODO LO VISTO QUE ME PARECE IMPORTANTE

Los hotfix o cambios en caliente te realizan una copia de la rama de producción (comúnmente la rama es master) y a partir de ahí realizar los cambios, al finalizar tus cambios, finalizas el hotfix y los cambios se mezclan en la rama de producción y en la rama de desarrollo (master, develop) de esta manera se garantiza que se corrige el problema en producción y hacia el futuro dado que en algún momento lo que este en la rama de desarrollo saldrá a producción.
Te invito a revisar que son los flujos de trabajo en git:

git flow init -f

Donde tendrás que definir cual es la rama que tienes para producción cual para desarrollo, cual para nuevas características, cual para los cambios en calientes, etc.
https://readthedocs.org/projects/git-flow/downloads/pdf/latest/
https://www.atlassian.com/es/git/tutorials/comparing-workflows/gitflow-workflow

Mis notas de la clase

Resumen de palabras para trabajar en equipo:

Branch Master: es la rama principal, ““la primera””.
Branch: (rama) son todasa las ramas que tienes.
Merge: (unir) es unir un commit con otro commint, pueden ser de diferentes versiones.
Cheout: (revisar) es crear una rama nueva.
Hotfix: (revisión) es revisar lo mas rapido posible porque hay que unirla a un Brach.

Espero les sea util: 😎💚💚

Leer también el libro que recomienda al principio me está ayudando mucho, así se puede profundizar más.

Esto se podría explicar bien con la idea de los multuniversos de Marvel.

Ramas:

  • Herramienta de git para tener diferentes flujos de trabajo y luego fucionarlos.
  • Las ramas se crean copiando un commit anterior (checkout) para luego generar un nuevo flujo sobre este.
  • Fucionar dos ramas (merge) puede generar conflictos: diferencias entre ambos archivos.
  • Algunas ramas usuales son:
    hotfix: rama de solucion de errores
    development: rama de experimentos

**Ramas: **
Master: Rama principal de nuestro repositorio (Donde estan las versiones 1, 2, 3… actual).

Nombres comunes para una rama en la que arreglamos fallos: bugfixing/hotfix.

**Ramas: **
Master: Rama principal de nuestro repositorio (Donde estan las versiones 1, 2, 3… actual).

Nombres comunes para una rama en la que arreglamos fallos: bugfixing/hotfix.

Cuando queremos fusionar los cambios de una rama con la rama master (u otra rama):

git merge [nombreDeLaRama]

Puedes practicar el uso de las ramas haciendo modificaciones a los proyectos de los cursos, esto te servirá de práctica. Al final puedes tener tantas variantes como ramas en tu repositorio, tu decidirás si quieres hacerle merge a éstas o dejarlas tal cual.

Desde octubre del 2020 ahora la rama master tiene como nuevo nombre main.

  • Lo único que cambia es el nombre y tener en cuenta el nombre en los comandos
  • Dadle ❤️ para que todos se enteren y no se vayan a perder 😃
  • Suerte 😄

Si en el proceso de “Merge” tengo 2 cambios diferentes en la misma línea entre las ramas como se elige que cambio dejar?

Es posible hacer un merge entre más de 2 ramas?

Les comparto mis notas de Git y GitHub en la web:

https://todointerconectado.com/Proyectos/2-Git_GitHub/index_git.html

GitFlow es una herramienta de control de versiones diseñada para simplificar el proceso de desarrollo de software. Fue creada por Vincent Driessen y se basa en el modelo de desarrollo propuesto por el mismo. GitFlow proporciona una manera estructurada para desarrollar código, actualizar la documentación, administrar los problemas y lanzar cambios al código de producción. Esto asegura que todos los cambios se realicen de manera segura y controlada.

GitFlow se basa en dos ramas principales: “master” y “develop”. Estas dos ramas son usadas para almacenar los cambios realizados en el código. La rama master se usa para almacenar la versión del código en producción y la rama develop se usa para almacenar los cambios que se realizan antes de que sean liberados a producción.

Además de las ramas principales, GitFlow también usa ramas “feature” para almacenar los cambios que se realizan para agregar nuevas funcionalidades al código. Estas ramas se crean de la rama develop y se pueden fusionar de vuelta una vez que los cambios han sido completados.

GitFlow también usa ramas “hotfix” para corregir errores en el código. Estas ramas se crean de la rama master y se fusionan de nuevo una vez los cambios se han realizado.

GitFlow es una excelente herramienta para cualquier equipo de desarrollo que busca mejorar su flujo de trabajo. Al usar GitFlow, los equipos pueden realizar cambios de manera segura y controlada, lo que les permite desarrollar, probar y lanzar cambios con mayor rapidez y eficiencia.

Funcion y uso del Git: Por defecto cada commit que enviamos al repositorio va directo a la carpeta master esta carpeta la llamaremos asi por que es la carpeta donde esta la versiona final del proyecto que estamos haciendo. Ahora que pasa cuando queremos experimentar con algun otro tipo de framework nuevo o simplemente queremos trabajar con otras personas en el mismo proyecto sin romper el codigo o simplemente tenemos unos errores o bugs que no nos dejan hacer nada en nuestro proyecto, para eso tenemos las siguientes ramas de git:


  • master: Es la rama donde se guardaran todas las versiones del archivo final que subas al repositorio

  • development: Esta es la rama que se usa cuando queremos hacer pruebas con otros frameworks, hacer actualizaciones o simplemente experimentos

  • hotfix: Esta rama la utilizamos para arreglar bugs o errores que encontremos en nuestro codigo alojando dichas versiones aqui para no dañar todo el proyecto


IMPORTANTE Puedes tener todas las ramas necesarias que creas posibles llamarlas como gustes y tenerle su utilidad cualquiera, lo importante es tener en mente que tienes que utilizar un esquema para no dañar el codigo que tienes, trabajar en experimentos y un apartado para resolver los errores todo esto sin dañar tu proyecto

En algunos repositorios remotos, si está el bugfix, esto quiere decir que son bugs menores o que no afectan producción. El hotfix si es para corregir y enviar en caliente a producción. Cualquiera de las dos formas son válidas.

ramas de un proyecto:
Master: esta es la rama principal del proyecto
Development : rama para hacer experimentos o probar nuevas posibilidades sin sin involucrar a la rama principal
hotFix : rama para solucionar bugs o errores en el proyecto

Merge: Lleva una versión de cualquier otra rama a la rama master. Cuando se aplica este comando se pueden generar conflictos que rompan versiones anteriores.

aqui les dejo el aporte de una compañera de clases anteriores:
https://drive.google.com/file/d/1ADhTgqUuDQRXriN3HXkOpHhOctDuzB2J/view

hotfix: Un arreglo en caliente

Branch y Merge

Las Ramas

Las ramas son utilizadas para desarrollar funcionalidades aisladas unas de otras. La rama master es la rama “por defecto” cuando creas un repositorio. Crea nuevas ramas durante el desarrollo y fusiónalas a la rama principal cuando termines.

Crea una nueva rama llamada “feature_x” y cámbiate a ella usando

git checkout -b feature_x

Vuelve a la rama principal

git checkout master

Borrar la rama

git branch -d feature_x

Una rama nueva no estará disponible para los demás a menos que subas (push) la rama a tu repositorio remoto

git push origin <branch>

Los commits (Versiones) Se aplican sobre una rama (Por Default es la Rama Master). Pero con Checkout podemos crear otras ramas.
Ventajas de tener otras ramas:

  • Hacer experimentos con el código sin tocar la versión actual

  • Reparar errores sin tocar la versión actual.

Cuando queremos combinar una de las versiones de las ramas a la rama master (o a cualquier otra de las ramas) usamos el comando merge.

Master
Branch/NewDevelopment(V1)
Branch/NewDevelopment(V2)

	Branch/HotFixFalladeSeguridad
	**Merge with Master**
	
	_Branch/NewDevelopment(V2)_ **Merge With 		 
              MAster**