В чем разница между всеми различными типами управления версиями?

После того, как по крайней мере 10 человек на SO сказали, что контроль версий - это хорошо, даже если это только я, у меня теперь есть дополнительный вопрос.

В чем разница между всеми различными типами управления версиями и есть ли известное руководство по управлению версиями, которое очень простое и легкое для понимания?

Ответов (13)

Решение

Эрик Синк хорошо разбирается в системе управления версиями . Здесь также есть некоторые существующие вопросы по SO.

Всем, кто только начинает использовать контроль версий:

Пожалуйста, не используйте git (или hg или bzr) из-за шумихи

Используйте git (или hg или bzr), потому что они лучше подходят для управления исходным кодом, чем SVN.

Я использовал SVN на работе несколько лет, а 6 месяцев назад перешел на git. Не изучив сначала SVN, я был бы совершенно потерян, когда дело дошло до использования DVCS.

Для людей, только начинающих работать с контролем версий:

  • Начните с загрузки SVN
  • Узнайте, зачем вам нужен контроль версий
  • Узнайте, как совершить, оформить заказ, ветвь
  • Узнайте, почему слияние в SVN - это такая боль

Затем переключитесь на DVCS и узнайте:

  • Как клонировать / ветвить / фиксировать
  • Как легко объединить ваши ветки обратно (сходите с ума по веткам!)
  • Насколько легко переписать историю коммитов и поддерживать ваши ветки
    в актуальном состоянии с помощью основной строки ( git rebase -i ,)
  • Как опубликовать свои изменения, чтобы другие могли получить выгоду

tldr; толпа людей:

Начните с SVN и изучите основы, а затем перейдите к DVCS.

См. Также этот вопрос SO:

Здесь также применим ответ на другой вопрос , самое главное

Джон Воркс сказал:
Самое важное в управлении версиями:

ПРОСТО НАЧНИТЕ ИСПОЛЬЗОВАТЬ

В его ответе содержится более подробная информация, и я не хочу, чтобы меня обвиняли в плагеризме, так что взгляните.

Кажется, мы живем в золотой век контроля версий, с множеством вариантов, каждый из которых имеет свои плюсы и минусы.

Вот те, которые я вижу наиболее часто используемыми:

  • svn - currently the most popular open source?
  • git - very hot since Linus switched to it
  • mercurial - some smart people I know swear by it
  • cvs - the one everybody is switching from
  • perforce - imho, the best features, but it's not open source. The two-user license is free, though.
  • visual sourcesafe - I'm not much in the Microsoft world, so I have no idea about this one, other than people like to rag on it as they rag on everything from Microsoft.
  • sccs - for historical interest we mention this, the great-grandaddy of many of the above
  • rcs - and the grandaddy of many of the above

My recommendation: you're safest with either git, svn or perforce, since a lot of people use them, they are cross platform, have good guis, you can buy books about them, etc.

Dont consider cvs, sccs, rcs, they are antique.

The nice thing is that, since your projects will be relatively small, you will be able to move your code to a new system once you're more experienced and decide you want to work with another system.

Если вы работаете в среде Windows самостоятельно, то однопользовательская лицензия на SourceGear's Vault бесплатна.

Контроль версий необходим для разработки, даже если вы работаете в одиночку, потому что он защищает вас от вас самих. Если вы допустили ошибку, легко вернуться к предыдущей версии вашего кода, которая, как вы знаете, работает. Это также позволяет вам исследовать и экспериментировать с вашим кодом, потому что вам не нужно беспокоиться о том, обратимо ли то, что вы делаете. Существует две основных ветви систем контроля версий (VCS): централизованная и распределенная.

Централизованные VCS основаны на использовании центрального сервера, где каждый «проверяет» проект, работает над ним и «фиксирует» свои изменения обратно на сервер, чтобы кто-нибудь еще мог их использовать. Основными централизованными VCS являются CVS и SVN. Оба подвергались резкой критике, потому что «слияние» «ветвей» для них чрезвычайно болезненно. [TODO: напишите объяснение того, что такое ветки и почему слияние с CVS и SVN затруднено]

Распределенная VCS позволяет каждому иметь свой собственный сервер, где вы можете «получать» изменения от других людей и «отправлять» изменения на сервер. Наиболее распространенными распределенными VCS являются Git и Mercurial. [TODO: напишите больше о распределенной системе контроля версий]

