Luis Ramírez
PreguntaQue sucede si hay 2 programadores y ambos modifican una misma. Línea, pero ninguno de ellos sabía que ya estaba corregida esa línea, como evitar que envíen eso al máster antes de causar más errores, porque puede pasar que alguien ya lo corrigió mientra uno trabajaba.

Francisco Antonio González Merino
Ese puede evitar implementando una manera de trabajar con las ramas utilizando Gitflow o Gitlab flow (hay muchos mas workflows) que se usan principalmente para trabajar con issues utilizando adminisrtadores de repositorios como GitLab o en la plataforma GitHub o similares.
Lo principal ahí para evitar conflictos es, tras empezar a trabajar en un nuevo cambio, crear inmediatamente una nueva solicitud de cambio (Pull Request en GitHub o Merge Request en GitLab) o una Issue que este asociada a una solicitud de solicitud de cambio. Independiente de que no tengas código.
Se te creara una rama, que se obtiene de la rama master o la que tiene los últimos cambios, para que trabajes con tus cambios asociada ese pull o merge request. Mas antes de empezar a codificar siempre debes traerte los cambios de la rama master o la que tiene los últimos cambios ( esto dependerá mucho del tipo de worflow de ramas que utilices) por si encontramos conflictos en nuestros cambios para resolverlos. Si no puedes resolverlos por temas externos al código ( ya sea de dependencias, de arquitectura o de negocios ) deberás empezar a escalar ese conflicto con tus compañeros de trabajo o tu jefatura en su defecto.
Cuando al administrador del repositorio decida que pull request pasar a la linea base, a master o la rama que tengas de principal ( porque tiene que ser otra persona que pase los cambios a master previamente habiendo realizado pruebas en local de que esos cambios no tendrán conflictos al hacer merge con master, con sus correspondientes pruebas pasadas), esa persona al menos tiene que tener claridad que cambios se irán pasando primero o que orden.
Tras pasar un pull request y hacer merge de esos cambios a master, todas las otros pull request deberian actualizar desde la rama master para no tener conflictos. Hasta que todos esos pull request pasen a master sin ningun problema.
Eso a groso modo es una manera de trabajar de manera ordenada tanto con workflows de ramas junto con administradores de repositorios como github, gitlab o Bitbucket.
Como recomendacion eviten usar Gitflow como flujo de trabajo con ramas, no se estila ya mucho emplearla. Crea muchas ramas innecesarias y que flujos como GitHub flow o GitLab Flow trabajan mucho mas limpio en ese sentido utilizando a lo mucho 2 o 3 ramas principales para poder trabajar con cambios en Git.
Yo utilizo la de GitLab Flow ya que es mas simple y comoda para trabajar con Issues y Merge request https://about.gitlab.com/blog/2014/09/29/gitlab-flow/ lean eso que es una buena lectura para que puedan implementar este tipo de trabajo con las ramas en Git.
Luis Ramírez
jajaja si eso veo, muy amable grande fredy jaja y tu John thanks

John Cardenas
Hola Luis,
La respuesta a tu pregunta la encuentras en la siguiente clase :)