Сейчас в своей работе использую ГИТ и меня все устраивает (В конфигураторе выгрузить/загрузить конфигурацию в файлы, потом GitGUI). Если учесть, что у меня еще есть не-1С разработки, то и выбора то у меня особо нет.

Тем не менее интересна тема про 1С-хранилище конфигурации.

Ребята, кто работал и с тем и с тем, поделитесь мнением... Я правильно понимаю, что и смотреть в сторону Хранилища не стоит? И вообще, голосуем!

Git - в интеренте?

если да - то вот он и ответ...

их даже сравнивать нельзя. отставание лет на 20.

Хранилище удобно только тем,что оно встроено в конфигуратор.
В остальном,там даже сравнение изменений нормального нет.

Гит, конечно, крут. Но смотреть надо в целом на процесс. Сколько занимает времени выложить свои изменения в хранилище с учётом выгрузить конфигурацию в файл? Особенно если смотреть на какую-нибудь ЕРП. Сколько занимает времени получить изменения из хранилища в свою конфигурацию с учетом загрузки конфигурации из файлов? Для хранилища конфигурации секунды/минуты. А для GIT? Если долго, может ли это быть фоновым процессом, не мешающим работе?
Я гитом не пользовался для 1С поэтому и спрашиваю. Подозреваю, что время серьёзное. Как вы это делаете? Запускаете в нерабочее время?

(0) Скажите, коли пользуетесь ГИТом, как с ним конфигуратор работает? С хранилищем мне понятно. Пришла заявка от пользователя, определил нужный объект конфигурации, парой кликов мыша захватил в хранилище, внес правки, протестировал, так же парой кликов выложил изменения в хранилище. Заявка может закрыться за десять минут. А как с ГИТом происходит?

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

(6) У меня выгрузка ЕРП занимает 20-30 минут. При этом на 100% нагружает одно ядро процессора и, подозреваю, нехило грузит диск сохранением 100500 мелких файлов. Что уже не полезно в случае работы нескольких разработчиков на одном терминальном сервере.
>> какое-то время тому назад завезли оптимизацию
С учетом того, что свежие релизы ядра входят в моду далеко не сразу, когда еще дождёмся этой оптимизации :(

интересно а на гите можно скачать все Все ваши конфы?

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

Вроде умельцы как-то запилили гит для интарсети, но это надо парится поднимать его и т.д.

как вообще он работает с 1с?

(4) По времени сравнимо с выгрузкой/загрузкой из cf. Оптимизация действительно есть, один раз выгрузил - во второй раз выгрузятся только изменения. загружается всегда одинаково. В случае разности версий платформ бывабают изменения формата. Я делаю коммит с комментарием "обновление платформы". Ничего страшного. Но в целом Рразрабатываю строго на той платформе, что крутится в продакшене.

Больше всего мне нравится система ветвлений: Одна заявка - одна ветка, с номером заявки в названии (уже понятно, что исправлял и зачем). Если вдруг я оказываюсь в "творческом поиске" и мне нужны эксперименты - ветка от ветки. Потом мерж, если творчество увенчалось успехом)

А вот если мне в течении моего творческого поиска прилетает срочная заявка, да еще и затрагивающая уже исправленные объекты: Делаю ветвление от Мастера (ветви GIT соответствующей тому что крутится в продакшене), переключаюсь на неё уже там правлю. Потом мержи в свои девелоперские ветки.

(8) GIT - это не гитхаб и не гитлаб. Гит-репозиторий можно поднять на своем сервере. Использовать только на своей рабочей станции и можно оплатить приватный репозиторий на гитхабе или гитлабе. Они тогда про них никому не расскажут.

для GPL и прочие открытые лицензии они разрешают держать репозитории бесплатно. Поэтому там и хостятся большинство opensource проектов.

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

Не правда

>Вроде умельцы как-то запилили гит для интарсети, но это надо парится поднимать его и т.д.
не сложно, для админа средней руки.

тут есть все ответы
https://git-scm.com/book/ru/v2

(7)
>Что уже не полезно в случае работы нескольких разработчиков на одном терминальном сервере.
Из рабочей базы не нужно выгружать. Один раз выгрузил, создал репозиторий, склонировал его себе на рабочую станцию. Потом коммит в репозиторий на РС и из него пуш в основной репозиторий.

