Git -Based Source Control в Enterprise: предлагаемые инструменты и практика?

Ответ 1

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

DVCS против CVCS в контексте предприятия:

Я не буду говорить об общих плюсах и минусах здесь, а скорее сосредоточусь на вашем контексте. Это общая концепция, что использование DVCS требует более дисциплинированной команды, чем использование централизованной системы. Это связано с тем, что централизованная система предоставляет вам простой способ обеспечить соблюдение вашего рабочего процесса, использование децентрализованной системы требует большей коммуникации и дисциплины, чтобы придерживаться установленных конвенций. Хотя это может показаться, что оно вызывает накладные расходы, я вижу преимущество в увеличении связи, необходимого для того, чтобы сделать его хорошим процессом. Ваша команда должна будет сообщать о коде, об изменениях и статусе проекта в целом.

Другим аспектом в контексте дисциплины является поощрение ветвления и экспериментов. Здесь цитата из недавно появившейся записи бликки Мартина Фаулера в средствах управления версиями, он нашел очень кратким описание этого явления.

DVCS поощряет быстрое ветвление для экспериментирование. Вы можете делать ветки в Subversion, но тот факт, что они видны всем, препятствует людям от открытия ветки для экспериментальная работа. Аналогично, DVCS поощряет проверку работы: совершая неполные изменения, может даже не скомпилировать или пройти тесты, чтобы ваш локальный репозиторий. Опять вы могли сделайте это в филиале разработчика в Subversion, но тот факт, что такие ветки находятся в общем пространстве люди менее склонны это делать.

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

Workflows:

Ларри Остерман (разработчик Microsoft, работающий над командой Windows) имеет отличный пост в блоге о рабочем процессе, который они используют в команде Windows. Наиболее заметно:

• Чистый, высококачественный код только магистрали (master repo)
• Все разработки происходят в ветвях функций
• Группы функций имеют командные репозитории
• Они регулярно объединяют последние изменения сундуков в свою ветку функций (Forward Integrate)
• Полные функции должны проходить через несколько качественных ворот, например. обзор, покрытие тестов, Q & A (репозиции самостоятельно)
• Если функция завершена и имеет приемлемое качество, она объединяется в туловище (Обратный интегратор)

Как вы можете видеть, каждый из этих репозиториев живет самостоятельно, вы можете разделить разные команды, продвигающиеся в разных темпах. Также возможность внедрения гибкой системы затворов качества отличает DVCS от CVCS. Вы также можете решить свои проблемы с разрешениями на этом уровне. Только горстка людей должна иметь доступ к мастер-репо. Для каждого уровня иерархии есть отдельное репо с соответствующими политиками доступа. Действительно, этот подход может быть очень гибким на уровне команды. Вы должны оставить это в каждой команде, чтобы решить, хотят ли они поделиться своим репо между собой или если они хотят использовать более иерархичный подход, когда только команда может взять на себя ответственность за репо.

(Изображение украдено у Джоэла Спольского hginit.com.)

На данный момент остается сказать одно: несмотря на то, что DVCS обеспечивает отличные возможности слияния, это никогда не заменяет использование непрерывной интеграции. Даже в этот момент у вас есть большая гибкость: CI для ретрансляции транков, CI для командных репозиториев, Q & РЕПО и т.д.

Git в контексте предприятия:

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

• Еще одна незрелая поддержка Windows (пожалуйста, поправьте меня, если это изменилось недавно) Теперь окна github windows client, tortoisegit, SourceTree from atlassian
• Отсутствие зрелых инструментов графического интерфейса, интеграция инструмента vdiff/merge для граждан первого класса
• Несогласованный интерфейс с очень низким уровнем абстракций поверх внутренней работы
• Очень крутая кривая обучения для пользователей svn
• Git является очень мощным и позволяет легко изменять историю, очень опасно, если вы не знаете, что делаете (и вы будете иногда даже, если считаете, что знаете)
• Нет доступных коммерческих опций поддержки.

