Является ли Git готовым к моему боссу?

Ответ 1

Зависит от команды. Если вы часть технологически подкованной команды, то git замечательно (и часто более чем замечательно). Но если некоторые люди не удобны в командной строке, могут быть некоторые проблемы (потому что tortoisegit находится в зачаточном состоянии, а все остальные GUI, с которыми я столкнулся, честно говоря, сосать).

Если у вас есть люди с не-техническими навыками (дизайнеры, руководители высшего звена и т.д.), я бы пошел с чем-то вроде подрывной деятельности. TortoiseSVN замечательно (и довольно прост в использовании), и svn получил, возможно, 80% от awesome git.

Ответ 2

Более простой шаг (и один, который я сделал успешно) - создать центральный репозиторий Subversion, который дает всем хорошие инструменты, такие как TortoiseSVN. Затем разработчики, которые хотят использовать git-svn как полноценную среду Git в качестве клиента Subversion.

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

Ответ 3

Мы используем git в моей компании, и, основываясь на ваших требованиях к визуальным инструментам, я бы сказал нет. черепаха идет, но пока не совсем. Такие инструменты, как GitX и GitNub, отлично подходят в OS X, но они не полностью охватывают все, что вы описываете.

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

Самая большая проблема, с которой вы, вероятно, столкнетесь, - это сдвиг парадигмы. Это не самая легкая вещь для освоения, и это будет неприятно для некоторых из вашей команды, поскольку они привыкают к работе с git и ее более распределенной (хотя я не большой поклонник их распределения распределенных SCM).

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

Ответ 4

Переход от VSS к Subversion станет отличным обновлением. Subversion предоставит вам отличные возможности, такие как атомарные коммиты, отличный графический интерфейс, интеграция с IDE, отличная работа с Windows, концепция набора изменений, надежный репозиторий и т.д. Для типичной компании на базе Windows с небольшими/средними командами я считаю, что подрывная деятельность - отличная инструмент.

Если вас интересует распределенный VCS, вы должны смотреть на git, hg, bzr. hg и bzr опережают git, насколько Windows поддерживает. Тем не менее, для Windows (msysgit) есть версия с портированной версией командной строки git, которая объединяет обратные изменения в основной git. Также сообщество git быстро растет, и поэтому я ожидаю, что опыт Windows улучшится.

Git поддерживает гибридный сценарий, где сервер может быть CVS/SVN, а отдельные разработчики могут использовать git -svn для работы локально и управления локальными ветвями. Такая настройка дает лучшее из обоих миров. Однако git -svn является уязвимым для Windows из-за зависимости от библиотек Perl SVN. В этом случае не так просто использовать приятные функции git, как разработчики, разделяющие ветки и т.д.

Учитывая, что ваши проекты не являются открытыми, я думаю, что Subversion, скорее всего, предоставит все необходимые вам функции. После того, как git соответствует требуемой панели юзабилити Windows, вы можете импортировать ваши SVN-репозитории в git.

Если ваша компания не сильно влияет на ветвление и слияние, я бы пошел на SVN, иначе вам нужно будет внимательно рассмотреть DVCS.

Я работаю над проектом с открытым исходным кодом, репозиторий хранился в CVS, который затем перенесен в SVN, а затем в git. Каждый шаг был серьезным обновлением. Главной мотивацией перехода SVN на git было упрощение для участников, чтобы они поддерживали свои ветки, постоянно обновляли их, подталкивали их к разработчикам и разработчикам легко применять их с минимальными усилиями.

Ответ 5

Когда речь идет о графических инструментах для git, единственным полезным инструментом, который я использовал до сих пор, является gitk (который визуализирует Дерево ревизий для вас), и я использовал git за последние полгода сам, как сказал кто-то еще, TortoiseGit все еще очень рано и имеет некоторые изломы для разработки.

На работе мы оценивали три разных DVCS (а именно git, mercurial (hg) и bazaar) и имел полный упакованный вечер, представляя их для остальной компании. Mercurial получил самый положительный ответ, и есть Tortoise его вариант.

Я предлагаю вам сделать то же самое. Найти кого-нибудь, который может представить альтернативу git (например, меркурийному или базару) и сделать презентацию вместе в DVCS в вашей компании. Гораздо важнее рассказать своим коллегам, как потрясающий DVCS, а не босс, потому что в конце концов они будут использовать его. Таким образом, он более образован, если они были подвергнуты воздействию таких инструментов и сами почувствовали его вкус.

