Должен ли я использовать SVN или Git? [закрыто]


321

Я начинаю новый распределенный проект. Стоит ли использовать SVN или Git и почему?


5
Да, Git работает на Mac. Если вы используете macports для его установки, он даже установит интерфейс Mac для интерфейса коммитов и просмотра.
Сет Джонсон

3
возможно дубликат stackoverflow.com/questions/871/...

3
@Andre - потому что вы можете использовать MonoDevelop - я переключаюсь с Vault на SVN, чтобы разрабатывать программное обеспечение .NET на своем компьютере Mac или ПК. Не было клиента для Vault, но был для SVN :-)
schmoopy


4
Github / bitbucket + sourcetree = рай! - sourcetreeapp.com
thecodeassassin

Ответы:


253

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

SVN разработан, чтобы быть более центральным, где Git основан на том, что каждый пользователь имеет свое собственное Git-репо, и эти репозитории возвращают изменения обратно в центральное. По этой причине Git предоставляет пользователям лучший локальный контроль версий.

Между тем у вас есть выбор между TortoiseGit , GitExtensions (и если вы размещаете свой «центральный» git-репозиторий на github, их собственный клиент - GitHub для Windows ).

Если вы хотите выйти из SVN, возможно, вы захотите немного оценить Bazaar . Это одна из систем контроля версий следующего поколения, имеющая этот распределенный элемент. Он не зависит от POSIX, как git, поэтому существуют собственные сборки Windows, и его поддерживают некоторые мощные бренды с открытым исходным кодом.

Но вам могут даже не понадобиться такие функции. Посмотрите на особенности, преимущества и недостатки распределенных VCS . Если вам нужно больше, чем предлагает SVN, рассмотрите один. Если вы этого не сделаете, вы можете придерживаться превосходной (в настоящее время) интеграции SVN для настольных ПК.


24
Мог бы также взглянуть на Hg (Меркурий)
Джоэл

24
С октября 2008 года ситуация значительно улучшилась. Вы можете установить TortoiseGit, получить последнюю портативную версию MSysGit и сообщить TortoiseGit, где ее найти. Я только что перенес свой большой репозиторий svn на git сегодня, потому что плохая поддержка переименования svn, наконец, свела меня с ума
Мы все Моника

4
Переходя на 2 года, теперь у нас есть несколько хороших инструментов для Windows. В настоящее время я использую NetBeans с MSysGit. Мне также повезло с TortoiseGit. Я думаю, что это достаточно хорошо для использования в производстве. Учитывая, как трудно управлять простыми конфликтами в git subversion, это огромное улучшение.
Кейо

24
Мы используем Git на Windows интенсивно и уже давно. Git абсолютно фантастичен для Windows.
Чарли Флауэрс

13
@Oli Было бы неплохо обновить ваш ответ (особенно о git-клиенте Windows) на основе комментариев и вашего опыта. Нынешний ответ кажется предвзятым сейчас, когда прошло 2-3 года с момента его написания.
Амит

111

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

Я определенно рекомендую git over subversion; он просто намного более универсален и позволяет "автономную разработку" таким способом, каким подрывная деятельность никогда не могла. Он доступен практически на всех мыслимых платформах и имеет больше возможностей, чем вы когда-либо будете использовать.


9
У меня, с другой стороны, были некоторые проблемы с git на windows, это очень странно для моего репо. И я использовал самую последнюю версию в Cygwin (это было что-то вроде месяц назад).
Роман Плашил

7
@Roman: ну, порт Cygwin вряд ли совпадает с портом win32. Я ожидаю, что порт Cygwin гораздо менее проверен ...
SamB

49
«больше возможностей, чем вы, вероятно, когда-либо будете использовать» - это красный флаг в моей книге
BT

26
@ BT "красный флаг", я не согласен. Мне часто хочется, чтобы был какой-то способ что-то сделать, и после небольшого поиска я обнаружил, что есть несколько команд, о которых я не знал, которые делают именно это. Я использую GIT на своей машине с Windows, и у меня еще не было серьезных проблем.
testing123