Чтобы обновить конфу, делаешь "Загрузить конфигурацию из файлов"

Если через гит объект одновременно правили 20 разрабов, как он сольется в одно целое?

Если уф, то однозначно EDT и Git

Да

(13) по студенческом опыту разработки QGIS могу сказать: объединяет он превосходно. А если уж и проиходит конфликт слияний, то лучше о нем узнать до коммента (гит не даст сделать коммит, запросит ручное объединение. Но у меня такого небыло. Но я разрабочик один)

(5) Эта система работает прекрасно, до тех пор пока у вас "заявки" на один-два часа и пару объектов. Как только у Вас проект, на проект на 10 объектов и человеко-неделю (плюс "заявки"). Становится сложнее.

(17) у меня в хранилище активно работают 2...3 человека, при чем у меня бывают задачи довольно объемные (даже на неделю) с захватом несколько десятков объектов (остальные в это время решают мелкие задачи), как с таким режимом справится гит ?

(18) Одна ветка на проект и по ветке на мелкие задачи. Задачи закрываются быстрее, изменения попадают в основную ветку.
Ведующий проекта потягивает изменения из основной ветки (уже протестированные и утвержденные) в свой проект по мере необходимости или по регламенту, раз в день, например.

Если не меняли "его объекты", то проблем 0 - займет 30секунд. Если меняли и изменения нужные и важные, то так и так подтягивать их нужно.

Гит нужен только там где он действительно нужен.
Для микроразработок он избыточен. А это основная масса всего что происходит в 1с.
А так схема - работаем в хранилище, но потом грузим в гит для всех его фишек и CI - вполне рабочая штука.
Требуется дисциплина при большом количестве разработчиков, но это решаемо.

Не знаю, как в хранилище. Но в ГИТЕ у каждого разработчика скорее всего будет своя ИБ для целей разработки. Если ИБ очень большие и нет эталонной маленькой - то, это может быть проблемой.

Поправьте меня, если я не прав.

(20) Скажу так. Сейчас на огромном проекте 100+ разрабов. Выработалась дисциплина и уже очень редко вопли - отдайте корень.
Я не знаю какие были бы доп затраты если такую прорву народа с разным уровнем компетенций в гит загнать.

(20) жить без него не могу. Каждый плагин для сайта на 100 строк кода, держу в отдельном репозитории)

(21) Как не изворачивайся - 1 конфиг на ИБ.
Хочешь того или нет - это не обойдешь

(23) Да не вопрос.
Штука то хорошая, тут вопросов нет.
Другой вопрос, что хранилище хорошо своей монолитностью и кондовостью, это же его и слабость

Я за оба инструмента.
Жаль такого пункта нет

(22) для "100+  разрабов" должен быть свой отдел автоматизации, который интегрирует 1c8<->SVN<->Project management system  -bug tracking system .

чтобы не было неандертальского "Выработалась дисциплина".

Ну,вместо git можно взять любой cvs и commit выгруженные файлы конфигурации туда или reload обратно.
Понятно,что cvs умеет очень много всего полезного и делает это быстро.
Но,куча разных ветвей в реализации потом всегда выдазят проблемами при объединении,и вины системы тут нет-из одного места можно поехать в разные,и только взаимоблокировка не пускает в такие опасные путешествия,а взаимоблокировку умеет только хранилище.

(28) про взаимо блокировку - не знаю , а блокировку git , svn и  Mercurial умеют  делать.

(27) А кто сказал что этого нет?
Просто заводить Гит ради Гит, когда у тебя десятки подрядчиков разного уровня компетенций - ну такое.
Хранилище - стандарт в отрасли, и уже сложно найти того кто не умеет.

(30) меня бы взял на работу, если я с ГИТом на ты?

(31) Гипотетически.
Если гит это единственное что ты умеешь, то нет)

(27) вот тут согласен. Там еще и тестеры должны быть, которые задачи обратно возвращают... и как все уживаются у меня много вопросов. Но интерес, праздный. Ибо я уже нашел способ как самим с собой уживаться.

