Ну вот пример, мне дали сделать кнопку, а я в свою задачу подмержил мастер (а там новый код). Я когда делаю МР в свою главную задачу, то там будет на проверке и новый код. Оно нафига кому надо?
Если тебе не нужнн новый код то не мерджишь и не будет нового кодп
Юра
Юра
Автор сказал что ему нужен новый код
Юра
Значит он ожидает что при тестировании С будет новый код из мастера
Павел
Или например есть конфликты, и sub1 и sub2 будут их решать, причем решать одинаковые конфликты, а потом будут еще конфликты между ними вроде, когда они оба будут мержиться в futur
Павел
Значит он ожидает что при тестировании С будет новый код из мастера
Ему нужен новый код, но его ревьюеру в МР он нафиг не сдался, у него там только кнопка
Юра
Ну просто это туплсть
Юра
Реально тупач тупость )
Павел
Реально тупач тупость )
Каждый может иметь свое мнение )) я описал определнные кейсы, если это не переубедило, ну ок
Юра
Эй рябата, я тут собрался потестить свою фичу которач базируется на вашей ветке через пятое колено, поэтому будьте добры смерджите себе мастер )
Юра
Гит не для этого создавался чтобы такую тупость делать
Павел
Эй рябата, я тут собрался потестить свою фичу которач базируется на вашей ветке через пятое колено, поэтому будьте добры смерджите себе мастер )
Это в целом странный кейс. Но вообще такого не должно быть, в целом есть например главный над фичой, и он периодиески должен подмерживать мастер, без таких вот запросов, а кто делает подфичу - тот подмерживает только фичу
Konstantin
если честно как раз примерно для этого 🙂 он же изначально децентрализованный для того, чтобы ты контрибьютерам линукса присылал по почте патчи
Юра
Нет не для этого
Konstantin
не ну тебе виднее, ладно
Konstantin
а они это вливают в свою копию ядра, дальше из набора патчей снизу формируют патч в вышестоящего коммитера ядра итд
Юра
Если предположить что веткой А занимается одна команда, веткой Б другая, а веткой С третья, то ты будешь послан если попросишь кого-то вмержить мастер только чтобы потестить свой код
Павел
Если предположить что веткой А занимается одна команда, веткой Б другая, а веткой С третья, то ты будешь послан если попросишь кого-то вмержить мастер только чтобы потестить свой код
По хорошему у команд не должно быть таких зависимостей
Павел
а подмерживание - чисто чтобы потом не было конфликтов
Павел
Если одна команда жестко завязана на нереализованном функционале другой - тут уже что-то пошло не так
Юра
Не ну вот реально допустим я а ветке А делаю авторизацию, апи. На каком-то этапе я сделал основной функционал и кто-то решил форкнуться от нее и пилить формк авторизации. В этом время в мастере появились новые изменения которые нужны форме авторизации, но не мне в ветке А. Я себе пилю и пилю апи. И тут ты такой а смерджи себе мастер, потому что мне нужно
Павел
Не ну вот реально допустим я а ветке А делаю авторизацию, апи. На каком-то этапе я сделал основной функционал и кто-то решил форкнуться от нее и пилить формк авторизации. В этом время в мастере появились новые изменения которые нужны форме авторизации, но не мне в ветке А. Я себе пилю и пилю апи. И тут ты такой а смерджи себе мастер, потому что мне нужно
Это немного другой кейс, есть изначальная завязка на авторизацию - общую фичу. А вообще, я должен сам по себе мержить мастер(дев) себе регулярно без таких вот запросов
Юра
Ты должен это делать когда ты готов
Юра
А не когда кому-то понадобилось
Павел
Короче выдуманный сценарий, невнятный
Юра
Вправе не делать вообще пока не решил мерджить обратно
Павел
Если челику нужна авторизация, значит она должна быть уже готова, и влита в мастер
Павел
Короче сами придщумываем приключения, чтобы их потом решить
Юра
Это ты опять придумал
Юра
Все тебе должны
Юра
Тот должен вливать мастер себе, это должно быть готово уже
Юра
Ощущение что максимальный размер команды был два человека
Павел
Ок, я заканчиваю. Какой то разговор о придуманных кейсах, которые надо сделать явно специально, а мне придумывать решения ))
Павел
Ощущение что максимальный размер команды был два человека
Чуваки которые с большими командами, вообще сразу в мастер пушат и радуются, и это не рофл
Юра
Короче если кто-то что-то должен сделать чтобы ты что-то сделал, это значит не гит вэй
Павел
это все понятно, что все это херня и сразу пушить в мастер надо...
Павел
но на вопрос чуваку не ответили вроде как? в шторме есть одной кнопкой пушить в нужные ветки?
Павел
*ROFL*
Павел
но на вопрос чуваку не ответили вроде как? в шторме есть одной кнопкой пушить в нужные ветки?
Ну можно в шторме без переключения веток обновить их и потом подмержить, но да - это не 1 клик
Konstantin
Чуваки которые с большими командами, вообще сразу в мастер пушат и радуются, и это не рофл
типа того, да, дешевле фича-флаги и вот это всё завести, чем заставлять тыщу человек страдать с гитом вот так
Konstantin
хер с ними с людьми, просто это флоу довольно сильно провоцирует на ошибки и вечно сломанный билд, поэтому лучше всё упрощать пока можно
Павел
Разбавлю симфонийским вопросом)
Не могу понять в чем причина: при тестировании через phpunit всего проекта - моки срабатывают, а когда делаю привязку к команде —filter=methodName - то моки перестают подрубаться и врубаются сервисы оригиналы. Контейнер симфони как то работает по разному
Ivan
Добрый день! В данный момент пишу сервис авторизации. По сути аналог passport.yandex.ru/accounts.google.com, человек заходит, есть варианты авторизации, регистрации, восстановления пароля. Сервис так же находится на отдельном поддомене. После авторизации есть возможность отредактировать данные профиля, настройки безопасности, контроль сессий. Далее, используя данный сервис, планируется выписывать oauth2 токены, которые будут использоваться как своими приложениями (веб, мобильные), так и сторонним приложениям, которым мы дадим доступ. Планирую авторизацию на самом сервисе авторизации реализовать через сессии с использованием кук. Список авторизованных сессий хранить в базе данных, пользователь их будет видеть в профиле, и сможет удалить определенные, либо все сразу. Сессия будет включать в себе информацию о fingerprint устройства, юзерагент, ип адрес, что бы было представление, что это за сессия. При выписке oauth2 токенов (jwt), которые тоже хранятся в бд, буду токен привязывать к той сессии, с которой он был сформирован, соответственно, если сессия будет аннулирована пользователем, то и удалять все выписанные токены к ней. Если oauth2 токен выписан для нашего приложения, в нем будет пометка об этом, и scopes внутри него тогда учитывать не буду, если же приложение стороннее, то учитывается scopes. Подскажите, у меня правильное видение такой системы?
Юра
Кука вечная что-ли?
Юра
Не понятно что есть сессиия
Юра
Чел зашел в другом браузере и что?
Юра
Другая сессия?
Юра
Вообще если что такие сервисы есть уже
Юра
Платные правда по-моему
Юра
https://auth0.com/docs/authenticate/protocols/oauth
Ivan
Чел зашел в другом браузере и что?
Да, в другом браузере другая сессия. Кука не вечная, но на год вполне может стоять.
Юра
Тогда если токены привязаны к сессии, то я не увижу свои токены в другом браузере?
Юра
Вообщем непонятна привязка
Ivan
Список сессий будет в профиле пользователя
Юра
Я просто не понимаю зачем привязывать токены к сессии
Юра
Кто-то может с трёх браузеров на даух компах заходить и что он потом будет делать со всем этим зоопарком сессий
Юра
Или почистил куку, новая сессия. А что делать со старой сессией?
Юра
Как понять она активна или это мусор
Ivan
Согласен, оно не обязательно. Просто хотел информацию об устройстве, с которого была произведена авторизация, хранить именно в сущности сессия, что бы понимать какие токены откуда. Иначе придётся это хранить в таблице токенов и при рефреше копировать эту информацию а новый токен.
Юра
Ну можно хранить да
Юра
Но просто не инвалидировать токены
Ivan
Ну если посмотреть тот же Гугл, он хранит информацию об устройствах, с которых произведена авторизация, с возможностью разлогинить
Юра
Не делать им грубо говоря cascade delete
Юра
А то связь между токеном и сессией мне кажется не настолько дубовая
Ivan
ip спорно, если динамик ip то будет разлогинивать, или же будет неактуальная инфа
IP скорее для информации, по нему будет так же определена геолокация, разлогинивать при смене ип точно не стоит
Юра
Если нужно разлогинить все устройства этого юзера, просто удаляешь все токены у которых этот юзер
Юра
И не надо через привязку к сессин
Юра
Если нужно разлогинить акк этого юзера на другом компе удаляешь, удаляешь сессию
Юра
Мне кажется это две разные штуки
Ivan
Да, тоже думаю, так правильно. Спасибо!
Юра
А то так можно разлогинить акк юзера на другом компе и случайно похерить доступ всех приложений
Юра
Кстати фигня получится
Юра
Удалять тогда надо через софт делит
Юра
А то токены потеряют информацию о том кто их создал
Ivan
Да, там везде планируется soft delete
Юра
А так норм делать?
return $arr['some'] ?? throw new \Exception("blablabla")
Павел
Konstantin
очень жду когда в пхп завезут оператор ин. задолбал array_key_exists
Юра
Да есть такое
Юра
Пиши RFC )