Я использую git для личных проектов и считаю его отличным. Он быстрый, гибкий, мощный и отлично подходит для удаленной разработки.
Но сейчас это работает, и, честно говоря, у нас проблемы.
По умолчанию git, похоже, не подходит для централизованной разработки в крупной (более 20 разработчиков) организации с разработчиками различных способностей и уровней сложности git - особенно по сравнению с другими системами контроля версий, такими как Perforce или Subversion, которые нацелены на такую среду. (Да, я знаю, Линус никогда не предназначал этого для этого.)
Но - по политическим причинам - мы застряли с git, даже если он отстой из-за того, что мы пытаемся с ним делать.
Вот что мы видим:
- Инструменты графического интерфейса незрелые
- Используя инструменты командной строки, очень легко испортить слияние и стереть чужие изменения.
- Он не предлагает разрешений на репозиторий для каждого пользователя, помимо глобальных прав только для чтения или чтения-записи.
- Если у вас есть разрешение на ЛЮБУЮ часть репозитория, вы можете сделать то же самое для КАЖДОЙ части репозитория, поэтому вы не можете сделать что-то вроде создания ветки отслеживания малых групп на центральном сервере, что другие люди не могут возиться с.
- Трудно поощрять рабочие процессы, кроме «все идет» или «доброжелательного диктатора», не говоря уже о принуждении
- Неясно, лучше ли использовать один большой репозиторий (который позволяет всем возиться со всем) или множество репозиториев для каждого компонента (что создает головную боль при попытке синхронизировать версии).
- При наличии нескольких репозиториев также непонятно, как реплицировать все источники, которые есть у кого-то еще, путем извлечения из центрального репозитория, или сделать что-то вроде получения всего по состоянию на 4:30 вчера днем.
Однако я слышал, что люди успешно используют git в крупных организациях, занимающихся разработкой.
Если вы находитесь в такой ситуации - или если у вас обычно есть инструменты, советы и рекомендации, которые помогут упростить и повысить продуктивность использования git в большой организации, где некоторые люди не являются поклонниками командной строки, - я хотел бы услышать, что у вас есть предлагать.
Кстати, я уже задавал версию этого вопроса в LinkedIn и не получил реальных ответов, но много "черт возьми, я бы тоже хотел это знать!"
ОБНОВЛЕНИЕ: позвольте мне уточнить ...
Там, где я работаю, мы не можем использовать НИЧЕГО, кроме git . Это не вариант. Мы застряли в этом. Мы не можем использовать mercurial, svn, bitkeeper, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, bazaar, Darcs, monotone, Perforce, Fossil, AccuRev, CVS или даже старый добрый проектор Apple, который я использовал в 1987 году. Итак, пока вы можете обсудить другие варианты, вы не получите награду, если не обсудите git.
Кроме того, мне нужны практические советы по использованию git на предприятии . Я поставил целый список проблем, с которыми мы сталкиваемся, в начале этого вопроса. Опять же, люди могут обсуждать теорию, но если вы хотите получить вознаграждение, дайте мне решения.
источник
a process
... (ненавижу это слово)Ответы:
Вопреки распространенному мнению, я считаю, что использование DVCS - идеальный выбор в корпоративной среде, потому что он обеспечивает очень гибкие рабочие процессы. Сначала я расскажу об использовании DVCS против CVCS, передовых методах, а затем, в частности, о git.
DVCS против CVCS в контексте предприятия:
Я не буду здесь говорить об общих плюсах и минусах, а сосредоточусь на вашем контексте. Распространено мнение, что использование DVCS требует более дисциплинированной команды, чем использование централизованной системы. Это связано с тем, что централизованная система предоставляет вам простой способ обеспечить соблюдение рабочего процесса, а использование децентрализованной системы требует большего взаимодействия и дисциплины, чтобы придерживаться установленных соглашений. Хотя может показаться, что это приводит к накладным расходам, я вижу выгоду в усилении взаимодействия, необходимом для того, чтобы сделать этот процесс хорошим. Вашей команде необходимо будет сообщить о коде, изменениях и статусе проекта в целом.
Еще одно измерение в контексте дисциплины - поощрение ветвления и экспериментов. Вот цитата из недавней записи в блики Мартина Фаулера об инструментах управления версиями , он нашел очень краткое описание этого явления.
DVCS обеспечивает гибкие рабочие процессы, поскольку они обеспечивают отслеживание набора изменений с помощью глобально уникальных идентификаторов в ориентированном ациклическом графе (DAG) вместо простых текстовых различий. Это позволяет им прозрачно отслеживать происхождение и историю набора изменений, что может быть весьма важным.
Workflows:
Ларри Остерман (разработчик Microsoft, работающий в команде Windows) написал в блоге отличный пост о рабочем процессе, который они используют в команде Windows. В частности, у них есть:
Как видите, если каждый из этих репозиториев работает отдельно, вы можете разделить разные команды, продвигающиеся с разной скоростью. Кроме того, возможность реализации гибкой системы контроля качества отличает DVCS от CVCS. Вы также можете решить свои проблемы с разрешениями на этом уровне. Только горстка людей должна иметь доступ к главному репо. Для каждого уровня иерархии создайте отдельный репозиторий с соответствующими политиками доступа. Действительно, такой подход может быть очень гибким на командном уровне. Вы должны предоставить каждой команде право решать, хотят ли они поделиться своим командным репозиторием между собой или хотят ли они более иерархического подхода, при котором только руководитель команды может принять участие в командном репо.
(Фотография украдена с сайта Джоэла Спольски hginit.com .)
На данный момент остается сказать одно: - хотя DVCS предоставляет большие возможности слияния, это никогда не заменяет использование непрерывной интеграции. Даже в этот момент у вас есть большая гибкость: CI для основного репозитория, CI для командных репозиториев, репозиториев вопросов и ответов и т. Д.
Git в контексте предприятия:
Как вы уже отметили, Git, возможно, не идеальное решение для корпоративного контекста. Повторяя некоторые из ваших опасений, я думаю, что наиболее примечательными из них являются:
Все еще несколько незрелая поддержка в Windows (пожалуйста, поправьте меня, если это недавно изменилось)Теперь в Windows есть клиент github windows , tortoisegit , SourceTree от atlassianЯ не хочу начинать здесь git vs. hg flamewar, вы уже сделали правильный шаг, переключившись на DVCS. Mercurial решает некоторые из вышеперечисленных вопросов, и поэтому я думаю, что он лучше подходит для корпоративного контекста:
Короче говоря, при использовании DVCS на предприятии я думаю, что важно выбрать инструмент, который вызывает наименьшее трение. Чтобы переход был успешным, особенно важно учитывать различия в навыках разработчиков (в отношении VCS).
Уменьшение трения:
Хорошо, поскольку вы, кажется, действительно застряли в ситуации, ИМХО осталось два варианта. Нет инструмента, чтобы упростить git; мерзавец является сложным. Либо вы противостоите этому, либо обходите git: -
Честно говоря, я думаю, что у вас действительно проблема с людьми, а не с инструментами. Что можно сделать, чтобы исправить эту ситуацию?
источник
Я инженер SCM в достаточно крупной организации разработки, и мы перешли на git из svn за последний год или около того. Мы используем его централизованно.
Мы используем gitosis для размещения репозиториев. Мы разбили наши монолитные репозитории svn на множество более мелких репозиториев git, так как модуль ветвления git в основном является репозиторием. (Есть способы обойти это, но они неудобны.) Если вам нужны виды управления доступом для каждой ветки, gitolite может быть лучшим подходом. Есть также версия GitHub с внутренним брандмауэром, если вы хотите потратить деньги. Для наших целей подойдет gitosis, потому что у нас есть довольно открытые разрешения для наших репозиториев. (У нас есть группы людей, которые имеют доступ на запись к группам репозиториев, и каждый имеет доступ на чтение ко всем репозиториям.) Мы используем gitweb для веб-интерфейса.
Что касается некоторых из ваших конкретных проблем:
Мы перешли на git, потому что у нас много удаленных разработчиков и у нас было много проблем с Subversion. Мы все еще экспериментируем с рабочими процессами, но на данный момент мы в основном используем его так же, как мы использовали Subversion. Еще нам понравилось то, что он открыл другие возможные рабочие процессы, такие как использование промежуточных репозиториев для проверки кода и обмена кодом между небольшими группами. Также многие люди начинают отслеживать свои личные сценарии и так далее, потому что создать репозиторий очень просто.
источник
На самом деле Линус утверждает, что централизованные системы просто не могут работать.
И что не так с рабочим процессом диктаторов и лейтенантов?
Помните, что git - это распределенная система; не пытайтесь использовать его как центральный.
(Обновлено)
Большинство ваших проблем исчезнут, если вы не попытаетесь использовать git, как если бы это был «svn на стероидах» (потому что это не так).
Вместо того, чтобы использовать чистый репозиторий в качестве центрального сервера, на который каждый может нажать (и, возможно, облажаться), настройте несколько менеджеров интеграции, которые обрабатывают слияния, чтобы только они могли нажимать на чистый репозиторий.
Обычно эти люди должны быть руководителями группы: каждый лидер объединяет работу своей команды и помещает ее в благословенное хранилище.
Еще лучше, если кто-то другой (например, диктатор) оттащит от руководителей команд и внесет их изменения в благословенный репозиторий.
Если у интеграторов нет времени проверять код, это нормально, но вам все равно нужны люди, которые интегрируют слияния от всех.
Выполнение git pulls не занимает много времени.
git действительно заменяет человеческое время и внимание; именно поэтому он был написан в первую очередь.
Инструменты графического интерфейса довольно хорошо справляются с базовыми вещами.
Расширенные операции требуют мышления программиста / ботаника (например, мне комфортно работать из командной строки). Чтобы понять концепцию, нужно время, но это не так сложно.
Это не будет проблемой, если у вас не будет много некомпетентных разработчиков с полным правом записи в «центральный репозиторий».
Но если вы настроите свой рабочий процесс так, что только несколько человек (интеграторов) будут писать в «благословенный» репозиторий, это не будет проблемой.
Git не позволяет легко испортить слияния.
Когда возникают конфликты слияния, git четко помечает конфликтующие строки, чтобы вы знали, какие изменения принадлежат вам, а какие нет.
Также легко стереть чужой код с помощью svn или любого другого (не распределенного) инструмента. На самом деле с этими другими инструментами намного проще, потому что вы склонны «сидеть на изменениях» в течение длительного времени, и в какой-то момент слияние может стать ужасно трудным.
А поскольку эти инструменты не знают, как объединять, вам всегда приходится объединять вещи вручную. Например, как только кто-то фиксирует файл, который вы редактируете локально, он будет помечен как конфликт, который необходимо разрешить вручную; Теперь , что является поддержание кошмар.
С git большую часть времени не будет конфликтов слияния, потому что git действительно может слиться. В случае возникновения конфликта git четко пометит строки для вас, чтобы вы точно знали , какие изменения принадлежат вам, а какие - от других людей.
Если кто-то уничтожает изменения других людей при разрешении конфликта слияния, это не будет ошибкой: либо потому, что это было необходимо для разрешения конфликта, либо потому, что они не знают, что делают.
Эти проблемы исчезнут, когда вы перестанете пытаться использовать git, как если бы это была централизованная система.
Призыв к суждению.
Какие у вас проекты?
Например: зависит ли версия xy проекта A именно от версии wz проекта B, так что каждый раз, когда вы проверяете xy проекта A, вам также необходимо проверять wz проекта B, иначе он не будет построен? В таком случае я бы поместил проект A и проект B в один и тот же репозиторий, поскольку они, очевидно, являются двумя частями одного проекта.
Лучшая практика здесь - использовать свой мозг
Я не уверен, что ты имеешь в виду.
источник
Я настоятельно рекомендую http://code.google.com/p/gerrit/ для работы на предприятии. Это дает вам контроль доступа и встроенный рабочий процесс на основе проверки. Он аутентифицируется в любой системе LDAP. Вы можете подключить его к Hudson с помощью http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin , что позволит вам создавать и тестировать изменения, пока они все еще находятся на рассмотрении; это действительно впечатляющая установка.
Если вы решили использовать gerrit, я рекомендую стараться вести довольно линейную историю, а не разветвленную историю, как некоторые из разработчиков открытого исходного кода. Геррит формулирует это как «разрешить только быструю перемотку вперед». Затем вы можете использовать ветвление и слияние, как вы привыкли, для выпусков и прочего.
источник
Я отвечаю на этот вопрос, основываясь на моем опыте работы менеджером по разработке в крупной телекоммуникационной компании, где мы внедрили Git в 2010 году.
Здесь у вас совсем другой набор проблем:
Workflows
Мы успешно внедрили режим центрального репозитория: то, что у нас есть в нашем корпоративном проекте (большой портал для 5 миллионов пользователей), де-факто является центральным репозиторием, который производит официальные сборки, а затем используется в процессе доставки (который, в нашем case, состоит из трех уровней тестирования и двух развертываний). Каждый разработчик управляет своим собственным репозиторием, и мы работаем для каждой отдельной функции.
Клиентские инструменты
Сейчас доступно несколько вариантов, сейчас это очень многолюдный район. Многие разработчики успешно используют IntelliJ Idea и Eclipse с подключаемым модулем Git без каких-либо других вещей. Также большинство разработчиков Linux без проблем используют клиент CLI git. Некоторые разработчики Mac успешно используют Tower Git . Обратите внимание, что ни один из этих клиентов не может помешать пользователю «испортить» центральный репозиторий: необходим механизм управления на стороне сервера.
Контроль доступа к серверу и интеграция
Если вы хотите, чтобы разработчики не «испортили» ваш репозиторий Git, вам действительно нужно выбрать решение, которое:
Готовых серверных решений, которые могут помочь в этом, не так много, я предлагаю вам проверить одно из них:
Надеюсь это поможет!
источник
Похоже, ваша проблема в том, что вы не определились с рабочим процессом и не создали его. Git достаточно гибок, чтобы использовать его, как svn или любую другую VCS, но он настолько мощный, что, если вы не установите правила, которым все должны следовать, вы просто запутаетесь. Я бы порекомендовал рабочий процесс диктатор-лейтенант, о котором упоминалось выше, но в сочетании с моделью ветвления, описанной Винсентом Дриссеном . Для получения дополнительной информации см. Эти скринкасты Дэвида Бока и Марка Деррикутта .
источник
Что касается инструментов , пользователи MacOS-X считают GitX (http://gitx.frim.nl/) очень простым и эффективным. Недостатком является то, что не поддерживаются клиентские хуки Git (те, что находятся под $ GIT_ROOT / .git / hooks).
В целом, я настоятельно рекомендую выбрать инструмент, поддерживающий детальный контроль доступа к: - веткам (чтобы отделить стабильные ветки выпуска со строгой безопасностью от тематических веток, требующих большей гибкости и гибкости); - принудительное использование идентификационных данных (автор / участник ). Это КЛЮЧ для SOX - ограничения команд git - контрольный след. Это КЛЮЧ для SOX
Вот те, которые я успешно использовал с этими функциями:
PS Не стоит недооценивать соответствие SOX и CMMI : во многих случаях у вас есть ограниченный выбор, который продиктован корпоративными политиками безопасности вашей компании.
Надеюсь это поможет.
Лука.
источник
Недавно мы перешли с svn на git. Поскольку git-daemon не работает с msysgit, мы выбрали подход центрального репозитория на сервере Linux с gitosis.
Чтобы исключить возможность облажаться с хозяином, мы просто вытащили его. Вместо этого мы готовим все выпуски путем слияния ветвей, выбранных для тестирования, и помечаем слияние. Если он проходит тесты, коммит помечается версией и запускается в производство.
Чтобы справиться с этим, у нас есть ротация диспетчера релизов. Менеджер релизов отвечает за проверку каждой ветки перед тем, как она будет готова к тестированию. Затем, когда владелец продукта решает, что пора объединить утвержденные ветки вместе для нового тестового выпуска, менеджер выпуска выполняет объединение.
У нас также есть ротационная роль службы поддержки 2-го уровня, и, по крайней мере, для нас рабочая нагрузка такова, что можно выполнять обе роли одновременно.
Преимущество отсутствия мастера в том, что невозможно добавить какой-либо код в проект, не пройдя через диспетчер релизов, поэтому мы непосредственно обнаружили, сколько кода было незаметно добавлено в проект раньше.
Процесс проверки начинается с того, что владелец ветки отправляет разницу на доску обзора и помещает на доске зеленую наклейку с названием ветки (у нас есть рабочий процесс на основе Канбана) в разделе «для проверки» или, если это часть завершенного пользователя. рассказ, переместите всю карточку истории в «для просмотра» и поместите на ней пост. Менеджер релизов - это тот, кто перемещает карточки и помещает их в «готовые к тестированию», а затем владелец продукта может выбрать, какие из них включить в следующий тестовый выпуск.
При выполнении слияния менеджер выпуска также следит за тем, чтобы у коммита слияния было разумное сообщение о фиксации, которое может быть использовано в журнале изменений для владельца продукта.
Когда выпуск запущен в производство, тег используется как новая основа для веток, и все существующие ветки объединяются с ним. Таким образом, у всех ветвей есть общий родитель, что упрощает обработку слияний.
источник
Я также добавлю сообщение "вы подумали".
Одна из замечательных особенностей Bazaar - его гибкость. В этом он превосходит все остальные распределенные системы. Вы можете управлять Bazaar в централизованном режиме, в распределенном режиме или получить это: оба (то есть разработчики могут выбирать, какая модель им удобна или какая лучше всего подходит для их рабочей группы). Вы также можете отключить централизованный репозиторий, пока находитесь в дороге, и снова подключить его, когда вернетесь.
Вдобавок к этому отличная документация и кое-что, что порадует ваше предприятие: доступная коммерческая поддержка.
источник
источник
Что касается пунктов 3 и 4 (разрешения для каждого пользователя, раздела, ветки), обратите внимание на gitolite ( описано в книге Pro Git: http://progit.org/book/ch4-8.html ).
Политика или нет, Git - такой же хороший выбор DCVS, как и любой другой. Как и любой другой мощный инструмент, стоит потратить немного времени на то, чтобы понять, как этот инструмент устроен для работы, и с этой целью я настоятельно рекомендую книгу Pro Git. Пару часов, проведенных с ним, в конечном итоге избавят от многих разочарований.
источник
Графический интерфейс: на данный момент TortoiseGit v1.7.6 подходит для большинства повседневных операций. Log, Commit, Push, Pull, Fetch, Diff, Merge, Branch, Cherry-pick, Rebase, Tag, Export, Stash, Add submodule, и т.д ... Также изначально поддерживает x64
источник
Чтобы эффективно использовать git в команде разработчиков с большим количеством разработчиков, требуется система CI, которая непрерывно строит и тестирует. Jenkins предоставляет такой автомобиль, и я очень рекомендую его. Элемент интеграции должен быть выполнен несмотря ни на что, и делать это раньше и чаще намного дешевле.
источник
Больше подходит для совместной разработки, чем гитозис или гитолит, но с открытым исходным кодом Gitorious . Это приложение Ruby on Rails, которое управляет репозиториями и объединяет их. Это должно решить многие ваши проблемы.
источник
Git позволяет создавать частные ветки. Это побуждает разработчиков часто совершать коммиты, чтобы разбить модификации на небольшие коммиты. Когда разработчик готов опубликовать свои изменения, он отправляет их на центральный сервер. При необходимости он может использовать сценарии предварительной фиксации для проверки своего кода.
источник
NXP управляет Git и Subversion с помощью одной общей платформы (в масштабе предприятия), интегрируя разработку мобильных приложений под Android с традиционными проектами программного обеспечения: http://www.youtube.com/watch?v=QX5wn0igv7Q
источник