Який контроль джерел мені потрібен для великого проекту середньої компанії? [зачинено]

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

Це лише той приклад, про який я цікавився. Я знаю, як використовувати SVN, але навіть на моїй останній роботі ми не використовували його в наших проектах, оскільки все робилося в PHP, і це були типово окремі проекти на 1 тиждень. Я просто мав SVN для свого локального коду і не потрібно було використовувати його з іншими.

Отже, що таке хороший контроль над джерелами, а конкретно, чому це добре для цього?

Використовуйте все, що вам зручніше. Усі системи управління версіями аналогічно роблять те саме; немає причин знову винаходити колесо, оскільки "воно може працювати краще". Якщо вашій команді нічого не влаштовує, виберіть варіант, який має найпростішу інтеграцію зі стандартним IDE вашої команди.

Mercurial чудовий, розповсюджений та безкоштовний.

Я думаю, що це залежить від того, який рівень підтримки вам потрібен.

Я використовую git вдома для своїх веселих проектів, коли виникають проблеми, це коштує мені часу, але я можу витратити час на вивчення того, що мені потрібно, щоб виправити це.

На роботі ми використовуємо Perforce, оскільки необхідна підтримка 24/7 технічної підтримки є обов'язковою. У нас люди постійно працюють над цим кодом у Нью-Йорку, Німеччині, Ірландії та Японії. Якщо є проблема, ми повинні отримати відповідь якнайшвидше. З мого досвіду, люди з Perforce дійсно знають, що вони роблять, і сприйнятливі до пропозицій.

Хоча я вважаю, що це питання є широким і має стосуватися на основі компанії на основі вашої ІТ-структури та структури мережі / розробки, я вважаю, що найважливішим аспектом вибору контролю джерела / версій є не те, яку програму ви використовуєте, але чи є його використання практично структурованим та нав'язаним.

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

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

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

Є й інші хороші програми управління джерелами, як сказала @EricBoersma:

Використовуйте все, що вам зручніше.

Просто створіть процеси та передовий досвід, і викупіть ті, хто можуть їх застосувати.

У вас є великі помилки щодо того, як працює git. Надіслати запит на притягнення до воротаря - це лише один із способів зробити це. Існує багато інших способів його налаштування, в тому числі майже точно так само, як svn, саме стільки людей починають, перш ніж їм достатньо комфортно налаштувати. З DVCS, як git, у вас є достатньо варіантів, щоб структурувати джерело управління навколо вашого робочого процесу, а не навпаки.

Раніше я вважав, що управління джерелом - це лише інструмент, і що кожен із продуктів робив більш-менш те саме. І тоді точка цих розподілених систем управління версіями натиснула на мене.

Розподілений контроль версій дозволяє мати більше одного центрального сховища. Уявіть зміни коду, що переміщуються з локального сховища розробників, у сховище функцій, у сховище продукту, у сховище QA і нарешті у звільнене сховище.

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

Ви знаєте, як використовувати SVN, а потім використовувати SVN - лише переходите до DVCS, якщо в них є щось, що вам потрібно.

Що насправді важливо, це те, що ви використовуєте щось, що вам сподобається, що є простим у використанні. Мартін Фаулер зробив швидке n просте опитування щодо СКС, результати дуже цікаві.

Я створив git на своїй останній роботі, де ми працювали над проектом аналогічного розміру (15 розробників, 18-місячний проект), і він добре працював.

Спосіб, яким ми його встановили, був:

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

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

Я хотів би дати Microsoft Foundation System System (TFS) принаймні гарний вигляд. З ваших коментарів я розумію, що ви не магазин Microsoft. Однак, наскільки я розумію, є те, що є досить надійний модуль Eclipse, якщо ви використовуєте цей IDE для розробки.

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

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