Resolución de conflictos al hacer un merge

Resumen

Encontré una extensión de VSCode que me pareció práctica para la visualización de ramas y realizar acciones. GIT Graph

Freddy: "No entres en pánico cuando tienes un conflicto"
Yo la clase pasada:

Apuntes!

Resumen de la clase anterior… xD

Hasta los mejores cometen errores, pero todo tiene solución.

Freddy se olvidó de guardar el archivo .html, y lo malo es que commiteó ese archivo todavia con el merge conflict.
Con los:

<<<<<<< HEAD
=======
>>>>>>> cabecera

Si les pasa esto, no entren en pánico, mientras el commit siga en nuestro repositorio local. Tienen dos formas al menos de solucionarlo, uds eligen la que mas les convenga:

1. Reemplazar el commit fallido
   Pueden corregir el archivo (en este caso hubiera bastado con guardarlo) y luego usar

git add .
git commit --amend

El --amend “suma” al commit anterior el nuevo contenido en el staging area. Asi que no se está creando un nuevo commit, si no reemplazando el último.

1. Borrar el commit, sin perder los cambios, arreglar y commitear de nuevo.
   Bastaria con devolver el commit a la staging area, usando:

git reset HEAD~1 --soft

y luego guardar el archivo y volver a hacer el commit (ya que esta vez con el reset si borraron el commit con el fallo).

Practiquenlo!, creanme que commit --amend resulta bastante útil, más de una vez habré commiteado algo, y luego me doy cuenta que me faltó algo, o algo está mal, y en vez de armar otro commit arreglando el error, podemos reemplazarlo con amend.

Espero les sirva 😃.

Lo que pensaba de los conflictos

No es broma*

Gracias a este curso ahora puedo ver que esto no es un problema

Para revertir un merge:
git merge --abort

Vengo de otros cursos de platzi, y se nota la calidad que tiene fredy de dar las clases. se mete en el cuento. le pone empatía. se emociona cuando está explicando. tiene una fluidez que genera confianza en la información que está entregando. todos los profes de alguna manera se tienen que contagiar de esto. por que aquí es donde realmente digo que me siento confiado en la inversión que realicé

Si despues tienen mas ramas y no sabe como va su proyecto pueden usar GitKraken, es como un visor grafico de git Bash y hasta puedes hacer todo lo que haces en la linea de comandos aqui

Un día me salieron 54 conflictos en el mismo archivo… fue un largo día.

¡Hola! Comparto algunos comandos que están en el libro Pro Git, que me parecieron de mucha utilidad:

git checkout –b // creará una nueva rama y saltará a ella de forma inmediata

git branch --list // listará las ramas existentes

git branch --delete [nombreRama] // borrará la rama que se indique

git branch –D [nombreRama] // fuerza la eliminación de ramas que aún no han sido fusionadas

git branch –v // muestra el último commit de cada rama

git branch --merged // lista las ramas que se fusionaron con la rama actual

git branch --no-merged // lista las ramas que no se han fusionado con la rama actual

git merge --abort // anula el merge y devuelve todo a como estaba antes

¡Saludos!

Un pequeño apunte

Esto ya lo habia visto antes

En la clase anterior me salió un conflicto y entré en pánico. Ahora ya estoy con un pánico informado. Gracias!!

El problema que aparece en el minuto 07:50 no es realmente que el profesor haya hecho click en el lugar incorrecto. Lo que ocurrió fue que el archivo blogpost.html no fue guardado despues de haber arreglado los conflictos.

Los dioses del desarrollo me fallaron desde la clase anterior, pero mantuve la calma y con lo visto en esta clase, solucioné el conflicto. ¡Genial!

