Git vs Хранилище. Битва титанов?

17.09.24

Разработка - Групповая разработка (Git, хранилище)

Называть Git новой технологией – уже смешно, но для многих 1С-ников это действительно «новое и неизведанное». Расскажем о плюсах и минусах двух главных систем контроля версий в мире 1С: Git и хранилища.

Скажу пару слов, откуда взялась идея этого доклада. В 2021 году я выступал на конференции Инфостарта в Москве, рассказывал, как у нас CI бороздит просторы Большого театра.

В своем докладе я так сильно хвалил OneScript, что Андрей Овсянкин, автор OneScript, не мог пройти мимо. Он подошел после доклада и спросил: «Как вы заставляете людей на Git переходить? Они же не хотят». Из этого вопроса и возникла идея доклада.

Мой доклад – это творческая компиляция моих же внутрикорпоративных объясняюще-вдохновляюще-мотивационных митапов, которые были призваны мотивировать команды переходить на разработку в Git.

 

Я занимаюсь продвижением Git, я адепт Git, я люблю Git, я не люблю хранилище, поэтому в моем докладе не будет никакого беспристрастного сравнения двух систем. На мой взгляд, такое сравнение в принципе невозможно. У этих двух систем настолько разные весовые категории, что сравнивать можно только их идеи.

Поэтому план доклада будет таким:

  • Я сейчас представлю участников.

  • Мы сравним идеи, которые были заложены в архитектуру Git и хранилища.

  • Я расскажу свое видение – в чем подвох, почему 1С-ники до сих пор не на Git.

  • Обсудим несколько практических кейсов, которые возникают при разработке в Git, и покажу, как одни и те же ситуации решаются в Git и в хранилище.

И поскольку я все-таки адепт Git, не удивляйтесь, что в течение всего доклада я буду немного унижать хранилище. Хотя что там унижать-то? Было бы что унижать.

 

Сравнение Git и хранилища

 

Итак, «Git против хранилища – битва титанов?» Нет. Нет никакой битвы титанов.

Git – это действительно титан программистского мира. Это де-факто стандарт по контролю версий во всем программистском мире.

  • Он может хранить любые файлы, может сравнивать что угодно с чем угодно, с точностью до символа.

  • Все, что вы хотели сделать с вашими файлами, но по каким-то причинам боялись, с Git это можно сделать беспроблемно, безопасно и безбоязненно. Вы можете любые свои фантазии с ними реализовывать, а потом нажать кнопку и откатиться, словно ничего не было. Он всегда может вам дать безопасность. В Git столько возможностей и инструментов, аналогов которым нет в других системах контроля версий, не говоря уже про хранилище.

  • Git – ласковый мерзавец. Даже если вы что-то хотите сделать с вашими файлами и ошиблись, он вам сам подскажет, как лучше написать, как сделать, чтобы достичь ваших целей.

  • И для любителей метафизики: если вы создаете ветки и хорошо оформляете свои коммиты, по истории ветвления Git можно даже восстановить историю вашей мысли – как вы разрабатывали задачу. Вы пошли сюда, тут тупик, потом сюда и так далее.

Git – это система, которой реально нет аналогов. Чтобы не быть совсем голословным, приведу простой пример. Редактор Visual Studio Code – это тоже стандарт де-факто для быстрого программирования под Windows. Он постоянно используется в Windows. Там огромное количество плагинов, поддержка всех языков. И если мы возьмем голый Windows, поставим туда Visual Studio Code, первое, что он спросит: «А где Git? Давайте поставим». То есть программисты реально не мыслят себя без Git. Кроме 1С-ников.

Git – титан, красавец, полубог, Геракл. Настоящий титан мира программирования.

 

А хранилище – это вообще не титан. Я выбрал Ахиллесика. Он тоже красивый.

У хранилища много плюсов:

  • Интеграция с 1С. Это однозначный плюс, ни у кого такого нет. Киллер-фича.

  • Низкий поребрик вхождения. Чуть позже пару слов об этом скажу.

  • Хранилище конфигурации умеет хранить конфигурацию. Круто.

  • Можно сравнить несколько версий между собой.

  • Можно сделать отчет по истории хранилища – у вас получится текстовый файл: можно нажать Ctrl+F и быстро поискать по комментариям, если вы их оформляли при помещении в хранилище.

  • Но есть баг: у нас на 8.3.10 эта штука не работает, потому что программисты 1С придумали, что комментарий в комментарии не нужен. И если есть два слэша, то все после них отбрасывается. Вы помещаете в хранилище, даете ссылку на Jira – http:// – и после них все пропало. Поэтому поиск по отчету мы использовать не можем. Говорят, в новых версиях платформы это починили и можно использовать.

И все. Как вообще можно сравнивать хранилище и Git? Давайте поговорим об их идеях, сравним их идеи.

 

Идея хранилища. Без всякого сарказма, я считаю, что идея хранилища потрясающая. Оно отлично решает основную проблему групповой разработки – это объединить изменения, собрать воедино то, что люди сделали.

Люди, которые его придумали, скорее всего, знакомы с теорией решения изобретательских задач. Потому что по теории решения изобретательских задач нужно вычленить проблему, а потом сделать какое-то идеальное решение, при котором проблема рассасывается сама, и ее нет, ничего делать не надо. Захват – это как раз идеальное решение этой проблемы. Потому что у нас по каждому объекту линейная история изменений. Пока кто-то один захватил объект, что-то делает, второй ничего не может сделать с этим, ждет. Когда первый отпустил, второй получает последнюю актуальную версию. У нас линейная история изменений, и нет никакого объединения изменений.

Счастье, радость, реально круто придумано. Классический пример того, как сферическая программистская мысль натыкается на грубую шероховатость суровой реальности и не выдерживает с ней столкновения.

Почему не выдерживает? Я не претендую на какую-то полноту опыта работы с храном, я все-таки адепт Git, но достаточно долго в профессии, много работал с храном и видел две системы работы с хранилищем.

Первая система пытается эксплуатировать стандартную идею захвата в хранилище. У нас есть некое боевое хранилище, к нему подключена база, там захватываются объекты, и люди разрабатывают:

  • Сидит некий программист Серега, захватил объекты, разрабатывает изо всех сил.

  • Тут к нему приходит другой программист Андрюха, и говорит: «Слушай, чувак, отпускай объекты, мне нужно внедриться, у меня уже согласовали внедрение, я задачу закончил, отпускай».

  • И Серега говорит: «Ты что, я не закончил! Мне еще надо две недели, чтобы все сделать!»

  • Андрюха ему скажет: «Ты что, две недели мы не можем ждать! У нас параллельная разработка, куча команд, мы закончили! Мы не будем тебя ждать, отпускай объекты!»

Серега сохраняет CF, отпускает объекты, Андрюха внедряется, Серега захватывает назад и объединяет изменения. Получается, что захват, который был призван сделать так, чтобы не было объединения изменений, не избавляет от объединения изменений. Объединение изменений осталось, и оно объективно нужно, это веяние нашего времени. Но захват добавляет головняков, конфликтов и проблем.

Часто бывают ситуации, особенно на удаленке, когда сидит Андрюха, разрабатывает, пишет в чат: «Серега, давай объекты отпускай, мне нужно внедряться», потом: «Серега, объекты отпускай, мне внедряться надо! Ты чего молчишь?» Потом в общий чат пишет: «Где этот упырь, чего он мне не отвечает?!» Ему говорят, что он в отпуске. «А-а-а, кто может захват в хранилище снять? Галя, у нас отмена!»

Вот к чему приводит захват – головняк и сложности, а объединение изменений никуда не делось. Это первая система работы с храном.

Вторая система подразумевает, что все разрабатывают на копии, никто объекты не захватывает, объекты можно захватывать только для внедрения. Ты захватил, внедрился, отпустил – все. Никаких проблем с отпусками, красиво все, благолепие.

Что при этом происходит? Сидит Серега, разрабатывает на копии. Сейчас все разрабатывают на копии, никто объекты не захватывает. Закончил, согласовывается внедрение, он берет свою CF, берет базу, подключенную к храну, захватывает объекты, объединяет изменения и вылезает красивое окошко с кучей галочек.

И тут начинается интересное:

  • Как узнать, могу я забрать целиком весь объект, не глядя, не просматривая все изменения, или нет?

  • Или мне нужно пойти в историю хранилища по этому объекту и посмотреть, не было ли там изменений с тех пор, как я сделал свою копию базы?

  • А от какой версии хранилища я сделал свою копию базы? У меня может быть желтенькая бумажечка есть? Нет, я же программист.

  • Даже если есть excel-ка, где расписаны задачи, с какой ревизии начиналась каждая и так далее – я один объект, два, три посмотрю, было или не было внедрения. А потом я устану и мне проще руками будет все эти галочки протыкать, глазами посмотреть.

