Мы в .NET, Java и Rails магазин
Мы использовали Subversion в течение многих лет, и его фантастической системы, сделали все, что мы думали, нам нужно от SCM. Около 9 месяцев назад мы начали играть с Github.com, разрабатывая приложение Rails (неизбежное в сообществе Rails).
С тех пор мы полностью перешли на Github.com, используя частные репозитории для разработки коммерческих программ с закрытым исходным кодом.
Git заставило нас не сломать код сборки или clobber в месяцах - что-то, что случалось время от времени, и заставило нас потерять работу дня, пытаясь исправить проблему. Subversion не предоставляет вам гибкость в ваших методах работы, которые делает Git. Если у вас проблемы (сломанная сборка или исправление), Subversion не поможет вам, это даже будет работать против вас. Его механизм ветвления/слияния очень трудно использовать, поскольку он не отслеживает происхождение ветки. Кроме того, когда вы объединяетесь, история изменений изменяется таким образом, что все изменения команды в конкретной ветви приписываются пользователю, выполняющему слияние. Git также молниеносно, так как весь репо, над которым вы работаете, является локальным, что очень заметно, когда вы работаете в удаленных местах.
Сказанное, Subversion займет у вас неделю или две, чтобы получить опыт работы, Гит занимает не менее месяца, особенно если вы приехали из Subversion или CVS. Если вы притворитесь, что это просто более современный SVN или CVS, вы разочаруетесь в отсутствии улучшения в рабочем процессе кодирования, и вы будете раздражены множеством команд.
У нас есть установка с тремя ветвями: исправление < -> master < -> разработка. В нормальных условиях команда разработчиков будет работать в отрасли развития. Для каждого пользовательского рассказа разработчик создаст ветку разработки: разработка < -> пользовательская история. Когда история завершена, история пользователя сливается с разработкой, и ветка истории пользователя может быть удалена. Это продолжается и продолжается, и мастер остается стабильным и незатронутым, пока менеджер сборки не решит, что он сэкономят все изменения в развитии обратно в мастер. Если в то же время клиент звонит и требует исправления, это тоже делается изолированно от основного и может быть объединено с остальной частью базы кода (мастер &) в подходящий момент в будущем.
Теперь обратитесь к графическим интерфейсам и SCM. Мы избегаем их, как чумы. Графические интерфейсы плохо подходят для работы с SCM. Я знаю - спорный, но выслушай меня. Командная строка замедлит вас больше, чем делает GUI, и когда вы работаете с SCM, и есть вероятность, что вы собираетесь сделать что-то плохое или разрушительное для своего центрального репо, медленное - это хорошо. Медленно заставляет задуматься о своих действиях. Все типичные графические интерфейсы, которые я видел (EclipseSVN, TortoiseGit/SVN), все предварительно выбирают ваши недавние изменения как часть комманды, которую вы собираетесь совершить, независимо от того, готовы ли эти изменения к совершению или нет. ПЛОХО!!!! Вам нужно подумать о своих коммитах и о том, насколько они сложны или сложны, - командные строки работают лучше, чем GUI в этом отношении. Все наши .NET-кодеры, которые, естественно, обращаются к выполнению задач с помощью графических интерфейсов, используют командную строку Git и используют командную строку SVN до этого только по тем причинам, которые были изложены выше. Это дало им большее чувство контроля.
Subversion не может быть худшим выбором для вас, тем более, что относительно легко переносить репозиторий CVS на Subversion. Не пробовал никаких плагинов для VS, хотя (обычно для этого используется Tortoise SVN). – Daff
Вы уверены, что смена систем контроля версий - это не просто лечение симптомов, а не причина? Почему вы пытаетесь улучшить скорость проверок? Некоторые разработчики только совершают один раз в неделю, что приводит к длительным сеансам слияния/сломанным сборкам? – jared
Он будет лечить симптом. Проблема в том, что некоторые разработчики просто не проверяют вообще, если не спросят, и слияние - это королевская боль, если они сменяют месячные изменения. – Jesse