(32) что уж так-то(

(33) Потому что гит это технология, которая обсосана как только можно. В принципе если человек пишет код, то за разумное время он ей овладеет.
И в экосистеме 1С в списке того что должен уметь кандидат где то там в конце.

(25) Поддержу.

(30) система контроля версий в разработке по - это целый мир. а хранилище на его фоне - жалкая подачка Нуралиевых.
если не контролировать уровень компетенций - никакая дисциплина не поможет.

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

(20)
> А так схема - работаем в хранилище, но потом грузим в гит для всех его фишек и CI - вполне рабочая штука

Расшифруйте аббревиатуру CI, пожалуйста?

(37)
трансформация кода в программу- много этапный процесс. и на каждом этапе - своё хранилище. в рамках хранилища 1с8 подобная трансформация затруднительна или невозможна.

вследствие этого затруднительно специализация (разработка тестирование сборка). также затруднен контроль изменений.

если бы Ничего плохого в хранилище не было , то в edt не нужно было бы делать выгрузки.Ничего плохого в хранилище нет, если кроме хранилища ничего нет.

(39) у него там много всего, читай (20). Он просто людей в ГИТ не пускает, у него есть аргументы.

(38) Continuous Integration

Знаю по крайней мере два сучая, когда гит не взлетел в командах на несколько десятков разработчиков, а ХР прекрасно шуршит

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

Если команда работает с хранилищем то тебе никто не даст работать с ГИТ-ом. Либо всей команде переходить на него либо тебе на хранилище.

(39) тестирование отдельных веток - дело вредное, тестирование нужно всех изменений (что-бы не нарваться "к пуговицам притензии есть?")

у хранилища есть минусы
1. самый главный минус - это проблемы когда объект сырой но его надо отдать соседу,
2. нет сравнения форм
3. нет сравнения компоновки
4. убогое сравнение прав

остальное - идеально

как я понимаю п. 2,3,4 в ГИТ тоже нет в адекватном виде?

(39) по поводу многоэтапности трансформации кода - это вред, чем меньше трансформаций тем меньше будет ошибок.

В этом плане хранилище дает 100 очков фору гит-у

ну и кстати видел такую реализацию (хотя сам ей не пользуюсь)

Хранилище 1 - для разработчиков подсистемы 1
Хранилище 2 - для разработчиков подсистемы 2
.....

Хранилище ТЕСТ - в него через объединение сливают релизы и на нем тестируют, только после этого готовую версию выпускают в виде обновления для продукта, и в обратку по Х1 и Х2

данная схема позволяет не путать отделам свои доработки от чужих (по тому как чужие накатываются только скопом при выпуске релиза из теста) и позволяет хранить историю выпуска релизов отдельно от доработок.

(43) в виде xml сравнит

(46) >>>в виде xml сравнит

это называется адекватный вид? попробуй сравни макет с компоновкой данных:)

(43)если в хранилище нет совсем сравнения, управляемых форм или есть, но неадекватное?

(48) А что, в гите обычные формы сравниваются адекватно?

(48)Нет совсем и есть две большие разницы.
Я спросил про УФ

гит и хранилище это инструмент версионирования а не сравнения
сравнивает кдифф или другой инструмент (конфигуратор, едт)

(4) Для хранилища конфигурации секунды/минуты. А для GIT?

Для хранилища секунды минуты, а для гита - определяется скоростью интернета. Ну или сети, если гит сервер свой. Если бы в Гит выкладывали "минутами", то с ним бы никто не работал.
Сравнение вообше неуместно.

(52) "для гита - определяется скоростью интернета"
А что, кто-то запрещает использовать локальный гит-сервер? Обязательно всё отдавать микрософту? О_о

(53) ну я про свой гит сервер написал. У чувака проблема - там работа с хранилищем "выкладывание" измеряется минутами. Поэтому я и написал про "скорость интернета". Вдруг они на модемах 32К работают. Переедут на Гит и скажут что фигню посоветовали, медленно все )))
Вообще не понимаю, если конфа на УФ, да если еще и пилят ее больше 1го человека - нафига использовать эти технологии прошлого века (хранилище). Фигачишь в ЕДТ и радуешься.

(54) "Фигачишь в ЕДТ и радуешься."
У меня кулер сгорел от такой радости...

(52) ничего там скоростью Интернета не определяется. Гит распределённая система, связь нужна только когда делаешь pull или push и по сетке бегают только изменения. В остальном у тебя есть локальная копия нескольких веток.

Подозреваю, что с распределенностью у Хранилища никак.

(57) https://memepedia.ru/wp-content/uploads/2016/09/1393992931__.png