Получается, что:

  • Идея хранилища о том, что объединения изменений нет, не соответствует действительности – объединение изменений никуда не делось. Но эта идея привела к тому, что в хранилище нет никаких инструментов для того, чтобы облегчить объединение изменений.

  • Все хранилище рассчитано на то, что каждое изменение мы смотрим руками и глазами. Все хранилище – про ручной труд.

  • Нет автоматического контроля конфликтов – все руками.

  • Блейм через комментарии – это вообще одна из тех вещей, от которых меня постоянно трясет. Часто возникающая задача: в процессе работы конфигурация выдала ошибку в какой-то строке. Техподдержка смотрит: «Кто последний трогал эту строку? Кто виноват?»
    Как это в хранилище посмотреть? Мы все опытные, знаем, что можно искать виновника изменений, используя дихотомию. Мы смотрим последнюю, там уже измененная, в середину тыкаем, там еще старая, еще в середину, и вот так можно быстро найти. Но это тоже долго.
    Поэтому у нас 20-кратная вложенность комментариев: «Я такой-то тогда-то потрогал эту строчку, вот это заменил», «А я такой-то закомментарил изменения этого», «А я раскомментировал предыдущего» и так далее. Получается ад из комментариев двадцатикратной вложенности, которые пишутся, т.к. в хранилище тяжело найти, кто трогал строчку.

  • Откат изменений как демоническое обновление. У нас в компании запрещен откат изменений в хранилище, потому что когда-то сделали откат, а потом восстанавливали все хранилище из бэкапа. И теперь у нас если кто-то внедрился, а потом нужно откатить, мы делаем ручную антивыкладку. Это такая же выкладка, так же нужно руками делать, глазами смотреть, вроде ничего не перезатер, вроде нормально.

Это то, как работают с хранилищем. Его идея о том, что объединения и изменения нет, привела к тому, что мы все делаем руками.

 

А теперь давайте поговорим про Git и про его идею.

Git придумал Линус Торвальдс для того, чтобы объединять изменения кода от работы программистов, с которыми он вместе разрабатывает ядро Linux.

Git придуман в помощь программисту для объединения изменений – это его основа, его идея, он создан ради этого. Из-за этого в нем безумное, огромное количество возможностей, инструментов, всяких фишечек, которые облегчают работу с изменениями, берут ее на себя, автоматизируют и так далее.

  • Автодетект конфликтов – настраиваемый. О чем это? Когда я разрабатываю в Git, я создаю свою ветку. Git автоматически запоминает, от какой ревизии я создал свою ветку. Я что-то наизменял, в это время в основной ветке тоже кто-то что-то наизменял. Я теперь хочу залить свои изменения назад. Git сам автоматически проверяет, нет ли конфликтов между тем, что я наизменял и кто-то наизменял. И если не было конфликта – я трогал что-то, что никто больше не трогал – Git это объединяет автоматически. Мне не нужно ставить ни единой галки – ничего. Это просто за секунду залетает, и все. Все, что можно сделать автоматически, Git берет на себя.

  • Бесконфликтное автоматическое слияние. За секунду все залилось, даже не грею голову. Я точно знаю, что я ничего не перезатер. 100%.
    Почему настраиваемый автодетект конфликтов?

    • По умолчанию Git определяет конфликт по изменению одной и той же строчки – если я потрогал строчку и кто-то потрогал эту же строчку, у нас возникнет конфликт. В этом случае мы объединяем код у себя конфигуратором – чуть позже покажу маленький скрипт, с помощью которого мы это делаем.

    • Но при работе с Git мы всегда можем откатиться на ручное объединение – мы настроили так, что у нас конфликт вылезает, если двое потрогали один и тот же файл (общий модуль или форму, или документ). Тогда мы это объединяем конфигуратором. А все, что можно объединить автоматически, Git объединяет автоматически.

  • Blame. Блейм в Git – это когда я беру тот же Visual Studio Code, открываю в нем общий модуль или модуль объекта, тыкаю строчку мышкой и вижу справа – кто, когда и по какой задаче его менял. Все! Мне не нужна дихотомия. В Git это по дефолту из коробки. На GitLab то же самое: можно нажать кнопку Blame и сразу увидеть по каждой строчке автора в одном месте.

  • Вишенки с тортиков – если эту же конфигурацию параллельно со мной разрабатывает другая команда, и они что-то навертели-накрутили, и мне вся их задача не нужна, весь этот «торт», он мне вреден при моем телосложении.
    А вот «вишенка» у них на тортике, какое-то конкретное изменение – оно бы мне пригодилось. Я бы хотел забрать в свою ветку какую-нибудь функцию в общем модуле и метаданные для ее работы. И я могу в Git сказать, чтобы он перенес эту «вишенку» в мою ветку. Хлоп, и она уже тут. Вся. Все изменения, и только они.
    Мне не надо никаких галок ставить, ничего не надо. Git берет на себя работу с изменениями. Причем я могу это сделать еще до внедрения. Они еще не внедрились даже, их кода (этого «торта») нет в основной ветке. Но я могу уже это все забрать себе. Вот что дает Git.

  • Любые файлы: синхронные релизы, документация. Если вы помните, лет 7 назад Алексей Лустин рассказывал, что у нас уже нет монопроектов – всегда рядом с 1С есть какой-нибудь сайт. Синхронные релизы всегда возникают.
    Мы можем в Git хранить конфигурацию 1С и тут же рядом сайт со всеми его заморочками, скриптами и так далее. Это в Git из коробки, ничего даже делать не надо.
    Мы можем хранить в одном репозитории Git запросы из консоли запросов; переписку из Outlook, которая объясняет, почему именно так мы реализовали эту задачу; Excel, Word, любые файлы – это все из коробки.

  • Откат задачи – это отдельная фишка. В хранилище мы можем откатиться до версии, но если кто-то после косячной выкладки еще что-то навыкладывал, то откатится все. А в Git я могу просто выбрать конкретную задачу, нажать в GitLab одну кнопку – убрать галочку, чтобы мне не делали merge request, нажать «OK», и все. Git знает сам, какие изменения там были, и он сам их все откатит. Только их и все. Git берет на себя всю автоматизацию по работе с изменениями. Если где-то нужен именно человеческий интеллект, то, конечно, все возлагается на человека. Но все, что можно решить автоматически, Git берет на себя.

 

В чем подвох?

 

Если все так классно в Git, почему тогда 1С-ники до сих пор не на Git? В чем подвох?

 

Я думаю, что подвох именно в этом.

Хранилище – это низкий поребрик. Вспомните сами себя, берете какого-нибудь джуна, спрашиваете: «Работал с хранилищем?» – «Нет» – «Смотри, база подключена к храну, вот сюда заходим, нажимаем “Обновить конфигурацию из хранилища”, объекты захватили, поменяли, поместили». Все, он умеет работать с хранилищем. Ничего больше не надо.

Один раз надо потом его будет отругать, когда он вам базу от хранилища отключит. А потом он себя отругает, когда начнет помещать, не подтянув изменения, и у него роли расползутся – придется сохранять конфигурацию в файл и подтягивать изменения через сравнение-объединение. И все. Хранилище очень легко пройти.

А Git – это неприступная крепость. Страшно, белые буквочки на черном фоне. Что это такое? Это для гиков? Как вообще можно этим пользоваться?

Но посмотрите на картинку – там же нет пацанов, которые из лука стреляют по вам, или расплавленное олово льют на вас. Да, там ров есть. Но там же есть мост, есть документация. Усохни, моя душенька – мост! Можно легко изучить.

На конференции Инфостарта в Москве выступали ребята с «Тинькова», они рассказали: «Мы сели вчетвером, посидели пару часиков, разобрались, как все работает, и перешли на разработку в Git».

Там нет ничего сверхъестественного. Чтобы освоить инструмент, достаточно потратить пару часов. Но если вы его освоили, потом будет уже легче. Конечно, целиком вы его не освоите, там очень много всего, фишек безумное количество. Но вы начнете работать и постепенно в процессе работы будете улучшать свое владение Git.

 

Зато что там дальше…

  • За поребриком у нас – хоронилище. Мы в хоронилище похоронили конфигурацию, она там похороненная лежит, потому что ничего с ней не сделать.

  • А за суровыми воротами – стройные деревья коммитов, веточки, красота, солнышко сверкает, ласточка с весной и все такое. Потому что там инструменты, ты наслаждаешься жизнью, и у тебя все хорошо. Но нужно потратить время – лучше день потерять, потом за пять минут долететь.

 

Кейсы

 

Теперь давайте немного поговорим про конкретные приемы работы с 1С – как одни и те же кейсы решаются в хранилище и в Git.

