Я смотрю на репозитории Mercurial некоторых известных продуктов, таких как TortoiseHg и Python , и даже несмотря на то, что я вижу, как несколько человек вносят изменения, временная шкала всегда выглядит довольно чистой, просто одна ветвь движется вперед.
Однако, скажем, у вас 14 человек, работающих над одним и тем же продуктом, разве это не приведет к быстрому переходу в кошмар ветвей с 14 параллельными ветвями в любой момент времени?
Например, с двумя людьми и продуктом в changeset X теперь оба разработчика начинают работать над отдельными функциями утром в понедельник, поэтому оба начинают с одного и того же родительского набора изменений.
Когда они фиксируют, у нас теперь есть две ветви, а затем с 14 людьми, мы быстро получим 10+ (может быть, не 14 ...) ветвей, которые необходимо объединить с настройками по умолчанию.
Или ... Что я здесь не вижу? Возможно, это не проблема?
Редактировать : Я вижу некоторую путаницу относительно того, о чем я здесь на самом деле спрашиваю, поэтому позвольте мне уточнить.
Я хорошо знаю, что Mercurial легко обрабатывает несколько веток и слияний, и, как говорится в одном ответе, даже когда люди работают с одними и теми же файлами, они не часто работают с одними и теми же строками, и даже в этом случае возникает конфликт легко обрабатывается. Я также знаю, что если два человека в конечном итоге создадут ад слияния, потому что они изменили большую часть одного и того же кода в одних и тех же файлах, здесь произойдет общая ошибка планирования, поскольку мы поместили две функции в одном и том же месте на двух разработчиков, вместо того, чтобы пытаться работать вместе, или просто дать обоим одному разработчику.
Так что это не так.
Что мне интересно, так это то, как эти проекты с открытым исходным кодом управляют такой чистой историей. Для меня не важно (как удивился один комментарий), что история чиста, я имею в виду, мы делаем работаем параллельно, что хранилище способно отразить это, тем лучше (на мой взгляд) Однако у этих репозиториев, на которые я смотрел, этого нет. Похоже, что они работают по модели Subversion, где вы не можете выполнить коммит до обновления и слияния, и в этом случае история представляет собой одну прямую линию.
Так как они это делают?
Они «перебазируют» изменения так, что они следуют последнему совету ветви, даже если они были изначально зафиксированы в истории ветви? Пересадка наборов изменений, чтобы они казались «зафиксированными в основной ветке с самого начала?»
Или проекты, на которые я смотрел, были такими медленными (на данный момент, я не слишком давно смотрел в историю) на добавление новых вещей, которые на самом деле работали только по одному человеку за раз?
Или они проталкивают изменения одному центральному сопровождающему, который проверяет, а затем интегрирует? Это не похоже на то, что многие из проектов, на которые я смотрел, имели разные имена в наборах изменений.