Solo ella causo conflictos en mi vida :’(

git reset -------------- borrar commits
git branch -d --------- borrar ramas
git rm ------------------ borrar archivos

Keep calm, use git merge and resolve the conflict

Flujo Paso a Paso GIT
Desde creación de repo git init hasta resolución de conflicto en git merge. SI te perdiste, puedes retomar desde aquí para ver todo el flujo. Usé otro ejemplo para no machacar tu trabajo con el ejemplo de Fredy.
Enjoy it!
Creamos directorio

mkdir prueba1

Cambiamos al directorio creado

cd prueba1/

Iniciamos un repo local

git init

Comprobamos estado repo local

git status

Creamos archivo hola mundo en el directorio local/no en el repo

vim "holamundo.txt"

dentro de vim ( es un editor de texto seguir los siguientes pasos: )
apretar tecla “i” para insertar texto
escribir "hola mundo"
apretar tecla escape <ESC> para salir de modo edición
escribir “:” para escribir comando
escribir “wq” ( que es write and quit, para guardar y salir)
agregamos el archivo al repo local —>> tracked

git add holamundo.txt   

git status

hacemos nuestro primer commit, el archivo ahora esta guardado en el repo local

git commit  

se abre editor de texto
dentro de vim ( es un editor de texto seguir los siguientes pasos: )
apretar tecla “i” para insertar texto
escribir "nuestro primer commit hola mundo"
apretar tecla escape <ESC> para salir de modo edición
escribir “:” para escribir comando
escribir “wq” ( que es write and quit, para guardar y salir)
Vemos el registro de nuestros commits

git log      

Vemos hacia donde apunta el HEAD (la última versión)

git show     

listamos las ramas creadas, no hay ninguna todavía

git branch   

Creamos la rama prueba a partir de larama master

git branch prueba   

Vemos nuestra nueva rama en el listado de ramas

git branch   

Cambiamos a la rama prueba para trabajar sobre ella

git checkout prueba  

Comprobamos que efectivamente hemos cambiado de rama (prueba)

git status   

Vemos a donde apunta la HEAD (ultima versión)

git show     

ls

vim "holamundo.txt"

dentro de vim ( es un editor de texto seguir los siguientes pasos: )
apretar tecla “i” para insertar texto
escribir "hola mundo en branch prueba"
apretar tecla escape <ESC> para salir de modo edición
escribir “:” para escribir comando
escribir “wq” ( que es write and quit, para guardar y salir)

Trackeamos los últimos cambios y hacemos commit a la vez en la branch prueba

git commit -am "hola mundo para branch prueba"

Cambiamos a rama master

git checkout master  

git status

Vemos que en master estamos en la versión anterior
porque los cambios los hemos hecho en “prueba”

cat holamundo.txt

git log

**Mezclamos los cambios en la rama master incluyendo los cambios de la rama pruebas**

git merge prueba

**Cambiamos a rama prueba**

git checkout prueba

git merge master

Master y prueba vuelven a estar actualizadas. HEAD apunta a las dos

git show

vim "holamundo.txt" 

Vamos a crear un conflicto cambiando el mismo archivo en prueba y en master
dentro de vim ( es un editor de texto seguir los siguientes pasos: )
apretar tecla “i” para insertar texto
escribir " hola mundo en branch prueba con conflicto"
apretar tecla escape <ESC> para salir de modo edición
escribir “:” para escibir comando
escribir “wq” ( que es write and quit, para guardar y salir)

git commit -am "prueba con conflicto"

git checkout master

vim holamundo.txt

Hacemos el cambio en master para generar el conflicto
dentro de vim ( es un editor de texto seguir los siguientes pasos: )
apretar tecla “i” para insertar texto
escribir " hola mundo en branch prueba con cambio en master para ver conflicto resuelto"
apretar tecla escape <ESC> para salir de modo edición
escribir “:” para escibir comando
escribir “wq” ( que es write and quit, para guardar y salir)

git commit -am "prueba de conflicto"

git merge prueba   **aquí salta el conflicto**

vim holamundo.txt

este es un archivo de hola mundo para branch prueba con conflicto

prueba
apretar tecla escape <ESC> para salir de modo edición
escribir “:” para escibir comando
escribir “wq” ( que es write and quit, para guardar y salir)

git commit -am "archivo corregido"  **hacemos commit de archivo corregido**

git status

git merge prueba   

cat holamundo.txt

Hasta aquí esta resuelto el conflicto. Master tiene la versión que queríamos
Prueba tiene aún su propia versión. Si queremos dejarlo todo igual debemos hacer
un merge desde master a prueba
Vamonos a prueba para hacerlo

git checkout prueba

cat holamundo.txt

Traigamos el merge hacia prueba

git merge master

master y prueba vuelven a estar actualizadas y HEAD apunta a las dos

cat holamundo.txt

git show

Final

las clases con freddy son las primeras que no le adelanto la velocidad, es súper llevadero!

Para ver los cambios, de Quién, Cuándo y Dónde:

git blame nombreArchivo
git blame nombreArchivo -L numeroLinea

Git nunca borra nada a menos que nosotros se lo indiquemos. Cuando usamos los comandos git merge o git checkout estamos cambiando de rama o creando un nuevo commit, no borrando ramas ni commits (recuerda que puedes borrar commits con git reset y ramas con git branch -d).

Git es muy inteligente y puede resolver algunos conflictos automáticamente: cambios, nuevas líneas, entre otros. Pero algunas veces no sabe cómo resolver estas diferencias, por ejemplo, cuando dos ramas diferentes hacen cambios distintos a una misma línea.

Esto lo conocemos como conflicto y lo podemos resolver manualmente, solo debemos hacer el merge, ir a nuestro editor de código y elegir si queremos quedarnos con alguna de estas dos versiones o algo diferente. Algunos editores de código como VSCode nos ayudan a resolver estos conflictos sin necesidad de borrar o escribir líneas de texto, basta con hundir un botón y guardar el archivo.

Recuerda que siempre debemos crear un nuevo commit para aplicar los cambios del merge. Si Git puede resolver el conflicto hará commit automáticamente. Pero, en caso de no pueda resolverlo, debemos solucionarlo y hacer el commit.

Los archivos con conflictos por el comando git merge entran en un nuevo estado que conocemos como Unmerged. Funcionan muy parecido a los archivos en estado Unstaged, algo así como un estado intermedio entre Untracked y Unstaged, solo debemos ejecutar git add para pasarlos al área de staging y git commit para aplicar los cambios en el repositorio.

Los merge funciona en la direcion que necesitemos tanto para la rama master como en la rama que estemos trabajando

Dejo mis apuntes de esta parte 😄

Cuando ocurre un conflicto, la única salida es resolverlo o se puede deshacer un merge?

Casi se cae el curso por no dale guardar xD

Los modos de pantalla para los cursos deberían estar en light mode, no se alcanzan a distinguir bien los códigos en obscuro, yo entiendo perfectamente que cuando uno codifica es mas relajado a los ojos el modo dark, pero para los cursos deberían los profesores cambiar a light para poder apreciar mejor los textos, además hace contraste con las demás partes de la página, como estos comentarios, o la descripción, estaría cool tener dark theme en mi cuenta platzi!!! XD

Hice un repositorio donde estoy describiendo los comandos explicados hasta ahora y función. También hice una sección de comandos sobre las branch y otro de como crear el repositorio y GitHub y conectarlo con nuestro repositorio local.

Es un HTML bien feo jajajaj (Lo único interesante es que le agregué un script para reconocer si es de noche y sugerir usar el “tema oscuro”) así que si quieren hacerle cambios y ponerlo más bonito estaré atentos a sus pull request 😄

https://github.com/avasquez-ve/gitCommands

Un conflicto se da cuando se hacen modificaciones en los mismos archivos, en las mismas lineas desde lugares (ramas o autores) diferentes

Hola comunidad! Hace unos momentos respondí la pregunta de si era posible dar prioridad a los registros de una rama sobre la otra al momento de hacer un git merge. Me pareció que sería un aporte interesante por lo que resumiré la respuesta aquí.
.
En resumen la respuesta es si.
.
Se puede conseguir mediante el uso de los argumentos -X ours o -X theirs asociados a git merge.
.
Para explicarlo brevemente: Supongamos que en este momento tenemos dos ramas: master y secundaria, y un archivo llamado registros.txt en cada rama, este archivo tiene un registro en la línea uno, este registro es diferente en cada rama.
.
Aquí las ramas:
.

.
Aquí los registros en el archivo de la rama master (commit ha sido aplicado):
.

.
Aquí los registros en el archivo de la rama secundaria (commit ha sido aplicado):
.

.
Imaginemos que aplicamos git merge secundaria desde la rama master (solo imaginémoslo porque no lo haremos), es evidente que obtendremos un error que deberemos solucionar manualmente. El error obtenido sería similar a esto:
.

.
Entonces, ¿Qué pasa si ante cada git merge quiero dar prioridad a una rama sobre otra? Es aquí donde deberemos usar el argumento -X ours o -X theirs.
.
Si aplicamos git merge secundaria -X ours le estamos diciendo a git que, ante un conflicto, como el anterior mencionado, elija mantener automáticamente los registros de nuestro archivo en la rama actual, para este caso: la rama master.
.
Si aplicamos git merge secundaria -X theirs le estamos diciendo a git que, ante un conflicto, elija mantener automáticamente los registros de nuestro archivo en la rama que “estamos trayendo”, para este caso: la rama secundaria.
.
Para continuar con el ejemplo, apliquemos git merge secundaria usando el argumento -X theirs para dar prioridad a los registros que “estamos trayendo” de la rama secundaria y descartar los registros de la rama master.
.

.
Ahora veamos el contenido del archivo luego de priorizar.
.

.
Como pueden ver, el git merge no ha arrojado ningún conflicto, y en el contenido del archivo encontramos los registros del archivo en la rama secundaria.
.
Si deseas ver toda la respuesta para entenderla mejor puedes ir aquí: https://platzi.com/comentario/2034034/
.
Espero les sirva. Saludos!

Ok, resolví un problema en la clase anterior y ni me había dado cuenta xD

📌 Para eliminar una rama de nuestro repositorio local ejecutaremos el comando git branch -d seguido del nombre de la rama.

En el video anterior ya se me había generado el conflicto, lo arreglé exactamente igual como Freddy y no pensé que se arreglaba de esa manera(manualmente), pensé que había un comando especial para arreglarlo. Excelente curso, sigo aprendiendo con estas explicaciones de Freddy.

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

Tuve un conflicto desde el primer intento con merge (en la clase 16) porque me arrojaba que había cambiado 2 líneas del archivo estilos.css en ambas ramas cuando solo lo modifiqué en una (cabecera).

Sucedió que tenía un problema de sintaxis en el archivo blogpost.html y al modificarlo (en la rama master) parce ser que el code interpretó que estaba modificando todo el archivo estilos.css. El problema fue que en la línea <div id= “cabecera”> yo coloqué erróneamente <div/ id=“cabecera” y creo que por ello no reconocía la parte de cabecera del archivo estilos.css.

Cabe mencionar que no conozco html… aún.

Así pues, cuando modifiqué las líneas de conflicto aparentemente en una sola rama, realmente fueron modificadas en las dos.

Al final, resolví el conflicto y quedó bien el archivo.

Con este comando es posible visualizar las ramas del proyecto y como se relacionan

git log --graph --decorate --oneline

Si escriben el comando
**git log --graph --full-history --all ** saldrá un mapa de todas las ramas y cambios que han existido

Para el caso de freddy donde no guardo los cambios e hizo el commit lo puede volver hacer, pero con el amend de la siguiente manera.

Primero guarda los cambios de los archivos.
luego ejecuta git commit --amend
Una vez realizado esto te preguntará por el mensaje del commit y le das guardar.

git merge -> si al fusionar los cambios resulta un conflicto, en los archivos este se muestra así:

   <<<<<<< HEAD
       cambio 1
    ----------------
        cambio 2 
   >>>>>>> nombreRama

 Pasos para solucionar el conflicto:
    1. buscar archivos donde se encuentran los conflictos
    2. selecionar un de los dos cambios y eleminar el otro, junto a los indicadores (<<<<<<< HEAD, ----------------, >>>>>>>>>>nombreRama)
    3. realizar 'git commit -am'

En la clase anterior me generó conflicto. Opte por cancelar el merge.
git merge --abort
y revise la posible causa
git diff master…cabecera

Algo interesante es que cuando estas en una rama, realizas un cambio a algun archivo (sin hacer el commit en la rama en que te encuentras) y quieres hacer un checkout a otra rama, git manda un error indicando que has hecho cambios y que no los has guardado. Está increible porque evita que piedas los cambios que no has guardado!! Súper!. 😄

Git es impresionante, además te facilita el trabajo dándote opciones de comandos, por ejemplo en caso de que no quisieras conservar el marge te indica que puedes ejecutar el comando;

git merge --abort

Y este comando sería útil en el caso donde hubieran dos proyectos que modifican el mismo código fuente pero se tiene que revisar que cambio se va primero a producción.

estúpido y sensual bloc de notas

![](

Freddy! … la manera como explicas as cosas son amenas … y me atreveria a decir divertidas, el git merge es un punto en el que necesitaba enfatizar mas … y la explicacion dad … muy buena!.. estamos haciuendo todo por consola entiendo que tambien hay tools para majear todo esto de manera visual … como el gitExtension q es libre y sirve… para ver graficamente todas las ramas … visualmente ayudan un monton ! … ya que desarrollar software conlleva muchas personas y codigo…
Me encantaria saber si tu usas un tool libre de paga q sea visual …???

pude arreglar el conflicto en el video pasado aunque si me asuste cuando lo vi xD

:ajajja creí que me había vuelto daltónico, ese azul después de las 18:00 lo veo morado. Gracias al efecto nocturno que trae UBUNTU. Sustos que dan gustos xdddd

Realizando el merge aprendí que al realizar algún cambio, debo verificar si este también afecta a mi master, de lo contrario salen los conflictos que dijo Freddy.

Al trabajar con otras personas, es necesario utilizar un repositorio remoto.
­
Para copiar el repositorio remoto al directorio de trabajo local, se utiliza el comando git clone <url>, y para enviar cambios al repositorio remoto se utiliza git push.
Para actualizar el repositorio local se hace uso del comando git fetch , luego se debe fusionar los datos traídos con los locales usando git merge.
Para traer los datos y fusionarlos a la vez, en un solo comando, se usa git pull.
­
Para crear commits rápidamente, fusionando git add y git commit -m "", usamos git commit -am "".
­
Para crear nuevas ramas, hay que posicionarse sobre la rama que se desea copiar y utilizando el comando git branch <nombre>.
Para saltar entre ramas, se usa el comando git checkout <branch>
­
Una vez realizado los cambios a la rama, éstas deben fusionarse con git merge.
El merge ocurre en la rama en la que se está parado, por lo tanto la rama a fusionar “viene”, transformándose en la principal.
Los merges también son commits.
Los merges pueden generar conflictos, esto aborta la acción y pide que soluciones el problema manualmente, aceptando o rechazando los cambios que vienen.

Siento que Freddy le da con toda la fuerza del mundo a su tecla de enter.

rayita rayita rayita jajaja

Nota mental: los conflictos son normales, no entres en pánico. ¡Son fáciles de arreglar!

ALGO MUY IMPORTATE. cuando hacemos la solucion de conflictos y tenemos que elegir que cambios se van aceptar, si queremos hacer otra opcion que no esta en los cambios realizados lo que debemos hacer es elegir una opcion, para luego modificarla y guardarla, si primero modificamos una opcion y luego la elegimos tendremos un error en los archivos, VSC nos mostrara en ambos archivos el mismo codigo que cambiamos y elegimos, aun que puede que en la practica cada codigo funcione cómo se supone deberia. el detalles es que en el editor de codigo nos aparecera el mismo codigo para ambos y nos puede confundir o causer problemas.
.
Al menos asi me sucedio a mi y lo que hice fue desacer los cambios que tenia en el stage y volver al momento de elegir los cambios, elegir los cambios y entonces modificar, en este caso el color.
.
esto me sucedio debido a que no modifique el archivo estilos.css en el editor de texto sino directamente en VSC.

Espero puedan entender lo que escribí aquí, trato de hacerlo simple, ya sea para que lo entienda yo mismo a la hora de repasar o ustedes al ver este aporte.

Aqui mis apuntes

Lo bueno es que desde el video anterior me salio mal aqui lo puedo arreglar JAJAJAJA

Una hora de Platzi son como 10 horas en el mundo real

Nunca antes había visto realmente el potencial que tiene git

Para abortar un merge al tener un conflicto, se puede utilizar el siguiente comando:

git merge --abort

CONSEJO:
ASÍ COMO UN CONFLICTO LO OCASIONAN DOS PERSONAS, TAMBIÉN LO RESUELVEN DOS PERSONAS, CONSULTA CON TU COMPAÑERO PARA VER POR QUÉ ÉL HIZO ESO Y POR QUÉ TU HICISTE LO OTRO!!!

4:04 YA HAZ EL MADITO MERGE!!

hahahaha

Para poner en practica git a parte de tenerlo en algunos proyectos, lo que hice fue crear un repositorio con anotaciones y carpetas para cada curso, una anotacion por clase por ej:
“git-flujo-basico.txt” dentro de la carpeta “anotaciones-git” crearlo todo desde consola y editarlo con nano o vim, asi tambien crear un branch para otro curso que haya tomado, por ejemplo en mi caso el curso de terminal y linea de comandos asi pongo en practica lo aprendido y lo que vaya tomando de este curso.

Voy de corrido, pero es un tema que ya sé, cualquier pregunta estoy disponible para responder

Alguien mas acaba de perder el miedo a los conflictos?

Honestamente me paso ese problema en la clase anterior a esta, y guiándome de la lógica hice lo mismo que enseña Freddy aquí.
Muchas veces lo que debemos hacer es simplemente leer y ver qué es lo que en el fondo esta pasando y entender el porque, así vamos a poder lograr entender el problema y a futuro poder evitarlos o identificarlos fácilmente. Y recuerden, Googlear no es malo, siempre y cuando entiendas él porque de las cosas.

Les recomiendo esta página de Git Interactivo para que puedan practicar https://tinyurl.com/y2mu9om4

Para aquellos que quieran saber el cómo borrar una rama este es el comando

git branch -D "nombre de la rama"```

Una pequeña nota al hacer merge:
Los archivos no solo se modifican sino que se eliminan si es necesario
Por ejemplo, tengo 2 ramas

1. Master
   -> historia.txt
   -> hyperblog/
2. Temp
   -> hyperblog

Al hacer en la rama Master: git merge Temp, también se elimina el archivo historia.txt ya que segun entiendo es dejar en ambas ramas lo mismo y no solo añadir cambios. Corrijanme si me equivoco.

Tremenda explicación y enseñanza para trabajo colaborativo, no entrar en panico es la clave, los conflictos son inevitables.

En resumen, Git es asombroso!

Los editores populares incluyen lo mismo que visual studio code.

Visual Studio Code, lo mejorcito para trabajar…

Lo siento Atom.

Increíble!
Me tomo mas tiempo de lo que esperaba pero todo hasta al momento aprendido correctamente

Lo mejor seria tener una comunicacion efectiva con el equipo de trabajo para saber exactamente que bloques se van a comenzar a modificar o en su defecto ir revisando si la rama Master ha tenido cambios en el mismo bloque que estamos modificando para saber desde que linea podria agregar informacion y asi no tener conflictos. Pero como dice el profe, es mas de comunicacion entre los equipos para que eso no pase y se pueda trabajar correctamente

Los que usan un IDE de intellij como webstorm tienen una pestaña abajo para ver los commits.

Recomiendo usar diff3 para hacer de la resolución de conflictos una labor más sencilla.

Con la visión por defecto, contamos con solo los cambios realizados por nosotros y por la otra parte

<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

Con diff3, adicionalmente podemos observar lo que fue cambiado por ambas partes

<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
|||||||
Conflict resolution is hard.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

Este tipo es muy bueno explicando, solucione muchas dudas

Tener las ramas siempre actualizadas antes de empezar a trabajar es sumamente importante

Freddy ¿POR QUE NO DICTA MAS CURSOSSSSSSSSSSSS? =(

Interesante como esto nos ayuda con nuestro team, hay que comunicarnos con los compañeros todo el tiempo, nada de individualismos

me paso en el video pasado
por que me aburri de crear todo el html, copie el de Freddy y lo copie y lo guarde en el branch cabecera, cuando fusioné OH errores por do quier,

donde le doy like o me gusta al profe? que profesor tan bueno para explicar bien, muchas gracias.

La herramienta Git es útil incluso para las personas que están comenzando en el mundo de la programación, ya que cuando yo comencé me hubiera sido muy útil ya que también creaba mil versiones del mismo programa solo por probar cosas. Creo que Git debería ser enseñado entre las primeras materias básicas de las universidades

Tus clases son adictivas Freddy 😃 verdaderamente da ganas de seguir estudiando

no necesariamente es falta de comunicación, de hecho suele ser muy normal que un merge dos o mas miembros este tocando el mismo archivo y hay que tomar la decisión de que cambios persisten.

Antes de ver este video me dio un conflicto. Lo pude solucionar, pero hubiera sido bueno haber visto este video antes jajaja

La mejor forma de solucionar el conflicto es con comunicación .
Y sabiendo que cambio aporta mas para mejorar el trabajo para eso se trabaja en equipo para construir algo mejor .

ayer me queria morir cuando me salio un error con las dos fuentes, y mire esta clase y me di cuenta de lo facil que era

yo ocupaba lo basico de git por eso tome este curso por que cada vez que aparecia un conflico entraba en panico profundo jajaja!. ahora entiendo lo facil que es solucionarlo!

Que nota saber que me salió el error en la clase anterior y ver como Freddy repite los pasos que hiciste, Me siento toda una sensei jajajajaja. Aclaro. Hasta ahora estoy tomando el curso, nunca había manejado Git, pero ayudan muchos los mensajes cuando salen errores.

Tu también tenias la impresión de que git iba a ser muy dificil?
Eres de los mios
Pero sabes? Al menos para mi siento que no ha sido tan dificl
Es intuitivo cuando lo miras desde las necesidades de un desarrollador
Por supuesto que requiere una curva de dominio de la terminal, pero de ahí en adelante es bastante intuitivo.
Mi recomendacion?
Domina el uso de cada uno de los comando que hemos visto practicando uno por uno con un proyecto propio de prueba y de ahora en adelante, todas tus practicas de programacion y proyectos personales hazlas desde el principio usando git.

A alguien le gustaria trabajar en conjunto en un proyecto para interiorizar el flujo de trabajo de un equipo?