Git не обеспечит процесс «управления изменениями», который вы ищете.Это одно из тех требований к управлению, которые коммерческие системы контроля версий любят рекламировать, чтобы привлечь компании блестящими объектами.Это не значит, что вы не можете этого сделать, это просто за пределами цели Git.Очень похоже на аутентификацию и контроль доступа (вы можете использовать ssh и gitolite, но сам git не предоставляет эти сервисы).Возможно, вам придется разработать эту интеграцию самостоятельно, если вы не работаете с обычным инструментом отслеживания ошибок.
Блокировка файлов всегда неверна.Это то, для чего "слияние".
В настоящее время я работаю над базой кода в ~ 200 000 строк кода с 10 разработчиками, и git работает очень хорошо.У нас есть группы на порядок больше, также мы используем git для других проектов.Сила Git заключается в слиянии, и именно так он работает с несколькими разработчиками и множеством коммитов.Имейте в виду, что каждый толчок - это слияние в git, независимо от того, похоже это или нет.Ваш локальный репозиторий может иметь ветку с именем master, но это не та ветка, что и master в центральном репозитории.Чтобы синхронизировать их, вы выполняете слияние, которое иногда является просто «ускоренным слиянием».
Мы не пытаемся заставить сильную ссылку запрашивать изменения.Когда я подумал о написании интерфейса для этого, я столкнулся с одной проблемой: как заставить тупую систему отслеживания знать каждую ветку, в которой находится ошибка. Для этого недостаточно простого хука.
Вам следуетперейти к Git для улучшения процесса разработки.Для меня это в корне изменило (улучшило) способ написания кода.Вам будет предложено представить пример того, как Git лучше управляет изменениями в бизнес-среде без всяких предварительно упакованных маркеров, поставляемых дорогими инструментами IBM.Реальная проблема в том, что, приняв git, вы больше никогда не сможете работать ни с одним из других инструментов, независимо от того, насколько они хороши в бизнес-кейсе ...