@ testing123, но тогда они не являются функциями, которые «вы, вероятно, [никогда не будете использовать», потому что вы фактически использовали их.
mulllhausen

77

Вот копия ответа, который я сделал на некоторый повторяющийся вопрос с тех пор, как он был удален о Git против SVN (сентябрь 2009 г.).

Лучше? Помимо обычной ссылки WhyGitIsBetterThanX , они разные:

одна - центральная VCS, основанная на дешевой копии для веток и тегов, другая (Git) - распределенная VCS, основанная на графе ревизий. Смотрите также Основные понятия VCS .


Эта первая часть вызвала некоторые неосведомленные комментарии, притворяясь, что основная цель двух программ (SVN и Git) одинакова, но они были реализованы совершенно по-разному.
Чтобы прояснить принципиальную разницу между SVN и Git , позвольте мне перефразировать:

  • SVN является третьей реализацией контроля версий : RCS, затем CVS и, наконец, SVN управляют каталогами версионных данных. SVN предлагает функции VCS (маркировка и слияние), но его тег - это просто копия каталога (например, ветвь, за исключением того, что вы не «должны» что-либо трогать в каталоге тегов), и его объединение все еще сложно, в настоящее время основанное на метаданных -данные добавлены, чтобы вспомнить, что уже было объединено.

  • Git - это управление содержимым файлов (инструмент, созданный для объединения файлов), превращенный в настоящую систему управления версиями , основанную на DAG ( направленном ациклическом графе ) коммитов, где ветви являются частью истории данных (а не самими данными). ) и где теги являются истинными метаданными.

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

  • если у вас много сложных слияний, выполнение их с SVN будет более длительным и более подверженным ошибкам. если вам нужно создать много веток, вам нужно будет управлять ими и объединять их, опять же, намного проще с Git, чем с SVN, особенно если задействовано большое количество файлов (скорость становится важной)
  • если у вас есть частичное слияние для незавершенной работы, вы воспользуетесь областью размещения Git (индекс), чтобы зафиксировать только то, что вам нужно, спрятать остальное и перейти к другой ветке.
  • если вам нужна автономная разработка ... хорошо, с Git вы всегда «онлайн», со своим собственным локальным репозиторием, независимо от того, какой рабочий процесс вы хотите использовать с другими репозиториями.

Тем не менее, комментарии к этому старому (удаленному) ответу настаивали:

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

, на что я ответил:

«заменяемость» ... интересный термин ( используется в компьютерном программировании ).
Конечно, Git вряд ли является подтипом SVN.

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

Вы, конечно, не можете (всегда) просто заменить SVN на Git «без изменения каких-либо желательных свойств этой программы (корректность, выполненная задача, ...)» (что является ссылкой на вышеупомянутое определение замещаемости ):

  • Один - это расширенный инструмент ревизий, другой - настоящая система контроля версий.
  • Один подходит для небольших и средних монолитных проектов с простым рабочим процессом слияния и (не слишком много) параллельных версий. Для этого достаточно SVN, и вам могут не понадобиться все функции Git.
  • Другой позволяет использовать средние и большие проекты на основе нескольких компонентов (по одному репо на компонент ), с большим количеством файлов для слияния между несколькими ветвями в сложном рабочем процессе слияния, параллельными версиями в ветвях, слияниями модернизации и так далее. Вы можете сделать это с SVN, но вам гораздо лучше с Git.
    SVN просто не может управлять любым проектом любого размера с любым рабочим процессом слияния. Мерзавец может.

Опять же, их природа принципиально иная (что приводит к разной реализации, но это не главное).
Один видит контроль версий как каталоги и файлы, другой видит только содержимое файла (настолько, что пустые каталоги даже не регистрируются в Git!).

Общая конечная цель может быть одинаковой, но вы не можете использовать их одинаково и не можете решить один и тот же класс проблем (по объему или сложности).


10
Я не согласен с вами, что git и svn принципиально различны, но я не согласен по многим вашим вопросам. svn, возможно, был написан для замены cvs, но они никак не связаны между собой, в то время как cvs начинались как сценарии поверх RCS, так что существует прямая связь. Тем не менее, человек, которого вы цитируете, совершенно прав, они оба принципиально управляют ревизиями файлов, реализацией и процессом, в котором это происходит (или как это происходит), являются деталями реализации. Это похоже на разницу между CRC и SHA1, принципиально очень разные, но они делают то же самое.
Эрик Фанкенбуш

