После того, как, по крайней мере, 10 человек сказали, что контроль версий был хорошим, даже если это только я, у меня теперь есть следующий вопрос.
В чем разница между всеми типами управления версиями и есть ли руководство, которое любой знает для контроля версий, которое очень просто и легко понять?
Eric Sink имеет хороший обзор управления версиями. Есть также некоторые существующие questions здесь, на SO.
Мы, кажется, находимся в золотой век контроля версий, с множеством вариантов, все из которых имеют свои плюсы и минусы.
Вот те, которые я вижу наиболее часто используемыми:
Моя рекомендация: вы безопасны с помощью git, svn или perforce, так как многие люди используют их, они являются кросс-платформенными, имеют хорошие guis, вы можете покупать книги о них и т.д.
Не рассматривайте cvs, sccs, rcs, они античные.
Самое приятное, что, поскольку ваши проекты будут относительно небольшими, вы сможете переместить свой код в новую систему, когда будете более опытны, и решите, что хотите работать с другой системой.
Для всех, кто только начинает использовать управление версиями:
Пожалуйста, не используйте git (или hg или bzr) из-за обмана
Используйте git (или hg или bzr), потому что они лучшие инструменты для управления исходным кодом, чем SVN.
Я использовал SVN в течение нескольких лет на работе и переключился на git 6 месяцев назад. Без изучения SVN сначала я был бы потерян, когда дело дошло до использования DVCS.
Для людей, только начинающих с контроля версий:
Затем переключитесь на DVCS и узнайте:
TL;DR; толпа:
Начните с SVN и изучите основы, затем оканчивайтесь на DVCS.
Контроль версий необходим для развития, даже если вы работаете сами, потому что он защищает вас от вас самих. Если вы допустили ошибку, попробуйте вернуться к предыдущей версии вашего кода, который, как вы знаете, работает. Это также освобождает вас от изучения и экспериментирования с вашим кодом, потому что вам не нужно беспокоиться о том, является ли то, что вы делаете, обратимым или нет. Существуют две основные ветки систем управления версиями (VCS), централизованные и распределенные.
Централизованные VCS основаны на использовании центрального сервера, где каждый "проверяет" проект, работает над ним и "фиксирует" свои изменения обратно на сервер для кого-либо другого. Основными централизованными VCS являются CVS и SVN. Оба подвергались серьезной критике, потому что "слияние" "ветвей" крайне болезненно с ними. [TODO: напишите объяснение, какие ветки и почему слияние сложно с CVS и SVN]
Распределенный VCS позволяет каждому иметь свой собственный сервер, где вы можете "вытаскивать" изменения от других пользователей и "нажимать" изменения на сервер. Наиболее распространенными распределенными VCS являются Git и Mercurial. [TODO: напишите больше о распределенном VCS]
Если вы работаете над проектом, я настоятельно рекомендую использовать распределенный VCS. Я рекомендую Git, потому что он невероятно быстрый, но его критиковали как слишком сложного в использовании. Если вы не против использования коммерческого продукта, то BitKeeper предположительно прост в использовании.
Я бы начал с:
Затем, как только вы его прочитали, скачайте и установите SVN, TortoiseSVN и пропустите первые несколько глав book и начните работу.
ответ на другой вопрос также применим здесь, самое главное
Jon Works сказал:
Самое главное в управлении версиями:ТОЛЬКО НАЧАТЬ ИСПОЛЬЗОВАНИЕ IT
Его ответ более подробно, и я не хочу, чтобы меня обвиняли в плейгеризме, поэтому взгляните.
Простой ответ: вам нравятся кнопки отмены? Ответ, конечно, да, потому что мы все время совершаем ошибки.
Как программисты, часто бывает так, что может потребоваться несколько часов тестирования, изменения кода, перезаписывать, удалять, перемещать файлы и переименовывать, прежде чем мы разработаем метод, который мы пытаемся исправить, - это совершенно неправильно один и код более сломан, чем когда мы начали.
Таким образом, Source Control - это массивная кнопка отмены, чтобы вернуть код в более раннее время, когда трава была зеленой, а еда в изобилии. И не только это, из-за того, как работает управление версиями, вы все равно можете сохранить копию своего сломанного кода, если через несколько недель вы снова захотите ссылаться на нее, и вишня выберет любые хорошие идеи, которые вышли из нее.
Я лично (хотя его можно назвать overkill) использует бесплатную версию лицензии Single Source для Source Gear Fortress (которая является их продуктом управления версиями Vault с функциями отслеживания ошибок). Я считаю, что пользовательский интерфейс очень прост в использовании, он поддерживает как checkout > edit > checkin model, так и модель edit > merge > commit. Это может быть немного сложнее настроить, требуя, чтобы вы запускали локальную копию ISS и SQL-сервера. Возможно, вы захотите попробовать меньшую программу, такую как рекомендованные другими ответами здесь. Посмотрите, что вам нравится и что вы можете себе позволить.
Марк сказал:
git - очень жарко, так как Linus переключился на него
Я просто хочу отметить, что Линус не переключился на него, Линус написал его.
Если вы работаете в среде Windows, то однопользовательская лицензия для SourceGear Vault является бесплатной.
Мы используем и как Mercurial. Это следует за распределенной моделью - она устраняет некоторые ощущения необходимости "проверять" работу. Mozilla имеет перемещен в Mercurial, что является хорошим признаком того, что в ближайшее время он не уйдет. Один из них, на мой взгляд, заключается в том, что для него не очень хороший графический интерфейс. Если вам удобно работать с командной строкой, это очень удобно.
Просто начните использовать элемент управления источником, независимо от того, какой тип вы используете. То, что вы используете, не имеет значения; это использование его, которое важно
Как и все остальные, SC действительно зависит от ваших потребностей, вашего бюджета, вашей среды и т.д.
В своем корне исходный элемент управления предназначен для предоставления центрального хранилища всего вашего кода и отслеживания того, кто что с ним сделал, когда. Должна быть полная история, и вы можете получить продукты, которые выполняют полный журнал изменений, аудит, контроль доступа, и далее и далее...
Каждый продукт, который там находится, начинает сиять (так сказать), когда вы начинаете смотреть, как вы хотите или хотите включить SC в свою среду (будь то ваш личный код и документы или крупные корпорации). И, как люди используют их, они обнаруживают, что инструмент имеет ограничения, поэтому люди пишут новые. SVN рождался из-за ограничений, которые создатели видели с помощью CVS. Linus хотел что-то лучше для ядра Linux, поэтому теперь у нас есть git.
Я бы сказал, начну использовать один (что-то вроде SVN, которое очень популярно и довольно легко использовать) и посмотреть, как это происходит. По прошествии времени вы можете обнаружить, что вам нужны другие функции или необходимо взаимодействовать с другими системами, поэтому вам может понадобиться SourceSafe или другой инструмент.
Контроль источника всегда важен, и, хотя вы можете уйти с ручными повторными номерами версий PSD файлов или что-то в этом случае, вы будете забывать запускать этот пакет script один или два раза или вероятно, забудет, какое число пошло, с каким изменением. То, что большинство из этих инструментов SC могут помочь (пока вы регистрируетесь/проверяете).
Смотрите также этот вопрос: