Сразу стоит сказать некоторые вещи:
- GIT работал в Astra Linux SE v.1.4 2014 года выпуска - а в ней, как правило, все через жопу;
- серверной частью GIT занимался приходящий системный администратор, квалификация которого неизвестна;
- оценка программы ведется с позиции пользователя GIT: программиста, у которого лапки по части GIT.

GIT хранит на сервере эталонные версии исходников и с помощью своей клиентской части подхватывает изменения программистов, построчно, - и делает их эталонными. Если два разработчика редактировали один и тот же файл - возникает некомпилируемый конфликт, выделяемый системой прямо в исходниках конструкцией вида "<<<<<<<<<<", - решить который можно только вручную. Из этого следует, что при использовании GIT требуется разделение труда программистов между файлами проекта: чтобы один, по возможности, не лез к другому. Иначе оба программиста будут отвлекаться на решение большого количества конфликтов - что не раз случалось во время отладки по результатам испытаний программного обеспечения. Решили конфликт, пересобираешься полностью заново (несколько минут), уткнулся в следующий конфликт - и так в цикле.

Взаимодействие с сервером производится 3 командами:
- commit. Утверди мои изменения, сделанные после последней синхронизации;
- pull. Дай изменения, сделанные другими после последней синхронизации. Пересборка проекта покажет конфликты;
- push. Возьми актуальные исходники с разрешенными конфликтами. Запиши изменения построчно в лог на сервере (логи смотрятся через браузер как сайт).

Но работает не все идеально, ввиду неидеальности работы сервера с исходниками:
- если создаешь в проекте новый файл - требуется включить его в список файлов ГИТ;
- ГИТ обрабатывает и проектные файлы .PRO, и внешние конфигурационные файлы проекта. Так как у разных разработчиков разные настройки - пути 2: каждый раз править файл конфигурации или исключать его из обработки GIT;
- из-за 2 пунктов выше, была несколько раз ситуация, когда после пулла проект отказывался работать, даже будучи собранным, - и, внезапно, выясняется, что новые файлы насоздавались, - а их и нет. Так вообще было создано 2 новых подпроекта одним разработчиком - а остальные были ни сном ни духом, пока глючить не начало спустя неделю-две;
- несколько раз была ситуация, когда ГИТ возвращал в клиент утвержденные ранее удаленные строки. Это были и комментарии, и строки кода. Только по памяти и ручным бакапам исходников удавалось разгрести и понять, что в таких конфликтах есть истина, а что ложь. Плюс ручной поиск строк, не являющихся конфликтами (ведь ГИТ их не выделяет каким-либо способом). Поэтому шугаешься каждого пулла и пуша - перепроверяя правильность сохранения исходников;
- нельзя просто скопировать исходники с одного компа на другой и пуллить последние изменения с сервера. Это приводит к каким-то другим критическим багам, уже забытым.

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

Возможно, в Windows ГИТ работает прекрасно.