Контроль версий (a.k.a. контроль версий).
Рассмотрим следующую проблему. Вы работаете над проектом с кем-то еще и делитесь файлами. Вам обоим нужно поработать, скажем, над "WhwhatController.java". Это огромный файл, и вы оба должны отредактировать его.
Самый примитивный способ справиться с этим - не редактировать файл одновременно, но тогда вы оба должны быть на одной странице. Когда у вас есть команда, особенно если в команде десятки, сотни или тысячи членов (типично для проектов с открытым исходным кодом), это становится абсолютно невозможным.
Старое, примитивное «решение» этой проблемы состояло в том, чтобы иметь механизм проверки / возврата. Когда вам нужно отредактировать файл, вы «извлекаете его», и файл блокируется, так что никто не может редактировать его, пока вы не разблокируете его, «отметив его». Это делается с помощью соответствующего программного обеспечения, например, невероятно глупого кусочка Microsoft SourceSafe. Но когда люди забывают «зарегистрировать файл», никто больше не может редактировать этот файл, пока он используется. Затем кто-то уходит в отпуск или покидает проект по какой-то другой причине, и в результате возникает бесконечный хаос, растерянность и, как правило, немало утерянного кода. Это добавляет огромную управленческую работу.
Затем появился CVS и впоследствии Subversion, которую авторы называют «CVS сделано правильно», поэтому CVS и Subversion - это, по сути, одна и та же идея. С тех, нет фактической проверки. Вы просто редактируете нужные вам файлы и регистрируете их. Обратите внимание, что фактические файлы хранятся на центральном сервере, и каждый пользователь также запускает программное обеспечение на своих рабочих станциях. Это расположение на сервере называется хранилищем.
Теперь, что произойдет, если два человека работают над одним файлом в CVS / Subversion? Они объединяются, как правило, с использованием GNU diff и patch. 'diff' - это утилита, которая извлекает разницу между двумя файлами. «patch» использует такие «diff» файлы для исправления других файлов.
Так что, если вы работаете с WhwhatController.java в одной функции, а я работаю над тем же файлом в другой функции, то когда вы закончите со своими вещами, вы просто отметите их и внесете изменения применяются к файлу на сервере. Между тем, моя локальная копия не знает о ваших изменениях, поэтому ваши изменения не влияют на мой код. Когда я закончу с изменениями, я также проверю файл. Но теперь у нас есть этот, казалось бы, сложный сценарий.
Давайте назовем оригинальный файл WheverController.java файлом А.
Вы редактируете файл, и в результате получается файл B.
Я редактирую тот же файл в другом месте, без ваших изменений, и этот файл является файлом C.
Теперь у нас, похоже, есть проблема. Изменения в файлах B и C являются изменениями в файле A. Таким образом, в случае смешно отсталого барахла, такого как SourceSafe или Dreamweaver, обычно заканчиваются изменениями файла B (потому что он был зарегистрирован первым).
CVS / Subversion и предположительно Git (о котором я почти ничего не знаю) создают патчи вместо просто переопределения файлов.
Разница между файлом A и C создается и становится патчем X. Разница между A и B создается и становится патчем Y.
Затем исправления X и Y применяются к файлу A, поэтому конечным результатом является файл A + изменения, внесенные в B и C на наших соответствующих рабочих станциях.
Обычно это работает безупречно. Иногда мы можем работать над одной и той же функцией в одном и том же коде, и в этом случае CVS / Subversion уведомит программиста о проблеме и представит проблему в самом файле. Эти проблемы обычно легко решаются, по крайней мере у меня никогда не было проблем с их решением. Графические утилиты, такие как Visual Studio, Project Builder (Mac OS X) и тому подобное, обычно показывают как файлы, так и конфликты, так что вы можете выбрать, какие строки вы хотите сохранить, а какие выбросить ... и затем вы также можете редактировать файл вручную, если вы хотите объединить конфликт вручную.
Таким образом, по сути, контроль исходного кода - это решение проблемы нескольких человек, работающих над одними и теми же файлами. Вот и все.
Надеюсь, это объясняет.
РЕДАКТИРОВАТЬ: Есть много других преимуществ с приличными системами контроля версий, такими как Subversion и, вероятно, Git. Если есть проблема, вы можете вернуться к другим версиям, чтобы вам не приходилось сохранять все резервные копии вручную. На самом деле, по крайней мере с Subversion, если я что-то напутал или захочу взглянуть на старую версию кода, я могу сделать это, не мешая чужой работе.