Дмитрий, и руками тоже, конечно, но вообще у нас Gitlab CI, Docker, вот это вот все. В общем, взять и заменить СУБД для тестов просто так не получится.
Дмитрий, видимо, мне стоит дописать в вопрос, что на этом работа с данной строкой JSON, которая должна быть массивом, из нее созданным, не заканчивается. И код приложения ложится с ошибкой типа или например "Illegal string offset 'holder'" - то есть приложение, обращаясь к якобы массиву через "$arr['holder']", на самом деле обращается к строке, в которой есть JSON и в нем объект с полем "holder".
iMaximus, все верно, но тут вышло так, что почему-то изменения более ранние были накачены как актуальные. Я не понял, что произошло, и в итоге решил в пятницу проблему, поменяв местами во время мержа активную ветку и ту, которую указывал для мержа. Все получилось. Повторять не хочу, да и времени на работе нет. Возможно, что я просто под конец недели что-то неверно понял.
Денис Загаевский, у меня тоже еще ни разу такой проблемы не было, в итоге на самом деле помогло делать мерж, поменяв местами активную ветку и ту, которую указываешь для мержа.
iMaximus, да понятно, что нужно сливать постоянно, но бывает так, что есть ветка истории, пускай она будет H1 (не обращаем внимание на предыдущие обозначения веток). От нее отводятся ветки двух задач, T1 и T2. Над каждой веткой работает какой-то разработчик, в итоге кто-то из них успевает первым закончить свою задачу, и беспроблемно вливает свои изменения из T1 в ветку истории H1. При этом его код и код того, кто работал над T2, где-то пересекаются.
В итоге когда тот, кто наконец закончил свою Т2, встает перед проблемой мержа. Сливать изменения между T1 и T2 в процессе - не вариант. Выливать их постепенно в H1 - тоже не вариант, так как по процессу работы нужно сначала ревью, потом тесты, сборка и ручное тестирование. В общем, в итоге встает иногда задача таких вот мержей.
Илья лук, да, возможно. Вопрос в том, что там будет использоваться в качестве плеера на стороне телевизора. В общем, пока не совсем есть время для всего этого, но как только смогу уделить его, обязательно еще отпишусь здесь :-)
programrails, ничуть не отрицая вашего опыта, замечу, что Upwork используется как раз ради исключения таких вот проблем. Там можно и нужно работать на длинных заказах именно потому, что условия устанавливаешь ни ты, ни заказчик, а некий арбитр между вами. И если и заказчик и исполнитель на них согласны (это важно), то все идет отлично.
Я, например, заводил туда сам своих клиентов, именно ради такого арбитража как раз. Да, комиссии, да, правила, но в итоге все спокойны и довольны. А напрямую работать, когда непонятно чье законодательство будет для вас арбитром, это так себе удовольствие, как мне кажется, и именно что да, нужно будет некое представительство в той стране, если это возможно, чтобы если что оно могло отстаивать права исполнителя на правовой территории заказчика.
Илья лук, вы продолжаете не понимать, что мне нужно. Я не хочу смотреть видео на ТВ с компьютера, я хочу работать на компьютере, имея телевизор как монитор. Не думаю, что VLC сможет помочь мне в этом.