Когда мы представили его, мы также предположили, что люди не контролируют версию, поэтому мы быстро объяснили основные понятия, такие как checkin-checkout и commit-merge и почему люди контролируют версию. В основном это было похоже на статьи Эрика Санка об управлении версиями, но разделились до нужных вещей.

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

Ответ 6

По умолчанию графический интерфейс git для Windows ужасен и имеет тенденцию застревать в циклах повторного сканирования. Теперь я использую клиент командной строки, который кажется прекрасным, пока вы можете иметь дело с использованием vi для внесения записей в журнал. Я только начал использовать github, что нормально, но имеет отвратительную навигацию.

Лично я использую Subversion с Apache почти для всего, что я делаю. Subversion отлично работает, хорошо документирована, легко настраивается и бесплатна.

Ответ 7

У большинства компаний любого типичного размера действительно требуется распределенный источник управления?

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

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

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

Ответ 8

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

Чтобы ответить на ваш вопрос: "Является ли Git готовым?" = > Я думаю, что это (за исключением кривой обучения командной строки.)

Я думаю, что вы и ваша команда/компания должны спросить себя: "Готовы ли вы к git?." После того, как вы начнете использовать его, у вас будет много энергии у вас под рукой.

Ваши первые шаги к обучению Git:

• Чтение руководств Git в github.
• Перейдите к Pragmatic Programmer и d/l "free" Индердер в Гитуб
• Вы также можете выбрать Прагматическое управление версиями с помощью Git

Ответ 9

Как раз в связи с упоминанием Spoike о TortoiseHg для Mercurial, автономная загрузка Windows для Bazaar в наши дни включает TortoiseBzr, хотя она отмечена как экспериментальная.

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

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

Е.

Ответ 10

Когда я впервые столкнулся с Git, моя первая реакция была "Я просто не Git it". Я видел много мощных инструментов, но они были не очень интуитивными. Когда я стал использовать Git, я понял, что единственной особенностью, которая мне очень понравилась, была быстрая дешевая и легкая ветвь.

Я попробовал несколько графических интерфейсов, включая GTK, который поставляется с Git. Я нашел их более запутанными, чем операции с командной строкой.

Если ваша компания используется для Subversion, и вам нужно перейти на DVCS, попробуйте Mercurial. Пользователи Subversion будут чувствовать себя дома очень быстро. Тем не менее, мало кто может обернуть вокруг Меркуриал идею о том, что должно быть веткой. Какие виды побегов с использованием DVCS в ноге в первую очередь (за исключением возможности совершить локально и нажать/вытащить других до нажатия в основной репозиторий).

Я ежедневно работаю с Subversion и Mercurial, что вполне подходит для всех моих проектов. Я думаю, если вам не нужна сила разветвления и возможность редактировать предыдущие версии... Subversion или HG будет вашим лучшим выбором. Я бы не рекомендовал Git, как кому-то сначала подвергать DVCS, а просто мое мнение и опыт с ним.

Ответ 11

Есть очень хороший pod cast о GIT.

Ответ 12

Конечно, я думаю, что Git готов. Просто убедитесь, что у вас есть время в вашем графике проекта, чтобы люди привыкли к нему, когда они переключаются...

Ответ 13

Есть ли поддержка для Git в большинстве сторонних приложений (кроме Eclipse..)? Не для многих из тех, что я видел.

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

Кроме того, новее не всегда лучше. Требуется время, чтобы этот тип сдвига парадигмы был подтвержден как улучшение. Посмотрите на люфт на Maven с течением времени. Не будьте настолько быстрыми, чтобы прыгать с корабля из проверенного решения, а не когда ваша задача и репутация поставлены на карту - если Git не работает, вы не будете выглядеть хорошо, рекомендуя его. По крайней мере, с таким продуктом, как SVN, у вас есть тот факт, что он НЕ новый, он определенно доказан с течением времени, и даже если есть проблемы, рекомендация не может быть поставлена ​​под сомнение слишком жестко, потому что она по-прежнему является ответом по умолчанию от большинства разработчиков. Это труднее атаковать советы, чтобы перейти на отраслевой стандарт, чем переключиться на что-то новое и нестандартное.

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