37

2 ключевых преимущества SVN, которые редко упоминаются:

  1. Поддержка больших файлов. В дополнение к коду я использую SVN для управления своим домашним каталогом. SVN - единственная VCS (распределенная или нет), которая не душит мои файлы TrueCrypt (исправьте меня, если есть другая VCS, которая эффективно обрабатывает файлы размером более 500 МБ). Это потому, что сравнения сравнения передаются в потоковом режиме (это очень важный момент). Rsync недопустим, потому что это не 2-х сторонний.

  2. Частичное хранилище (subdir) извлечение / регистрация. Mercurial и bzr не поддерживают это, а поддержка git ограничена. Это плохо в командной среде, но неоценимо, если я хочу проверить что-то на другом компьютере из моего домашнего каталога.

Просто мой опыт.


6
«Пожалуйста, исправьте меня, если есть другая VCS, которая эффективно обрабатывает файлы размером более 500 МБ» - конечно же, выполняйте!
Джеймс Криси

8
Perforce = не бесплатно. Кроме того, Perforce доступна не для всех платформ.
WhyNotHugo

4
Почему бы не поместить репозиторий SVN ВНУТРИ контейнеров truecrypt? Вы также можете туннелировать это через ssh и настроить сервер для хранения этого конкретного репо в другом файле truecrypt. Это имеет дополнительное преимущество, заключающееся в том, что вы можете сделать частичные проверки этого репо.
WhyNotHugo

1
@Hugo Насколько я знаю, клиент Perforce доступен для Windows, Unix, вариантов Linux, Mac, Amiga, BeOS, Cygwin, HPUX, IBM AS / 400, OS / 2, DEC VMS и файлового сервера Novell. В списке отсутствует какая-то соответствующая платформа?
eis

1
Да, OpenBSD (и я знал это по опыту, не нужно было гуглить это). Я думаю, что это не будет работать на Maemo, хотя я могу ошибаться (и да, я использую Git на Maemo).
WhyNotHugo

25

После дополнительных исследований и просмотра этой ссылки: https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html

(Некоторые выдержки ниже):

  • Это невероятно быстро. Ни один другой SCM, который я использовал, не мог идти в ногу с ним, и я использовал много, включая Subversion, Perforce, darcs, BitKeeper, ClearCase и CVS.
  • Это полностью распространено. Владелец хранилища не может диктовать, как я работаю. Я могу создавать ветки и фиксировать изменения, пока они отключены на моем ноутбуке, а затем синхронизировать их с любым количеством других репозиториев.
  • Синхронизация может происходить на многих носителях. Канал SSH, по HTTP через WebDAV, по FTP или путем отправки электронных писем с исправлениями, которые будут применены получателем сообщения. Центральный репозиторий не нужен, но может использоваться.
  • Филиалы даже дешевле, чем в Subversion. Создать ветку так же просто, как записать 41-байтовый файл на диск. Удалить ветку так же просто, как удалить этот файл.
  • В отличие от Subversion, ветки ведут свою полную историю. без необходимости выполнять странную копию и пройтись по копии. При использовании Subversion мне всегда было неловко смотреть историю файла на ветке, которая возникла до того, как была создана ветка. из #git: spearce: Я не понимаю одну вещь о SVN на странице. Я сделал ветку в SVN и просмотр истории показал всю историю файла в ветке
  • Слияние веток проще и более автоматическое в Git. В Subversion вам нужно помнить, с какой последней ревизии вы слились, чтобы вы могли сгенерировать правильную команду слияния. Git делает это автоматически и всегда делает это правильно. Это означает, что меньше шансов ошибиться при объединении двух веток.
  • Слияния ветвей записываются как часть правильной истории хранилища. Если я объединяю две ветви вместе или если я объединяю ветку обратно в ствол, из которого она получена, эта операция объединения записывается как часть истории репозитория как выполненная мной и когда. Трудно оспорить, кто выполнил слияние, когда оно прямо там в журнале.
  • Создание репозитория является тривиальной операцией: mkdir foo; cd foo; git init Вот и все. Что означает, что я создаю Git-репозиторий для всего в эти дни. Я склонен использовать один репозиторий на класс. Большинство этих репозиториев имеют размер менее 1 МБ на диске, поскольку в них хранятся только конспекты лекций, домашние задания и мои ответы на LaTeX.
  • Внутренние форматы хранилища невероятно просты. Это означает, что ремонт очень прост, но даже лучше, потому что он настолько прост, что его очень сложно испортить. Я не думаю, что кто-либо когда-либо имел поврежденный репозиторий Git. Я видел, как Subversion с fsfs испортилась сама. И я видел, как Berkley DB слишком часто портил себя, чтобы доверять мой код бэкэнду bdb в Subversion.
  • Формат файлов Git очень хорош для сжатия данных, несмотря на то, что это очень простой формат. Репозиторий CVS проекта Mozilla составляет около 3 ГБ; это около 12 ГБ в формате fsfs Subversion. В Git это около 300 МБ.

