No, eso no es del todo correcto. Depende en cierta medida del software de control de versiones que estés usando, pero me gusta Git, así que hablaré sobre eso.
Supongamos que tenemos un Foo.java archivo:
class Foo {
public void printAWittyMessage() {
// TODO: Be witty
}
}
de Alice y Bob tanto modifican el archivo. Alice hace esto:
class Foo {
public void printAWittyMessage() {
System.out.println("Alice is the coolest");
}
}
y Bob hace esto:
class Foo {
public void printAWittyMessage() {
System.out.println("Alice is teh suk");
}
}
Alice comprueba su versión primero. Cuando Bob intenta controlar su entrada, Git le avisará que hay un conflicto y no permitirá que el compromiso sea enviado al repositorio principal. Bob tiene que actualizar su repositorio local y solucionar el conflicto. Él va a tener algo como esto:
class Foo {
public void printAWittyMessage() {
<<<<< HEAD:<some git nonsense>
System.out.println("Alice is the coolest");
=====
System.out.println("Alice is teh suk");
>>>>> blahdeblahdeblah:<some more git nonsense>
}
}
Los <<<<<
, =====
y >>>>>
marcadores muestran las líneas que se han cambiado de forma simultánea. Bob debe resolver el conflicto de alguna manera sensata, eliminar los marcadores y cometer el resultado.
Así que lo que finalmente vive en el repositorio es:
versión original -> versión de Alice -> Versión conflicto fija de Bob.
Para resumir: el primero para cometer obtiene sin ningún problema, el segundo para cometer debe resolver el conflicto antes de entrar en el repositorio. Nunca deberías terminar con los cambios de alguien siendo golpeados automáticamente. Obviamente, Bob puede resolver el conflicto incorrectamente, pero la belleza del control de versiones es que puedes revertir el arreglo incorrecto y repararlo.
Usted lo ha dicho muy bien! Claps :-) –