Контроль джерел на основі Git на підприємстві: пропоновані інструменти та практики?

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

Але зараз це покладено на роботу і, чесно кажучи, у нас виникають проблеми.

З іншого боку, git, здається, не працює добре для централізованого розвитку у великій організації (20+ розробників) з розробниками різних можливостей та рівнів вишуканості git - особливо порівняно з іншими системами управління джерелами, такими як Perforce або Subversion, які спрямовані на таке середовище. (Так, я знаю, Лінус ніколи цього не призначав.)

Але - з політичних міркувань - ми застрягли в git, навіть якщо це смокче за те, що ми намагаємося з цим зробити.

Ось деякі речі, які ми бачимо:

• Інструменти графічного інтерфейсу не дозріли
• Використовуючи інструменти командного рядка, легко прокрутити злиття та знищити чужі зміни
• Він не пропонує дозволів для сховища для кожного користувача за межами глобальних привілеїв лише для читання або читання-запису
• Якщо у вас є дозвіл на БУДЬ-яку частину репозиторію, ви можете зробити те ж саме для КОЖНОЇ частини сховища, тому ви не можете зробити щось на зразок створення гілки відстеження невеликої групи на центральному сервері, чого інші люди не можуть возитися з.
• Робочі процеси, відмінні від "що-небудь йде" або "доброзичливого диктатора", важко підбадьорити, не кажучи вже про виконання
• Незрозуміло, чи краще використовувати одне велике сховище (яке дозволяє всім возитися з усім) або безліч складових сховищ (які створюють головний біль, намагаючись синхронізувати версії).
• З кількома сховищами також незрозуміло, як повторити всі джерела, які має хтось інший, витягнувши з центрального сховища або зробити щось на кшталт отримання всього станом на 4:30 вчора вдень.

Однак я чув, що люди використовують git успішно у великих організаціях розвитку.

Якщо ви знаходитесь у цій ситуації - або якщо у вас зазвичай є інструменти, поради та підказки для полегшення та продуктивності використання git у великій організації, де деякі люди не є фанатами командного рядка - я хотів би почути, що у вас є запропонувати.

До речі, я вже задавав версію цього питання на LinkedIn, і я не отримав справжніх відповідей, але багато "боже, я теж хотів би це знати!"

ОНОВЛЕННЯ: Дозвольте уточнити ...

Де я працюю, ми не можемо використовувати нічого, крім git . Це не варіант. Ми з цим застрягли. Ми не можемо використовувати mercurial, svn, bititter, Safe Visual Source Safe, ClearCase, PVCS, SCCS, RCS, базар, Darcs, монотонний, Perforce, Fossil, AccuRev, CVS або навіть хороший проектор Apple, який я використовував у 1987 році. Тож, хоча ви можете обговорити інші варіанти, ви не отримаєте щедрості, якщо не будете обговорювати git.

Також я шукаю практичні поради щодо використання git на підприємстві . Я поставив цілий список проблем, з якими ми стикаємося у верхній частині цього питання. Знову ж таки, люди можуть обговорити теорію, але якщо ви хочете заробити винагороду, дайте мені рішення.

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

DVCS проти CVCS в контексті підприємства:

Я не хочу говорити про загальні плюси / мінуси тут, а скоріше зосереджуюсь на вашому контексті. Загальна думка, що для використання DVCS потрібна більш дисциплінована команда, ніж використання централізованої системи. Це тому, що централізована система надає вам простий спосіб забезпечити свій робочий процес, використання децентралізованої системи вимагає більше спілкування та дисципліни, щоб дотримуватися встановлених конвенцій. Хоча це може здатися, що це викликає накладні витрати, я бачу користь у розширеному спілкуванні, необхідному для того, щоб зробити його гарним процесом. Вашій команді потрібно буде повідомити про код, про зміни та загальний статус проекту.

Інший вимір у контексті дисципліни - це заохочення розгалуження та експериментів. Ось цитата з недавньої статті Мартіна Фаулера про інструменти контролю версій , він знайшов дуже стислий опис цього явища.

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

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

Робочі процеси:

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

