Скажу пару слов, откуда взялась идея этого доклада. В 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.