Прочитав все это, я убедился, что Git - это путь (хотя есть небольшая кривая обучения). Я также использовал Git и SVN на платформах Windows.

Я хотел бы услышать, что другие скажут после прочтения выше?


15
Git невероятно быстр в некоторых операциях, главным образом потому, что эта операция влияет только на ваш локальный репозиторий. Например, Git checkin не следует справедливо сравнивать с SVN checkin, потому что SVN checkin также является толчком к переходу на промежуточное хранилище для остальной части вашей команды. Это требует попадания в сеть, а сравнение Git без сетевого коммита с передачей по сети приводит к появлению несоответствующего сравнения. Если вы фиксируете, а затем теряете жесткий диск, с Git вы теряете свои изменения. Это хорошо, если вы ожидаете этого, но в нераспределенных SCM этого не ожидается.
Эдвин Бак

1
@EdwinBuck Не принимая во внимание то, что сделал Вакар, в тестах даже с учетом сетевого времени git работает быстрее: git-scm.com/about/small-and-fast
Sqeaky

Ваш пункт «Создание репозитория - тривиальная операция» чрезвычайно важен, особенно в Windows: по сравнению с SVN гораздо проще быстро смоделировать связку взаимосвязанных распределенных репо, все из которых связаны с центральным (--bare) репо с помощью Git, чем это делается аналогично SVN (установить приложение Windows SVN server и т. д.). Также (как ни странно) я нахожу, что Git более согласован во всех ОС: командная строка очень хорошо спроектирована и, таким образом, достаточна большую часть времени (и практически идентична между ОС) по сравнению с различными нативными приложениями клиент / сервер SVN ...
Shivan Dragon

1
Статья вики, на которую вы ссылаетесь, полна ошибок. Поэтому ваш ответ неверен. Downvoted. В вики есть страница обсуждения, которая ссылается на svnvsgit.com и объясняет, почему сравнение неверно.
Бахреп

Невероятно быстро? Я переместил проект ciforth из местного cvs в github. Это простой проект, но он имеет один большой основной исходный файл в 10 000 строк. Если я пытаюсь использовать вину на этот файл, GitHub падает в тайм-аут. В большинстве случаев, если кто-то не удовлетворен тем, чтобы говорить быстро, и настаивает на использовании такого квалификатора, это не является взвешенным мнением, что вызывает у меня подозрение в отношении всего, что вы говорите. Groetjes Альберт
Альберт ван дер Хорст

12

Я бы создал хранилище Subversion. Делая это таким образом, отдельные разработчики могут выбирать, использовать ли клиенты Subversion или Git-клиенты (с git-svn). Использование git-svnне дает вам всех преимуществ полноценного решения Git, но дает отдельным разработчикам большой контроль над своим рабочим процессом.

Я полагаю, что через некоторое время Git будет работать так же хорошо в Windows, как и в Unix и Mac OS X (как вы и просили).

Subversion имеет отличные инструменты для Windows, такие как интеграция TortoiseSVN для Explorer и интеграция AnkhSVN для Visual Studio.


11