Я не хочу запускать git vs. hg flamewar здесь, вы уже сделали правильный шаг, переключившись на DVCS. Mercurial адресует некоторые из вышеперечисленных пунктов, и я думаю, что он лучше подходит в контексте предприятия:

• Поддерживаются все plattform, которые запускают python.
• Отличные инструменты графического интерфейса для всех основных платформ (win/linux/OS X), интеграция с интеграцией первого класса /vdiff
• Очень последовательный интерфейс, простой переход для пользователей svn
• Может делать большинство вещей, которые git может делать тоже, но обеспечивает более чистую абстракцию. Опасные операции всегда явны. Расширенные функции предоставляются через расширения, которые должны быть явно включены.
• Коммерческая поддержка доступна от selenic.

Короче говоря, при использовании DVCS на предприятии я считаю важным выбрать инструмент, который вводит наименьшее трение. Чтобы переход был успешным, особенно важно учитывать различное умение разработчиков (в отношении VCS).

Сокращение трения:

Хорошо, так как вы, кажется, действительно застряли в ситуации, осталось два варианта IMHO.  Нет никакого инструмента, чтобы сделать git менее сложным; git является сложным. Либо вы сталкиваетесь с этим, либо работаете вокруг git: -

• Получите git вводный курс для всей команды. Это должно включать только основы и некоторые упражнения (важно!).
• Преобразуйте мастер-репо в svn и дайте "молодым звездам" git -svn. Это дает большинству разработчиков простой в использовании интерфейс и может компенсировать недостающую дисциплину в вашей команде, в то время как молодые звезды могут продолжать использовать git для своих собственных репозиториев.

Честно говоря, я думаю, что у вас действительно есть проблема людей, а не проблема с инструментом. Что можно сделать, чтобы улучшить эту ситуацию?

• Вы должны четко указать, что, по вашему мнению, ваш текущий процесс будет содержать поддерживаемую базу кода.
• Вложите некоторое время в непрерывную интеграцию. Как я изложил выше, независимо от того, какой тип VCS вы используете, никогда не будет замены для CI. Вы заявили, что есть люди, которые подталкивают дерьмо в мастер-репо: попросите их исправить свое дерьмо, пока красное предупреждение отключится и обвинит их в нарушении строя (или не соответствует метрике качества или что-то еще).

Ответ 2

Я инженер SCM для достаточно большой организации развития, и мы перешли к git из svn за последний год или около того. Мы используем его централизованно.

Мы используем gitosis для размещения репозиториев. Мы разрушили наши монолитные хранилища svn во многих небольших хранилищах git, поскольку блок разветвления git - это в основном репозиторий. (Есть способы обойти это, но они неудобны.) Если вы хотите, чтобы элементы управления доступом на ветки, gitolite может быть лучше подход. Там также есть версия GitHub внутри брандмауэра, если вы хотите потратить деньги. Для наших целей gitosis прекрасен, потому что у нас есть довольно открытые разрешения для наших репозиториев. (У нас есть группы людей, у которых есть доступ на запись к группам репозиториев, и у всех есть доступ на чтение ко всем хранилищам.) Мы используем gitweb для веб-интерфейса.

Что касается некоторых ваших конкретных проблем:

• merges: вы можете использовать инструмент визуального слияния по вашему выбору; в разных местах есть инструкции по настройке. Тот факт, что вы можете слить и проверить его достоверность полностью на своем локальном репо, является, на мой взгляд, основным плюсом для git; вы можете проверить слияние, прежде чем нажимать что-нибудь.
• GUI: У нас есть несколько человек, использующих TortoiseGit, но я не рекомендую это; он, по-видимому, взаимодействует нечетным образом с командной строкой. Я должен согласиться, что это область, которая нуждается в улучшении. (Тем не менее, я не являюсь поклонником GUI для управления версиями в целом.)
• ветки отслеживания небольших групп: если вы используете что-то, что обеспечивает более тонкие списки ACL, такие как gitolite, достаточно просто сделать это, но вы также можете создать общую ветвь, подключив локальные репозитории различных разработчиков - репозиторий git может иметь несколько пультов.