Обновление конфигурации разработки до текущей.

  • Если с хранилищем работать по первой схеме, то, конечно, все просто – обновили конфигурацию из хранилища, и все. Но я уже рассказал, какие проблемы при этом бывают.
    А при второй схеме работы с хранилищем приходится идти в базу, которая подключена к храну, обновлять ее, сохранять CF, тащить в свою базу, сравнивать-объединять, руками все галочки ставить, глазами проверять – не затер ли ты что-то и так далее. Потом к тебе прибегают через два часа: «Я же там процедуру поменял, а ты мне перезатер!» А я не увидел – там 150 изменений было, я глазами смотрел, я устал. Бывает.

  • А в Git нужна такая команда:

    git fetch && git merge origin/develop
    Подтягиваем изменения и мержим – все. В 95% случаев мерж бесконфликтный, залетает за секунду, никаких галочек ставить не надо. Если есть конфликт, на следующих слайдах покажу, что мы при этом делаем. Но в Git все просто.

     

Обратный пример – поставка для QA на другом релизе. У нас, к моему удивлению, достаточно часто такая задача возникает. У нас разработчики разрабатывают на каком-то более-менее современном релизе. А QA гоняет нагрузочное тестирование на предыдущем релизе, говорит: «Дай мне свою поставку на предыдущем релизе, у нас эталон на этом релизе, мы хотим сравнить».

  • И представьте, как это выглядит в хранилище. Вы сначала пошли в хранилище, взяли оттуда нужную версию конфигурации, развернули в какую-то временную базу, потом накатываете туда свою CF, пытаясь включить в поставку ваши изменения, не включая в поставку изменения последнего релиза. Это реально целое горе.

  • А вот так это делается в Git:

    git diff --merge-base develop > changes.diff
    git checkout тег_релиза
    git apply changes.diff
    oscript tools/СобратьCF.os
    Флаг –-merge-base develop возвращает тот самый коммит, от которого я начал свою ветку. И от этого коммита до текущего он просто все изменения закидывает в файлик, потом я переключаюсь на нужный релиз и все эти изменения применяю. Да, бывают нюансы, когда это не работает, но очень часто, в 95% – беспроблемный merge. Все получается автоматически буквально за несколько секунд. Никаких галок ставить не надо.
    А затем мы запускаем СобратьCF.os – это простенький скрипт на OneScript, который создает временную базу, загружает конфигурацию из файлов и выгружает в CF. Все.

     

Кто виноват?

  • Про мучения с поиском виновного в хранилище я уже рассказывал.

  • А в Git можно использовать команду:

    git blame путь/к/файлику
    Или просто ткнуть в строчку в Visual Studio Code – вы сразу видите, кто последний трогал строчку.

     

Откат задачи – тоже уже говорил:

  • В хранилище это ручная антивыкладка, которая тоже выкладка – надо смотреть, вдруг я что-нибудь перезатёр.

  • А в Git – команда:

    git revert хеш_коммита
    Или в GitLab три раза кликнуть мышкой, и все изменения задачи автоматически отменятся.

     

 

Взять кусок кода у соседней команды – команда Git «взять вишенку»:

git cherry-pick хеш_коммита

И этот коммит идет в мою ветку – это то, что умеет Git.

Автоматическая проверка конфигурации:

  • Чтобы при помещении в хранилище что-то сделать автоматически, люди ставят какие-то HTTP-прокси, что-то выдумывают

  • А в Git это из коробки – там есть хуки, вы можете по любым условиям запустить что угодно: автотесты, SonarQube. Все это, повторюсь, из коробки.

Документация и связанные релизы, о них я тоже уже говорил. Из коробки, само.

Код-ревью. Вы делаете merge request, там видны все изменения, которые вы предлагаете залить в основную ветку. Код-ревью из коробки, он естественным образом получается.

Огромное количество других инструментов, про которые времени не хватит все рассказать.

Git – это потрясающая вещь для программиста. Он сделан в помощь программистам.

 

Когда у нас в файле возникает конфликт, мы откатываемся на ручное объединение – для этой цели мы написали простенький скрипт.

Когда Git мержит ветки, то, что бесконфликтное, оно в текущей директории уже объединилось. Поэтому все, что этот скрипт делает:

  • он создает временную базу;

  • загружает туда текущую конфигурацию;

  • создает CF той ветки, с которой мы мержимся;

  • открывает конфигуратор;

  • все, что остается человеку – это нажать «Сравнить/объединить» и выбрать собранный CF.

  • Из-за того, что бесконфликтное уже объединено, в этом сравнении-объединении мы видим только конфликты. У нас люди заняты только тем, чем должны заниматься люди, а то, чем может заниматься машина, машина уже сделала. Мы видим только конфликты. Мы точно знаем, что там есть чужой код, и я не могу его пропустить. Я точно знаю, что мне нужно внимательно объединять, потому что где-то что-то конфликтануло.

Вот так мы объединяем – так у нас работает объединение изменений и мерж в Git.

Мы работаем в конфигураторе, у нас 8.3.10, обычные формы, поэтому мы не можем использовать EDT, и слава Богу.

 

Git – наше все!

 

Git – реально наше все. У всех программистов на других языках – давно уже так. И я надеюсь, что и у 1С-ников тоже очень скоро будет так.

  • Во-первых, это CI-щий (сияющий) инструмент. Это путь в тот самый дивный новый мир CI, CD, DevOps и так далее.

  • Из-за того, что Git на себя берет автоматизацию вашей работы, ваша эффективность увеличивается – вы начинаете больше делать за единицу времени. Да, вы тратите время для того, чтобы изучить Git, но это повышает вашу эффективность.

  • А повышение вашей эффективности повышает вашу зарплату.

Надеюсь, вас это вдохновит.

 

Вопросы и ответы

 

Я так понял, вы используете для всех задач Git Bash. Вы не упомянули ни разу ни о каких вспомогательных инструментах. Вам действительно этого хватает? Даже для просмотра изменений в файле и для структуры веток вы все равно Git Bash смотрите?

Не совсем. Я давний линуксоид. И я – да, использую Git Bash, мне другие клиенты Git не интересны и не нужны. Различия я смотрю через vim diff.

Но в компании у нас есть люди, которые используют SourceTree и другие клиенты Git, например, встроенные возможности VS Code или его плагинов для Git.

Буквально сегодня была дискуссия, как настроить KDiff3 и P4Merge для мержа.

В SourceTree очень удобный механизм для мержа внешних обработок. Там можно просто нажать на обработке, в которой конфликт, правую кнопку мыши, сказать, что у тебя есть внешняя программа слияния – конфигуратор, и SourceTree сама расчетверит эту обработку – достанет общего предка, покажет текущую, покажет ту, с которой мержимся. И потом очень удобно их в конфигураторе обновлять – сравнивать-объединять.

Есть использование GUI-клиентов. Но те люди, которые начинают более активно использовать Git, в конце концов переходят на Git Bash, потому что он лучше, удобнее и проще.

Расскажите про вашу связку Git-конфигуратор. Как выглядит ваш процесс разработки?

Есть конфигуратор, в котором я сижу, разрабатываю, сделал какое-то цельное изменение. Жму «Выгрузить конфигурацию в файлы» и коммичу руками. Все.

У меня вопрос в обратную сторону. В Git есть классный механизм – reflog, с ним можно достать все, что потерял. А в хранилище что-то подобное есть?

Я понятия не имею про хранилище. Насколько я знаю, нет ничего такого.

Хранилище – это все-таки централизованная система учета версий 20-летней давности. Там последовательная история коммитов. Возможностей Git, конечно, там нет.

Для нас обновление от франчайзи – это вечная боль на двое суток. Она еще и с откатами бывает обратно. Первый вопрос: Git анализирует изменения в правах доступа, в разделении прав к отчетам? Вообще анализирует ли Git пользовательские разделенные права при изменении? И второй вопрос: как вообще через Git работать с конфигурацией от франчайзи?

Если вас интересует именно конкретно обновление типовых, лучше посмотреть доклад Артема Кузнецова про обновления. Он там рассказывает и старые варианты с тремя конфигураторами, и новый – как это с Git можно автоматизировать.

Git работает с файлами, он про 1С вообще ничего не знает, ему безразлично. Мы просто берем конфигурацию 1С, выгружаем в файлы, после этого Git работает с тем, что у нас есть. И в файлах выгруженной конфигурации есть все про права.

Насколько я слышал, многие очень радуются тому, что можно Git-ом объединить права как текст. Это проще и быстрее, чем что-то делать в конфигураторе.