Самое смешное: я размещаю проекты в Subversion Repos, но получаю к ним доступ через команду Git Clone.

Пожалуйста, прочитайте Разработка с Git на Google Code Project

Хотя Google Code изначально говорит на Subversion, вы можете легко использовать Git во время разработки. Поиск «git svn» предполагает, что эта практика широко распространена, и мы также рекомендуем вам поэкспериментировать с ней.

Использование Git в репозитории Svn дает мне следующие преимущества:

  1. Я могу работать распределенным на нескольких машинах, совершая и вытягивая их
  2. У меня есть центральный backup/public репозиторий SVN для других, чтобы проверить
  3. И они могут свободно использовать Git для своих

3
Примечание: по состоянию на июль 2011 года Google Code изначально поддерживает Git.
Джереми Салвен

9

Не совсем отвечаю на ваш вопрос, но если вы хотите воспользоваться преимуществами Distributed Revision Control - похоже, что вы это делаете - и вы используете Windows, я думаю, вам лучше использовать Mercurial, а не Git, поскольку Mercurial имеет гораздо лучшую поддержку Windows. Mercurial также имеет порт Mac.


9

Если ваша команда уже знакома с программным обеспечением для управления версиями и исходным кодом, таким как cvs или svn, то для простого и небольшого проекта (такого, как вы утверждаете), я бы порекомендовал вам придерживаться SVN. Я действительно доволен svn, но для текущего проекта электронной коммерции, который я делаю на django, я решил работать с git (я использую git в svn-mode, то есть с централизованным репо, к которому я обращаюсь и тяну для того, чтобы сотрудничать хотя бы с одним разработчиком). Другому разработчику удобно работать с SVN, и, хотя опыт других может отличаться, нам обоим действительно не хватает времени, чтобы использовать git для этого небольшого проекта. (Мы оба хардкорные пользователи Linux, если это вообще имеет значение.)

Конечно, ваш пробег может отличаться.


8

Определенно svn, поскольку Windows - в лучшем случае - гражданин второго сорта в мире git(см. Http://en.wikipedia.org/wiki/Git_(software)#Portability для получения более подробной информации).

ОБНОВЛЕНИЕ: Извините за неработающую ссылку, но я прекратил попытки заставить SO работать с URI, которые содержат круглые скобки. [ссылка исправлена ​​сейчас. -ed]


1
К вашему сведению: заключите URL в угловые скобки или замените скобки на% 28 и% 29.
Фил

1
Будет ли работать кодировка URL для синтаксиса [] ()?
Хэнк Гей

16
Это неверный FUD. Git фантастичен для Windows. И SVN довольно плохо везде.
Чарли Флауэрс

6
Для всех тех, кто меня опровергает, пожалуйста, вернитесь и посмотрите на комментарии разработчиков примерно с 2008 года: совершенно ясно, что Линус и банда не заботились о поддержке Windows. Это нормально: я тоже не хочу этого делать, и мое ПО не так сложно, как VCS, которое ожидает POSIXish-поведения от файловой системы. Тем не менее, кажется несправедливым характеризовать мое высказывание как FUD, если вы посмотрите на контекст.
Хэнк Гей

2
Может быть, в 2008 году git плохо работал на Windows, но я использую msysgit с 2009 года, и он работает безупречно. Это включает в себя gitk, автономный настольный эквивалент GitHub.
Дан Даскалеску

8

Главное, что Git - это распределенная VCS, а Subversion - централизованная. Распределенные VCS немного сложнее для понимания, но имеют много преимуществ. Если вам не нужны эти преимущества, Subversion может быть лучшим выбором.

Другой вопрос - поддержка инструментов. Какие VCS лучше поддерживаются инструментами, которые вы планируете использовать?

РЕДАКТИРОВАТЬ: Три года назад я ответил так:

А на данный момент Git работает на Windows только через Cygwin или MSYS . Subversion поддерживала Windows с самого начала. Поскольку git-решения для окон могут работать на вас, могут возникнуть проблемы, так как большинство разработчиков Git работают с Linux и не думали о переносимости с самого начала. На данный момент я бы предпочел Subversion для разработки под Windows. Через несколько лет это может быть неактуально.

Теперь мир немного изменился. У Git хорошая реализация для Windows. Хотя я не проводил тщательного тестирования на Windows (поскольку я больше не использую эту систему), я вполне уверен, что все основные VCS (SVN, Git, Mercurial, Bazaar) теперь имеют надлежащую реализацию Windows. Это преимущество для SVN исчезло. Остальные пункты (Централизованные и Распределенные и проверка поддержки инструмента) остаются в силе.


Я оптимистичен, что горизонт неактуальности будет намного короче, чем несколько лет.
Грег Хьюгилл

Да, возможно, это будет только один год. Git имеет динамичное сообщество разработчиков. Но у Subversion тоже есть. Через год или два вам придется снова взглянуть на оба вопроса, чтобы ответить на этот вопрос.
Mnementh

1
Сейчас год или два спустя. Как это выглядит? :)
Мерлин Морган-Грэм

