Как и какой инструмент следует использовать для управления версиями?

Question

Немного фона:

Я использую Team Foundation Server в течение нескольких месяцев и знаю, как его использовать. Я использовал его для своего проекта на Codeplex. Они требовали TFS, и это было в моих установках Visual Studio, поэтому в основном я никогда не знал, что все, что нужно, чтобы заставить его работать, так как он легко работал внутри Visual Studio, и мне просто нужно было делать Check In и Check Out ...

Но теперь мне захотелось узнать, какие другие альтернативы были доступны, и сначала установили командную строку Mercurial (которую я никогда не использовал), затем искали альтернативу графического интерфейса и установили TortoiseHg и следовали инструкциям из документации на своем Веб-сайте. Затем он сказал, чтобы установить трехсторонний инструмент Diff ... Я искал его, а затем нашел TortoiseSVN; Я думал, что это должен быть какой-то плагин или что-то в этом роде, поэтому я искал SO для вопросов, связанных с моей ситуацией, когда я наткнулся на этот SO Question и был довольно загипнотизирован множеством инструментов для разной работы.

Сейчас:

• Может кто-нибудь объяснить, что все инструменты для управления версиями. Должен ли я устанавливать другой инструмент для каждой другой задачи. Разве нет ни одного пакета для всех. И в основном, какие задачи мы выполняем в Source Controlling. Я знаю только Check In, Check Out и проверку отличия от сайта Codeplex. Что еще я должен знать.

• Имеет ли каждый сайт, такой как Git, BitBucket и т. Д., Использовать различные черепахи (xxx) для управления ими.

• Аре управления источником и управления версиями различных терминов

Пожалуйста, помогите ..

Answer 1

Это огромная тема, и невозможно будет предоставить единый всеобъемлющий ответ. Тем не менее, вот несколько мыслей, если вы ищете больше Software Configuration Management решения, а не простой Revision Control System типа подхода:

Management Release:

В дополнение к управлению параллелизмом (заезд, регистрация по прибытии out и т. д.), ваш SCM может/должен также предоставлять функции истории, тегов, ветвлений и других типов управления выпуском. То есть, он всегда должен обеспечивать единый источник правды о том, какие исходные файлы, в какие выпуски, пакеты обновлений и т. Д. Чтобы сделать это, ваша среда сборки должна быть хорошо интегрирована в ваш SCM.

WIP Управление:

Хорошая система SCM позволит вам сравнить вашу работу в незавершенном до последней проверяется в правке. Он также должен позволить вам вернуть ваш WIP, временно отложить его или слить чужие изменения в файл по файлу.

Документация & Обучение

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

Непрерывная интеграция:

Automated сборки является обязательной для любой серьезной организации, и вы должны выбрать в SCM, который может быть доступом с построенными системами (например, Hudson, CruiseControl, бамбук и т.д.)

Система SCM должна иметь встроенную систему аутентификации, а также иметь возможность использовать внешние поставщики аутентификации, поскольку многие организации меняются со временем. Кроме того, он должен иметь возможность поддерживать разработчиков, работающих за пределами брандмауэра, предпочтительно по http.

IDE и инструмент для сборки Интеграция

Чтобы сделать все эти вещи проще ваш SCM должен быть в состоянии быть легко связаны в вашей системе разработки и использования инструментов командной строки, которые вы используете. Этот факт упрощается благодаря тому, что почти все не связанные с Microsoft среды IDE поддерживают все инструменты SCM.

Источник Просмотр

Большинство SCM инструменты, которые я видел, имеют ряд очень высокого качества, браузеры сторонних таких как Fisheye. Поэтому я обесцениваю это как дифференцирующий фактор.

Какой инструмент использовать?

Если ваша организация достаточно хорошо находится внутри вашей компании, тогда выберите Subversion. Он очень популярен, интегрируется с каждым инструментом IDE/OS/Build, работает с ToroiseSVN, поддерживает все платформы, поддерживает несколько протоколов, несколько пользовательских интерфейсов, мощную командную строку, огромное сообщество, является бесплатным и прочным. Он также имеет отличный бесплатный book.

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

За этими двумя, сэкономить массу времени и хлопот и забыть обо всем остальном .... на самом деле. Я понимаю, что меня умиляют, но вы попросили высказаться.

Answer 2

Если бы я должен был что-то посоветовать вам, это было бы

Использование ртутный (ака hg), и начните с , изучая его в командной строке. То, что вы узнаете все основные понятия, , которые могут быть несколько скрыты от , вы используете только наглядный графический интерфейс, такой как как TortoiseHG. Все с хорошим упрощенным учебником, конечно, возможно широко известный hginit который охватывает некоторые простые сценарии использования.

Это будет ответ на вопрос «Что еще мне знать», по крайней мере, для начала. Затем вы можете исследовать себя, имея ограниченную, но достаточно прочную основу. Или, по крайней мере, вы сможете задать более сжатые вопросы, чтобы узнать больше, или больше понять вопрос, который вы цитируете. Разумеется, ваш вопрос несколько шире, но я бы посоветовал не пытаться сразу все схватить. У каждой системы есть свои причуды и специальности, но теперь вы не должны беспокоиться об этом. Как и при программировании - вы не должны пытаться изучать сразу несколько языков, если вы еще не знаете.

Ах, и как последний штрих: Черепаха (xxx) - это не совсем система контроля версий, это просто типичное имя для интегрированного с оболочкой клиента Windows для системы xxx. Насколько мне известно, часть «Черепаха» относится к «оболочке».

---

PS. «Меркуриальный» совет объясняется моим личным вкусом, но также ощущением того, что обучение Hg позволит вам легко понять большинство идей из других систем (если вам когда-либо понадобится).

Answer 3

Из моего личного опыта я бы рекомендовал взглянуть на новое поколение «систем управления версиями», которые называются системами управления распределенной версией. Это такие системы, как Git (и я думаю, Mercurial, но я не использовал это)., Что actaully сохраняет полную систему управления версиями локально, и когда вы фиксируете удаленный репозиторий (нажимаете git terms), вы нажимаете изменения в своей локальной версии система управления системой управления главной версией на сервере.

Также Git предназначен для того, чтобы сделать ветром легкий ветерок. В таких системах, как ветвление Subversion, не так просто, но с Git Branching рекомендуется применять изменения. Я использовал Git, Subversion (SVN) и SourceSafe (самая худшая система управления версиями в три раза!), И это главное преимущество Git над более традиционными системами управления версиями.

Для примера, если вы исправление ошибки или добавить функцию в базе кода, который использует SVN стандартная практика будет

1. Выезд филиал вы собираетесь работать.
2. Марка любая ошибка исправляет и тестирует их.
3. Проверьте изменения.

С Git или подобных систем вы бы

1. Отделение мастер филиала локально (т.е. разработка, producton версия 1.1, и т.д.).
2. Внесите исправления и протестируйте ошибки в локально разветвленной версии (т. Е. Вы создали ветку jira-123-bugfix для версии 1.1).
3. Слейте ветку обратно в свою локальную копию основной ветки, из которой вы ее создали, и убедитесь, что все в порядке.
4. Затем нажмите изменения, внесенные в локальную копию главной ветки, в центральный репозиторий Git.

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

Для получения дополнительной информации см. Статьи A Successful Git Branching Model.