Nein, das stimmt nicht ganz. Es hängt etwas davon ab, welche Versionskontrollsoftware Sie verwenden, aber ich mag Git, also werde ich darüber reden.
Angenommen, wir haben eine Datei Foo.java:
class Foo {
public void printAWittyMessage() {
// TODO: Be witty
}
}
Alice und Bob beide die Datei ändern. Alice tut dies:
class Foo {
public void printAWittyMessage() {
System.out.println("Alice is the coolest");
}
}
und Bob tut dies:
class Foo {
public void printAWittyMessage() {
System.out.println("Alice is teh suk");
}
}
Alice überprüft ihre Version zuerst. Wenn Bob versucht, sein Einchecken zu überprüfen, wird Git ihn warnen, dass es einen Konflikt gibt, und wird nicht erlauben, dass das Commit in das Haupt-Repository geschoben wird. Bob muss sein lokales Repository aktualisieren und den Konflikt beheben.
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>
}
}
Die <<<<<
, =====
und >>>>>
Markierungen zeigen, welche Linien gleichzeitig geändert werden: Er wird so etwas wie dieses. Bob muss den Konflikt auf eine vernünftige Art lösen, die Marker entfernen und das Ergebnis festschreiben.
So schließlich, was im Repository lebt, ist:
Originalversion -> Alice-Version -> Bob konflikt feste Version.
Zusammengefasst: der erste Commit kommt ohne Probleme herein, der zweite Commit muss den Konflikt lösen, bevor er in das Repository gelangt. Sie sollten niemals damit enden, dass jemandes Änderungen automatisch verfälscht werden. Offensichtlich kann Bob den Konflikt falsch lösen, aber das Schöne an der Versionskontrolle ist, dass Sie die falsche Korrektur rückgängig machen und sie reparieren können.
Du hast gesagt, es schön! Klatsch :-) –