Вы очень красиво про Git рассказываете. Но есть одно большое «но»: мы в 1С не работаем с исходниками. У нас нет исходников в текстовом виде, кроме скриптов, которые мы пишем. Все остальное – это бинарные файлы, которые можно, как вы говорите, выгрузить в файлы. И они даже не полностью выгружаются – мы даже обычные формы не в состоянии выгрузить в некие исходные файлы. Исходники как таковые – вторичны. И мы с этими вторичными файлами потом будем работать в Git. Обычные формы у нас выгрузились в бинарники. У нас есть одна версия этого бинарника, есть другая. Что нам Git автоматически смержит в этих двух бинарниках? Если мы не имеем исходников, имеет ли тогда смысл геморроиться? Там же целый спектр проблем! Бухгалтерия, выгруженная в эти файлики, занимает 2 или 3 гигабайта этих исходников. Как? Зачем?

Давайте пробую все-таки рассказать.

Во-первых, конечно, цель доклада была – вдохновить и рассказать, как все классно.

Во-вторых, то, что мы не работаем с исходниками – это не совсем правда. У нас есть исходники, за исключением обычных форм – выгрузка конфигурации в файлы дает нам как раз эти самые исходники, мы работаем именно с ними.

А выгрузка и загрузка из файлов – это методы платформы. Это платформа выгружает конфигурацию в файлы, потом может загрузить, она может загрузить измененные исходники назад в конфигуратор и получить это все.

У нас обычные формы, мы с ними работаем. Конечно, то, что я рассказывал про git revert, для изменений обычных форм не пройдет. Возможно, это наша специфика – у нас конфигурация выступает как back-office, и изменения на формы очень мало завязаны. Для перехода на Git мы все больше и больше идем к тому, что вся логика и весь код из форм выносится в модули объектов и работает там. В формах – только формы. Наверное, это даже правильно.

Какие-то изменения обычных форм, чтобы они конфликтанули – это очень редкая вещь. Я работаю так уже около четырех лет. Я с какими-то проблемами именно при объединении обычных форм не сталкивался.

Сейчас если нет конфликта, то просто новая версия затирает предыдущую, и все нормально.

А если есть конфликт, тогда мы откатываемся на ручное объединение, конфигуратором также объединяем, смотрим, исправляем, снова выгружаем конфигурацию в файлы, и у нас снова консистентная версия в файлах и все нормально, у нас проблем с этим нет.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2022 Saint Petersburg.

 

Приглашаем на конференции Инфостарта 2025 года

INFOSTART TEAMLEAD EVENT

Не только для разработчиков, но и для руководителей отделов разработки, тимлидов и ИТ-директоров.
Место: Москва
Даты: 24-25 февраля 2025 г.

Подробнее

INFOSTART A&PM EVENT (Анализ & Управление проектами)

Практическая конференция для аналитиков и руководителей проектов 1С.
Место: Санкт-Петербург
Даты: 29-31 мая 2025 г.

Подробнее


См. также

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Программист Стажер Платформа 1С v8.3 Платные (руб)

Использования систем контроля версий — стандарт современной разработки. На курсе научимся использованию Хранилища 1С и GIT при разработке на 1С:Предприятие 8. Разберем подходы и приемы коллективной разработки, научимся самостоятельно настраивать системы и ориентироваться в них.

4900 руб.

29.06.2022    11497    94    4    

125

Групповая разработка (Git, хранилище) Программист Руководитель проекта Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда в хранилище одновременно разрабатывают несколько команд, сортировка сделанного и несделанного при формировании релиза и проведение code review по задачам превращаются в непроходимый квест. В таких случаях нужен бранчинг. Расскажем об опыте перехода на новую схему хранения кода для ИТ-департамента.

23.09.2024    2084    kraynev-navi    2    

23

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Во многих командах незаслуженно забывают о том, что в базе меняются расширения (как от вендора, так и собственные) и внешние отчеты и обработки. Вплоть до того, что релиз происходит каждый день – меняются печатные формы, отчеты, обработки. Расскажем о том, как выгружать в Git не только изменения конфигурации рабочего контура, но и файлы внешних обработок и расширений.

05.09.2024    1716    ardn    12    

14

EDT Групповая разработка (Git, хранилище) Программист Платформа 1С v8.3 Бесплатно (free)

Заказчики любят EDT+Git за прозрачность и контроль качества. А у разработчиков есть две основные причины не любить EDT – это тормоза и глюки. Расскажем о том, что нужно учесть команде при переходе на EDT+Git.

14.08.2024    7026    lekot    34    

7

Групповая разработка (Git, хранилище) Программист Платформа 1С v8.3 Бесплатно (free)

В «долгоиграющих» проектах стандартный захват объектов 1С в хранилище может привести к длительным простоям других разработчиков. Но и создавать под каждую доработку отдельное хранилище, чтобы использовать технологию разветвленной разработки конфигураций от фирмы «1С» – избыточно. Расскажем о том, как разрабатывать в отдельной базе без ожиданий, а потом с легкостью перенести изменения в хранилище, используя основную идею технологии 1С – конфигурацию на поддержке хранилища.

05.08.2024    3404    sinichenko_alex    16    

24

Групповая разработка (Git, хранилище) Программист Руководитель проекта Стажер Бесплатно (free)

Про изменения и новинки в агрегаторе открытых проектов OpenYellow, которые появились с момента его создания: про портал, Github и Telegram

15.07.2024    2852    bayselonarrend    8    

24

Групповая разработка (Git, хранилище) Программист Стажер Бесплатно (free)

О проблемах новых 1С-проектов в общем океане открытого программного обеспечения.

07.07.2024    3503    bayselonarrend    57    

37

Групповая разработка (Git, хранилище) OneScript Программист Платформа 1С v8.3 Бесплатно (free)

Скрипт для работы с SonarQube и локальным репозиторием Git.<br> Цель проекта – возможность выполнить быструю проверку качества кода перед тем, как помещать доработки в рабочее хранилище. В Sonar и Git выгружается не вся конфигурация, а только объекты из заданного списка.<br> https://github.com/vkrivov/go/

02.07.2024    3124    vkrivov@yandex.ru    8    

18
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. acces969 361 17.09.24 12:07 Сейчас в теме
Для развертывания и поддержания работы GIT нужен отдельный человек. Т.е. +1 в штате. Для больших компаний это нормально, даже нужно. Но по факту, у 99% команд разработки нет свободных рук, а тимлид/архитектор загружен даже больше миддлов и джунов.
Опять же, bus factor - уйдет тимлид и GIT рассыпется.
У хранилища таких проблем нет.
Award; teyana; 7OH; nvv1970; d4rkmesa; +5 Ответить
2. Golovanoff 45 17.09.24 12:45 Сейчас в теме
(1) Для работы бригады лесорубов с помощью бензопил нужен отдельный человек, чтобы заправлял пилы бензином, следил за уровнем масла. Для больших компаний это нормально, даже нужно. Но по факту у 99% бригад лесорубов нет времени не то что изучать работу с помощью бензопил, нет времени даже точить топоры! А спец. человек для этого и так слишком занят, сильнее, чем обычные лесорубы. Уйдет спец по бензопилам - бензопила рассыпется. А у топора такой проблемы нет.

Правильно я понял?
ardn; Sushruta; SirStefan; jarinat; user2041697; mikeA; mrChOP93; awk; JohnyDeath; user1001838; Йожкин Кот; maksa2005; dhurricane; asmuk; pavlov_dv; edkuznetsov; andreysidor4uk; serg-lom89; SerVer1C; +19 3 Ответить
6. acces969 361 18.09.24 07:18 Сейчас в теме
7. Golovanoff 45 18.09.24 07:59 Сейчас в теме
18. ubnkfl 18.09.24 18:09 Сейчас в теме
(2) это ж из Кови? )
Некий человек увидел в лесу дровосека, с большим трудом пилившего дерево совершенно тупой пилой. Человек спросил дровосека:
- Уважаемый, почему бы вам не наточить свою пилу?
- У меня нет времени точить пилу, я должен пилить, – простонал дровосек
Golovanoff; +1 Ответить
44. nvv1970 20.09.24 11:39 Сейчас в теме
(2) доля лукавства здесь есть

в большинстве своем работа (не везде, но именно в большинстве) с хралищем максимально анархична
и именно это в глазах РП, аналитиков видится основным достоинством...
все валится в кучу максимально быстро.
все равны, главного нет, анархия - мать порядка, и вот это все...

Т.е. струкутра команды РП->аналитики->разрабы
Т.е. разрабы - это свора не связанных между собой людей. Они общаются с аналитиками. Общего архитектора нет.
Это наиболее распространенная схема работы.
У людей еще не произошел качественный переход к укруплению разработки, они эволюционно еще на базовой ступени.