• Чистий високоякісний кодекс лише для магістралі (master repo)
• Вся розробка відбувається на особливих галузях
• У командних команд є репост команди
• Вони регулярно об'єднують останні зміни магістралі у свою галузь функцій ( Forward Integrate )
• Комплексні функції повинні пройти декілька гарантій якості, наприклад, огляд, тестові покриття, відповіді на запитання (відповіді самостійно)
• Якщо функція завершена і має прийнятну якість, вона об'єднується в магістраль ( Reverse Integrate )

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

(Зображення викрадено з hginit.com Джоела Спольського .)

На цей момент залишається сказати одне: - навіть хоча DVCS забезпечує великі можливості злиття, це ніколи не замінює використання безперервної інтеграції. Навіть у цей момент у вас є велика гнучкість: CI для репо-магістралі, CI для командних репостів, репортаж із питань відповідей тощо.

Git у корпоративному контексті:

Git - це, мабуть, не ідеальне рішення для корпоративного контексту, як ви вже вказали. Повторюючи деякі ваші занепокоєння, я вважаю, що особливо це:

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

Я не хочу тут запускати git vs. hg flamewar, ви вже зробили правильний крок, перейшовши на DVCS. Меркуріал стосується деяких пунктів вище, і я вважаю, що це краще підходить для корпоративного контексту:

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

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

Зменшення тертя:

Добре, оскільки, здається, ви справді застрягли з ситуацією, у IMHO залишилися два варіанти. Немає інструменту, щоб зробити git менш складним; git є складним. Або ви зіткнетесь з цим, або вирішите навколо git: -

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

Якщо чесно, я думаю, що у вас справді є проблема людей, а не проблема інструментів. Що можна зробити, щоб покращити цю ситуацію?

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

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

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

Щодо деяких ваших конкретних проблем:

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

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

Так, я знаю, Лінус ніколи цього не призначав.

Власне, Лінус стверджує, що централізовані системи просто не можуть працювати.

І що не так з робочим процесом диктаторів і лейтенантів?

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

(оновлено)

Більшість ваших проблем зникнуть, якщо ви не спробуєте використовувати git так, як ніби це "svn на стероїди" (тому що це не так).

Замість використання голого сховища в якості центрального сервера, де кожен може натиснути (і, можливо, викрутити), встановіть кілька менеджерів інтеграції, які керують об'єднаннями, щоб тільки вони могли просуватися до голого сховища.

Зазвичай цим людям слід керувати командою: кожен керівник інтегрує роботу своєї команди та висуває її до благословенного сховища.

Ще краще, що хтось інший (тобто диктатор) відтягує від керівників команд і інтегрує їх зміни до благословенного сховища.

З цим робочим процесом немає нічого поганого, але ми перевантажені роботою, і нам потрібні наші інструменти, щоб замінити час і увагу людини; ніхто не має пропускної здатності навіть робити перевірки коду, не кажучи вже про доброзичливого диктатора.

Якщо інтегратори не встигають переглянути код, це добре, але вам все одно потрібно мати людей, які інтегрують злиття від усіх.

Робота з гутом не потребує багато часу.

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. Ви можете підключити його до Хадсона за допомогою http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin , що дозволяє будувати та перевіряти зміни, поки вони ще переглядаються; це дійсно вражаюча установка.

Якщо ви вирішили використовувати геррі, я рекомендую спробувати зберегти досить лінійну історію, а не гіллясту історію, як це люблять деякі з відкритих джерел. Герріт це висловлює як "дозволяти тільки швидкі зміни вперед". Тоді ви можете використовувати розгалуження та злиття більше, як ви звикли, для випусків та чогось іншого.

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

Тут у вас зовсім інший набір проблем:

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

Робочі процеси

Ми успішно прийняли режим центрального сховища: те, що ми маємо в нашому проекті підприємства (великий портал для 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 Client (ті, що знаходяться під $ GIT_ROOT / .git / гачки).

Загалом я рішуче вибираю інструмент, який підтримує тонкий контроль доступу : ). Це KEY для SOX - обмеження команд git - аудит-слід. Це KEY для SOX

Я успішно використовував ці функції:

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

PS Не варто недооцінювати відповідність SOX та CMMI : багато разів ви маєте обмежений вибір, який диктує Ваша компанія Enterprise Policy щодо безпеки.

