Non, ce n'est pas tout à fait correct. Cela dépend un peu du logiciel de contrôle de version que vous utilisez, mais j'aime Git donc je vais en parler.
Supposons que nous ayons un fichier Foo.java:
class Foo {
public void printAWittyMessage() {
// TODO: Be witty
}
}
Alice et Bob modifier le fichier. Alice fait ceci:
class Foo {
public void printAWittyMessage() {
System.out.println("Alice is the coolest");
}
}
et Bob fait ceci:
class Foo {
public void printAWittyMessage() {
System.out.println("Alice is teh suk");
}
}
Alice vérifie sa première dans la version. Quand Bob essaye de vérifier son entrée, Git l'avertira qu'il y a un conflit et ne permettra pas que le commit soit poussé dans le dépôt principal. Bob doit mettre à jour son référentiel local et corriger le conflit. Il va obtenir quelque chose comme ceci:
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>
}
}
Les <<<<<, ===== et >>>>> marqueurs indiquent les lignes ont été modifiées en même temps. Bob doit résoudre le conflit de manière sensée, retirer les marqueurs et valider le résultat.
Alors, que vit finalement dans le référentiel est:
Version originale -> version d'Alice -> Bob version fixe conflit. Pour récapituler: le premier à valider entre sans problème, le second à valider doit résoudre le conflit avant d'entrer dans le référentiel. Vous ne devriez jamais vous retrouver avec les changements de quelqu'un étant automatiquement bousculés. De toute évidence, Bob peut résoudre le conflit de manière incorrecte, mais la beauté du contrôle de version est que vous pouvez annuler le correctif incorrect et le réparer.
Vous avez dit gentiment! Claps :-) –