Нет, это не совсем правильно. Отчасти это зависит от того, какое программное обеспечение для управления версиями вы используете, но мне нравится Git, поэтому я поговорю об этом.
Предположим, у нас есть файл Foo.java:
.
class Foo {
public void printAWittyMessage() {
// TODO: Be witty
}
}
Алиса и Боб оба изменяют файл. Алиса делает это:
class Foo {
public void printAWittyMessage() {
System.out.println("Alice is the coolest");
}
}
и Боб делает это:
class Foo {
public void printAWittyMessage() {
System.out.println("Alice is teh suk");
}
}
Алиса сначала проверяет свою версию. Когда Боб попытается зарегистрировать его, Git предупредит его, что существует конфликт, и не позволит отправить коммит в основной репозиторий. Боб должен обновить свой локальный репозиторий и исправить конфликт. Он получит что-то вроде этого:
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>
}
}
Маркеры <<<<<, ===== и >>>>> показывают, какие строки были изменены одновременно. Боб должен разрешить конфликт каким-то разумным способом, убрать маркеры и зафиксировать результат.
Так что в конечном итоге живет в хранилище:
Оригинальная версия -> Версия Алисы -> Исправленная конфликтом версия Боба.
Подводя итог: первый коммит попадает без проблем, второй коммит должен разрешить конфликт до попадания в репозиторий. Вы никогда не должны заканчивать тем, что чьи-то изменения автоматически перекрываются. Очевидно, что Боб может разрешить конфликт неправильно, но прелесть контроля версий в том, что вы можете откатить неверное исправление и исправить его.