Мы перешли на git, потому что у нас много удаленных разработчиков, и потому, что у нас было много проблем с Subversion. Мы все еще экспериментируем с рабочими процессами, но в настоящий момент мы в основном используем его так же, как мы использовали Subversion. Другое, что нам понравилось в этом, было то, что он открыл другие возможные рабочие процессы, такие как использование промежуточных репозиториев для проверки кода и совместного использования кода среди небольших групп. Это также побудило многих людей начать отслеживать их личные сценарии и т.д., Потому что так легко создать репозиторий.

Ответ 3

Да, я знаю, Линус никогда не думал об этом.

Собственно, Линус утверждает, что централизованные системы просто не могут работать.

И что случилось с рабочий процесс диктатора и лейтенанта?

Помните, что git - распределенная система; не пытайтесь использовать его как центральный.

(обновлено)

Большинство ваших проблем исчезнут, если вы не попытаетесь использовать git, как если бы это было "svn на стероидах" (потому что это не так).

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

Обычно эти люди должны быть лидерами команды: каждый лидер объединяет свою собственную работу в команде и отталкивает ее в благословенный репозиторий.

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

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

Если интеграторы не имеют времени на просмотр кода, это прекрасно, но вам все равно нужно иметь людей, которые объединяют слияния всех.

Выполнение git pulls не занимает столько времени.

git pull A
git pull B
git pull C

git заменяет человеческое время и внимание; почему он был написан в первую очередь.

• Инструменты графического интерфейса не являются зрелыми.

Инструменты gui могут справиться с основными вещами довольно хорошо.

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

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

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

Но, если вы настроите свой рабочий процесс так, чтобы только несколько человек (интеграторов) записывали в "благословенный" репозиторий, это не будет проблемой.

git не позволяет сгладить слияния.

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

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

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

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

Если кто-то уничтожает изменения других людей при разрешении конфликта слияния, это не будет ошибкой: это будет либо потому, что это необходимо для разрешения конфликта, либо потому, что они не знают, что делают.

• Он не предоставляет разрешения для репозитория для каждого пользователя за пределами глобальных прав на чтение или чтение-запись

• Если у вас есть разрешение на ЛЮБОЙ части репозитория, вы можете сделать то же самое для КАЖДОЙ части репозитория, поэтому вы не можете сделать что-то вроде создания ветки отслеживания небольших групп на центральном сервере что другие люди не могут возиться.

• Рабочие процессы, отличные от "ничего идут" или "доброжелательный диктатор", трудно поощрять, не говоря уже о соблюдении

Эти проблемы исчезнут, когда вы перестанете пытаться использовать git, как если бы это была централизованная система.

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

Судебный вызов.

Какие проекты у вас есть?

Например: действительно ли версия x.y проекта A зависит от точно такой версии w.z проекта B, что каждый раз, когда вы проверяете x.y проекта A, вам также нужно проверить w.z проекта B, иначе он не будет создан? Если это так, я бы поставил оба проекта A и проект B в один и тот же репозиторий, так как они, очевидно, две части одного проекта.

Лучшей практикой здесь является использовать ваш мозг

• С несколькими репозиториями также неясно, как реплицировать все источники, которые есть у кого-то еще, вытаскивая из центрального репозитория или делать что-то вроде получения всего с 4:30 вчера днем.

Я не уверен, что вы имеете в виду.

Ответ 4

Я настоятельно рекомендую http://code.google.com/p/gerrit/ для работы на предприятии. Он обеспечивает контроль доступа и встроенный рабочий процесс, основанный на обзоре. Он аутентифицируется против любой системы LDAP. Вы можете подключить его к Hudson с помощью http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin, позволяя вам создавать и тестировать изменения, пока они все еще находятся на рассмотрении; это действительно впечатляющая настройка.