Сподіваюся, це допомагає.

Лука.

Нещодавно ми перейшли з svn на git. Оскільки git-daemon не працює з msysgit, ми вибрали підхід до центрального репозиторію на сервері Linux з gitosis.

Щоб виключити можливість накрутити майстра, ми його просто відкинули. Натомість ми готуємо всі випуски, об'єднуючи гілки, обрані для тестування, та тегуємо об'єднання. Якщо він проходить тести, фіксація позначається версією та вводиться у виробництво.

Для вирішення цього питання ми маємо обертову роль диспетчера випусків. Менеджер випусків відповідає за перегляд кожної гілки, перш ніж вона буде готова до тесту. Тоді, коли власник продукту вирішить, що пора з'єднати затверджені гілки разом для нового тестового випуску, менеджер випуску виконає злиття.

У нас також є ротаційна служба служби 2-го рівня, і принаймні для нас обсяг роботи такий, що можна виконувати обидві ролі одночасно.

Як перевагу відсутності мастера, неможливо додати будь-який код до проекту, не переходячи через менеджер випусків, тому ми безпосередньо виявили, скільки коду, який раніше мовчки додавали до проекту.

Процес огляду починається з того, як власник філії надсилає розгляд до оглядової дошки та розміщує зелений пост на дошці з назвою гілки (у нас є робочий процес на основі Kanban) у розділі "для перегляду" або якщо він є частиною завершеного користувача історія, перенесіть всю історію на «для перегляду» і поставте на неї постіт. Релейний менеджер - це той, хто переміщує картки та розміщує їх на "готові до тестування", і тоді власник продукту може вибрати, які з них потрібно включити в наступному тестовому випуску.

Здійснюючи злиття, менеджер випуску також переконуєсь у тому, що комісія злиття містить слушне повідомлення про фіксацію, яке може бути використане в журналі змін власників продукту.

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

Я додам також повідомлення "чи вважали ви"

Однією з чудових речей Базару є його гнучкість. Тут він б'є всі інші розподілені системи. Ви можете керувати Bazaar в централізованому режимі, розподіленому режимі або отримати це: і те й інше (тобто розробники можуть вибрати, з якою моделлю вони зручні або яка найкраще працює для їх робочої групи). Ви також можете відключити централізоване сховище під час руху в дорозі та підключити його знову, коли повернетесь назад.

Крім того, відмінна документація та щось, що зробить ваше підприємство щасливим: доступна комерційна підтримка.

• Встановіть гідний веб-інтерфейс, як Github FI
• Дотримуйтесь порівняно централізованої моделі (спочатку), щоб людям було комфортно.
• Запустіть збірку безперервної інтеграції для кожного спільної гілки.
• Поділіться хорошим набором глобальних параметрів налаштування git.
• Інтегруйте git у свою оболонку із завершенням bash та підказкою із поточною гілкою.
• Спробуйте інтеграцію Git IntelliJ як інструмент злиття.
• Переконайтесь, що ви .gitignored відповідно.

Щодо пунктів 3 та 4 (дозволи на кожного користувача, за секцією, за галузями), ознайомтеся з гітолітом (висвітлено у книзі Pro Git: http://progit.org/book/ch4-8.html ).

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

GUI: На даний момент TortoiseGit v1.7.6 повинен бути добре для більшості щоденних операцій. Журнал, фіксація, натискання, витягнення, вилучення, відмінність, злиття, відділення, вишня, вибір, база даних, тег, експорт, приховування, додавання підмодуля тощо ...

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

Більш підходить для колаборативного розвитку, ніж гітоз або гітоліт, але з відкритим кодом - Gitorious . Це додаток Ruby on Rails, яке обробляє управління сховищами та об'єднання. Це повинно вирішити багато ваших проблем.

Git дозволяє створювати приватні відділення. Це спонукає розробників брати на себе зобов'язання часто, щоб розбити модифікації на невеликі комітети. Коли розробник готовий опублікувати свої зміни, він переходить на центральний сервер. Він може використовувати сценарії попереднього введення, щоб перевірити свій код, якщо це необхідно.

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