" title="Написать письмо">Написать письмо

Статистика

Пользователи : 1
Статьи : 1967
Просмотры материалов : 7176831
 
Контроль версий GIT (01.11.2023). Печать E-mail
2023 - Ноябрь
01.11.2023 17:01
Save & Share
Гладко было на бумаге - да забыли про овраги. Клиент-серверная программа GIT, используемая для синхронизации исходников при работе с ними несколькими программистами, - оказалась не только не всегда хорошей, но даже иногда вредной.



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

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

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

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

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

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

Последние новости


©2008-2024. All Rights Reserved. Разработчик - " title="Сергей Белов">Сергей Белов. Материалы сайта предоставляются по принципу "как есть". Автор не несет никакой ответственности и не гарантирует отсутствие неправильных сведений и ошибок. Вся ответственность за использование материалов лежит полностью на читателях. Размещение материалов данного сайта на иных сайтах запрещено без указания активной ссылки на данный сайт-первоисточник (ГК РФ: ст.1259 п.1 + ст.1274 п.1-3).

Много статей не имеет срока устаревания. Есть смысл смотреть и 2011, и даже 2008 год. Политика сайта: написать статью, а потом обновлять ее много лет.
Открыта карта ВТБ для донатов на дорогостоящие эксперименты: 5368 2902 0040 0838.

Рекламодателям! Перестаньте спамить мне на почту с предложениями о размещении рекламы на этом сайте. Я никогда спамером/рекламщиком не был и не буду!
Top.Mail.Ru