(56) речь пуш была. Если у него модем 32к и файлик несколько метров, придется таки несколько секунд подождать для пуша.

(55) ЕДТ не для слабонервных кулеров, эт да

лапы, крылья... главное хвост! (то есть мозг, если он есть то пофиг на чем работать, если нет - то же пофиг)

Я для себя, кое что из этой ветки взял. Всем спасибо.

(52) >> для гита - определяется скоростью интернета
Все же полезно читать вопрос полностью, а не отвечать на вырванную из контекста фразу.
Я спрашивал "с учётом выгрузки/загрузки конфигурацию в файл". А это явно не интернет и не секунды.
1С работает с монолитной конфигурацией в базе данных, а не набором выгруженных файлов. Гит работает с файлами, а не конфигурацией. Значит возникает промежуточный этап, тяжелый и по времени и по ресурсам сервера, обязательный при почти каждой операции в гите.
Поэтому, мне кажется, что разным командам разное. Если тебе надо разрабатывать большую подсистему, которую ты через недельку запушишь, тебе гит хорош. Если надо фигачить заявки пользователей, где "захватить объект, внести изменения, протестировать, поместить в хранилище" отлично укладывается до обеда, тебе хранилище доступно, легко и удобно как старые тапки.

Сферы деятельности разные. Так что для своей ниши то конечно хранилище

А для своей ниши то ГИТ

(0) Даже не смотри в сторону хранилища, потому что зачем?
Смотри в сторону https://edt.1c.ru/, там нативная работа с гитом

(66) О да.
Видел я возмущения некого товарища Глеб Стальной на партнерке, что как нам жить - закупаем мощные машины разработчикам, а все равно медленно.

(67) Причем в этом году)

(67) Во-первых, это вопрос времени
Во-вторых, наверное именно поэтому мы постепенно переходим на EDT, ага
В-третьих, это все одно неизбежно, так чего уж там

(69) + мы не закупаем технику, мы арендуем сервера
Из техники закупаются только ноуты разработчикам, на которых сотрудник заходит в удаленный сервер через RDP

Мыши плакали, кололись, но продолжали использовать хранилище...
Плюс была настроена выгрузка в гит, но она пару месяцев назад сломалась)

(66) Обычные формы там не работают, поэтому отпадает.

Кто-нибудь ответьте на (5). Я бы с удовольствием перешел на гит.

Схема работы с хранилищем как в (5):
>Пришла заявка от пользователя, определил нужный объект конфигурации, парой кликов мыша захватил в хранилище, внес правки, протестировал, так же парой кликов выложил изменения в хранилище.

Так-то можно было вообще все в текстовые файлы выгружать и молниеносно править через какой-нить notepad+, а потом уж обратно загружать
Но никто же не отказывается от конфигуратора, потому что он медленнее notepad+

(69) То что это неизбежно, это факт.
То что это временно это тоже факт, но прогресс идет слишком медленно, увы.
(70) Там была обозначена в теме совершенно другая позиция, я не знаю кому верить, по этому не верю Вам обоим)
Тема на партнерке есть, кому надо - найдут.

(71) Про (5) Эээ..., никак не работает, нет там такого

(73) Ну, если хочешь найти истину, обозначь тему
Не хочешь, не обозначай, че, у нас свободная страна
Я говорю как есть
Причем жизнь не стоит на месте, многое меняется

(74) Что? Как предполагается использовать гит согласно (0)?

1. В тестовой базе делаем правки
2. Выгружаем конфу в файлы
3. ???
4. Коммит?
5. ???
6. Загружаем конфу из файлов

?


Кстати, в EDT расширения есть?
Я даже отказался от Visual Studio в пользу vscode, когда попробовал https://www.tabnine.com/

(76) Эээ... не, ну через огромную задницу с выгрузкой/загрузкой конечно же можно, но кто же будет так делать?
В EDT да, есть я же написал https://edt.1c.ru/, почитай

Концепция немного другая. В других средах разработки, проект это набор файлов, которые компилятся сборщиком. У 1С это один файл с закрытой информационной структурой.
Нужен парсер, который будет разбирать конфу на части и кидать в гит, а потом при получении собирать. И тогда будет удобно.

(78) Рукалицо
Какой один файл?
Кто говорит про cf?
Речь про текстовые файлы, в которые выгружается конфа
Так что парсер встроен в конфигуратор
Только он как бы ничего не дает, потому что неудобно же шо пипец
Поэтому EDT с нативной работой с гитом

