Как организовать gitflow?

#1

Добрый день!
Пытаюсь запустить разработку через git.
Понял, что чего-то не понял. Прошу помощи.
И так:

  1. Есть два разработчика Р1 и Р2.
  2. Р1 создает проект в Гит в ./
  3. Р1 создает папку ./db и папку ./hran.
  4. Р1 в папке ./db создает подпапку с пустой базой Б1. Создает подпапку для хранилища в ./hran.
  5. Р1 привязывает Б1 к хранилищу в подпапке ./hran/ - Х1.
  6. Р1 выводит папки с базами и хранилищами 1С из под контроля git т.к. это бинарники.
  7. Р1 создает в папке проекта подпапку ./cf и через gitsync export выгружает в нее свое хранилище с пустой базой.
  8. Р2 делает git pull и вытягивает папку ./cf
    1. Р2 собирает из папки ./cf хранилище Х2 и привязанную к хранилищу 1С базу Б2.
  10. Теперь каждого разработчика есть база Б1 у Р1 и Б2 у Р2 и у каждого разработчика есть хранилище 1С - Х1 у Р1 и Х2 у Р2. Базы Б1 и Б2 связаны с соотв. хранилищами.

До этого момента вроде бы все ясно. Дальше:

  1. Р1 делает справочник СПР1 у себя в Б1 и отправляет в Х1.
  2. Р2 делает справочник СПР2 у себя в Б2 и отправляет в Х2.
  3. Р1 запускает gitsync и отправляет свое хранилище 1С в папку git проекта - ./cf
  4. Р2 запускает gitsync и отправляет свое хранилище 1С в папку git проекта - ./cf
  5. Разработчики пушат свои версии ./cf и затягивают изменения в ./cf
    Как им получить изменения в свои рабочие базы? Р1 и Р2 должны содержать по два справочника. Что для этого нужно сделать?
#2

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

#3

Как раз от единого хранилища 1С хотелось бы уйти. Т.е. Р1 и Р2 работают без хранилища? И разбирают для отправки в ./cf свои базы? Чтобы получить изменения из хранилища git нужно собрать из исходников новую базу? А собственно почему бы не оставить все как есть. Просто при необходимости получить изменения из хранилища гит нужно собрать и новую базу и новое хранилище.

#4

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

#5

Все равно непонятно. Ок - пусть будет без хранилища. Р1 и Р2 сделали себе по отдельной ветке в хранилище гита. Добавили по справочнику. Как им теперь обменяться изменениями?
Делаю gitsync и ./cf папку отправляю в хранилище git. В двух ветках разные версии содержимого папки. Как теперь слить изменения? Делаю mердж реквест с веткой master. Первый мердж проходит успешно. Второй мердж реквест говорит, что есть конфликты. Ок - объединяю вручную. Ииииии получаю треш - выживет один :)) http://take.ms/Y7h4J
Что мешает гиту объединить автоматом? Что не так делаю?

#6

Git всегда при двойных изменениях в одном файле оставляет этот файл на ручное объединение. Для ручного объединения можно воспользоваться например Kdiff3.
Еще раз обращаю внимание, что при объединении xml файлов конфигурации вероятность сборки конфигурации обратно в cf где-то 50% :-).
Чтобы гарантированно обменяться изменениями, нужно взять 2 cf-ника, объединить их средствами конфигуратора и отдать результат разработчикам, чтобы они залили его себе.

#7

Похоже 50% это довольно оптимистичная оценка - врукопашную хмлками жонглировать…
Итого, отказываемся от хранилища 1С чтобы вручную объединять CFники? И в чем выигрыш? И какая польза от git?

#8

Ну отказываться от хранилища я пока варианта не вижу.
Git нужен:

  1. Быстро посмотреть изменения
  2. Хранить сопутствующие отчеты, обработки и прочие файлики
  3. Когда перейдем на EDT :slight_smile:

А аналог git-flow вполне возможен и с использованием хранилищ (1С сами так и делают)
1С при наличии конфигурации поставщика делает автоматическую расстановку галочек для объединения даже лучше чем git. Беда с 3-х сторонним сравнением произвольных конфигураций, но такое есть уже в EDT.

1 Симпатия
#9

Гитфло от 1С (без гита) https://its.1c.ru/db/v8std#content:-2145782938:hdoc:_top:стандарты%20разработки%20разветвленная

Фичебранч это “Технический проект”

1 Симпатия
#10

На СППР посмотрел первым делом. Для теста создать проект не получилось - ошибка в проверках на форме (ну или я не догнал как пользоваться хотя делал по инструкции). Плюс нет интеграции с ванессой и от этого полезность инструмента /2. Может PRmex что то стоящее там сделает. Пока это не более чем прототип. Который сам по себе нужно пилить и пилить.

1 Симпатия
#11

Спасибо, что помог разобраться :slight_smile:

#12

Git нужен много для чего:

  • статический анализ кода, например, через наш плагин для Сонара
  • кучи инструментов для код-ревью
  • blame
  • трекеры и связь задач с кодом
  • много для чего еще
#13

Мы в СППР прикрутили и гит и загрузку задач с редмайна и всё это завязали друг с другом:

image
image.png581×775 35 KB

При разборе помещение сразу связывается с задачами
Есть кнопочка GitHub, которая ведет на одноименный портал по конкретно этому коммиту
Связывание с типовым справочником СППР ОбъектыМетаданных - можно сразу видеть кто, когда, зачем и по каким задачам его правил объект.
Объекты Метаданных разбираются почти штатными средствам СППР

Дальнейшие планы - прикрутить сюда же результаты тестирования (пишем очередной вело-дженкинс :wink: )

3 Симпатий
#14

Женя, настала пора приехать на ИЕ докладчиком (наверное, теперь уже на следующий) :slight_smile: