Начинающий контроль исходного кода

Question

Какую систему управления версиями лучше всего изучить, если вы новичок в управлении версиями?

Answer 1

Все, кроме визуального безопасного источника; предпочтительно тот, который поддерживает концепции ветвления и слияния. Как уже говорили другие, Subversion - отличный выбор, особенно с клиентом TortoiseSVN.

Обязательно ознакомьтесь (простите за каламбур) Классическая серия Эрика Синка по Source Control HOWTO .

Answer 2

Я бы пошел прямо на Git . Я раньше использовал Subversion, но всегда чувствовал, что делаю это неправильно. Git имел смысл с первого дня.

Полезные ресурсы:

• Линус Торвалс на Git
• Скотт Чакон "Getting Git"

Answer 3

Я бы посоветовал вам попробовать Subversion, например, с установщиком SVN в один клик . Попробуйте выполнить поиск SO по «Subversion», и вы найдете множество вопросов с ответами, которые указывают на хорошие учебники.

Удачи!

Answer 4

Есть несколько основных концепций, которые я считаю важными для изучения:

1. Заезды / выезды (очевидно)
2. Локальные версии и версии сервера
3. Отображение / привязка локального рабочего пространства к удаленному хранилищу или хранилищу.
4. Объединение ваших изменений обратно в файл, содержащий изменения из др.
5. Ветвление (что это такое, когда / зачем его использовать)
6. Объединение изменений из ветви обратно в основную ветку или ствол.

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

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

Git также становится все более популярным вариантом и является еще одной бесплатной или очень дешевой альтернативой Subversion. Тем не менее, знание концепции ветвления и слияния становится критически важным для использования Git.

Вы можете использовать unfuddle как бесплатный и простой способ экспериментировать с Git и Subversion. Я использую его для размещения нескольких репозиториев Subversion для некоторых побочных проектов, над которыми я работал в прошлом.

Answer 5

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

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

2. Несколько лет спустя я занимался созданием проекта с открытым исходным кодом и в то время rubyforge предлагал репозитории CVS. Я попробовал это, и это было немного лучше, чем PVCS. Конечно, я был единственным, кто использовал репозиторий. Однако я очень расстроился, когда попытался изменить структуру своих файлов, потому что мне не нравилось то, как я их изначально импортировал. В CVS это не сработало.

3. Через несколько лет я работал над другим личным проектом, и мой хостинг-провайдер предложил простые в настройке хранилища Subversion (SVN). Мне потребовалось немного исследований, чтобы правильно его запустить и запустить, но как только я прошел начальную кривую обучения, она мне понравилась.

4. Вскоре после этого я понял, что мне нравится иметь контроль источника и что моя текущая работа не имела его. Таким образом, я проповедовал, и через долгое время моя команда внедрила Source Safe, потому что мы работаем в Visual Studio и, как правило, являемся магазином Microsoft. Мне не терпелось его использовать, но вскоре я обнаружил, что теряю файлы и что Visual Studio помещает вещи в неправильное место, и я некоторое время работаю над проектом, а затем отправляюсь экспортировать свою работу в другое место и обнаружим, что он либо не будет экспортировать, либо будет экспортировать только некоторые проекты в решении. Это заставило меня осознать, что, хотя я и думал, что использую «систему контроля версий», копия кода, которая была наиболее безопасной, надежной и полной, была моей рабочей копией. Полная противоположность тому, что должен делать источник управления.

5. Итак, на прошлой неделе я был настолько сыт по горло Source Safe, что отправился на поиски. Изучив несколько решений, я решил попробовать git. Я не буду говорить, что все это были розы, так как у меня снова была некоторая кривая обучения, чтобы заставить ее делать то, что я хочу, однако мне понравилось это достаточно, чтобы преобразовать всю свою работу и личные проекты в это. Одна из действительно хороших вещей в этом заключается в том, что мне не нужен централизованный репозиторий, поэтому я могу использовать его, не проходя тонну красной ленты на работе, чтобы установить его.

Короче говоря, я бы порекомендовал Git, я использую Mysysgit в Windows, и у него есть дополнительный бонус, давая мне оболочку Bash. В Linux вы можете просто установить его из вашего менеджера пакетов. Если вам не нравится git, попробуйте Subversion. Если вам не нравится ни один из них, вам, вероятно, не понравятся CVS или PVCS. Ни при каких обстоятельствах не пытайтесь использовать Source Safe, это ужасно.

Answer 6

Vault от SourceGear.com превосходен. Это бесплатно для отдельных пользователей и обеспечивает превосходный интерфейс VS 2005/2008. Я люблю это!

рп

Answer 7

Я нашел http://unfuddle.com избавил меня от возни с установкой SVN или git. Вы можете получить там бесплатный аккаунт и использовать любой из них - плюс вы можете использовать свой OpenID там.

Тогда вам не придется возиться с правильной настройкой и сосредоточиться на том, как вы собираетесь его использовать!

Answer 8

У каждого инструмента есть свои сильные и слабые стороны. Вопрос в том, каковы ваши требования. К сожалению, с этой проблемой, как и со многими другими, зачастую выбирается не лучший инструмент, а тот, с которым кто-то знаком. Например, если вам не нужно много филиалов, а ваша команда небольшая и локальная, почти все vcs выполнят эту работу (кроме SourceSafe). Ситуация меняется, если вам нужны ветки (что почти по необходимости означает, что вам также нужно выполнять слияния), ваша команда распределена, вам нужна повышенная безопасность (субподрядчикам не разрешено все дерево исходного кода), отслеживание задач и т. Д. Также возникает вопрос стоимость тремя различными способами: стоимость лицензий, стоимость обслуживания (некоторые инструменты настолько сложны, что на практике вам нужен кто-то просто для управления репозиториями) и стоимость обучения.

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