Если уже есть техлид/архитектор (следующая ступень) - то и вопроса не возникнет "кто же будет мэйнтейнером репы в гит?"
Собственно все задачи техлида при работе с хранилищем - это кровище и боль. Именно он будет инициатором перехода в гит. Именно задачи "код ревью", "не помещаем пока не проверите и не протестите" парализуют работу команды через хранилище.
Гит легко закрывает любые вопросы.
Но работа проекта в гите вообще без мэйнтэенера (как это происходит в хранилище) быстро превратится в ад. Или я здесь не прав? ;) И мэйнтэйнер не нужен? Лесорубы и сами разберутся с мержами в мастер? Пуш-форс-форева? )))

Получается, что мы почти всегда сравниваем крайности "полная анархия, безвластие" и "попытка человекоподобной разработки".
Конечно, пока команда пока еще не слезла с пальмы (сами делаем первые шаги по земле) предлагать ей цивилизационные подходы - бесмысленно. Ибо зачем козе баян?

Но попробовав единожды ведение проекта в гите обратной дороги уже не будет. По крайней мере для руководителя разработки (техлида/архитектора, не про РП речь - ему то без разницы). Либо он заставит всех работать в гите. Либо сменит команду/место работы.
teyana; andreysidor4uk; angur; Golovanoff; yukon; +5 Ответить
46. Golovanoff 45 20.09.24 12:32 Сейчас в теме
(44) И соглашусь, и чуть-чуть нет.

Гит - это таки "персональный инструмент". Я использую гит, даже если я один - его возможности по работе с версиями мне очень нужны и и как жить без них - я уже не особо представляю.

А вот гитлаб (как замена сервера хранилища) - тут да, полностью согласен. Мерж-реквесты, мейнтейнер, код-ревью - это всё артефакты гитлаба.
47. nvv1970 20.09.24 12:51 Сейчас в теме
(46) в контексте данной статьи мы(вы) не рассматриваем индивидуальные плюшки гита, только контекст "хранилище кода и групповая разработка"
PS: я тоже "не представляю" ;)
45. reset2 17 20.09.24 12:02 Сейчас в теме
(2) не правильно понял.
<Душнила ON>
Топор меняют на бензопилу для увеличения производительности труда работяг. В нашем случае это скорее аналогия блокнота и конфигуратора/EDT...

При замене хранилища на GIT физически забивать код разработчики быстрее не станут, а еще больше гемора обретут с этими вашими мерджами и черри-пиками. Но зато увеличится эффективность разработки в целом за счет DevOps и прочей CI\CDшности. На мелких проектах это не надо, поэтому хранилище будет вполне эффективным решением. Для остального нужно отдельное тело на проекте, которое будет за это всё отвечать, ну либо сами разработчики будут этим заниматься, отнимая время непосредственно от разработки.

Если продолжить фантазировать в плоскости деревозаготовки, то правильная аналогия может быть обустройство новой технологичной площадки для накопления материалов, которая сама брак отсеет и отсортирует по качеству, соответственно нужен будет еще человек ответственный за эту "площадку" (заостряю внимание, что от этого работяги больше пилить не станут, но возможно качественнее).
<Душнила OFF>
triviumfan; +1 Ответить
49. Golovanoff 45 20.09.24 12:58 Сейчас в теме
(45) Вот не соглашусь. Как раз в области деревозаготовки хран и гит - это как раз ручная и бензопила. Причем умение пользоваться бензопилой - это же не "теперь ты прикован к этому инструменту, почувствуй, что эта бензопила - продолжение твоей руки". Совсем нет. Если удобнее и быстрее что-то пыщкнуть ручной ножовочкой с обратным пилом - да за ради Бога. Но если надо валить лес в промышленных масштабах - делать это ножовкой и оправдывать себя "эту вашу бензопилу придумал сотона, сгинь, сгинь" - это странно.

Инструмент под задачу - этого никто не отменял. Но для того, чтобы подбирать инструмент под задачу, нужно быть в курсе ассортимента инструментов.
52. reset2 17 20.09.24 16:47 Сейчас в теме
(49) Ну давай подискутируем (пятница же)...

Бензопила, пила, топор (технику для валки не берём) - EDT, конфигуратор, блокнот.
Бензопила, пила, топор - это инструмент с помощью которого рабочий производит древесину. И это прямая аналогия с конфигуратором, EDT, блокнотом, VSCod - с помощью этих инструментов разработчик "производит" код.
Так вот на этом этапе хранилище и GIT вообще никак не повлияют на скорость - разработчик в любом случае будет долбить на клавиши (пилить) с определенной скоростью, которая зависит от его навыков и мотивации.

Далее с добытой древесиной нужно произвести какие-то действия - отправить её в зону хранения, проверить её качество и отправить дальше. Тоже самое делаем с кодом, который выплюнул разработчик - отправляем на хранение, проверку качества и т.д.
В маленьких лесозаготовительных хозяйствах - просто бригадир и опушка леса, куда сгружаются спиленные стволы. like хранилище и руководитель группы.
В больших лесозаготовительных комплексах уже большие базы, с инфраструктурой, доп. подъезды (для параллельности), оборудованием, всякой автоматизацией и доп.персоналом. Соответственно Devops, CI/CD, скрипты, регламенты и персонал, которое без GIT сложно представить.

Жизнь конкретно взятого разработчика/работяги это никак не облегчает, а наоборот привносит еще больше неудобств.
triviumfan; teyana; +2 Ответить
14. yukon 151 18.09.24 09:25 Сейчас в теме
(1) Хм, вы возможно не совсем хорошо представляете себе что такое git сам по себе. Даже в лоб:
1. И гит и хранилище можно создать силами разраба на локальном компе
2. И гит и хранилище могут работать в режиме "в расшаренной папке"
3. И гит и хранилище могут работать в серверном варианте.

Так что с для технической поддержки разница невелика - и там и там требуются +/- одинаковые навыки администрирования. А фактор автобуса, для гита так вообще минимален - любой системный администратор осилит установку и поддержку гита.
Golovanoff; +1 Ответить
3. partizand 136 17.09.24 19:27 Сейчас в теме
(2) 1С не Ява, у неё нет исходников, как вам заметили. И требуются дополнительные обвязки. Ими занимаются как раз тимлиды обычно.
Хотя как я понял вы фанатик, что с вас взять?
Гит это инструмент. Хранилище это инструмент. Их нужно использовать, а не фанатеть от них.
Ну и потом, гит не единственный, есть же и другие системы контроля версий.
d4rkmesa; +1 Ответить
15. yukon 151 18.09.24 09:37 Сейчас в теме
(3) У конфигураций-то как раз есть исходники - разработчики с ними и работают.

Да все верно и гит и хранилище это инструмент. Хранилище для 2004 года было современным и удобным средством групповой разработки. Но сейчас то 2024-й так-то, и современный стандарт де-факто для разработки программного обеспечения это git. Хранилище же морально и технически устарело.

Хотя, конечно, вендор вполне мог бы его развивать и дальше, но последние функциональные фичи для хранилища добавляли аж в 8.3.10 (2018 год)

В 1С тоже это понимают - EDT принципиально не работает с хранилищем, только гит. Для 1С:Элемент - тоже только git, а в качестве IDE можно сказать Visial Studio Code.
Golovanoff; +1 Ответить
4. naf2000 18.09.24 06:25 Сейчас в теме
Работа с Git тяжела на конфигурациях уровня ЕРП
acces969; +1 Ответить
43. nvv1970 20.09.24 11:14 Сейчас в теме
(4) мой опыт говорит, что ничего подобного (почти)...
какие именно операции тяжелы?

самая тяжелая операция - это применение изменений конфигуратором уже после полной загрузки (исходников или cf)
5. Global__IT 303 18.09.24 07:01 Сейчас в теме
А зачем Андрюха должен отпускать объекты чтобы внедрился Серега? Если Серега без них свою часть сделал, применил и отладил.

Как Андрюха закончит, до этого получив новые объекты Серегины так и поместит в хранилище
8. Golovanoff 45 18.09.24 08:01 Сейчас в теме
(5) Потому что Серега не может внедриться - в хране объекты захвачены, а они Сереге нужны, он их тоже поменял. Параллельная неблокирующая разработка - объективная реальность при более-менее заметном количестве команд/разработчиков.
9. Global__IT 303 18.09.24 08:04 Сейчас в теме
(8) Вообще-то в описанном случае, первом , это не так. Во втором описанном случае так. Но тут нет. И поэтому этот довод некорректный.
И в любом случае останется история объединений.

Просто в хранилище одна ветка истории.
10. Golovanoff 45 18.09.24 08:09 Сейчас в теме
(9) Почему же не так? Я рассказываю то, что видел своими глазами.
В первом случае кто-то один захватил объект, а все остальные, которым нужно его поменять, вынуждены разрабатывать на базах, не подключенных к храну.
Во втором случае ВСЕ разрабатывают на базах, не подключенных к храну.
В обоих случаях после окончания разработки приходится делать ручное СравнениеИОбъединение.