(77) Видимо, кто-то делает.

Расширения - это хорошо, но пару лет назад я таки пробовал EDT - обычные формы выдали тучу ошибок, и я благополучно забыл про EDT.
Ситуация как-нибудь изменилась?

ОФ не планируются в EDT
Гит тоже их не переваривает. Они считай бинарник.

(78) выгрузить конфигурацию в файлы / загрузить конфигурацию из файлов.

Удобно если конфа не большая

(82) Не, я про сравнение. В cf файле же не поймешь, что менялось. Сейчас качну ее.
(79) Кстати под аккаунтом разработчика(с купленой версией клиентской и серверной) я не могу EDT скачать. Вот это действительно рука лицо.

(83) https://edt.1c.ru/faq/, вопрос "Порядок распространения и поддержки"

+(84) Платформу тоже почему-то не скачаешь, если у тебя нет ИТС, внезапно, да?

(85) И ты считаешь это корректным, что разработчик не может скачать платформу?

(86) LOL
Да, почему бы нет?
Почему 1С обязана давать тебе обновления бесплатно, раз ты не оплачиваешь ИТС?
Удивительное дело, когда такая же схема с другими IDE, то никто не видит в этом ничего странного, но как только речь зашла про родную 1С, то сразу опа, а почему не на халяву?

+(87) Странный ты разработчик, если у тебя нет тысячи в месяц с мелочью на абонплату за пользование продуктом, с помощью которого ты зарабатываешь на жизнь

У меня тут жена как-то в свое время с собрания в детском саду пришла, сказала, что стали собирать по три тысячи на год на нужды группы (карандаши всякие, платилин и пр.), так один мужик сказал, что он в принципе не против, но он бизнесмен и у него сейчас, внимание!, все деньги в бизнесе, нет возможности вынуть
Жалко меня там не было, я бы точно посоветовал бизнесмену закрыть к епеням такой свой бизнес и устроиться на нормальную работу хотя бы дворником что ли

(89) Это еще что. Есть бизнесмены которые жалуются что налоги им видите ли большие. А они между прочим меньше 50% оборотов, совсем охренели нищеброды. Если не могут 50% государству отдать нахрена вообще бизнесом заниматься.

(87) Ну практически любую ИДЕ я могу скачать для личного пользования вообще без ограничений или с триалом.

(90) Брякалка, ну вот ты-то куда лезешь со своими нравоучениями?
Я же не про проценты, я про 250 рублей в месяц на собственного ребенка
Один раз в сраном Маке сраный бургер не купить
Заметь, я ничего не сказал бы, если бы, например, человек работал дворником и едва бы сводил концы с концами
Понятно, что кому-то даже в Москве 3000 даже пусть в год — довольно тяжело
Но, блеать, мужик _одновременнно_ корячит пальцы, что он бизнесмен и тут же жалуется, что 3000 нет, все в бизнесе
Уверен, он даже не понял всей комедии и трагедии ситуации

(92) заседания жилищных ТС куда веселее в этом плане. Или когда люди строят дома за несколько сотен тысяч долларов и на асфальт пару тысяч долларов не могут скинуться.

Но на самом деле есть такая штука как cutting cost бизнесы. Смысл которых резать все даже самые мелкие затраты и тем самым получать конкурентное преимущество. Страшная вещь на самом деле работать с такими, но таких бизнесов достаточно много. Причем как правило в самых богатых (где очень высокая конкуренция) и в самых бедных (где низкая платежеспособность) экономиках.

Хотя да, к вашему примеру это имеет опосредованное отношение.

(93) Мда, видимо очень хотелось хоть что-нибудь ляпнуть, а по делу ничего не нашлось

(88) Рома, если 1С хочет привлечь молодых разработчиков, то ей не то, что бесплатный доступ к платформе надо давать. А доплачивать желающим пройти курсы. Сдал на проф и спеца, вот тебе сумма.

(95) Роме этого не объяснить. Это просто за гранью. Для лица, добровольно увешанного сертификатами  со всех сторон - это точно за гранью.

(92) Ты все затраты распределяешь на год?

