Какой источник контроля мне нужен для крупного проекта в средней компании? [закрыто]

Я знаю, что Git отлично подходит для проектов с открытым исходным кодом. Но мне было интересно: какая система управления исходным кодом желательна для компании с 20 программистами, работающими над проектом на 1 год? Из того, что я слышал, Git использует тягу; не было бы менее желательно, чтобы через кого-то проходили изменения в главном стволе? Особенно, когда все работают одновременно?

Это всего лишь пример, который меня интересовал. Я знаю, как использовать SVN, но даже на моей последней работе мы не использовали его в наших проектах, так как все было сделано на PHP, и это были, как правило, отдельные недельные проекты. У меня просто был SVN для моего локального кода, и мне не нужно было использовать его с другими.

Итак, что такое хорошие системы контроля версий и, в частности, почему это хорошо для этого?

Используйте то, что нравится вашей команде. Все системы контроля версий делают примерно одно и то же; нет смысла заново изобретать колесо, потому что «оно может работать лучше». Если вашей команде что-то не по вкусу, выберите вариант, который легче всего интегрируется со стандартной IDE вашей команды.

Mercurial отличный, распространяется и распространяется бесплатно.

Я думаю, что это зависит от того, какой уровень поддержки вам нужен.

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

На работе мы используем Perforce, потому что техническая поддержка 24/7 обязательна. У нас есть люди, работающие над кодом в Нью-Йорке, Германии, Ирландии и Японии все время. Если есть проблема, мы должны получить ответ как можно скорее. По моему опыту, люди в Perforce действительно знают, что они делают, и восприимчивы к предложениям.

Хотя я думаю, что этот вопрос является широким и должен решаться для каждой компании на основе вашей ИТ-инфраструктуры и сетей / структур разработки, я думаю, что наиболее важным аспектом при выборе источника / контроля версий является не то, какое приложение вы используете, но является ли его использование практически структурированным и обязательным.

Структура и обеспечение использования являются наиболее важными аспектами контроля версий.

Планируйте заранее и получите всех на борт. Обеспечить использование. Не только с программистами, но и со всем, что связано с проектами (документы, изображения и т. Д.).

SVN - прекрасное приложение, которое может быть интегрировано со многими надстройками (включая отслеживание ошибок / задач), не требует отдельного сервера и является бесплатным!

@EricBoersma говорит, что есть и другие хорошие приложения для контроля версий:

Используйте то, что нравится вашей команде.

Просто имейте процессы и лучшие практики на месте, и покупайте у тех, кто может обеспечить это.

У вас есть большие заблуждения о том, как работает git. Отправка запроса на получение привратнику - это только один из способов сделать это. Есть много других способов настроить его, в том числе в точности как svn, именно столько людей начинают, прежде чем им станет достаточно удобно настраиваться. С DVCS, подобным git, у вас есть достаточно вариантов, чтобы структурировать управление исходным кодом вокруг рабочего процесса, а не наоборот.

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

Распределенный контроль версий позволяет вам иметь более одного центрального хранилища. Представьте, что изменения кода переносятся из локального репозитория разработчика, в репозиторий компонентов, в репозиторий продукта, в репозиторий QA и, наконец, в выпущенный репозиторий.

Лично я использую коммерческий продукт под названием Kiln, который основан на Hg, но ключевой особенностью является распределенный контроль версий . Это революционизирует поток нового кода от разработчика в выпущенный продукт.

Вы знаете, как использовать SVN, а затем использовать SVN - переходите только на DVCS, если в них есть то, что вам нужно.

Что действительно важно, так это то, что вы используете то, что вам понравится, и которое легко использовать. Мартин Фаулер сделал быстрый н простой опрос о СУВ, что результаты очень интересны.

Я создал git на своей последней работе, где мы работали над проектом такого же размера (15 разработчиков, 18-месячный проект), и он работал хорошо.

Способ, которым мы настроили это, был:

У нас был git-сервер, который был нашим центральным авторитетным git-сервером. Члены команды не поощрялись отрываться друг от друга, чтобы все изменения передавались на центральный сервер.

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

Я бы хотя бы неплохо посмотрел Team Foundation System (TFS) от Microsoft. Я понял из твоих комментариев, что ты не магазин Microsoft. Тем не менее, я понимаю, что есть довольно надежный плагин Eclipse, если вы используете эту IDE для разработки.

Механизмы слияния и ветвления работают так же хорошо, как и любые другие системы управления исходным кодом (по моему опыту, лучше, чем svn, и почти так же хорошо, как и производительность), но что действительно хорошо, так это аспекты отслеживания проекта и управления проектом продукта, и встроенная автоматизация для сборок и развертываний.

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