А сказать заказчику "мы не можем эту задачу разрабатывать, там в хране объект захвачен другим отрядом" - наши заказчики такого не поймут-с.
48. reset2 17 20.09.24 12:51 Сейчас в теме
(10) Так в случае с GIT тоже самое "СравнениеИОбъединение" надо делать при параллельном изменении одного объекта, в этом случае GIT особо не облегчает.
Просто это самое "СравнениеИОбъединение" в случае с хранилищем будет делать Андрюха, т.к. Серега при захвате объектов может быть уверен в неприкосновенности своих объектов. С GITот тот кто последний пушит в репозиторий, или спец. обученное тело, если такое имеется и грамотно распределена разработка по веткам.
50. Golovanoff 45 20.09.24 13:06 Сейчас в теме
(48) Так я про это и рассказывал. Если есть конфликт, то СиО придется делать и никуда от этого не деться, ИИ у нас (ещё?) не умеет решать конфликты мержа.
А вот когда конфликтов нет, гит все делает САМ. Про это-то и речь. А вот в хране тебе все равно приходится смотреть глазками, ставить галочки ручками и тыкать кнопочки пальтчиками, потому что добыть из храна инфу о том, есть конфликт или нет - это жесть застрелиться, проще протыкать галочки и кнопочки. Есть вариант работы через поставки и просмотр дважды измененных, но это очень мало кто использует и выстроить работу через поставки - очень непростое дело. И даже если сделать, это дело очень быстро начинает подозрительно напоминать исковерканное и ущербненькое гит-флоу. :)
11. BackinSoda 18.09.24 08:37 Сейчас в теме
Жму «Выгрузить конфигурацию в файлы» и коммичу руками

И так при каждом изменении ? Для людей со средними компами и тяжелыми конфигурациями это нереально.
Зы: Хорошо еще когда хранилище есть, а не голая конфа в которой ведут разработку )
12. Golovanoff 45 18.09.24 09:12 Сейчас в теме
(11) А в чем проблема? Выгрузка занимает меньше секунды, она же инкрементная.

Инкрементную загрузку сделать - тут да, есть некоторые тонкости, а инкрементную выгрузку платформа делает сама.
13. yukon 151 18.09.24 09:12 Сейчас в теме
(11) Сценарий "выгрузить в файлы" отлично оптимизирован в конфигураторе для выгрузки при каждом изменении - выгружаются только измененные объекты. Тяжесть конфигурации влияет незначительно.
BackinSoda; Golovanoff; +2 Ответить
16. booksfill 18.09.24 11:20 Сейчас в теме
(13)
при каждом изменении - выгружаются только измененные объекты

Проверил на УПП под 8.2 (клиент - сервер), на локальной машине WIN10, RAM 16Gb, SSD, I5-7400, есть антивирус (не отключал, может зря).

Ничего не меняя в конфигурации, выгрузил 2-а раза, время в обоих случаях осталось одним и тем же - где-то 2мин.
Если в хранилище/git коммитить не слишком часто, то сойдет.

Надеюсь, что в новых версиях платформы все это кардинально ускорено. Есть данные?

GIT - вещь замечательная, но мало того, что порог вхождения совсем иной, так еще открывается пространство для "Наташа, вставай! Мы все испортили! Мы смерджили не те ветки! А еще, кажется, слишком рано сделали коммит, забыли добавить вот этот файл!"

И тут "вдруг" выясняется, что мы только думали, что знаем GIT, а там есть еще 100500 команд, которые что-то там правят, откатывают.
Причем все, как мы любим, строго по Гарри Поттеру, в виде заклинаний типа git reset HEAD~ --hard.
Можно для гурманов даже так git reset HEAD@gfa12a2
Если ошибешься - вызовешь дьявола.

Поэтому верно тут писали - для большой команды нужен выделенный гуру, а для маленьких может стать проблемой.

Забыл написать, я все равно за GIT - преимущества очень серьезные, мне не в лом потратить несколько часов, чтобы это дело освоить (немного лукавлю, уже работал с ним, но всё забыл).
Вот только сподвигнуть на это коллег, даже при наличии "здорового GUI" не уверен, да'с совсем не уверен.
19. dhurricane 18.09.24 18:24 Сейчас в теме
(16) Исходя из этого:
за GIT - преимущества очень серьезные....
Вот только сподвигнуть на это коллег, даже при наличии "здорового GUI" не уверен, да'с совсем не уверен
я бы сделал вывод, что не гуру нужен, а работа с сотрудниками, которые даже при наличии явных преимуществ альтернативы готовы ее бойкотировать в пользу привычного инструмента.
andreysidor4uk; mikeA; mrChOP93; Golovanoff; +4 Ответить
20. siamagic 18.09.24 23:34 Сейчас в теме
(16) Гит вообще не в тему и в 99% компаниях не к месту, потому как типовой отдел 10-20 сотрудников, Круг разработки для каждого обычно известен, мержится всё автоматический если глянуть ключи запуска 1с. Я 20 лет в разработке, в других языках нет достойной и простой альтернативы гиту - в 1С есть.

Увидел первую ссылку автора, всё стало понятно, этот человек на работает просто время гоняет. И чем больше бесполезных заморочек себе придумает тем типа больше работает ))))) ох уж эти одмины.
triviumfan; d4rkmesa; Painted; +3 3 Ответить
21. Segate 239 19.09.24 07:56 Сейчас в теме
(20) просто расскажите, как обновить переписанную ерп на 8 типовых релизов, когда там работают 10-20 разрабов одновременно?

Без код-фриза на 4 месяца?
Когда у вас только одних конфликтов больше 1500 штук?

Я честно пытался сделать это через сравнение-объединеие, но это тупо невозможно, как мне кажется
26. Golovanoff 45 19.09.24 08:21 Сейчас в теме
(21) Кто мешает вам сделать код-фриз при работе с гитом? Не принимайте мерж-реквесты и вот вам код-фриз.
Гит не забирает никакие возможности, гит их только добавляет.

В порядке бреда - я даже могу за очень короткое время запилить аналог "захвата" - рушить джобу валидации в пайплайне мерж-реквеста (вот сейчас кого-то порвет :)), если есть изменения определенных файлов в репозитории.
Но зачем? :)
27. Segate 239 19.09.24 08:22 Сейчас в теме
(26) Сергей, френдли файер)
Я не понимаю как это обновить без Гита, а с гитом-то как раз все понятно)
28. Golovanoff 45 19.09.24 08:25 Сейчас в теме
38. siamagic 19.09.24 19:34 Сейчас в теме
(21) У меня 2.4 на последнию 2.5 с двух обновлений взлетает, а у тебя 8? Ка что ли?
Работают в расширениях, расширения делятся по назначению: склад, производство, планирование, зарплата, обмены и т.д. Саму конфу таскать по хранилищам глупо и долго.

Покажите пример где гит может, а 1с нет.
22. Йожкин Кот 1008 19.09.24 07:59 Сейчас в теме
(20) Git не нужен только в одном случае, когда у тебя 0 (ноль) программистов в отделе. Хотя и в этом случае я б еще задумался.
mrChOP93; yukon; Golovanoff; +3 Ответить
39. siamagic 19.09.24 19:36 Сейчас в теме
(22) Гит нужен когда ты школата со смузи ))) Все эти ваши откатится, посмотреть кто там "насрал" в 40 обновлений назад - такие глупости оторванные от жизни.
triviumfan; user700897_nkt1c; +2 4 Ответить
40. yukon 151 19.09.24 19:40 Сейчас в теме
(39) Если у вас нет кейсов когда надо поднять историю зачем и когда это делалось, то это же не значит, что ни кого нет таких необходимости. Мы вот например регулярно смотрим - кто, когда и зачем менял тот или и иной кусок кода.
mrChOP93; Golovanoff; +2 Ответить
41. siamagic 19.09.24 20:30 Сейчас в теме
(40) Это говорит что в вашей команде часто косячат и у вас много времени на изучение этих косяков или *.
Вы заменили слово "пример" на "ящик", думаю не пользуетесь хранилищем по той же причине.
sys1c; d4rkmesa; BackinSoda; +3 2 Ответить
42. Йожкин Кот 1008 20.09.24 08:34 Сейчас в теме
(39) Спасибо, следующий.
mikeA; Golovanoff; +2 Ответить
53. mikeA 1 23.09.24 07:47 Сейчас в теме
(39) Гит нужен хотя бы для того, чтобы хранить там внешние обработки. Или когда хранилище клиента недоступно, но это уже другой уровень))
29. Golovanoff 45 19.09.24 08:36 Сейчас в теме
(16) "Если ошибешься", "страшно аж жуть", "мержил ветки - вызвал дьявола" - это всё психотравмы 1сников от хоронилища. Весь кайф гита как раз в том, что с ним вообще не страшно. Всегда можно вернуться к состоянию, от которого ты начал делать что-то противоестественное. Всегда можно достать неиспорченным то, что попортил. Если, конечно, ты не попортил .git :)
34. booksfill 19.09.24 11:17 Сейчас в теме
(29) Меня за git агитировать не надо.
Возьмем первые 4 возможности, мог бы дать git не кому-то сферическому, а именно нам:
- поддержка параллельной разработки разных фич. Очееень надо.

