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