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

10

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

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

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

Мартин Маат
источник
13
Потому что вы код в php не является причиной, чтобы не использовать VCS.
Chris
@ Крис: Если бы это зависело от меня, в сети был бы репо. Но, к сожалению, эта компания вообще не использовала его. Я просто говорил, что у меня нет опыта работы в команде с управлением исходным кодом
Взгляните на programmers.stackexchange.com/questions/940/…
ysolik
Или этот programmers.stackexchange.com/questions/19771/…
Амир Резаи

Ответы:

29

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

EricBoersma
источник
1
Это умный и беспристрастный ответ - мне нравится.
Мерф
1
+1 системы контроля версий достаточно сложны, все, что вы можете сделать, чтобы минимизировать это, будет к лучшему!
Даль
3
Есть вещи, которые распределенные VCS делают намного лучше, чем централизованные, и вы всегда можете использовать DVCS в качестве централизованного, поэтому для долгосрочного общего назначения я бы порекомендовал Git или Mercurial. Для подобных ситуаций подойдет любая достаточно современная VCS, и Subversion, вероятно, легче всего изучить.
Дэвид Торнли
Определенно используйте то, что ваша команда знает или удобно использовать. (Если это не CVS или RCS.) Если вы переключаетесь на что-то новое и каждый должен изучать это, сделайте математику: 20 человек * 3 часа обучения * 40 долларов США / час = 2400 долларов США.
Барри Браун
Или ожидайте, что они узнают, как грамотно подобрать новую VCS в течение 5 минут ...
альтернатива
4

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

Стивен А. Лоу
источник
4

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

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

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

Марк Талман
источник
1
+1: Perforce дорогой, но вы получаете то, за что платите.
Никто не
3

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

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

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

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

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

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

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

Пейдж Уотсон
источник
3

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

Карл Билефельдт
источник
2

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

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

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

Майкл Шоу
источник
Это много репозиториев для одного проекта. Какой кошмар для слияния.
JBRWilkinson
3
Я бы согласился с вами, если бы он сливался с SubVersion или CVS. Причина, по которой эти распределенные продукты контроля версий работают, заключается в том, что они делают объединение простым и в значительной степени бесконфликтным.
Майкл Шоу
2

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

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

gbjbaanb
источник
2

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

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

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

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

Cercerilla
источник
0

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

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

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

туз в рукаве
источник
Говоря как кто-то, кто использовал TFS от Eclipse. Нет, это ужасно. (я могу вдаваться в подробности), я бы определенно не назвал это надежным. TFS великолепен, но расширение Eclipse шокирующе плохо (где великолепно AnhkSVN для Visual Studio)
Линдон Уайт
У меня очень, очень плохой опыт работы с TFS по многим причинам, хотя я работаю в среде Microsoft и мне нравятся инструменты .Net и Ms в целом. Я никогда не буду рекомендовать TFS никому.
ПОПРАВИТЬ