3
В Git отсутствует расширение распределенной модели SCM для других фаз конвейера разработки программного обеспечения. У нас нет хорошей модели для систем сборки распределенных выпусков, распределенного автоматизированного тестирования, контроля качества, контроля над выпусками и т. Д. Мы только получаем некоторую экспериментальную поддержку для распределенного резервного копирования, и это после десятилетий исследований. Таким образом, Git предлагает больше для разработчика и меньше для процесса разработки программного обеспечения. Все реализации Git в конечном итоге благословляют одно репо как центральное, что упрощает наиболее интересные возможности Git для факсимиле SVN.
Эдвин Бак

1
@hibbelig Git не имеет центрального репозитория, каждый репозиторий эффективно (благодаря своему распределенному дизайну) равен. Это означает, что вы либо переделываете свой производственный конвейер, чтобы по возможности обрабатывать все репозитории одинаково, либо искусственно благословляете один репозиторий на «искусственно повышенный» статус (он же центральный репозиторий ). Если вы делаете первое, никто не знает много о построении параллельных конвейеров, где выпуск может исходить от любого разработчика, если вы делаете второе, обещание распределенной обработки обманывается централизованным соглашением.
Эдвин Бак

6

Я бы выбрал SVN, так как он более распространен и более известен.

Я думаю, Git был бы лучше для пользователя Linux.


1
Это, однако, быстро меняется. SVN теряет долю рынка, в то время как GIT получает: Например: wikivs.com/wiki/Git_vs_Subversion#Popularity или programmers.stackexchange.com/questions/136079/…
Зельфир Кальцталь

@Zelphir: Я бы не стал называть 7 лет быстро, но да, GIT получает долю на рынке и особенно лучше для слияния файлов.
Буркхард

4

Git изначально не поддерживается в Windows, только пока. Оптимизирован для систем Posix. Однако запуск Cygwin или MinGW позволяет вам успешно запустить Git.

В настоящее время я предпочитаю Git, а не SVN, но для того, чтобы преодолеть порог, если вы приехали из CVS, SVN, потребуется время.


8
Определите «изначально». msysgit отлично работает
Милан Бабушков

4

Я бы, наверное, выбрал Git, потому что чувствую, что он намного мощнее, чем SVN. Доступны дешевые услуги Code Hosting, которые отлично работают для меня - вам не нужно делать резервные копии или выполнять какие-либо работы по техническому обслуживанию - GitHub является наиболее очевидным кандидатом.

Тем не менее, я ничего не знаю об интеграции Visual Studio и различных систем SCM. Я представляю интеграцию с SVN заметно лучше.


4

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

Что я заметил, так это то, что каждый проект SVN по мере роста становится очень большим по размеру проектом, если только он не экспортируется. Где, как, проект GIT (вместе с данными Git) очень легкий по размеру.

В SVN я имел дело с разработчиками от новичка до эксперта, и новички и промежуточные звенья, похоже, создают конфликты файлов, если копируют одну папку из другого проекта SVN для ее повторного использования. Принимая во внимание, что я думаю, что в Git вы просто копируете папку, и она работает, потому что Git не представляет папки .git во всех своих подпапках (как это делает SVN).

