У вас два яйца и 100 этажей, яйца разобьются с 49-го этажа.
Вы сбросили с 50-го этажа, яйцо разбилось, у вас осталось одно яйцо.
Вы начинаете бросать с первого этажа до 49-го, всего уйдет 50 попыток. При этом существует решение, в котором задача решается в худшем случае за 14, вы проиграли.
У вас два яйца и 100 этажей, яйца разобьются с 10-го этажа.
Вы сбросили с 50-го этажа, яйцо разбилось, у вас осталось одно яйцо.
Вы сбросили с 25-го этажа, яйцо разбилось. У вас не осталось яйц и вы не решили задачу.
Заказчику пофигу есть у нас гит или нет, это совершенно не важно. Ему важно работает или нет ПО в установленные сроки с установленным функционалом
Несомненно. Но что бы сказал ваш заказчик, если бы узнал что десятки (сотни?) часов, потраченные на разработку самописной системы контроля версий можно было бы заменить готовой технологией, которая при этом во многом превосходит вашу?
Угадали. У нас разработка не ради разработки, а ради конечного продукта
Эта парадигма запрещает вам использовать любые современные инструменты, судя по всему?
Как можно в гите не дать посмотреть конкретный файл пользователю?
Это вы называете «спроектированной и декомпозированной структурой ПО»?
Вы сталкивались с тем что у вас все работало между 11 и12 часами и вы это поняли только в 16:00 и вопрос как откатится в гите реально решен? Вы пушите в гит после каждого изменения файла или только перед сборкой или только когда сочтете нужным?
Если нужно посмотреть локально я пользуюсь файловой историей. Я про возможность через пол года посмотреть по какой причине был изменена та или иная часть кода.
Просто глядя на «современную разработку» диву даёшься как такое можно сделать, зачем вы все усложняете
Вместо готовых инструментов вы используете какие-то костыли, но усложняют все, кроме вас? :)
Итого, плюсы и минусы вашей реализации по сравнению с введением Git-а:
+ Попрактиковались в написании своих костылей за счет заказчика
+ Ощущаете за собой право осуждать современное ПО в котором не разбираетесь (но, скорее всего, только внутри команды)
— Нет возможности правки одного файла одновременно несколькими разработчиками
— Приходится вручную контролировать доступа к файлам
— Нет нормальной истории изменений, что затрудняет поиск причины правок
— Вероятнее всего откат правок конкретных изменений одного разработчика невозможен
— Введение в проект новых разработчиков затруднено. Люди, работавшие с нормальными VCS крутят пальцем у виска.
Зачем вам отдельный специалист для слияния кода из веток тоже остается под вопросом, разобраться с Git-ом даже для джуна вопрос пары дней. А для разработчиков с 25-ти летним опытом тем более.
Вы сбросили с 50-го этажа, яйцо разбилось, у вас осталось одно яйцо.
Вы начинаете бросать с первого этажа до 49-го, всего уйдет 50 попыток. При этом существует решение, в котором задача решается в худшем случае за 14, вы проиграли.
Вы сбросили с 50-го этажа, яйцо разбилось, у вас осталось одно яйцо.
Вы сбросили с 25-го этажа, яйцо разбилось. У вас не осталось яйц и вы не решили задачу.
Несомненно. Но что бы сказал ваш заказчик, если бы узнал что десятки (сотни?) часов, потраченные на разработку самописной системы контроля версий можно было бы заменить готовой технологией, которая при этом во многом превосходит вашу?
Эта парадигма запрещает вам использовать любые современные инструменты, судя по всему?
Это вы называете «спроектированной и декомпозированной структурой ПО»?
Если нужно посмотреть локально я пользуюсь файловой историей. Я про возможность через пол года посмотреть по какой причине был изменена та или иная часть кода.
Вместо готовых инструментов вы используете какие-то костыли, но усложняют все, кроме вас? :)
+ Попрактиковались в написании своих костылей за счет заказчика
+ Ощущаете за собой право осуждать современное ПО в котором не разбираетесь (но, скорее всего, только внутри команды)
— Нет возможности правки одного файла одновременно несколькими разработчиками
— Приходится вручную контролировать доступа к файлам
— Нет нормальной истории изменений, что затрудняет поиск причины правок
— Вероятнее всего откат правок конкретных изменений одного разработчика невозможен
— Введение в проект новых разработчиков затруднено. Люди, работавшие с нормальными VCS крутят пальцем у виска.
Зачем вам отдельный специалист для слияния кода из веток тоже остается под вопросом, разобраться с Git-ом даже для джуна вопрос пары дней. А для разработчиков с 25-ти летним опытом тем более.