Хранилище - кондовое (в хорошем смысле). Пока оно "не жмет" - все хорошо. Плюс если не хватает возможностей/скорости для анализа - есть готовые инструменты, позволяющие зеркалить хранилище в гит-репозиторий.
Вопрос к гитоводам, восторгающихся бранчеванием - как вы СУБД бранчуете? :)

Вот вопрос конкретно к (9). Как выглядит процесс "А вот если мне в течении моего творческого поиска прилетает срочная заявка, да еще и затрагивающая уже исправленные объекты: Делаю ветвление от Мастера (ветви GIT соответствующей тому что крутится в продакшене), переключаюсь на неё уже там правлю. Потом мержи в свои девелоперские ветки".
А в "творческом" бранче уже куча изменений структуры БД и тестовые данные. На каждый бранч - по копии БД?

В (9) описана ситуация с EDT? С конфигуратором что-нибудь подобно вообще возможно? Если да, то поправьте меня в (76) плз

Пока хранилище, т.к. еще иногда актуальны ОФ.

Лично мне переход на git мне кажется вполне оправданным, если хранилище начало сильно "жать".
А вот переход на EDT - гораздо более спорный момент. Время сборки - существенный минус для языка, где большинство ошибок ловится только в рантайме.

(99) Под проект - делаю отдельную ИБ. Под задачи - нет.

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

(103) Просто этот момент почему-то гитоводы всегда опускают, когда взахлеб про бранчи рассказывают. Бранч налево, бранч направо - воздушная легкость! А бранчи не такие уж и "легкие". Хотя, безусловно, возможность очень полезная и удобная. Просто разработчику минимум две базы придется иметь. Ну да невелика проблема.

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

(104) Да есть такое дело. Нам от того не легче, но ведь и разработчики сайтов испытывают теже сложности. Ведь у сайта тоже есть БД.

1

(95) Предложи Нуралиеву, че

(96) Эээ... кто увешан сертификатами?
У меня, например, только по семерке замшелых годов и пара профов по восьмерке

(97) Надо было с родителей каждый месяц по 250 рублей собирать?

(106) не путай сайт в котором пусть 100 файлов (имею в виду код, без картинок) и 1с в котором примерно 1.5 ляма строк кода в типовой бухии, а в ЕРП около 3х лямов строк кода, и количество модулей измеряется не десятками и даже наверно не сотнями....

я не говорю, что ГИТ плохо, нет, я говорю, что когда говорят "я легко отпачкую себе хоть целиком все", но надо понимать сколько это "все" весит для сайта и 1с, там и объемы и скорости разные.

по этому я огромным сомнением читаю Ваши восторженные возгласы...

к примеру представь продакш базу ЕРП которая абсолютно пустая весит далеко за 2 гига, то есть с минимум данных для тестирования это примерно от 5 до 10 гиг. В реальности это от 20 до 100 гигов, у тебя 5 компаний, вот представь по две копии базы у себя на ноуте от каждой компании, да еще и репозитарий, и место для темпов... То есть 2 терабайта на ноуте уже мало..... а ведь без SSD не обойдешся с EDT.

А теперь вопрос - сколько стоит ноут который это потянет?

(111)

Для приложения с 10^10 строк кода с GIT-ом "я легко отпачкую себе хоть целиком все" не поменяется никак.

Вы хоть почитайте, что такое GIT, "программисты". GIT не "отпачкую всё" работает.

(111) Согласен с Вашими возражениями. Я вас услышал.

Необходимость копий ИБ - проблема. Причем она не только в технической плоскости, но и в плоскости безопасности. Сливать несколько веток в общий знаменатель - наверное проблема.

В моей же идеальной вселенной есть эталонная полнофункциональная ИБ маленького размера (для разрабов и подрядчиков), а полноразмерная копия БД нужна для поиска/устранения проблем с производительностью и финального тестирования. В реальном мире все не так.

Гит придумали для того чтобы "Почковать" миллионы строк кода.

(111) Ну вообще то git был создан Линусом для сопровождения разработки ядра линкуса и успешно с этим справляется, а там больше 10 млн.строк кода.

Никакие миллионы строк не "почкуются". Есть текущий HEAD и метки на тех файлах, которые были изменены.
Весь мир, в тч на самых огромных проектах использует git. И только одинэсники считают свой дебет-кредит слишком уникальным для этого.

(111) ну вообще базы можно держать на обычном винте. И почему обязательно ноут? Мощный стационарник + дешманский ноут для RDP.

