Система контроля версий для одного разработчика
Какая система контроля версий рекомендуется для очень маленькой команды (один разработчик)?
Цена не имеет значения. Клиент заплатит:-)
Я работаю на Vista32 с VS 2008 в C++ и позже в C# и с WPF. Настройка дополнительного (физического) сервера для этого кажется мне излишней.
Есть мнения?
26 ответов
Я бы использовал Subversion (на самом деле я его использую) [обновление: июль 2014 года - я использую Git - см. Конец ответа]. SVN это:
- свободно,
- достаточно хорошо (см. недостатки ниже),
- просто,
- отлично работает на Windows (и Linux тоже),
- многие люди используют его, поэтому легко получить помощь,
- может интегрироваться с большинством IDE, то есть Visual Studio (т.е. ankhsvn или VisualSVN - больше информации) или Eclipse (т.е. Subclipse - здесь кто-то спрашивал об этом).
Я бы настоятельно рекомендовал разделить машину с сервером контроля версий. В лучшем случае где-нибудь на облаке. Преимущества:
- Вы не потеряете свои репозитории контроля версий, если ваш ящик для разработки умрет.
- Вам не нужно беспокоиться об обслуживании еще одной коробки.
Есть компании, которые размещают SVN-репозитории.
Здесь приведены ссылки на пакеты SVN (клиент и сервер) для различных операционных систем.
Недостатки SVN
Я использую SVN на Windows-машине около 5 лет и обнаружил, что у SVN есть несколько недостатков:).
Это медленно на больших репозиториях
У SVN (или его клиента - TortoiseSVN) есть один большой недостаток - он ужасно медленный (при обновлении или фиксации) в больших (тысячи файлов) репозиториях, если у вас нет SSD- диска.
Слияние может быть трудным
Многие люди жалуются на то, насколько сложно слиться с SVN.
Я делаю слияния около 4 лет (в том числе около 2 лет в CVS - это было ужасно, но выполнимо) и около 2 лет с SVN.
И лично мне не трудно - с другой стороны - любое объединение легко после объединения веток в CVS:).
Я делаю слияние большого репозитория (фактически два репозитория) один раз в неделю, и редко возникают конфликты, которые трудно разрешить (большинство конфликтов решаются автоматически с помощью программного обеспечения diff, которое я использую).
Однако в случае проекта нескольких разработчиков слияние не должно быть проблемой, если вы соблюдаете несколько простых правил:
- часто объединяйте изменения,
- избегать активного развития в разных отраслях одновременно.
Добавлено в июле 2011
Многие разработчики рекомендовали распределенный контроль версий, например, Git или Mercurial.
С точки зрения одного разработчика, есть только несколько важных преимуществ DVCS по сравнению с SVN:
- DVCS может быть быстрее.
- Вы можете зафиксировать локальный репозиторий без доступа к центральному.
- DVCS - это популярная вещь, и ей интересно пользоваться / учиться (если кто-то платит за ваше обучение).
И я не думаю, что слияние является проблемой в случае одного разработчика.
Джоэл Спольски написал учебник по Mercurial, который, безусловно, стоит прочитать.
Таким образом, несмотря на многие преимущества DVCS, я бы остановился на SVN, если слияние или скорость не являются проблемой.
Или попробуйте Mercurial, который в соответствии с этими и этими вопросами лучше поддерживается (в июле 2011 года) в Windows.
Добавлено в июле 2014
Около года я использую Git (главным образом, Git Bash) для своих домашних проектов (т.е. решения проблем Эйлера), и локальные ветки для каждой проблемы Эйлера - действительно хорошая функция - именно так, как это описывается как преимущество DVCS.
Сегодня инструменты Git для Windows намного лучше, чем 2 года назад. Вы можете использовать удаленное репо (например, GitHub или ProjectLocker и многие другие), чтобы сохранить копию своего проекта подальше от рабочей станции без дополнительных усилий и денег.
Однако я использую GUI-клиент только для просмотра различий (и иногда для выбора файлов для фиксации), поэтому лучше не бояться командной строки - это действительно приятно.
Так что на сегодняшний день я бы пошел с Git.
Я бы также порекомендовал Mercurial. Его набор команд очень похож на тот, который есть в Subversion, поэтому кривая обучения не такая крутая. Как упоминалось ранее, он предназначен для локального запуска, но также легко обмениваться / объединять изменения между компьютерами или даже просто отправлять их на удаленный сервер для резервного копирования.
Он предлагает отличные инструменты, такие как TortoiseHG, и имеет хорошие плагины для NetBeans и Eclipse. Он также работает на Win32, как написано на Python.
Если вы не хотите настраивать сервер самостоятельно (например, для резервного копирования), доступны бесплатные хостинг-провайдеры; В Mercurial Wiki есть полный список.
Я определенно рекомендую Git
Прекрасно работает как для больших, так и для маленьких команд. Единственный недостаток - плохая поддержка родных окон. Хотя у меня в Cygwin все работает нормально. Там также существует собственный порт Windows.
Некоторые из его преимуществ:
- Отличная поддержка для нелинейного рабочего процесса. Его ветвление и слияние намного лучше, чем, например, Subversion.
- Хорошие инструменты для навигации по вашему хранилищу
- Хорошо справляется с крупными проектами.
- Невозможно изменить историю, не изменив криптографическую подпись вашего хранилища.
- С его не монолитным дизайном, это легко написать.
Некоторые люди считают, что у него крутая кривая обучения. Но как только вы поймете это, вы сможете сделать с ней практически все, что захотите.
Перейти на Subversion и TortoiseSVN, вам не нужно устанавливать его на сервере.
- Затраты равны нулю
- Документация по Subversion - это здорово и интересно читать
- tortoiseSVN - очень удобный клиент
Subversion имеет очень низкий барьер для входа.
TortoiseSVN - это бесплатный клиент, который интегрируется в ваш проводник, т. Е. В меню правой кнопки мыши.
Хранилище может быть просто каталогом где-то на вашем ПК или на сетевом диске. Резервное копирование просто означает архивирование этого каталога
Есть несколько плагинов для Visual Studio для Subversion, AnkSvn - это тот, который я использовал, он бесплатный и хорошо интегрируется (т. Е. Он будет хорош в перемещении и удалении файлов и т. Д.)
Subversion - хороший выбор для одного разработчика.
Обновить:
С этого поста я использую Mercurial. Это распределенный SVN. "Распределенный" аспект не может быть непосредственно полезным для отдельного разработчика, однако он лучше при слиянии и несколько быстрее. Существует также бесплатный и хороший клиент расширения для Windows Explorer - Tortoise Hg.
Итак, подведем итоги: если вы относитесь к категории людей, которые будут работать во многих филиалах одновременно (делать пики и т. Д.) Или если вы работаете на нескольких ПК одновременно и хотели бы иметь полный автономный доступ к истории регистрации на обоих, тогда Mercurial. Если вам просто нужно простое отслеживание и хорошо проверенное и простое для понимания решение, тогда Subversion.
Sourcegear Vault - отличный вариант, он работает на SqlServer и существует уже много лет. Я бы не стал использовать любую версию VSS (Visual Source Safe).
Я удивлен, что никто не упомянул Perforce. Это бесплатно для 2 человек, невероятно быстро, и интегрируется с VS. Также у исходного сервера есть привязки для него по умолчанию.
В дополнение к управлению исходным кодом, действительно стоит завершить цикл и настроить сервер символов и исходный сервер, чтобы у вас была простая отладка всего, что вы отправили (например, больше не нужно искать pdbs или источник, соответствующий двоичному файлу), И исходный, и символьный сервер полностью бесплатны и поддерживаются в VS с 2005 года.
Я использую Mercurial. Он работает отдельно в моей системе разработки Vista без каких-либо других зависимостей. Я использую командную строку, но есть также TortoiseHG для интеграции с Explorer.
Два комментария:
- Есть и другие инструменты, которые, вероятно, лучше интегрируются с VS. Я думаю, что у Subversion есть хорошие плагины против VS.
- Преимущество отдельного сервера в том, что это хорошая резервная копия всей вашей работы на тот случай, если ваш жесткий диск умирает от вас и т. Д.
Редактировать: @Slartibartfast - если вы просто хотите запустить управление исходным кодом на одном компьютере, то инструмент управления распределенным исходным кодом, такой как git или Mercurial, идеален, поскольку он предназначен для запуска полных репозиториев на машине без нагрузки на сервер. Тот факт, что вы никогда не подключаете свой репозиторий к чьим-либо другим, чтобы выдвигать и извлекать изменения, не означает, что этот инструмент не будет правильным.
Вы можете использовать Vault от SourceGear, инструмент для замены источника безопасной визуальной студии. Среда интегрирована в Visual Studio.
Инструмент бесплатный для одного пользователя.
Дополнительная информация: http://www.sourcegear.com/vault/index.html
Существует два возможных решения вашей проблемы: централизованная VCS или распределенная VCS (DVCS).
Централизованная VCS, такая как Subversion, удовлетворит вас функцией фиксации и просмотра журнала. Это также позволяет вам безопасно хранить свой репозиторий на другом компьютере, что должно быть одной из ваших основных целей, поскольку сбой жесткого диска всегда возможен. Однако при использовании Subversion история все еще находится только в центральном местоположении, что делает ее уязвимой, и вы заявили, что не хотите иметь другой сервер.
Распределенные системы контроля версий (DVCS), такие как Mercurial и Git, позволяют выполнять более сложные операции с вашим репозиторием. С обоими этими инструментами весь репозиторий находится на одном и том же компьютере, что упрощает создание резервных копий и использование репозитория на другом компьютере, например на ноутбуке. Хотя Mercurial на первый взгляд может показаться сложным, операции, которые вы будете использовать с Subversion, в значительной степени совпадают с Mercurial. Поэтому нет никаких дополнительных затрат, чтобы начать работу, если вы уже знаете Subversion, и вы можете легко использовать более продвинутые функции Mercurial позже.
Вы должны быть в состоянии найти службу онлайн-хранилища для вашего хранилища Mercurial, позволяющую вам легко создавать резервные копии и когда-нибудь делать совместную работу, если у вас есть такая необходимость.
Моя рекомендация - Mercurial с TortoiseHg.
Система контроля версий не заботится, если в ней участвует только один разработчик:)
Я бы порекомендовал вам использовать систему контроля версий, которую вы использовали ранее и понравились.
Если вам нравится интеграция системы контроля версий против 2008 года, я бы предпочел использовать TFS, хотя у меня никогда не было опыта в ее настройке, но это не должно быть так сложно.
Другая возможность - использовать svn (вы найдете несколько серверов на Google) и Tortoisesvn, который интегрируется в оболочку Windows и с которым приятно работать.
В ряде публикаций рекомендуется размещать репозиторий на сервере, поскольку он обеспечивает избыточность. Я не думаю, что это все, что полезно для одного пользователя. Использование отдельного серверного компьютера создает большую сложность, но это не приносит большой избыточности: если вы потеряете серверный компьютер, у вас по-прежнему будут текущие источники на компьютере разработчика, но вы, возможно, потеряли ВСЕ свои истории. Размещение репозитория на сервере имеет смысл, если этот сервер регулярно резервируется. Использование услуги внешнего хостинга для хранилища может обеспечить избыточность хранилища, но вы находитесь во власти внешней службы И вам необходимо подключение к Интернету для доступа к хранилищу. Если вы используете внешний хост, делайте частые резервные копии репозитория, который вы контролируете!
Я бы рекомендовал TortoiseSVN, используя локальный файловый репозиторий. Просто убедитесь, что вы регулярно делаете резервные копии локального хранилища на втором компьютере или внешнем носителе (например, CD-ROM).
Bazaar - хорошая система контроля версий. Мне нравится использовать его для моих конфигов linux, потому что вам не нужно создавать отдельный репозиторий.
Я понимаю, что стоимость не является проблемой, но хорошее бесплатное решение, которое не включает в себя регистрацию и выход, заключалось бы в размещении кода в Dropbox, выполняя это, вы мгновенно получаете управление версиями и резервное копирование, которые являются основными функциями, которые один разработчик системы обеспечит.
Некоторое время назад я написал в блоге с практическими рекомендациями об использовании SVN только с одним разработчиком. Я назвал это Единый источник контроля
Я бы порекомендовал две вещи:
Во-первых, этот другой сервер - что произойдет, если ваша машина умрет? дом сгорает? и т.д. Наличие этого на другом компьютере - хорошая идея с точки зрения избыточности.
Второй - ЧТО:
Если вы хорошо знакомы с безопасностью визуального источника (не), подумайте о SourceGearVault. Это ОЧЕНЬ приятно, очень быстро и очень сильно улучшенный "клон" VSS (то есть работает так же от пользователей POV, а не под капотом). Требуется SQL-сервер и Windows Tho (это.NET + SQL-сервер). Бесплатно для 1 пользователя.
Из вас нет, тогда я предлагаю вам сделать одну из двух вещей:
Во-первых, получите VisualSVN. Это здорово, работает с VS2008 действительно хорошо. Во-вторых, если вы ДОЛЖНЫ запускать его локально, получите сервер VisualSVN (бесплатно!). Убедитесь, что у вас есть хороший план резервного копирования. Работает на XP/2003/2008/Vista и т. Д. Это просто Apache + SVN, под капотом, так что это просто экономит на настройке - мне потребовалось 5 минут, чтобы установить и запустить его.
ИЛИ, и я предпочитаю это:
зайдите куда-нибудь, как Unfuddle, Dreamhost и т. д., и получите хостинг для SVN. Это личное, это быстро, а главное - это ОФИС. Моя учетная запись Dreamhsot, с чем-то сумасшедшим, например, 500 ГБ памяти и 1-2 ТБ перевода в месяц, стоит около 6 долларов в месяц! Есть другие, которые делают хостинг SVN + отслеживание ошибок и т.д. Посмотрите вокруг.
Но да - SVN - это schizzzznit. Вы можете создать локальный репозиторий, но мне нравится иметь удаленный резервный сервер.
TFS - это полное превышение для одного разработчика (или <5 IMO)
Несколько хороших ответов здесь.
Я хочу еще раз повторить предложение использовать отдельный компьютер для размещения сервера управления исходным кодом, хотя это не обязательно должен быть выделенный компьютер. Это может быть ваш Windows Home Server или другой сервер, который вы уже используете. Или это может быть виртуальная машина, размещенная на каком-либо другом сервере. Как бы то ни было, просто сделайте это отдельно от машин, на которых вы пишете код.
Я также хочу предложить вам хорошую дисциплину резервного копирования для вашего сервера. Нечто, по крайней мере, ночью; ежечасно, если можете. Выполните резервное копирование на выделенное устройство (например, на внешний жесткий диск) или на другое устройство (сервер в доме вашего двоюродного брата в другом штате) или в облаке (Amazon S3). Помните, что ваш исходный код является вашим ключевым активом; заботиться о нем!
Я использую Springloops - инструмент контроля версий для разработчиков
- SVN / Git контроль версий
- Автоматическое развертывание на серверах
- Создать репозитории
- Приглашать людей
- Импорт файлов
- Отличная поддержка
Итак, попробуйте Springloops
Я бы порекомендовал Subversion, поскольку он предназначен для одного разработчика, и я предполагаю, что вы не выполняете сложное слияние и много проверок журналов / истории.
Похоже, что многие люди используют http://svnrepository.com/ для своего хостинга. Он поставляется с Trac и даже Git, если вам это понадобится позже.
Руки вниз Я бы использовал git, и я считаю, что многие причины, по которым один разработчик хотел бы использовать git, намекаются или описываются в git magic
Я работаю с Bazaar уже несколько недель, и мне это очень нравится. Я разработчик Linux, поэтому не особо разбираюсь в Tortois, но если вам это нравится, вы должны знать, что Tortoisbzr существует
Ну, для начала вам не нужен распределенный пакет:) Я не уверен, что означает эта физическая часть, потому что вы можете поставить svn server на свой компьютер без особых проблем.
С другой стороны, в NetBeans есть модуль локальной истории, который регистрирует все локальные изменения файла. Может быть, что-то подобное будет достаточно для вас, если в Visual Studio есть нечто подобное.
Я не понимаю, почему тот факт, что ваш единственный разработчик что-то меняет в системе контроля версий. Я бы следовал той же системе (фактически я делаю на своих сольных проектах). В этих случаях я использую http://wush.net/ (svn и trac). Это быстро установить и не требует, чтобы вы сами знали или знали о каких-либо проблемах с сервером. Я рекомендую вам использовать что-то вроде этого.
Я также использую Perforce для своих личных вещей, в основном потому, что мы используем их на работе. Для этого также есть привязки emacs, так что вы можете синхронизировать, проверять, входить и выходить и т. Д. - все изнутри emacs.
Я недавно переместил свою студию из Subversion в Perforce и разместил некоторые заметки об этом, вроде посмертного, в моем блоге здесь. Надеюсь, это полезно.
Я бы порекомендовал использовать Subversion. Многие рекомендуют использовать отдельную коробку в качестве сервера на случай, если ваш компьютер разработчика умрет. Что происходит, когда сервер SVN умирает? Ответ здесь заключается в том, что независимо от того, где вы решите запустить сервер, убедитесь, что вы всегда делаете частые резервные копии, возможно, автоматизируемые ежедневно на некотором вторичном, предпочтительно удаленном компьютере.