После долгого общения с SVN я наконец-то решил переместить меня и моих разработчиков в Git, поскольку легко объединять и объединять работу, а также одним большим преимуществом является то, что изменения локальной копии могут быть зафиксированы настолько, насколько это возможно. желаемый, а затем, наконец, за один раз отправляется в ветку на сервере, в отличие от SVN (где мы должны время от времени фиксировать изменения в репозитории на сервере).

Кто-нибудь, кто может помочь мне решить, должен ли я действительно пойти с Git?


Я бы не стал называть разработчиков, которые скопировали папку, контролируемую SVN, в другой проект, чтобы использовать ее повторно, и не ожидал, что очевидные проблемы будут «промежуточными». Я бы назвал их новичками. Да, вы правы, это связано с подпапкой .svn, которая сообщает SVN, к какому репозиторию принадлежат файлы. Если пользователь удалил эту подпапку .svn, он мог бы импортировать папку в новый проект SVN. Я все еще с SVN, но мои потребности немногочисленны. GIT отлично подходит для крупных проектов.
Дьяста

3
Новейшим svn-клиентам не нужна .svnпапка в каждом подкаталоге. Это «исправляет» ошибку копирования до того, как это произойдет.
Эдвин Бак

4

Это сводится к этому:

Будет ли ваше развитие линейным? Если это так, вы должны придерживаться Subversion.

Если, с другой стороны, ваша разработка не будет линейной, а это значит, что вам нужно будет создать ветвление для различных изменений, а затем объединить такие изменения с основной линией разработки (известной Git как основная ветвь), тогда Git сделает Гораздо больше для вас.


3

ты пробовал бзр ?

Это довольно хорошо, connonical (люди, которые делают Ubuntu) сделали это, потому что им больше ничего не нравилось на рынке ...


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

Почти в 100% случаев с ОС люди «делали это [любое программное обеспечение], потому что больше ничего не нравилось на рынке».
WhyNotHugo

@Hugo С открытым исходным кодом, если им нравится что-то еще на рынке, они будут способствовать этому, а не делать что-то новое.
yingted

Это совсем не ответ на вопрос
Альберт ван дер Хорст

@AlbertvanderHorst Нет, это не так, на этот вопрос отвечали в дни дикого запада SO, когда никто не знал ничего лучшего, и предлагали альтернативу. Споря в моей спешке, похоже, что я также неправильно написал имя Canonical. Мне стыдно!
Омар Кохеджи

3

Могу ли я расширить этот вопрос и спросить, хорошо ли работает Git на MacOS?

Ответ на комментарии: Спасибо за новость, я с нетерпением ждал возможности попробовать это. Я установлю это дома на моем Mac.


1
Да, это прекрасно работает. Я установил его через MacPorts и использую ежедневно.
Грег Хьюгилл

Оно делает. Он отлично подходит для любой системы на основе POSIX (Unix, Linux, Solaris, BSD и т. Д.). В действительности проблема заключается только в Windows.
Оли

и git-gui и gitk, вероятно, работают в OS-X так же, как в Linux и Windows. В отличие от tortoiseSVN, какой AFAIK предназначен только для Windows?
Дэвид Шмитт

@David Schmitt: хорошо, tortoisesvn.tigris.org называет это «Расширением Windows Shell для Subversion», так что я бы предположил, да ;-).
SamB

@ Роберт: как прошел твой опыт работы с git на OS X?
Дэвид Шмитт


2

SVN кажется хорошим выбором под Windows, на что указывают другие люди.

Если кто-то из ваших разработчиков хочет попробовать GIT, он всегда может использовать GIT-SVN, где репозиторий SVN воссоздается в репозитории GIT. Затем он должен иметь возможность работать локально с GIT, а затем использовать SVN для публикации своих изменений в основном хранилище.


1

Вы должны пойти с DVCS, это как квантовый скачок в управлении источниками. Лично я использую Monotone и его ускорение разработки без конца. Мы используем его для Windows, Linux и Mac, и он был очень стабильным. У меня даже есть buildbot, выполняющий ночные сборки проекта на каждой из платформ.

Распространение DVCS обычно означает, что вы создадите центральный сервер, чтобы люди могли вносить изменения в него и из него.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.