Просто несколько указателей:

• StarTeam - самый простой из инструментов Я использовал. Это потребовало очень мало повышение квалификации. Я получил однодневное обучение так как я должен был быть сопровождающим. Это поддержание заняло у меня менее 30 минут в неделю. Пользователи, которых я "обучал" написав двухстраничное руководство и после этого у меня было очень мало вопросов отвечать.
• Континуус был другим концом масштаб, насколько простота использования обеспокоен. С другой стороны, обработка задач была великолепной и обеспечивала хорошую поддержку управления релизами. Проблема в том, что даже будучи менеджером релизов, я никогда не думал, что легкость создания релизов (это когда-то вы узнали, как, но это заняло значительное количество времени) должна быть важнее повседневной работы, которую делают разработчики.
• Слияния и создания филиалов отличается дико между инструментами. Некоторые инструменты делают это просто, как git и ClearCase (хотя последний очень медленный) некоторые в основном заставляют вас делать слить вручную. Если вам нужно сделать много сливается, стоимость может стать высокой. ClearCase также был дорогим во всех три категории, упомянутые ранее (хотя надо сказать, что мы использовали все продвинутые вещи, которые не необходимо). Git с другой стороны не хватает хорошего интерфейса и некоторых концепций отличается от того, что вы могли бы использовать к. Функции безопасности Git также отсутствует (Гитоз обращается к некоторым проблемы, но не все).
• Большинство инструментов, которые я использовал, также довольно медленный. Инструменты типа PVCS / Dimensions были просто медленно, несмотря ни на что такие вещи, как открытие каталога в хранилище), некоторые очень медленно более конкретные способы (например, ClearCase).

Из инструментов, которые я использовал, я бы выбрал StarTeam, если ваши разработчики не очень опытны (и если вы не против заплатить лицензию, что довольно дорого), и мерзавец, если у вас есть опытные парни из VCS, которые могут настроить окружающая среда для других парней. Mercurial также выглядит как интересный конкурент и, кажется, имеет несколько лучший пользовательский интерфейс.

Continuus, PVCS / Dimensions и ClearCase слишком медленные, слишком сложные и слишком дорогие практически для любого проекта. Если кто-то настаивает на выборе одного из них, я бы выбрал ClearCase.

Я не использовал Subversion, который многим нравится (но у меня есть ощущение, что это скоро изменится), поэтому не могу комментировать, как он сравнивается с другими инструментами, которые я использовал (обычно в качестве менеджер сборки и / или выпуска).

Что касается первого инструмента, который нужно выбрать, проблема с Git, Bazaar и Mercurial заключается в том, что они распределены по vcs. Это отличается от традиционной модели сервер-клиент, где у вас есть центральное хранилище. Для того, чтобы просто изучить материал, я бы рекомендовал также прочитать о концепциях Например, ветвление - это то, что вы можете не понять правильно, просто попробовав себя (существуют разные стратегии ветвления для разных ситуаций). К тому же, если вы единственный, кто обращается к хранилищу, это совсем другое дело, например, конфликты слияния не будут проблемой (вы можете их увидеть, но вы легко их исправите, так как знаете код в обеих ветках). Конечно, вы узнали бы о проверках, проверках и тому подобном, но я не думаю, что эти проблемы особенно сложны в первую очередь.

Добавленная проблема с vcs заключается в том, что они, как правило, используют разные термины. В StarTeam, который в остальном прост в использовании, они по какой-то причине настаивают на использовании терминов «проверить» и «проверить и заблокировать». Последнее - то, что большинство людей думают, что первое делает. Для этого есть причина (вы можете редактировать файлы, даже если у вас нет эксклюзивной блокировки), но все равно было бы гораздо разумнее вызывать их «Получить» и «Проверить», чтобы избежать путаницы.

Answer 9

@ Ян Нельсон :

Я согласен с вами, что Source Safe является плохой системой контроля версий, но имейте в виду, что использование Source Safe намного лучше, чем "носить с собой дискеты", как сказал Джоэл Спольски.

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

Answer 10

Subversion - хорошее место для начала. Это очень стабильная и современная система контроля версий. Лучший онлайн-ресурс для изучения Subversion - Контроль версий с Subversion . В отношении серверного и клиентского программного обеспечения существует множество вариантов. Я лично предпочитаю (для среды Windows).

1. Сервер VisualSVN

2. интегрированный в оболочку клиент TortoiseSVN и

3. Дополнение AnkhSVN Visual Studio Subversion

Опять же, в Subversion есть много доступных опций. Кроме того, это постоянно развивающаяся система контроля версий (в отличие от устаревшего SourceSafe). Его можно легко интегрировать с многочисленными автоматизированными инструментами сборки (CruiseControl, FinalBuilder) и системами отслеживания ошибок / проблем (JIRA).

Если вы ищете современные системы контроля версий, выберите Git (разработанный Линусом Торвальдсом). Но если вы совершенно не знакомы с системами контроля версий, я бы предложил начать с Subversion.