И вообще, при чем тут базы? Это уникальное ьребование гита? Без него вы их не используете?

Судя по обсуждению, для подпихивания своих изменений в рабочую базу, в случае GITа нужны телодвижения по загрузке конфы. В случае хранилища, там ничего такого делать не надо. хранилище-обновить конфу из хранилища и в путь. Откатиться на более старую версию - тоже никаких проблем, в случае протоколирования изменений, совместно с багтреккером - вся разработка становится ясной и понятной. Единственный минус для меня - ненадежность хранения БД хранилища в файловом варианте. А серверный доступен только при использования одинаковых версий платформ. Но если юэкапить папку с хранилищем, то,в общем-то,риск потерять хранилку болИе-Лимение ) минимизирован.
В случае групповой разработки, при использовании ГИТ не вижу никаких плюшек по сравнению с хранилкой.
Но тема интересная, безусловно.

(118) А как вы протоколируете изменения? В Хранилище есть для этого инструменты? А то в Интернетиках пишут, что коментарии кода ставят.

(118) Какие еще телодвижения по загрузке?
В случае гита у тебя есть локальный каталог src (это конфа разобранная на файлы по модулям, формам и пр) и есть база со свое конфой. ЕДТ умеет собирать из файлов конфу и накатывать ее на твою базу.
База вообще не в курсе ни про хранилище, ни про гит.
Гит в отличие от хранилища
- собирает только изменения (хранилище же копит какую то тьму tmp файликов, видимо это "отпечатки" конфы, поэтому тяжелое и монстроузное)
- поэтому в гите быстро переключаться между ветками и коммитами
- посмотреть изменения в коммите или разницу между ними можно мгновенно
- откатить свои изменения на версию коммита можно мгновенно
- вернуться на версию последнего коммита можно не только файлом целиком. В редакторе видны участки кода, которые были изменены. Можно прямо здесь посмотреть - что же мы поменяли конкретно в этой функции и как этот участок кода выглядел до наших изменений.
- можно посмотреть кто, когда, во сколько и каким коммитом внес конкретные изменения в конкретную функцию до этого. А если гит связан с трекером - перейти к задаче, которая вызвала эти изменения.
- если вы делаете какую-то задачу и тут нужно срочно поправить баг и вернуться к задаче, можно сделать stash, а потом восстановиться из него - тоже мгновенно
- в гит пушить изменения своей ветки можно хоть каждую минуту чтобы зафиксировать проверенные изменения и продолжить. Запилили, проверили, зафиксили, переходим дальше. Закончили ветку, отдали в тест. В хранилище же как правило попадают только протестированные изменения (т.к. в противном случае нужно второе хранилище "production"), поэтому фиксирование изменений уже не управляется желанием разрабочика.
- при использовании гита цикл разработка-тестирование-внедрение изменений становится непрерывным. Можно пилить новый релиз и править только баги в старом. При этом исправления багов одним движением руки приезжают в релиз, который еще пилится.
- чтобы отдать на тест заказчику, достаточно  скинуть ему ссылку или хэш коммита. При использовании хранилища - нужно выгружать конфигурацию (мы ведь не отдаем протестированные изменения в тест, правильно?)
- на гите легко навешиваются хуки и организовывается автоматизированное тестирование
- НО САМОЕ ГЛАВНОЕ - в гите нет этой долбанной блокировки объектов. Один и тот же модуль или форма может правиться несколькими разработчиками одновременно. Если правились разные куски кода, все мержится без проблем. В противном случае последнему пушеру придется решить конфликт. Но возникает это крайне редко и делается максимально просто.

Короче сравнение вообще неуместно.

(118) "В случае групповой разработки, при использовании ГИТ не вижу никаких плюшек по сравнению с хранилкой."
Улыбнуло... Вы попробуйте ГИТ на несколько человек. Втянетесь, раскурите плюшки и скажете что "хранилка" это вообще не средство для групповой разработки. Версионирование "в одного" еще может быть норм, если только что перешел с 7.7, то даже будет вау эффект )))

