Управление исходным кодом на основе Git на предприятии: рекомендуемые инструменты и методы?

Я использую 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 на предприятии . Я поставил целый список проблем, с которыми мы сталкиваемся, в начале этого вопроса. Опять же, люди могут обсуждать теорию, но если вы хотите получить вознаграждение, дайте мне решения.

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

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

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

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

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

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

Workflows:

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

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

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

(Фотография украдена с сайта Джоэла Спольски hginit.com .)

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

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

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

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

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

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

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

Уменьшение трения:

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

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

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

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

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

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

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

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

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

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

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

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

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

(Обновлено)

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

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

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

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

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

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

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

git pull A
git pull B
git pull C

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

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

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

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

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

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

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

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 миллионов пользователей), де-факто является центральным репозиторием, который производит официальные сборки, а затем используется в процессе доставки (который, в нашем case, состоит из трех уровней тестирования и двух развертываний). Каждый разработчик управляет своим собственным репозиторием, и мы работаем для каждой отдельной функции.

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

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

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

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

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

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

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

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

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

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

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

Вот те, которые я успешно использовал с этими функциями:

1. Проверка кода Gerrit (http://code.google.com/p/gerrit/)
2. GitEnterprise (http://gitenterprise.com)
3. CollabNet TeamForge (http://www.collab.net/gotgit), негласно использует Gerrit 2.1.8

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

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

Лука.

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

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

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

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

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

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

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

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

Я также добавлю сообщение "вы подумали".

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

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

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

Что касается пунктов 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