Объединение работы разработчиков в Git

[Mixim]

Продолжаю программировать и изучать Git, тему по которому впервые поднял здесь. Сколько ни читаю про SVN, про Git, никак до меня не доходит следующий вопрос: допустим, что над проектом параллельно работает 2 разработчика (Dev_1 и Dev_2), каждый из которых делает свои коммиты; предположим, что наши разработчики договорились: "Ты работаешь над Module1.cs, а я над Module2.cs" - если никто из них не лезет в чужой файл, то процесс выполнения коммитов вполне ясен - Dev_1 подправил код в Module1.cs, сделал коммит, Dev_2 скачал результаты работы Dev_1 и продолжил свою работу над Module2.cs, если каждый из них последовательно делают коммиты, то ничего страшного нет; теперь представим, что Dev_2 мало того что подготовил коммит для своего Module2.cs, так еще и подправил баг в Module1.cs, который не давал ему исправить баг в своем коде (предположим, что в начале разработки была выбрана не самая удачная модель и степень связности модулей очень высока), он сливает этот коммит в систему, забыв сообщить Dev_1: "Я немного залез в твой модуль, смотри ничего не испорть" и затем Dev_1 сливает свои правки Module1юcs в систему, затирая правки Dev_2 (файл Module2.cs он не тронул, но Module1.cs он затер своим) - код Dev_2 начинает вновь работать не правильно, летят сопли и слюни. Теперь представим, что у нас не 2 разработчика, а 22 или 222 и если в приведенном примере Dev_2 может созвониться/списаться с Dev_1 и попросить его не трогать Method1 в Module1.cs, то в этом случае такая связь будет проблематична - один разработчик будет затирать верные правки другого разработчика и они долго и нудно будут тянуть кота за его достоинство. Посему вопрос: как решаются такие проблемы?
Почитав этот материал, указанный вопрос заинтересовал еще больше. Ладно, если Линус очень качественно следит за всеми коммитами, не давая бестолковым янки вносить их, но такая организации работы над проектом очень тяжела (не может же, допустим, Линус каждый день просматривать bagfix'ы от 1000 разработчиков), как же тогда это делается?
Если же предположить, что есть возможность откатить сделанный коммит, то тогда проблема вновь решается, но это лишь в том случае, если после "случайного" затирания bugfix'а выполнено не более чем пара commit'ов, а если их было сделано несколько сотен, тысяч, то вновь придется упираться рогами в стену и искать место старого бага. И ладно, если все разработчики работают над проектом от его начала до конца, потерев мозг через пару дней они вспомнят что и как правили - идеальная ситуация, а теперь представим, что проект был выполнен на 30-40%, в него вложены немалые деньги, но проследив работу разработчиков, руководство поняло, что лучше от них избавиться (гора индусского кода и прочие проблемы) и нанять других - понятно, что все эти 30-40% выполненной работы нужно будет либо выполнять заново (вкладывать еще горку денег), либо продолжать развивать это чудо в нормальном стиле, но тогда новые разработчики будут вынуждены разбираться в сотнях тысяч строк не самого лучшего кода=>терять свое время и они просто не будут знать о коммитах, которые перекрывали друг друга.
Теперь основной вопрос: как все же объединяется работа нескольких разработчиков (сотен человек), как компонуется и объединяется их код?

[Progger]

Главная ошибка в этом описании в том, что если Dev_1 попробует сделать push со своей версией Module1.cs, git скорее всего сообщит, что в репозитории находится изменённая версия Module1.cs. Поэтому сначала придётся сделать pull и merge. Аналогично в svn попросит сначала сделать update, смержить изменения и сделать commit. В большинстве случаев, когда исправления затрагивают разные строки, всё это делается автоматически.

[Daynin]

Mixim,
вы упускаете несколько очень важных моментов. Во-первых, когда Dev1 вносит изменения в модуль Dev2, он не просто их внес и все. !ВСЕГДА! нужно описать что именно изменил коммит и для чего он это сделал. Итак, Dev1 внес изменения и написал, что этими изменениями он исправил такой-то баг. После чего Dev2 делает pull, получает изменения, читает сообщение, идущее вместе с коммитом, понимает, что баг действительно имел место быть и собственно все.

Но это только во-первых.

Во-вторых. В больших командах никто не работает с одной веткой. То есть как минимум есть стабильная ветка и ветка разработки. Уж если Dev1 и Dev2 работают совершенно над разной функциональностью, то им стоило бы ответвиться от ветки разработки еще дальше, каждый сделал бы свою ветку и сливал бы в ветку разработки только стабильные версии своих изменений (обычно еще заводится feature-ветка для таких вещей).

В-третьих. Допустим Dev1 работает над Module1, а Dev2 - над Module2. Пусть даже Module1 использует функционал Module2. Чтобы у Module1 и Dev1 не было проблем, сам Dev1 пользуется API от Module2, при этом API этот реализован через интерфейс. Это позволяет Dev2 вносить изменения в функциональность, но не меняя API он не ломает код в Module1.

В-четвертых. В больших проектах пишут очень много Unit Tests. И изменения, которые что-то ломают просто не закоммитятся

[aSmile]

Я бы предложил ТС попробовать посмотреть самому, как это работает. Т.е. сделать репозиторий (на том же гитхабе, например), сделать два клона в разные директории, сделать разные изменения и сделать пуш обратно на гитхаб.

Ведь лучше один раз увидеть, чем сто раз услышать