- вливание части доработок в другую ветку. Хочется, но не так чтобы слишком.

- решение проблема захватов. Это просто боль на часто дорабатываемых объектах.

- кто, что конкретно изменял и как это вернуть. Хранилище тут что-то вроде журнала регистрации - формально что-то сделать можно, на практике проще махнуть рукой. Ну или начать прикручивать костыли вроде Elastic search.
Часто встречается не в виде "кто виноват", а в виде "что именно я сделал по такой-то задаче пол года назад".

Но git надо осваивать.
Тут IMHO подводные камни:
- если инструмент имеет 100 возможностей, но часто используется 15, то можно дать гарантию, что когда потребуется что-то из оставшихся 85, помнить что там как не будет никто. Отсюда и про заклинания.
А потребность обычно срочная.

- сопротивление сотрудников. Не, если у вас зарплата выше рынка, или/и руководитель жизни без git не видит, то да, иначе все плохо.

- Время на обучение не резиновое. Поэтому если есть n часов на обучение, то оно будет идти по приоритетам и есть вероятность, что git будет задвинут в конец очереди.
35. Golovanoff 45 19.09.24 11:46 Сейчас в теме
(34) Никто не может помнить все "заклинания" гита. Кроме гугла. Мне когда что-то надо нестандартное - ок, гугел, первая ссылка на стэковерфлоу, ктрл-ц ктрл-в. В подавляющем большинстве вопрос решен примерно за 30 сек.

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

Гит - это не теорема Перельмана, это едрид мадрид просто инструмент контроля версий файлов. "Давайте заложим 500ч на всё управление на обучение, ой, это же капец, денег нет, в конец очереди".
Опять сразу всплывает:
- У тебя топор тупой, заточи его, быстрее будет!
- Ой нееет, нет времени, нет денег, мне некогда, надо рубить деревья, не мешай.

Это не проблема руководства, каждый уважающий себя программист обязан в 2024 году знать гит.
36. zqzq 25 19.09.24 13:31 Сейчас в теме
(35) В дополнение, сейчас как хобби осваиваю Linux для дома, и GPT-4o mini примерно в 100 раз эффективнее рысканья по гуглу.

Лайвхак: бесплатно/без регистрации/без NPV можно использовать 4o mini через сайт поисковика duckduckgo (в меню AI Chat).
DikovSV; rozer; artbear; Golovanoff; +4 Ответить
37. Golovanoff 45 19.09.24 13:32 Сейчас в теме
17. Созинов 18.09.24 16:42 Сейчас в теме
Спасибо за статью. А где-то можно найти файлы сборки конфигурации и решения конфликтов, о которых в статье говорится?
23. Йожкин Кот 1008 19.09.24 08:01 Сейчас в теме
(17) Если конфигурация на УФ, то с такими операциями неплохо справляется EDT. Да в каких-то случаях медленно, иногда есть ошибки, но все равно лучше консоли.
Созинов; +1 Ответить
24. Golovanoff 45 19.09.24 08:13 Сейчас в теме
(17) NDA не позволяет мне просто слить весь код "автопрогона" (так у нас исторически зовется вся CI обвязка над тестами) в интернет. и скрипты у нас завязаны на эту обвязку, то есть присутствует некая "среда обитания" скриптов, завязанная на наши модули и классы.

Но вот, например, простенький скрипт, которым собирается CF для текущего состояния репозитория:
СобратьCF.os


ПараметрыРепозитория() возвращает структуру с версией платформы, путями к директориям сборки, добавленным в .gitignore, настройки пути до конфигурации 1с и т. д.
OneC.Конфигуратор() возвращает УправлениеКонфигуратором с опятьже выставленными версией платформы, каталогом сборки и т.д.
В целом смыл скрипта должен быть понятен, это же ванскрипт.

Скрипт решения конфликтов побольше, похитрее работает с гитом, выковыривая версии, и он гораздо больше завязан на наши модули и классы, поэтому не выкладываю его. Но суть его та же - создаем временную базу, грузим конфу текущей ветки, собираем cf, грузим во временную базу конфу основной ветки, запускаем конфигуратор. На ванскрипте - дело на пару часов наваять.
mikeA; Созинов; +2 Ответить
25. Созинов 19.09.24 08:15 Сейчас в теме
(24) Спасибо, направление понятно.
54. mikeA 1 23.09.24 07:52 Сейчас в теме
(24) git merge пишет конфликты в виде >>> HEAD ... === ... <<< commitid или как-то так.
Вы вырезаете то что есть перед сборкой или есть параметр merge чтобы там осталось только то что пришло?
55. Golovanoff 45 23.09.24 10:03 Сейчас в теме
(54) Нет, ничего не вырезаю. У нас сейчас политика "при наличии конфликтов решаем их в конфигураторе", поэтому автомерж гита отключен - в файл .gitattributes добавлена строчка

src/cf/**/* -merge


При ее наличии гит просто выбрасывает конфликт и свои метки в файлы конфигурации не добавляет.

Те, кто попродвинутей и используют для мержа vsc, k3diff, p4merge и т.д. - могут у себя эту настройку убрать и мержиться гитом. Или, например, убрать ее для файлов bsl. Тогда да, у них будут эти гитовые метки, но они знают, что с этими метками делать.
artbear; mikeA; +2 Ответить
56. mikeA 1 23.09.24 10:03 Сейчас в теме
(54) Я пока вижу такую схему:

merge --strategy-option ours
загрузить из файлов
hard reset
merge --strategy-option theirs
загрузить из файлов во временную базу
выгрузить в файл
сравнение/объединение
ammed latest commit

Хотя оно и через VS Code сравнивается нормально.
66. mikeA 1 02.10.24 19:12 Сейчас в теме
Попробовал merge расширения через Гит, благо задача такая как раз подвернулась. Всё прошло на удивление гладко. Правда я уже долго использую Гит но в одну сторону, в основном для версионирования обработок. В результате появилась методика и скрипт, но при всём уважении к создателям onescript всё таки на Питоне.

Методика такая:

1. Гитом объединяем всё что он может автоматически

git merge <ИмяВетки>

2. Вручную объединяем модули, которые Гит объединить не смог

git mergetool *.bsl

3. При необходимости вручную объединяем описание структуры конфигурации

git mergetool src/<ИмяФайлаКонфигурации>/Configuration.xml

4. Готовим файлы для сравнения и объединения конфигуратором

Запускаем icmerge.py в каталоге репозитория который

- Копирует в каталоги .2 и .3 файлы, которые объединились на этапах 1, 2 и 3
- Для остальных файлов копирует в эти каталоги нашу и не нашу версии соответственно
- Отменяет подготовку к помещению в репозиторий (stage)
git restore *.xml *.bsl
- Удаляет новые файлы
git clear -f -d *.xml *.bsl
- Выгружает не нашу версию конфигурации в файл в каталог .3
- Загружает нашу версию конфигурации из каталога .2 в базу разработки

5. Конфигуратором сравнение/объединение базы разработки с файлом из каталога .3

6. Выгружаем базу разработки в файл

7. git commit && git push

Строку подключения и путь к платформе скрипт берёт из файла .<ИмяФайлаКонфигурацииИлиРасширения>.icbase который надо положить рядом с файлом <ИмяФайлаКонфигурацииИлиРасширения>.cf/cfe.
Теоретически скрипт может обрабатывать несколько файлов cf/cfe, но я проверял только на одном cfe.
В gitignore лучше добавить строчку .* чтобы все эти временные каталоги и файл настроек не улетели в Гит.
Прикрепленные файлы:
icmerge.py
.ИмяФайлаКонфигурацииИлиРасширения.icbase
Golovanoff; +1 Ответить
67. yukon 151 02.10.24 19:24 Сейчас в теме
(66) Отличный пример. Мы тоже начинали с перевода хранилищ расширений в гит. Когда поднаторели и убедились, что это все работает стали переводить и доработку конфигураций в гит.

Сейчас остался только один самый сложный проект, который сейчас обслуживается 5 хранилищами. Его хотим за следующий год полностью перевести на гит.