(119) В смысле, "как вы протоколируете изменения"? Хранилище все же какая-никакая, но VCS. Другое дело что инструментарий ревизий версий в сравнении с гитом ограниченный и тормознутый. Поэтому одна из "промежуточных" практик - зеркалировать коммиты из хранилища в гит. Фишка в том, что доля "настоящих команд" в общей массе разработки на 1С невелика. Средняя команда на среднем продукте в 1С - полтора разработчика :) Поэтому большинство вполне нормально на хранилище и живут. Даже если несколько разрабов, но каждый тянет "свой кусок" - то тоже вполне терпимо. Просто нет особой необходимости в более продвинутых инструментах.

(121) "хранилка" это вообще не средство для групповой разработки."
CSV в своё время была вполне себе групповой. И даже RCS.

Здравствуйте. А как вы захватываете объекты в GIT-е? Например мне надо захватить корень метаданных, но не рекурсивно (добавлять объекты), или захватить Модуль документа, а формы не захватывать.

EDT не проходит, потому что УПП, там почти все на обычных формах.

(124) В гите объекты не захватываются. Они мержатся по результату

(119) на текущий момент, в багтреккере есть номера задач. Изменения в коде помечаются ФИО разраба и номером задачи, по поводу которой изменен код. При выкладивании, разраб пишет в комменте номер задачи, по поводу которой он изменяет хранилку. Все. можно посмотреть, для чего была изменена любая строчка кода, выделенная комментом разраба.
(120) я вообще не спорю. Тема  весьма интересная (и новая пока что, для меня). Поэтому могу говорить только о хранилке.
(122) у нас по 8-9 человек на 1 базу. ГИТ интересен, имеет смысл рассмотреть, как замену, или дополнение к хранилке.
Да, действительно, сравнение версий это что-то с чем-то. Поставил на сравнение и ушел курить...

(124) Никак. В распределенных VSC другая модель работы. Правь что угодно. От слова абсолютно. Это как оптимистические блокировки против пессимистических. В результате может получиться лажа, но на практике это происходит очень редко. Тогда последний кто вливает свои изменения и попадает на конфликт - должен его разрулить вручную. Но так как "фракция" для конфликтов гораздо мельче уровня объекта, то и вероятность конфликтов гораздо ниже.

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

1с и так глючная.

(130) не глючная, а сырая

Зачем лишние телодвижения?

(127) " Изменения в коде помечаются ФИО разраба и номером задачи, по поводу которой изменен код. "
В том то и дело, что гит это умеет и так. Если нужно привязаться к номеру задачи - при коммите указываем его. А если трекер интегрировать с гитом - можно прямо из задачи в трекере проваливаться в список изменений кода, которые были сделаны по этой задаче.

Используем Хранилище 1C -> git -> bitbucket
Синхронизация через gitsync.
Разработчики по факту работают только с хранилищем 1с.

(134) "Разработчики по факту работают только с хранилищем 1с."
Тогда нафейхоа гит?

(135) Изменения удобно смотреть.

(134) У нас такая же схема. Плюс еще внешние и произвольные отчеты раньше выгружались.

(135) SonarQube, Vanessa. В Jira видим комментарии по каким задачам внесены изменения. И как отметили в (136) удобно иногда просто посмотреть нет ли говнокода :)

(134) Проблем с gitsync не было? Я когда-то пытался перенести хранилище с немаленькой историей и на очередном коммите он сказал что не в силах... Да и кто-то еще отписывался по похожей фигне. Работал-работал, а потом устал.

(134) >>Разработчики по факту работают только с хранилищем 1с.
Эээ... чего?
А как я тогда свои изменения в Битбакете вижу?

(138) При настройке иногда проблемы возникают. (авторизация с bitbucket, локальные настройки git, глючная версия git). Но если все настроено и работает, то работает без проблем.
Если много версий и не нужна вся история, можно сразу с какой нибудь крайней версии выгружать.

(139) В зависимости от проекта у меня выгружается раз в час или раз в сутки. Под разработчиками я имел в виду только разработчиков в нашей компании.
А как настроено у вас не знаю.

заводите локальный хранилище git-репозиториев. например:
https://gogs.io/
и льете туда 1С и не 1С. у нас так сделано.
100+ сообщений в теме. вы серьезно?

(141) А, пардон, я почему-то подумал, что это про опыт использования EDT и про то, что он не с гитом работает, а с каким-то своим гитом
Не, у нас натурально EDT с гитом, Битбакет, Дженкинс, Сонаркуб и пр. https://www.youtube.com/watch?v=Aiel8HlZrwM