Если вы решите использовать gerrit, я рекомендую сохранить довольно линейную историю, а не ветвящуюся историю, как некоторые из парней с открытым исходным кодом. Геррит формулирует это как "разрешить только быстрые изменения". Затем вы можете использовать ветвление и слияние в большей степени, чем вы привыкли, для выпусков и много чего.

Ответ 5

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

Здесь у вас совершенно другой набор проблем:

• рабочие процессы
• клиентские инструменты
• контроль доступа к серверу и интеграция

Workflows

Мы успешно приняли режим центрального репозитория: то, что мы имеем в нашем корпоративном проекте (большой портал для 5-миллионной базы пользователей), является де-факто центральным репозиторием, который производит официальные сборки, затем осуществляется через процесс доставки (который, в нашем случае состоит из трех уровней тестирования и двух развертываний). Каждый разработчик управляет своим собственным репо, и мы работаем с принципом "по отрасли".

Клиентские инструменты

Теперь доступно несколько вариантов, теперь это очень переполненная область. Многие разработчики успешно используют IntelliJ Idea и Eclipse с плагином Git, без каких-либо других вещей. Также большинство разработчиков Linux используют клиент CLI Git без каких-либо проблем. Некоторые разработчики Mac успешно используют Tower Git. Обратите внимание, что ни один из этих клиентов не может помешать пользователю "испортить" в центральном репозитории: необходим механизм управления на стороне сервера

Контроль доступа к серверу и интеграция

Если вы хотите, чтобы разработчики "перепутали" ваш репозиторий Git, вам нужно выбрать решение, которое:

• предоставляет удобный веб-админ-интерфейс для выполнения каждой операции.
• позволяет принудительно вводить идентификаторы пользователей (использование "голого" репозитория Git очень легко совершить в интересах кого-то другого)
• предоставляет вам надежную защиту (так, например, вы можете предотвратить FORCE-PUSH и установить некоторые ветки для чтения только для некоторых разработчиков/групп).
• интегрироваться с вашей корпоративной системой аутентификации (например, LDAP, Windows ActiveDirectory)
• предоставляет вам полный аудит (соответствие SOX иногда очень важно для крупных корпораций).

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

• Gitorious: он может обеспечить базовую безопасность уровня доступа, но ему не хватает мелкозернистого управления разрешениями из коробки, поэтому вы, вероятно, будете необходимо выполнить некоторую кодировку для обработки сценариев, таких как разрешения уровня ветки. В нем также отсутствует интеграция с существующими механизмами корпоративной аутентификации.
• GitHub Предприятие: недавно опубликованное GitHub, оно включает GitHub в вашем корпоративном. В нем отсутствует соответствие SOX и мелкозернистая безопасность.
• Gerrit: он может обеспечить защиту и интеграцию уровня доступа на уровне доступа к корпоративным системам аутентификации, но в нем отсутствует соответствие SOX и SSO. Также некоторые операции могут выполняться только через SSH через CLI
• GitEnterprise: он предоставляет разрешения на уровне ветки, соответствие SSO, SOX, полное администрирование через Интернет. Недавно он также был интегрирован с Gerrit, так что он также предоставляет вам полный экземпляр Gerrit.

Надеюсь, это поможет!

Ответ 6