Если вы работаете над проектом, я настоятельно рекомендую использовать распределенную VCS. Я рекомендую Git, потому что он невероятно быстрый, но его критиковали как слишком сложный в использовании. Если вы не против использования коммерческого продукта, BitKeeper якобы прост в использовании.

Я бы начал с:

Затем, как только вы его прочтете, загрузите и установите SVN , TortoiseSVN, просмотрите несколько первых глав книги и приступайте к работе.

Мы используем и любим Mercurial . Он следует распределенной модели - это частично избавляет от необходимости «проверять» работу. Mozilla перешла на Mercurial , что является хорошим признаком того, что она не исчезнет в ближайшее время. Один из минусов, на мой взгляд, в том, что для него не очень хороший графический интерфейс. Однако, если вам удобна командная строка, она очень удобна.

Mercurial Documentation Неофициальное руководство

Марк сказал:

git - очень жарко, так как Линус переключился на него

Я просто хочу отметить, что Линус не переключился на это, это написал Линус .

Простой ответ: нравятся ли вам кнопки отмены? Конечно, да, потому что мы, люди, постоянно совершаем ошибки.

Как программисты, часто бывает так, что может потребоваться несколько часов тестирования, изменения кода, перезаписи, удаления, перемещения и переименования файлов, прежде чем мы разработаем метод, который мы пытаемся использовать для решения проблемы, совершенно неправильный, и код более сломан, чем когда мы начинали.

Таким образом, Source Control представляет собой массивную кнопку «Отменить», чтобы вернуть код к более раннему времени, когда трава была зеленой, а еды было много. И не только это, из-за того, как работает система управления версиями, вы все равно можете сохранить копию своего сломанного кода, на случай, если через несколько недель вы захотите снова обратиться к нему и выбрать любые хорошие идеи, которые действительно вышли из него. .

Я лично (хотя это можно назвать излишним) использую бесплатную версию Source Gear Fortress с однопользовательской лицензией (это их продукт управления исходным кодом Vault с функциями отслеживания ошибок). Я считаю, что пользовательский интерфейс очень прост в использовании, он поддерживает как модель проверки> редактирования> проверки, так и модель редактирования> слияния> фиксации. Однако это может быть немного сложно настроить, требуя запуска локальной копии ISS и SQL-сервера. Возможно, вы захотите попробовать программу меньшего размера, например, рекомендованные другими ответами здесь. Посмотрите, что вам нравится и что вы можете себе позволить.

Просто начните использовать систему управления версиями, независимо от того, какой тип вы используете. Что вы используете, не имеет значения; важно его использование

Как и все остальные, SC действительно зависит от ваших потребностей, вашего бюджета, вашей среды и т. Д.

В своей основе система управления версиями предназначена для обеспечения центрального репозитория всего вашего кода и отслеживания того, кто, что и когда с ним сделал. Должна быть полная история, и вы можете получать продукты, которые делают полные журналы изменений, аудит, контроль доступа и так далее ...

Каждый продукт, который есть там, начинает сиять (так сказать), когда вы начинаете смотреть на то, как вы хотите или должны включить SC в свою среду (будь то ваш личный код и документы или крупные корпорации). И когда люди их используют, они обнаруживают, что у этого инструмента есть ограничения, поэтому люди пишут новые. SVN родился из ограничений, которые создатели видели в CVS. Линус хотел что-то получше для ядра Linux, поэтому теперь у нас есть git .

Я бы сказал, начните использовать один (что-то вроде SVN, который очень популярен и довольно прост в использовании) и посмотрите, как он пойдет. Со временем вы можете обнаружить, что вам нужны некоторые другие функции или необходимо взаимодействовать с другими системами, поэтому вам может потребоваться SourceSafe или другой инструмент.

Контроль исходного кода всегда важен, и хотя вы можете обойтись вручную перенумерованными версиями файлов PSD или чем-то еще, когда вы работаете с ними, вы забудете запустить этот пакетный скрипт один или два раза или, вероятно, забудете, какой номер пошел с чем меняют. Вот где может помочь большинство этих инструментов SC (пока вы регистрируетесь / выезжаете).