Из описанного вами - ну чето как то сложно. У нас просто обычный гит без скриптов в процессе разработки (не ну есть заклинания для выгрузки/загрузки ERP через ibcmd). Вся автоматизация вынесена в Дженкинс - он собирает, проверяет, тестирует и публикует все что нам нужно.
mikeA; Golovanoff; +2 Ответить
30. nagaitseff 178 19.09.24 08:41 Сейчас в теме
(21) Мы который год обновляем конфигурацию исключительно через гит + у нас много кода в расширении.
Гит прекрасно справляется, особенно объединять формы с добавленными реквизитами не составляет труда.
Разработка продолжается, потом просто данные с обновленной ветки поочередно накатываются на каждую ветку релиза с решением конфликтов. Конфликты мы решаем вручную. Из всех инструментов объединения мне нравится: Beyond Compare 4, она платная, но очень мощная и постоянно обновляется.

Если кому надо, вот настройки сравнения для конфигурации.
%baseCfg %secondCfg --L1 %baseCfgTitle --L2 /title1=%secondCfgTitle
%baseCfg %secondCfg --L1 /title1=%baseCfgTitle --L2 /title2=%secondCfgTitle /mergeoutput=%merged
%secondCfg %baseCfg %oldVendorCfg --L1 /title1=%secondCfgTitle --L2 /title2=%baseCfgTitle --L3 /title3=%oldVendorCfgTitle /mergeoutput=%merged
%secondCfg %baseCfg %oldVendorCfg --L1 /title1=%secondCfgTitle --L2 /title2=%baseCfgTitle --L3 /title3=%oldVendorCfgTitle /automerge /reviewconflicts /mergeoutput=%merged 
Golovanoff; +1 Ответить
31. Segate 239 19.09.24 08:52 Сейчас в теме
(30) речь как раз о том, что гит снимает с тебя львиную часть работы по объединению.

А вот делать то же самое без Гита я не осилил...
Golovanoff; +1 Ответить
32. nagaitseff 178 19.09.24 08:55 Сейчас в теме
(31) Согласен полностью, гит рулит на все 100%. У нас когда приходят новые в команду, в начале им конечно страшно, но через пару месяцев, они сами решают конфликты слияния и выгружают все правильно.
Golovanoff; +1 Ответить
33. nagaitseff 178 19.09.24 08:56 Сейчас в теме
(32) Сейчас мы обновляем ЕРП сильно доработанную на последний релиз долгой поддержки, как раз через гит)
nvv1970; Golovanoff; +2 Ответить
51. nvv1970 20.09.24 13:11 Сейчас в теме
(33) у нас как-то обновление заняло месяц...
разработка в хранилище (потому что там и мы, и сам клиент)
занаркоманенный учет - нужно было убедиться, что вся логика при переходе на новую LTS сохранена. Аналитики руками перепроверяли учет.
Вот тут как раз обновление сбоку-припеку в отдельной от гитсинка ветке все упростило, разработка не остановилась, доработки подтягивались, все влилось обратно в хранилище...
Отличный пример индивидуального использования гита в традиционной разработке.

А уж при групповой разработке в гите - обновление вообще какое-то блаженство. Возможность обновиться на несколько разных релизов (например 2.5.17 и 2.5.19) и дать пощупать - бесценна. При этом занимает это на порядки меньше времени, чем через конфигуратор. И разработку останавливать не нужно. И задачи не обязательно завершать - номально они потом вмерживаются в новый релиз.
Йожкин Кот; Golovanoff; +2 Ответить
57. 7OH 70 24.09.24 11:46 Сейчас в теме
А смысл сравнивать ГИТ и Хранилище ?
Тут и так ясно - ЧТО лучше.
Ладно бы была возможность выбора.
А так её нет.
Конфигуратор не научили работать с ГИТом (дайте и мы будем работать с гитом на ура).
А поделие ЕДТ не умеет с хранилищем (в догонку к остальным "не умеет").
И вот если переходить к сравнению ЕДТ и Конфига - это уже отдельное обсуждение, кто что и как может и перевешивают ли плюсы основные потребности и доступное время на решение проблем.
58. kaa_ 26.09.24 10:52 Сейчас в теме
Здравствуйте! Есть тупой практический вопрос.

Когда выгружаешь конфигурацию в файлы, вместе с ней в каталог Ext выгружается конфигурация поставщика в виде cf. Я эту красоту добавил в .gitignore чтобы без танцев с бубном выгрузить свои наработки в частное хранилище на Github. Но потом, когда понадобилось загрузить конфигурацию из файлов, меня платформа послала подальше потому что нет этой cf-ки.

Как грамотно эту проблему обойти?
59. Golovanoff 45 26.09.24 10:56 Сейчас в теме
(58) Добрый день. Если вы выгружаете конфу на поддержке - она выгружается вместе с cf-ником с конфой поставщика и при загрузке это все понадобится. Если вам не нужна конфа поставщика (нам она не нужна) - нужно снять конфу с поддержки и разрабатывать себе спокойно, выгружать, загружать - cf не будет.

У нас в репозитории лежит конфа без поддержки, Cf поставки у нас формируется при сборке релиза и эта cf накатывается сопровождением на боевую базу, которая на поддержке. Но у нас совсем-совсем нетиповая конфа. Как разрабатывают люди, дорабатывающие типовые - лучше у них поспрашивать.
60. kaa_ 26.09.24 11:22 Сейчас в теме
У нас конфигурация клиента ставится на нашу поддержку. Да, мы формируем cfu сами и обновляем.

Но конкретно у нас поддержка вендора сохраняется потому что выходят обновления и мы натягиваем на них наши доработки.

Получается что имеет смысл хранить эту несчастную cf где-то и подставлять когда надо собрать конфигурацию из файлов?
61. stal76 388 29.09.24 13:07 Сейчас в теме
Если кто-то захочет изучить git, то вот отличный курс, рекомендую:
https://www.youtube.com/watch?v=W4hoc24K93E&list=PLDyvV36pndZFHXjXuwA_NywNrVQO0aQqb
Из книжек, очень хорошо все объясняется в книге: "Pro Git".
Golovanoff; +1 Ответить
62. mrSallivan 78 01.10.24 18:15 Сейчас в теме
Что при этом происходит? Сидит Серега, разрабатывает на копии. Сейчас все разрабатывают на копии, никто объекты не захватывает. Закончил, согласовывается внедрение, он берет свою CF, берет базу, подключенную к храну, захватывает объекты, объединяет изменения и вылезает красивое окошко с кучей галочек.

если разворачивают хранилище, то выгрузку СФ на копии - не используют. Смысл тогда от хранилища? =)
При подключенном хранилище - все базы для разработки - так же подключены к хранилищу. Если условный Серега ушел в отпуск и не поместил объект - можно отобрать у него объект. Да, будет потеря его работы... Но кто же виноват, что Серега нарушил регламент командной разработки и держит объекты дольше, чем нужно... или вообще забывает их отпускать.
Еще момент в пользу хранилища - его можно быстро организовать на проходном проекте. Не нужно ничего дополнительно настраивать. Кроме того, про GIT знают не все. Если компания пригласила разработчиков с того же фриланса, кто их будет учить всем хитростям? И кто будет там это все поддерживать? =)

Согласен, GIT удобен в рамках какой-то своей экосистемы. И имеет массу преимуществ. НО! Это удобно только в рамках этой самой экосистемы.
64. mikeA 1 01.10.24 22:37 Сейчас в теме
объединяет изменения и вылезает красивое окошко с кучей галочек.


Смысл в том что при обновлении через Гит фильтр "дважды изменённые" есть всегда, причём всё остальное обновляется автоматически. Это если в терминах конфигуратора.
Golovanoff; +1 Ответить
63. пользователь 01.10.24 22:36
Сообщение было скрыто модератором.
...
65. user1519152 02.10.24 07:29 Сейчас в теме
С одной стороны, автор в материале и понимает о чем пишет. Действительно, хранилище это про то, как избежать конфликтов, а гит про то, как их адекватнее решить. И, рассказывая про хранилище, пишется как плохо хранилище решает конфликты. В практической разработке корпоративного решения, когда у любого функционала есть ответственный, конфликтов удается эффективно избегать. Если в вашем сценарии не удается- ну значит хранилище это не ваше. Эти варианты не лучше и не хуже, это просто про разное. И хранилище при корпоративной разработке при условии что у каждого кода есть ответственный- отличный выбор.
Просто не надо строгать пилой и пилить рубанком и все ок будет))
triviumfan; +1 Ответить
68. moolex 914 07.10.24 05:02 Сейчас в теме
Есть ещё одно решение:
Расширение 'Внешний регламент'
- самый простой способ поддерживать и доработывать множество баз на единой конфигурации.
69. triviumfan 96 07.10.24 09:13 Сейчас в теме
70. moolex 914 08.10.24 18:27 Сейчас в теме
(69) расширение 'Внешний регламент' опубликовано на этом сайте, там всё подробно расписано.
Оставьте свое сообщение