В инструментах пользователи MacOS-X находят GitX (http://gitx.frim.nl/) очень простыми и эффективными. Недостатком является то, что не поддерживает Git клиентские крючки (те, которые находятся под $GIT_ROOT/.git/hooks).

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

Я успешно использовал эти функции:

• Обзор кода Gerrit (http://code.google.com/p/gerrit/)
• GitEnterprise (http://gitenterprise.com)
• CollabNet TeamForge (http://www.collab.net/gotgit) использует Gerrit 2.1.8 за кулисами

P.S. Не стоит недооценивать соответствие SOX и CMMI: во многих случаях существует ограниченный набор вариантов выбора, который вы продиктованы политиками предприятия в области безопасности.

Надеюсь, что это поможет.

Luca.

Ответ 7

Недавно мы переключились с svn на git. Поскольку git -daemon не работает с msysgit, мы решили использовать центральный репозиторий на сервере Linux с гитозом.

Чтобы исключить возможность испортить мастер, мы просто разделили его. Вместо этого мы готовим все выпуски, объединяя ветки, выбранные для тестирования, и отмечаем слияние. Если он проходит тесты, фиксация помечена версией и будет запущена.

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

У нас также есть вращающаяся роль справочной службы 2-го уровня и, по крайней мере, для нас рабочая нагрузка такова, что возможно одновременно иметь обе роли.

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

Процесс проверки начинается с того, что владелец ветки отправляет diff на обзорную панель и помещает зеленую надпись на доске с именем ветки (у нас есть рабочий процесс на основе Kanban) в разделе "для проверки" или если он является частью заполненную историю пользователя, переместите всю карточку истории в "для обзора" и поместите в нее постит. Менеджер перераспределения - это тот, кто перемещает карты и отправляет их в "готовую к тестированию", а затем владелец продукта может выбрать, какие из них будут включены в следующую тестовую версию.

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

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

Ответ 8

Похоже, ваша проблема в том, что вы не решили или не создали рабочий процесс. Git достаточно гибкий, чтобы использовать его как svn или любой другой VCS, но он настолько мощный, что, если вы не устанавливаете правила, которые должны соблюдать все, то вы просто получите беспорядок. Я бы рекомендовал рабочий процесс диктатора-лейтенанта, упомянутый выше, но в сочетании с моделью ветвления, описанной Vincent Driessen. Для получения дополнительной информации см. Эти скринкасты Дэвида Бока, а этот Марк Деррикутт.

Ответ 9

Я добавлю также сообщение "Вы тоже считали".

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

Кроме того, отличная документация и что-то, что сделает ваше предприятие счастливым: доступна коммерческая поддержка.

Ответ 10

• Установите достойный веб-интерфейс, например Github FI
• Придерживайтесь относительно централизованной модели (изначально), чтобы люди были удобными.
• Запустите сборку непрерывной интеграции для каждой общей ветки.
• Поделитесь хорошим набором глобальных параметров конфигурации git.
• Интегрируйте git в свою оболочку с завершением bash и приглашением с текущей ветвью.
• Попробуйте IntelliJ git Интеграция как инструмент слияния.
• Убедитесь, что вы .gitignore, если это необходимо.

Ответ 11

Что касается пунктов 3 и 4 (для каждого пользователя, для каждого раздела, разрешений для каждой ветки), посмотрите gitolite (в книге Pro Git: http://progit.org/book/ch4-8.html).

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

Ответ 12

GUI: На данный момент TortoiseGit v1.7.6 должен быть хорошим для большинства ежедневных операций. Log, Commit, Push, Pull, Fetch, Diff, Merge, Branch, Cherry-pick, Rebase, Tag, Export, Stash, Добавить подмодуль и т.д. Поддерживает также x64 слишком

Ответ 13

Чтобы эффективно использовать git в команде разработчиков с большим количеством разработчиков, требуется система CI, которая строит и тестирует непрерывно. Дженкинс предоставляет такой автомобиль, и я очень рекомендую это. Компонент интеграции должен быть выполнен независимо от того, что и это намного дешевле, чем раньше и чаще.

Ответ 14

Более подходит для коллаборативного развития, чем гитоз или гитолит, но с открытым исходным кодом Gitorious. Это приложение Ruby on Rails, которое обрабатывает управление репозиториями и слияние. Он должен решить многие из ваших проблем.

Ответ 15

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

Ответ 16

NXP управляет Git и Subversion с одной общей платформой (в масштабах предприятия), интегрируя развитие мобильных телефонов Android с традиционными программными проектами: http://www.youtube.com/watch?v=QX5wn0igv7Q