JD
Александр Медведько
Нет. Конфигурация берётся из хранилища. В гит изменения выгружаются в одну сторону, затем архитектор собирает их через реквесты и помещает в хранилище
Так и будешь мучаться при такой односторонней игре
Size: a a a
2020 August 26
NG
проблемой является эфемерность мержа из хранилища в базу разраба. фиксируйте это отдельным коммитом или мержем девелопа в фича бранч
NG
тогда изменений не будет
NG
либо ребейзом фича бранча поверх девелопа. на ваш вкус
NG
но мерж - честнее. (нет, я не хочу снова устраивать холивар ребейз-против-мержа, пожалуйста :) )
АМ
у вас недоразветвленная разработка. часть информации о ветках и их синхронизации - эфемерная, и не попадает под систему контроля версий. логично, что когда разработчик возвращается в систему контроля версий, эта информация в нее попадает. т.е. это не проблема как таковая.
Почему? Фича-ветки создаются от dev или в случае фикса от релиза. Все мерджится только через реквесты для статического контроля кода и прочего.
АМ
проблемой является эфемерность мержа из хранилища в базу разраба. фиксируйте это отдельным коммитом или мержем девелопа в фича бранч
Мердж из девелопа в бранч мне не нравится. Потому что в этом случае коммиты располагаются в хронологическом порядке. Я хочу чтобы разработчик вёл локальную ветку и ребейзил ее в случае получения нового кода из конфигурации, а публиковал ее после окончания работ и сразу за этим делал бы реквест, который крутился бы до тех пор пока код не будет одобрен.
АМ
Собственно я и спрашиваю нормальная ли это схема в моей ситуации или есть проще?
NG
Александр Медведько
Мердж из девелопа в бранч мне не нравится. Потому что в этом случае коммиты располагаются в хронологическом порядке. Я хочу чтобы разработчик вёл локальную ветку и ребейзил ее в случае получения нового кода из конфигурации, а публиковал ее после окончания работ и сразу за этим делал бы реквест, который крутился бы до тех пор пока код не будет одобрен.
мерж из девелопа в бранч - это именно то, что де-факто делает ваш разработчик, когда забирает конфигурацию из хранилища к себе в базу
NG
> Я хочу чтобы разработчик вёл локальную ветку и ребейзил ее в случае получения нового кода из конфигурации, а публиковал ее после окончания работ и сразу за этим делал бы реквест, который крутился бы до тех пор пока код не будет одобрен.
можете делать и ребейз, да. главное, каким-то образом отражать информацию о переносе конфигурации хранилища в базу разработчика
можете делать и ребейз, да. главное, каким-то образом отражать информацию о переносе конфигурации хранилища в базу разработчика
NG
просто ребэйз - это не то, что физически делает разработчик. это неестественная операция
АМ
просто ребэйз - это не то, что физически делает разработчик. это неестественная операция
Это вопрос дискуссионный :)
NG
Александр Медведько
Это вопрос дискуссионный :)
о да)
АМ
> Я хочу чтобы разработчик вёл локальную ветку и ребейзил ее в случае получения нового кода из конфигурации, а публиковал ее после окончания работ и сразу за этим делал бы реквест, который крутился бы до тех пор пока код не будет одобрен.
можете делать и ребейз, да. главное, каким-то образом отражать информацию о переносе конфигурации хранилища в базу разработчика
можете делать и ребейз, да. главное, каким-то образом отражать информацию о переносе конфигурации хранилища в базу разработчика
Что Вы имеете в виду? Как отображать информацию?
JD
мерж из девелопа в бранч - это именно то, что де-факто делает ваш разработчик, когда забирает конфигурацию из хранилища к себе в базу
Вообще не хватает таких хау-ту наглядных примеров (с картинками или видео) по подходам пересаживания с хранилищ 1С в гит.
АМ
У меня тут как раз пробел, так как работа ручная и все на совести разработчика
NG
Александр Медведько
Что Вы имеете в виду? Как отображать информацию?
мерж-коммитом или ребейзом
АМ
мерж-коммитом или ребейзом
Это понятно. Ладно, если других возражений нет кроме принципиальных, то всем спасибо :)
КЧ
John Doe
Вообще не хватает таких хау-ту наглядных примеров (с картинками или видео) по подходам пересаживания с хранилищ 1С в гит.
Берёшь любой хау ту для гита, удаляешь из головы всю информацию о хранилище и пользуешь.
JD
Кирилл Черненко
Берёшь любой хау ту для гита, удаляешь из головы всю информацию о хранилище и пользуешь.
Так если бы я один был. Куча рыл рядом)