Git-Source Control на предприятии: предлагаемые инструменты и практики?
Я использую git для личных проектов и думаю, что это здорово. Это быстрый, гибкий, мощный и отлично работает для удаленной разработки.
Но теперь он обязателен на работе, и, честно говоря, у нас проблемы.
Похоже, из коробки Git не подходит для централизованной разработки в крупной (более 20 разработчиков) организации с разработчиками различных способностей и уровней сложности git - особенно по сравнению с другими системами контроля версий, такими как Perforce или Subversion, которые направлены на такую среду. (Да, я знаю, Линус никогда не предназначал это для этого.)
Но - по политическим причинам - мы застряли с git, даже если он отстой от того, что мы пытаемся с ним сделать.
Вот некоторые вещи, которые мы видим:
- Инструменты GUI не являются зрелыми
- Используя инструменты командной строки, очень легко испортить слияние и уничтожить чужие изменения
- Он не предлагает разрешения для репозитория для каждого пользователя, кроме глобальных прав доступа только для чтения или чтения и записи.
- Если у вас есть разрешение на ЛЮБУЮ часть репозитория, вы можете сделать то же самое для КАЖДОЙ части репозитория, поэтому вы не можете сделать что-то вроде создания небольшой группы отслеживания на центральном сервере, чего не могут другие люди. возиться с.
- Трудно поощрять рабочие процессы, отличные от "все идет" или "доброжелательный диктатор", не говоря уже о применении
- Неясно, лучше ли использовать один большой репозиторий (который позволяет всем связываться со всем) или множество репозиториев для каждого компонента (которые создают головную боль при попытке синхронизировать версии).
- С несколькими репозиториями также неясно, как скопировать все источники, которые есть у кого-то другого, путем извлечения из центрального репозитория, или сделать что-то вроде получения всего по состоянию на 4:30 вчера днем.
Однако я слышал, что люди успешно используют git в крупных организациях разработчиков.
Если вы находитесь в такой ситуации - или если у вас обычно есть инструменты, советы и приемы, позволяющие упростить и повысить производительность использования git в большой организации, где некоторые люди не являются поклонниками командной строки, - я хотел бы услышать, что у вас есть предлагать.
Кстати, я уже задавал версию этого вопроса на LinkedIn, и не получил никаких реальных ответов, но много "черт возьми, я бы тоже хотел это знать!"
ОБНОВЛЕНИЕ: Позвольте мне уточнить...
Там, где я работаю, мы не можем использовать НИЧЕГО кроме git. Это не вариант. Мы застряли с этим. Мы не можем использовать mercurial, svn, bitkeeper, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, базар, Darcs, monotone, Perforce, Fossil, AccuRev, CVS или даже хороший добрый проектор Apple, который я использовал в 1987 году. Поэтому, пока вы можете обсуждать другие варианты, вы не получите награду, если не будете обсуждать git.
Также я ищу практические советы по использованию git на предприятии. Я поместил целый список проблем, которые у нас есть, в верхней части этого вопроса. Опять же, люди могут обсуждать теорию, но если вы хотите получить награду, дайте мне решения.
16 ответов
Вопреки общему мнению, я считаю, что использование DVCS является идеальным выбором в корпоративных условиях, поскольку оно обеспечивает очень гибкие рабочие процессы. Сначала я расскажу об использовании DVCS против CVCS, о лучших практиках, а затем о git в частности.
DVCS против CVCS в контексте предприятия:
Я не буду говорить об общих плюсах и минусах, а скорее остановлюсь на вашем контексте. Это распространенная концепция, что использование DVCS требует более дисциплинированной команды, чем использование централизованной системы. Это связано с тем, что централизованная система предоставляет вам простой способ обеспечить ваш рабочий процесс, а использование децентрализованной системы требует большей коммуникации и дисциплины, чтобы придерживаться установленных соглашений. Хотя может показаться, что это приводит к накладным расходам, я вижу выгоду в расширении коммуникаций, необходимых для того, чтобы сделать это хорошим процессом. Ваша команда должна будет сообщить о коде, об изменениях и о статусе проекта в целом.
Другое измерение в контексте дисциплины - поощрение ветвления и экспериментов. Вот цитата из недавней записи Мартина Фаулера по bliki об инструментах контроля версий, он нашел очень краткое описание этого явления.
DVCS поощряет быстрое ветвление для экспериментов. Вы можете создавать ветки в Subversion, но тот факт, что они видны всем, не позволяет людям открывать ветки для экспериментальной работы. Точно так же DVCS поощряет проверку работы: внесение неполных изменений, которые могут даже не скомпилировать или пройти тесты, в ваш локальный репозиторий. Опять же, вы можете сделать это в ветке разработчика в Subversion, но тот факт, что такие ветки находятся в общем пространстве, делает людей менее склонными к этому.
DVCS обеспечивает гибкие рабочие процессы, поскольку они обеспечивают отслеживание изменений через глобально уникальные идентификаторы в ориентированном ациклическом графе (DAG) вместо простых текстовых различий. Это позволяет им прозрачно отслеживать происхождение и историю изменений, что может быть довольно важным.
Workflows:
Ларри Остерман (разработчик Microsoft, работающий в команде Windows) имеет отличный пост в блоге о рабочем процессе, который они используют в команде Windows. В первую очередь они имеют:
- Чистый, качественный только код ствола (мастер репо)
- Все разработки происходят по тематическим веткам
- Особые команды имеют репозитории
- Они регулярно объединяют последние изменения соединительных линий в свою ветвь функций (Прямая интеграция)
- Полные функции должны пройти несколько качественных проверок, например, обзор, тестовое покрытие, вопросы и ответы (репо самостоятельно)
- Если функция завершена и имеет приемлемое качество, она объединяется в транк (обратная интеграция)
Как вы можете видеть, если каждый из этих репозиториев живет самостоятельно, вы можете разделить различные команды, продвигающиеся с разной скоростью. Также возможность реализации гибкой системы контроля качества отличает DVCS от CVCS. Вы также можете решить свои проблемы с разрешениями на этом уровне. Только горстка людей должна иметь доступ к главному репо. Для каждого уровня иерархии есть отдельное хранилище с соответствующими политиками доступа. Действительно, этот подход может быть очень гибким на командном уровне. Вы должны оставить за каждой командой право решать, хотят ли они разделить репо своей команды между собой или если они хотят более иерархического подхода, когда только командный лидер может взять на себя командное репо.
(Картинка украдена с http://hginit.com/ Джоэла Спольски.)
Однако на данный момент остается сказать следующее:- хотя DVCS предоставляет отличные возможности слияния, это никогда не заменяет использование непрерывной интеграции. Даже в этот момент у вас есть большая гибкость: CI для репо транка, CI для репозитория команды, репо Q&A и т. Д.
Git в контексте предприятия:
Git, возможно, не идеальное решение для корпоративного контекста, как вы уже указали. Повторяя некоторые из ваших проблем, я думаю, что наиболее заметными из них являются:
-
Все еще несколько незрелая поддержка в Windows (пожалуйста, исправьте меня, если это недавно изменилось).Теперь в Windows есть github клиент Windows, tortoisegit, SourceTree из atlassian. - Отсутствие зрелых инструментов с графическим интерфейсом, отсутствие интеграции с vdiff / merge инструментами первого класса.
- Несовместимый интерфейс с очень низким уровнем абстракций поверх его внутренней работы
- Очень крутая кривая обучения для пользователей SVN
- Git очень мощен и позволяет легко изменять историю, очень опасно, если вы не знаете, что делаете (а иногда и так, даже если вы думали, что знаете)
- Коммерческая поддержка недоступна
Я не хочу начинать git и hg flamewar, вы уже сделали правильный шаг, переключившись на DVCS. Mercurial рассматривает некоторые из вышеперечисленных пунктов, и я думаю, что он лучше подходит для корпоративного контекста:
- Все платформы, которые запускают Python, поддерживаются
- Великолепные инструменты GUI на всех основных платформах (win/linux/OS X), первоклассная интеграция инструментов слияния /vdiff
- Очень согласованный интерфейс, простой переход для пользователей SVN
- Может делать большинство вещей, которые может делать git, но обеспечивает более чистую абстракцию. Опасные операции всегда являются явными. Расширенные функции предоставляются через расширения, которые должны быть явно включены.
- Коммерческая поддержка доступна от Selenic.
Короче говоря, при использовании DVCS на предприятии я думаю, что важно выбрать инструмент, который вводит наименьшее трение. Чтобы переход был успешным, особенно важно учитывать разные навыки между разработчиками (в отношении VCS).
Уменьшение трения:
Хорошо, так как вы, похоже, действительно застряли в этой ситуации, у ИМХО осталось два варианта. Там нет инструмента, чтобы сделать Git менее сложным; мерзавец сложен. Либо вы сталкиваетесь с этим, либо работаете над git:-
- Получите вводный курс для всей команды. Это должно включать только основы и некоторые упражнения (важно!).
- Конвертируйте мастер репо в svn и дайте "молодым звездам" git-svn. Это дает большинству разработчиков простой в использовании интерфейс и может компенсировать отсутствие дисциплины в вашей команде, в то время как молодые звезды могут продолжать использовать git для своих собственных репозиториев.
Честно говоря, я думаю, что у вас действительно есть проблема с людьми, а не проблема с инструментом. Что можно сделать, чтобы улучшить ситуацию?
- Вы должны четко дать понять, что, по вашему мнению, ваш текущий процесс закончится поддержкой кода.
- Инвестируйте некоторое время в непрерывную интеграцию. Как я уже говорил выше, независимо от того, какой тип VCS вы используете, CI никогда не заменится. Вы заявили, что есть люди, которые помещают дерьмо в мастер-репо: пусть они исправят свое дерьмо, пока гаснет красный сигнал тревоги, и обвиняет их в том, что они нарушили сборку (или не соответствуют метрике качества или что-то в этом роде).
Я инженер SCM в достаточно крупной организации по разработке, и мы перешли на git из svn за последний год или около того. Мы используем его централизованно.
Мы используем gitosis для размещения репозиториев. Мы разбили наши монолитные svn-репозитории на множество меньших git-репозиториев, поскольку ветвь git является в основном репозиторием. (Есть способы обойти это, но они неуклюжи.) Если вам нужны виды контроля доступа для каждой ветви, лучше использовать gitolite. Есть также версия GitHub с брандмауэром, если вы хотите потратить деньги. Для наших целей хорошо подходит gitosis, потому что у нас довольно открытые разрешения на наши репозитории. (У нас есть группы людей, которые имеют доступ на запись к группам репозиториев, и каждый имеет доступ на чтение ко всем репозиториям.) Мы используем gitweb для веб-интерфейса.
Что касается некоторых ваших конкретных проблем:
- слияния: вы можете использовать визуальный инструмент слияния по вашему выбору; в разных местах есть инструкции по настройке. Тот факт, что вы можете выполнить слияние и полностью проверить его действительность в локальном репо, на мой взгляд, является большим плюсом для git; Вы можете проверить слияние, прежде чем что-то нажимать.
- GUI: у нас есть несколько человек, использующих TortoiseGit, но я не очень рекомендую это; Кажется, что это странным образом взаимодействует с командной строкой. Я должен согласиться, что это область, которая нуждается в улучшении. (Тем не менее, я не фанат GUI для контроля версий в целом.)
- ветви отслеживания в небольших группах: если вы используете что-то, что обеспечивает более детализированные списки ACL, такие как gitolite, это достаточно просто сделать, но вы также можете создать общую ветку, подключив локальные репозитории различных разработчиков - репозиторий git может иметь несколько удаленных устройств.
Мы перешли на git, потому что у нас много удаленных разработчиков, и потому что у нас было много проблем с Subversion. Мы все еще экспериментируем с рабочими процессами, но на данный момент мы в основном используем его так же, как мы привыкли использовать Subversion. Еще одна вещь, которая нам понравилась, заключалась в том, что она открывала другие возможные рабочие процессы, такие как использование промежуточных хранилищ для проверки кода и обмена кодом между небольшими группами. Кроме того, многие люди начинают отслеживать свои личные сценарии и т. Д., Поскольку создать репозиторий очень просто.
Да, я знаю, Линус никогда не предназначал это для этого.
На самом деле, Линус утверждает, что централизованные системы просто не могут работать.
И что не так с рабочим процессом диктатора и лейтенантов?
Помните, git - это распределенная система; не пытайтесь использовать его как центральный.
(Обновлено)
Большинство ваших проблем исчезнет, если вы не попытаетесь использовать git, как если бы он был "svn on стероидами" (потому что это не так).
Вместо того, чтобы использовать пустой репозиторий в качестве центрального сервера, на который каждый может перейти (и, возможно, испортить), настройте несколько менеджеров интеграции, которые обрабатывают слияния, так что только они могут передавать в пустой репозиторий.
Обычно эти люди должны быть руководителями команды: каждый руководитель объединяет работу своей команды и переносит ее в благословенное хранилище.
Более того, кто-то еще (то есть диктатор) извлекает из лидеров команд и интегрирует их изменения в благословенное хранилище.
В этом рабочем процессе нет ничего плохого, но мы перегружены стартапом и нуждаемся в наших инструментах, чтобы заменить человеческое время и внимание; никто не имеет пропускной способности, чтобы даже делать обзоры кода, не говоря уже о доброжелательном диктаторе
Если у интеграторов нет времени на просмотр кода, это нормально, но вам все равно нужны люди, которые объединяют слияния от всех.
Выполнение мерзавцев не занимает много времени.
git pull A
git pull B
git pull C
мерзавец заменяет человеческое время и внимание; вот почему это было написано в первую очередь.
- Инструменты GUI не являются зрелыми
Инструменты графического интерфейса могут справиться с основными вещами довольно хорошо.
Расширенные операции требуют кодер / всезнайка (например, мне удобно работать из командной строки). Понять понятия нужно немного времени, но это не так сложно.
- Используя инструменты командной строки, очень легко испортить слияние и уничтожить чужие изменения
Это не будет проблемой, если у вас нет многих некомпетентных разработчиков с полным доступом для записи в "центральный репозиторий".
Но если вы настроите свой рабочий процесс так, чтобы только несколько человек (интеграторы) писали в "благословенный" репозиторий, это не будет проблемой.
Git не позволяет легко испортить слияния.
Когда возникают конфликты слияния, git четко помечает конфликтующие строки, чтобы вы знали, какие изменения ваши, а какие нет.
Также легко стереть чужой код с помощью svn или любого другого (не распределенного) инструмента. На самом деле, с этими другими инструментами это намного проще, потому что вы склонны долго "сидеть на изменениях", и в какой-то момент слияния могут стать ужасно трудными.
И поскольку эти инструменты не знают, как объединять, вам всегда приходится объединять вещи вручную. Например, как только кто-то сделает коммит для файла, который вы редактируете локально, он будет помечен как конфликт, который необходимо разрешить вручную; теперь это кошмар обслуживания.
С git большую часть времени не будет никаких конфликтов слияния, потому что git может фактически слиться. В случае возникновения конфликта git четко пометит для вас строки, чтобы вы точно знали , какие изменения ваши, а какие изменения от других людей.
Если кто-то стирает изменения других людей при разрешении конфликта слиянием, это не будет ошибкой: это будет либо потому, что это было необходимо для разрешения конфликта, либо потому, что они не знают, что делают.
Он не предлагает разрешения для репозитория для каждого пользователя, кроме глобальных прав доступа только для чтения или чтения и записи.
Если у вас есть разрешение на ЛЮБУЮ часть репозитория, вы можете сделать то же самое для КАЖДОЙ части репозитория, поэтому вы не можете сделать что-то вроде создания небольшой группы отслеживания на центральном сервере, чего не могут другие люди. возиться с.
- Трудно поощрять рабочие процессы, отличные от "все идет" или "доброжелательный диктатор", не говоря уже о применении
Эти проблемы исчезнут, когда вы перестанете пытаться использовать git, как если бы это была централизованная система.
- Неясно, лучше ли использовать один большой репозиторий (который позволяет всем связываться со всем) или множество репозиториев для каждого компонента (которые создают головную боль при попытке синхронизировать версии).
Судный звонок.
Какие проекты у вас есть?
Например: зависит ли версия xy проекта A от конкретной версии wz проекта B, так что каждый раз, когда вы проверяете xy проекта A, вам также необходимо извлекать wz проекта B, иначе он не будет построен? Если это так, я бы поместил и проект A, и проект B в один и тот же репозиторий, поскольку они, очевидно, являются двумя частями одного проекта.
Лучшая практика здесь - использовать свой мозг
- С несколькими репозиториями также неясно, как скопировать все источники, которые есть у кого-то другого, путем извлечения из центрального репозитория, или сделать что-то вроде получения всего по состоянию на 4:30 вчера днем.
Я не уверен, что вы имеете в виду.
Я настоятельно рекомендую http://code.google.com/p/gerrit/ для корпоративной работы. Это дает вам контроль доступа плюс встроенный рабочий процесс на основе обзора. Он аутентифицируется против любой системы LDAP. Вы можете подключить его к Hudson с помощью http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin, что позволит вам создавать и тестировать изменения, пока они еще находятся на рассмотрении; Это действительно впечатляющая установка.
Если вы решите использовать gerrit, я рекомендую стараться вести довольно линейную историю, а не ветвистую историю, как некоторые парни с открытым исходным кодом. Геррит формулирует это как "разрешить только быстрые изменения вперед". Тогда вы можете использовать ветвление и слияние в более привычном для выпусков и тому подобное виде.
Я отвечаю на этот вопрос, основываясь на моем опыте работы в качестве менеджера разработчиков в большой телекоммуникационной компании, где мы приняли Git в 2010 году.
У вас здесь совсем другой набор проблем:
- Рабочие процессы
- клиентские инструменты
- контроль доступа к серверу и интеграция
Workflows
Мы успешно внедрили режим центрального репозитория: то, что мы имеем в нашем корпоративном проекте (большой портал на 5 миллионов пользователей), является де-факто центральным репозиторием, который производит официальные сборки, а затем принимаются через процесс доставки (который в нашем случай, состоит из трех уровней тестирования и двух развертываний). Каждый разработчик управляет своим собственным репо, а мы работаем по принципу ветвления на функцию.
Инструменты клиента
Сейчас доступно несколько вариантов, сейчас это очень людное место. Многие разработчики успешно используют IntelliJ Idea и Eclipse с плагином Git, без каких-либо других вещей. Также большинство разработчиков Linux без проблем используют git-клиент CLI. Некоторые разработчики Mac успешно используют Tower Git. Обратите внимание, что ни один из этих клиентов не может помешать пользователю "запутаться" с центральным хранилищем: необходим механизм управления на стороне сервера
Контроль доступа к серверу и интеграция
Если вы хотите, чтобы разработчики не "запутали" ваш Git-репозиторий, вам действительно нужно выбрать решение, которое:
- предоставляет достойный интерфейс веб-администратора для выполнения каждой операции
- позволяет применять идентификационные данные пользователей (использование "чистого" Git-репозитория чрезвычайно легко сделать в интересах кого-то другого)
- обеспечивает детальную защиту (например, вы можете запретить FORCE-PUSH и настроить некоторые ветки на чтение только для некоторых разработчиков / групп)
- интегрироваться с вашей корпоративной системой аутентификации (например, LDAP, Windows ActiveDirectory)
- обеспечивает полный аудит (соответствие SOX иногда очень важно для крупных корпораций)
Существует не так много готовых к использованию серверных решений, которые могут помочь в этом, я предлагаю вам проверить одно из следующих:
- Gitorious: он может обеспечить базовый уровень безопасности доступа, но в нем нет точного управления разрешениями из коробки, поэтому вам, вероятно, придется выполнить некоторое кодирование для обработки сценариев, таких как разрешения на уровне ветви. Также отсутствует интеграция с существующими механизмами корпоративной аутентификации.
- GitHub Enterprise: недавно опубликованный GitHub, в вашей компании есть GitHub. Не хватает SOX-совместимости и мелкозернистой безопасности.
- Gerrit: он может обеспечить высокую степень защиты уровня доступа и интеграцию с корпоративными системами аутентификации, но ему не хватает соответствия SOX и SSO. Также некоторые операции могут выполняться только через SSH через CLI.
- GitEnterprise: он предоставляет разрешения на уровне филиала, SSO, соответствие SOX, полное веб-администрирование. Недавно он был также интегрирован с Gerrit, так что он также предоставляет вам полный экземпляр Gerrit
Надеюсь это поможет!
Что касается инструментов, пользователи MacOS-X считают GitX (http://gitx.frim.nl/) очень простым и эффективным. Недостатком является то, что он не поддерживает хуки Git Client (те, что в $GIT_ROOT/.git/hooks).
В целом, я настоятельно рекомендую выбрать инструмент, который поддерживает детальное управление доступом к: - ветвям (для отделения веток стабильного выпуска со строгой безопасностью от веток тем, которые требуют большей гибкости и гибкости) - принудительному применению идентификации (автор / коммиттер)). Это КЛЮЧ для SOX - ограничения на команды git - Audit-Trail. Это ключ для SOX
Те, которые я успешно использовал с этими функциями:
- Обзор кода Gerrit (http://code.google.com/p/gerrit/)
- GitEnterprise (http://gitenterprise.com)
- CollabNet TeamForge (http://www.collab.net/gotgit) использует Gerrit 2.1.8 за кулисами
PS Не стоит недооценивать соответствие SOX и CMMI: часто у вас есть ограниченный выбор, который диктуется политикой безопасности вашей компании.
Надеюсь это поможет.
Лука.
Похоже, ваша проблема в том, что вы не определились или не создали рабочий процесс. Git достаточно гибок, чтобы использовать его как svn или любую другую VCS, но он настолько мощный, что, если вы не установите правила, которым все должны следовать, вы просто получите беспорядок. Я бы порекомендовал рабочий процесс диктатора-лейтенанта, который кто-то упомянул выше, но в сочетании с моделью ветвления, описанной Винсентом Дриссеном. Для получения дополнительной информации смотрите эти скринкасты Дэвида Бока, а эту - Марка Деррикутта.
Мы недавно перешли с SVN на GIT. Поскольку git-daemon не работает с msysgit, мы выбрали подход с центральным хранилищем на сервере Linux с gitosis.
Чтобы исключить возможность испортить мастер, мы просто удалили его. Вместо этого мы готовим все выпуски, объединяя ветви, выбранные для тестирования, и помечаем слияние. Если он проходит тесты, коммит помечается версией и запускается в производство.
Для этого у нас есть вращающаяся роль менеджера релизов. Менеджер релизов отвечает за проверку каждой ветви, прежде чем она будет готова к тестированию. Затем, когда владелец продукта решает, что пришло время объединить утвержденные ветви для нового тестового выпуска, менеджер по выпуску выполняет слияние.
У нас также есть вращающаяся роль службы поддержки 2-го уровня, и, по крайней мере, для нас рабочая нагрузка такова, что возможно иметь обе роли одновременно.
В качестве преимущества отсутствия мастера невозможно добавить какой-либо код в проект без прохождения через менеджер релизов, поэтому мы напрямую обнаружили, сколько кода было незаметно добавлено в проект ранее.
Процесс рецензирования начинается с того, что владелец ветки отправляет diff на обзорную доску и размещает зеленую заметку на доске с названием ветки (у нас есть рабочий процесс на основе Канбана) в разделе "для рецензирования", или если он является частью завершенного пользователя. история, переместите всю карточку истории в "для просмотра" и поместите в нее постит. Менеджер по связям - это тот, кто перемещает карты и отправляет их в "готово к тестированию", а затем владелец продукта может выбрать, какие из них включить в следующем тестовом выпуске.
При выполнении слияния менеджер релизов также следит за тем, чтобы коммит слияния содержал разумное сообщение о коммите, которое можно использовать в журнале изменений для владельца продукта.
Когда релиз запущен в производство, тег используется как новая база для филиалов, и все существующие ветви объединяются с ним. Таким образом, все ветви имеют общего родителя, что облегчает обработку слияний.
GUI: На данный момент TortoiseGit v1.7.6 должен подойти для большинства ежедневных операций. Журнал, фиксация, Push, Pull, Fetch, Diff, Merge, Branch, Cherry-pick, Rebase, Tag, Export, Stash, Add submodule и т. Д.
Я также добавлю в пост "вы рассмотрели".
Одна из замечательных особенностей Bazaar - его гибкость. Это где он превосходит все другие распределенные системы. Вы можете использовать Bazaar в централизованном режиме, в распределенном режиме или получить следующее: и то, и другое (то есть разработчики могут выбирать, какая модель им удобнее или какая лучше подходит для их рабочей группы). Вы также можете отключить централизованное хранилище, находясь в дороге, и повторно подключить его, когда вернетесь.
Вдобавок ко всему, отличная документация и кое-что, что сделает ваше предприятие счастливым: коммерческая поддержка.
Чтобы эффективно использовать git в команде разработчиков с большим количеством разработчиков, требуется система CI, которая постоянно создает и тестирует. Дженкинс предоставляет такой автомобиль, и я очень рекомендую это. Часть интеграции должна быть сделана, несмотря ни на что, и намного дешевле делать это раньше и чаще.
- Установите достойный веб-интерфейс, например Github FI
- Придерживайтесь относительно централизованной модели (изначально), чтобы люди чувствовали себя комфортно.
- Запустите сборку Continuous Integration для каждой общей ветви.
- Поделитесь хорошим набором глобальных настроек git config.
- Интегрируйте git в вашу оболочку с завершением bash и запросом текущей ветки.
- Попробуйте IntelliJ Git Integration в качестве инструмента слияния.
- Убедитесь, что вы.gitignore в случае необходимости.
Что касается пунктов 3 и 4 (для каждого пользователя, для каждого раздела, для каждого филиала), взгляните на gitolite ( описанный в книге Pro Git: http://progit.org/book/ch4-8.html).
Политика или нет, Git - такой же хороший выбор DCVS, как и любой другой. Как и любому мощному инструменту, стоит потратить немного времени на то, чтобы понять, как этот инструмент предназначен для работы, и поэтому я настоятельно рекомендую книгу Pro Git. Несколько часов, проведенных с ним, сохранят много разочарований в долгосрочной перспективе.
Больше подходит для коллаборативного развития, чем гитоз или гитолит, но с открытым исходным кодом - Gitorious. Это приложение Ruby on Rails, которое управляет хранилищами и слияниями. Это должно решить многие ваши проблемы.
NXP управляет Git и Subversion с помощью одной общей платформы (в масштабе предприятия), интегрирующей разработку для мобильных устройств Android с традиционными программными проектами: http://www.youtube.com/watch?v=QX5wn0igv7Q
Git позволяет создавать частные ветки. Это побуждает разработчиков часто совершать коммиты, чтобы разбить модификации на небольшие коммиты. Когда разработчик готов опубликовать свои изменения, он отправляет на центральный сервер. Он может использовать сценарии предварительной фиксации для проверки своего кода, если это необходимо.