Как писать понятные коммиты

06.03.19

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

Как писать сообщения коммитов так, чтобы потом не было мучительно больно.

Использование git для 1с.

В своей работе я часто использую git для контроля версий продукта. Очень много времени и статей уделяется различным практикам работы с git: как именовать ветки, какое ветвление использовать, merge или rebase… Но мало внимания уделяют сообщениям коммитов. А ведь это основа – история разработки. Отсутствие соглашений о сообщениях затрудняет совместную работу.

 

Эволюция сообщений коммита.

Сначала коммиты у нас  были вот такими:

Как видно, понять, что было сделано, зачем, на что это может повлиять – практически невозможно. Разбор полетов занимает много времени.

Потом чуть-чуть подумали, договорились. Стало лучше.

Более подробное описание и ссылка на задачу.

Но на просторах github встречались такие коммиты

И описания для контрибьютеров.

Такие правила называются «Conventional Commits».

 

Conventional Commits

Подробно описано вот здесь https://www.conventionalcommits.org/ru/v1.0.0-beta.2/

Коротко: каждое сообщение коммита должно содержать:

  • указание на тип доработки;
  • опциально указать изменяемую область;
  • краткое описание коммита;
  • опциально подробное описание;
  • опциально номер решаемой задачи.

По такой истории сообщений можно автоматически генерировать CHANGELOG, для этого есть много библиотек. В том числе на OScript https://github.com/oscript-library/changelog-generate

 

Проблемы

Идея отличная. Проблема только в следовании схеме. Конечно, какие блоки использовать и как писать указано в документации к репозиторию. Но иногда забывается что именно писать. В одно проекте договорились писать feat, в другом feature; в каждом проекте свои блоки. Поэтому решили поискать пути автоматизации.

Commitizen

Нашелся классный пакет для node-js - commitizen. Он использует дополнительный пакет cz- customizable для вызова удобной формы ввода сообщения. А настройки соглашений хранит прямо в репозитории.

 

Установка и настройка

На компьютере должен быть установлен Node-js и npm. Через npm устанавливаем два пакета

npm install -g commitizen
npm install -g cz- customizable

Теперь надо сделать пару простых настроек.

Настроить package.

В корне репозитория добавляем файл package.json со следующим содержимым

{
	"config": {
		"commitizen": {
			"path": "cz-customizable"
		},
		"cz-customizable": {
			"config": "tools/js/commitizen.js"
		}
	},
	"devDependencies": {
		"cz-customizable": "^5.3.0"
	}
}

 

В папке tools создаем файл commitizen.js,  в котором описываем настройки договоренностей. Например, так:

"use strict";

module.exports = {
  // Добавим описание на русском языке ко всем типам
  types: [
    { value: "feature", name: "feature:   Добавление нового функционала" },
    { value: "fix", name: "fix:       Исправление ошибок" },
    { value: "docs", name: "docs:      Обновление документации" },
    { value: "test", name: "test:      Добавление тестов" },
    {
      value: "refactor",
      name:
        "refactor:  Правки кода без исправления ошибок или добавления новых функций"
    },
    {
      value: "perf",
      name: "perf:      Изменения направленные на улучшение производительности"
    },
    {
      value: "style",
      name:
        "style:     Правки по кодстайлу (табы, отступы, точки, запятые и т.д.)"
    },
    {
      value: "build",
      name: "build:     Сборка проекта или изменения внешних зависимостей"
    },
    { value: "ci", name: "ci:        Настройка CI и работа со скриптами" },
    { value: "revert", name: "revert:    Откат на предыдущие коммиты" }
  ],

  // Область. Она характеризует фрагмент кода, которую затронули изменения
  scopes: [
    { name: "Кэш" },
    { name: "ФормаОсновная" },
    { name: "Валидация" },
    { name: "АвтоматическоеТестирование"},
    { name: "Отчеты" },
    { name: "ПервыйЗапуск" },
    { name: "ЗащитаМодуля" },
    { name: "ТребованияКПроизводительности" },
    { name: "ХранениеДанных" },
    { name: "API" }
  ],

  // Возможность задать спец ОБЛАСТЬ для определенного типа коммита (пример для 'fix')
  /*
  scopeOverrides: {
    fix: [
      {name: 'style'},
      {name: 'e2eTest'},
      {name: 'unitTest'}
    ]
  },
  */

  // Поменяем дефолтные вопросы
  messages: {
    type: "Какие изменения вы вносите?",
    scope: "\nВыберите ОБЛАСТЬ, которую вы изменили (опционально):",
    // Спросим если allowCustomScopes в true
    customScope: "Укажите свою ОБЛАСТЬ:",
    subject: "Напишите КОРОТКОЕ описание:\n",
    body:
      'Напишите ПОДРОБНОЕ описание (опционально). Используйте "|" для новой строки:\n',
    breaking: "Список BREAKING CHANGES (опционально):\n",
    footer:
      "Место для мета данных (тикетов, ссылок и остального). Например: SECRETMRKT-700, SECRETMRKT-800:\n",
    confirmCommit: "Вас устраивает получившийся коммит?"
  },

  // Разрешим собственную ОБЛАСТЬ
  allowCustomScopes: true,

  // Запрет на Breaking Changes
  allowBreakingChanges: false,

  // Префикс для нижнего колонтитула
  footerPrefix: "YT:",

  // limit subject length
  subjectLimit: 72
};

В блоке types описываем префиксы изменений: feature, fix и т.д.

В блоке scope описываем блоки, с которыми будем работать. Есть возможность оставить пустым или указать собственный блок.

В поле footerPrefix можно задать префикс для системы учета задач.

В subjectLimit задается ограничение на длину короткого коммита. Часто звучит ограничение, что описание должно содержать глагол в повелительном наклонении, но у меня ни разу не получилось так написать.

При установке cz-customizable создается alias для гита: git cz. Индексируем изменения и выполним команду. Тогда откроется окно для ввода описания:

После выбор типа изменений:

Если нужна своя область

Описание коммита

Указываем номер задачи

В конце будет показан итоговый вид сообщения коммита. Можно отказаться или отредактировать.

Соглашаемся и смотрим что получилось.

Лайфхаки

Пара лайфхаков, которые я используются в работе.

Автодокументация

Мы создали документацию проекта на markdown. Разбили ее на значимые блоки. Добавили commit-msg hook(действие в гит, после изменения сообщения коммита) – сообщение коммита добавляется в историю изменений конкретного блока.

Smartgit

Перешли с SourceTree на SmartGIT. Главной киллфичей являлось то, что на дополнительные действия можно назначать хоткеи. Я добавил себе привычную комбинацию Ctrl-Shift-C и быстро вызываю окно для ввода сообщения коммита.

После всего недели использования, я уже не мог понять – как раньше жил без такого удобного инструмента. Более того, даже если в проекте не настроен commitizen, я руками завожу аналогичное вида сообщение.

Удачных всем коммитов.

Коммит git commitizen

См. также

Системы контроля версий для 1С-разработчиков.

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

Основы командной разработки на 1С. Использование систем контроля версий при разработке на платформе 1С:Предприятие 8

4900 руб.

29.06.2022    9142    78    4    

110

Особенности национального Workflow: Github Actions и OneScript

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

Сегодня мы посмотрим на Github Actions - встроенный инструментарий Github для автоматизации рабочих процессов. Разберем, что это такое, зачем и причем тут OneScript.

25.03.2024    1176    bayselonarrend    3    

35

Автоматизация процесса разработки с помощью сервиса GitFlic

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

GitFlic – первая в России полностью самостоятельная реализация сервиса для хранения репозиториев с исходным кодом. За три года разработки сервис GitFlic стал полноценным инструментом, которым можно заменить GitLab, GitHub и BitBucket. Расскажем о том, как выстроить в GitFlic процесс автоматического тестирования, статического анализа кода и сборки приложений.

05.03.2024    1866    user1989937    6    

15

OpenYellow - рейтинг открытых GitHub репозиториев для платформы 1С:Предприятие

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

Обновляемый топ GitHub репозиториев для 1С по всем языкам программирования и еще немного рассуждений про open-source.

05.02.2024    3780    bayselonarrend    15    

61

Насколько глубок 1С-ный GitHub?

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

Open-source проекты - важная часть мира программного обеспечения. 1С привычно держится немного в стороне от глобальных трендов, но бросить холодный статистический взгляд на положение дел мне показалось небезынтересным.

22.01.2024    7841    bayselonarrend    50    

86

TCP прокси-сервер хранилища конфигурации 1С

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

Продолжение истории с прокси хранилища, но уже не на HTTP, а на TCP и без падений по памяти веб-сервера. Проверяем комментарии хранилища, вызываем веб-хуки, старты пайплайнов, gitsync по событию помещения версии в хранилище. И все это полностью на знакомом и понятном OneScript.

17.01.2024    2772    kamisov    17    

57

Отдай корень! Библиотека OneScript для получения информации о захваченных объектах в хранилище

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

Хранилище конфигурации 1С - это инструмент групповой разработки. Работают с хранилищем следующим образом: захватывают какой-либо объект, редактируют, потом отдают его в хранилище. Хранилище помечает уже захваченные объекты и не дает возможности захватить их другим пользователям. Это рождает и самый большой недостаток хранилища - невозможность работы с одним объектом нескольких пользователей, например в случае доработки разных методов в одном большом модуле. Корень конфигурации - это самый верхний ее узел. Только захватив корень, мы можем добавить в конфигурацию новые общие модули, документы, справочники, регистры и подобное. Только захватив корень можно изменить настройки поддержки конфигурации. Соответственно, если корень захвачен одним программистом, другой программист не может добавить новые объекты или снять что-то с поддержки. Потому то и всплывает эта фраза - отдай корень, мне нужно тоже что-то добавить.

26.12.2023    1336    ardn    1    

26

Git Code Review - инструмент для рецензирования кода

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Конфигурации 1cv8 1С:ERP Управление предприятием 2 Абонемент ($m)

Git Code Review - инструмент, позволяющий быстро анализировать изменения из git-репозитория прямо в 1С

1 стартмани

20.12.2023    3958    59    salexdv    26    

81
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. infosoft-v 871 06.03.19 08:42 Сейчас в теме
Спасибо за подробное описание удобного инструмента.

ps. В последнем подкасте Радио-Т в темах слушателей обсуждался именно этот вопрос. Выводы к которому пришли ведущие: "не так важнО описание коммита как атомарность содержимого коммита" Посыл такой: по дифам можно понять кто и что сделал в интересах какой задачи но для этого коммит должен содержать только изменения конкретной задачи. Плохая практика, по мнению ведущих, решить задачу и поправить еще что то, не относящееся к задаче в одном коммите.
starik-2005; alur; gradi; shalimski; supermacho; +5 1 Ответить
2. Scorpion4eg 424 06.03.19 09:08 Сейчас в теме
(1)
Плохая практика, по мнению ведущих, решить задачу и поправить еще что то, не относящееся к задаче в одном коммите.

Согласен.
Для себя давно выработал стратегию коммитов:
1. Или закончил функционал.
2. Или сделанные изменения возможно придется откатить.

Но все равно бывает что-то да подмахну) Особенно когда видишь что вот этот кусок надо исправить. И чтобы не выходить из контекста - приходится исправлять.

Была бы возможность работать только в исходниках - нет проблем. Сделал прямо сейчас отдельную ветку, исправил то, что попалось на глаза. А дальше черрипикнул в рабочую ветку и дальше пилить фичу. Но с 1с пока такой трюк не проходит. У нас, по крайней мере.
3. ArchLord42 83 06.03.19 10:44 Сейчас в теме
(2)
Но с 1с пока такой трюк не проходит. У нас, по крайней мере.


а Вы как с гитом работаете?
У нас такой подход вполне себе работает :)
4. Scorpion4eg 424 06.03.19 11:19 Сейчас в теме
(3) Разработка внешних обработок. Используем precommit1c на oscript.
7. ArchLord42 83 06.03.19 13:25 Сейчас в теме
(4) Ну так черрипикнул, пересобрал обработку и дальше поехал, время на сброку обработки то минимально.
8. Scorpion4eg 424 06.03.19 13:53 Сейчас в теме
(7) Да. Если не работать с ОФ. А при работе с ОФ, каждая форма эта конфликт. И форм в проекте бывает от много до слишком много.
9. ArchLord42 83 06.03.19 13:54 Сейчас в теме
(8) С ОФ тут конечно печаль беда, не спорю)
5. Vladimir Litvinenko 2869 06.03.19 11:57 Сейчас в теме
Сделал прямо сейчас отдельную ветку, исправил то, что попалось на глаза. А дальше черрипикнул в рабочую ветку и дальше пилить фичу. Но с 1с пока такой трюк не проходит.

а Вы как с гитом работаете?
У нас такой подход вполне себе работает :)


(3) А как Вы с гитом работаете? ))
Если через конфигуратор, то не поделитесь последовательностью шагов при начале и завершении работы над фичей?

В частности интересны такие вопросы:

1) Обеспечивается ли как-то блокировка одних и тех же форм/макетов для изменения двумя разработчиками одновременно?
Если обеспечивается, то как?
Если не обеспечивается, то как мерджите формы и макеты?

2) Ведёте ли параллельно работу с хранилищем или только через гит?

3) Обеспечивается ли как-то блокировка корня конфигурации от одновременного добавления объектов в двух разных ветках?
Если да, то как?
Если нет, то как в этом случае мерджите в master/develop две ветки, одновременно изменившие корень?

4) Встречали ли проблемы с тем, что при выгрузке-загрузке конфигурации из репозитория меняются идентификаторы объектов метаданных?

5) Ведётся ли работа на конфигурации, основанной на типовой и находящейся на поддержке исходного поставщика?
Если да, то как организовали работу в этом случае? Все объекты сняты с замка? Как обеспечиваете обновление на новый релиз поставщика?
6. ArchLord42 83 06.03.19 13:18 Сейчас в теме
(5)

1) Блокировки нет, ну и таких ситуаций не возникает, т.к. у нас 2 разработчика менять 1 форму \ макет не могут не могут в один день.

Инструмент называется JIRA)) Просто не ставим примерно одни и теже задачи разным разработчикам, если что-то надо поменять на форме условных контрагентов, то делать это будет 1 человек, либо 2, но в разные дни.

2) У нас чисто 1С + GIT без хранилища, сидим 14 месяцев на такой конфигурации.

3) Корень так же не блокируется, но в отличии от пункта 1. изменения корня могут быть произведены несколькими разработчиками, но тут есть нюанс, мержить такой конфликт очень легко (1 кнопка "принять оба изменения" или как то так в VSC), с условием, что МД не сортируются самими разработчиками, сортировка идет (пока что) тим лидом (мной), но планирую сделать автоматически при релизе.

4) до 11 платформы было пару раз, но с нее уже остались только косяки, аля прыгающее свойство туда сюда <UserAlways=true\false> на не измененных формах, сейчас сидим на 13 платформе, в целом вообще все косяки по выгрузке пропали и все выгружается адекватно

5) У нас отраслевая конфа, но на поддержке, допилы идут следующим образом: новые МД в основную конфу, доработка "типового" кода \ мд через расширение, все на замке, кроме некоторых МД, которые отредактировать через расширение невозможно, но они все проброшены в расширение для контроля после обновления.
Пример МД: Определяемые типы, через расширение изменить состав нельзя, определяемый тип снимается с замка, добавляется тип, и перекидывается в расширение, там тип становится "произвольный" и не контролируется, тогда мы берем и прописываем по новой все типы в расширении и после обновы, если затерлось изменение, то расширение сразу же об этом сообщит при попытки примененения.
Так же если надо добавить новый реквизит, снимаем с замка только "корень" мд, справочника например, формы на замке, а реквизиты можно добавлять, ну и опять же в расширение они перекидываются для контроля.

В целом обновление происходит очень быстро, если код не надо править, галкой "дважды измененные" фильтруем все проблемные МД, пробегаем глазами, ничего чтобы не потерялось, особенно проверяем предопределенные элементы :), и сравнением объединением накатываем обновление от вендора.

Свои обновления готовит jenkins из репозитория, поставку не делаем, тут все по хардкору, он готовит cf \ cfe, а мы их прям загружаем в прод. :)
Но это если были обновлены правила поддержки МД, либо сравнением объединением, если типовые МД тронуты небыли.
Раньше тупо загружали cfник, но это дольше по времени, а так если видно, что тронуто ничего небыло, то проще через сравнение сделать.
По началу офк боялись накатывать прям загрузкой CFника в прод, но у нас как раз был переход между программами и поломка БД бы пожара не вызвала, собственно на этом этапе подтвердилась надежность такой процедуры, проблем небыло ниразу, за исключением того, что пропал 1 раз весь интерфейс программы после обновления (всегда обновляем монопольно) тупо пустое окно после запуска 1С, но помог банальный ребут сервера, странно было то, что ребут службы никак не помогал.

Ну а сам рабочий процесс такой:

1) Утром мы апдейтимся с апстрима (У всех форки + главный репо.)

2) Пилим фичи по гит флоу.

3) К концу дня прилетает N количество ПРов

4) Я делаю ревью, мержу, если на какой то итерации принятия ПРа происходит конфликт, то либо сам разраб. решает конфликт, либо я сам в его ветке это делаю (они дают мне доступ к своему форку), обычно конфликтов нету, либо они "1 кнопочные", т.к. задачи по интерфейсу разделаяются с учетом особенностей мержа XML форм, то их в принципе нет, а BSL довольно просто мержить.

5) Собственно мы по домам Jenkins садится за работу, тестит, собирает.

6) Следующим утром я встаю, ставлю сравнение объединение или загрузку конфы, кушаю и тд, потом подрую блокировку базы, обновляю и дальше по своим делам)

7) Обновляю свой репозиторий.

далее свою конфу (пункт 1) и все повторяется

Взаимодействие с гитом происходит через oscript, своя "нетленка", которая по настройкам собирает проект, cf \ cfe \ epf \ erf и тд. и кладет в папку build условную, а в source tree просто пользовательские команды на выгрузку \ загрузку + кнопочка git flow
KapasMordorov; Vladimir Litvinenko; +2 Ответить
10. Vladimir Litvinenko 2869 06.03.19 15:27 Сейчас в теме
(6) Большое спасибо за развёрнутый ответ. Звучит классно и действительно как применимый на практике процесс. Даже пул-реквесты в процесс разработки включили! Это наверняка требует умения и желания работать с git каждого разработчика.

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

Позвольте ещё один вопрос. Вы работаете с одним репозиторием, в котором исходники конфигурации и расширения разнесены по отдельным каталогам, или с двумя отдельными репозитоиями, отдельно для конфигурации и отдельно для расширения? Не принципиально конечно, но всё же интересно. Кажется, что при отказе от хранилища подход с одним репозиторием был бы удобнее.
13. ArchLord42 83 06.03.19 17:03 Сейчас в теме
(10)

Это наверняка требует умения и желания работать с git каждого разработчика.


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

К тому же город у нас не крупный и скажем так не всегда можно найти квалифицированного разработчика, за которым не надо следить, а ревью кода можно делать уже постфактум, когда доработка попала в хранилище, либо постоянно залезать в чужие конфигурации, так же прием с несколькими хранилищами который продвигало 1С в статьях на ИТС очень не понравился, особенно когда работал с другими ЯП и знал что вот есть GIT и с ним работать довольно комфортно и там куча плюшек вместе с ним приходит.

А разрабы кстати не особо восприняли такую идею, довольно сложно иногда тру 1Снику объяснить про все эти CI \ GITы \ тесты и тд, но за несколько скайп конференций я донес до них полезность перехода на GIT, особенно все в восторге о того, что не надо писать \ идти \ звонить другому разрабу с просьбой "осободи мне МД Х и Y"

Кстати Валерий вроде из BIA tech выступал на последней инфоконфе, вот его история почти как у нас, только размеры команд разные, даже порог входа ~7 дней, про которые он говорил у нас повторяются.

ЗЫ. Спасибо за статьи по Ванессе, мы как раз через ваши статьи сейчас основы тестирования до разрабов доносим)


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


да у нас "монорепозиторий", и конфа и расширения и обработки все по разным папкам лежит
Vladimir Litvinenko; +1 Ответить
14. Sherzod1984 11.03.19 17:19 Сейчас в теме
(10) Добрый день! Владимир Литвиненко, как можно с вами связаться?
21. zlakizla 62 21.05.19 18:25 Сейчас в теме
(6) Спасибо за статью и пояснения! Есть небольшой вопрос по рабочему процессу, поясните пожалуйста:
1) Чтобы перейти из пункта 2 в пункт 3 пользуетесь стандартной выгрузкой конфигурации в файлы? А дальше уже коммит этих файлов и ПР?
2) При выполнении пункта 1 делаете апдейт своей локальной ветки из удаленного репозитория, а потом изменения как попадают в конфигурацию? Так же загрузкой конфигурации из файлов?
22. ArchLord42 83 22.05.19 03:06 Сейчас в теме
(21) Не за что, только статья не моя)

Да, синхронизация GIT <> конфа происходит, через выгрузку \ загрузку XML, по факту это делается не из самого конфигуратора (да и загрузить из конфигуратора мы не сможем ибо конфа на поддержке), а скриптами из source tree.
Отсюда и особенности процесса, что обновляем из апстрима по утрам, т.к. операция долгая довольно и по мимо сборки и загрузки CF еще делается бэкап текущего состояния конфы, т.к. некоторые люди у нас (в том числе и я) забывали выгрузить изменения и затирали кучу работы пару раз :)
Ну и уже ребята со скиллом и пониманием гита, делают несколько фич сразу (если они небольшие), а потом раскидывают нужное по коммитам, т.к. выгрузка бывает тоже не быстрой, особенно когда еще не создан ConfigDumpInfo (он удаляется после загрузки конфы из гита, и в целом находится в гитигноре), ну либо сразу правят исходники через VS Code
24. zlakizla 62 22.05.19 05:39 Сейчас в теме
(22) Спасибо за пояснения. Правильно понимаю, что запускаете скрипт из sourcetree, который обновляет файлы локального репозитория из удаленного, затем из этих файлов собирает cf, и далее этот cf натягивается на конфигурацию разработчика? Предварительно делая бэкап конфигурации разработчика.
25. ArchLord42 83 22.05.19 07:49 Сейчас в теме
(24) да, все так :)

скрипт банальный что то типа

git fetch upstream && git rebase upstream/develop && git push --force && oscript tools/git/main.os -update
26. for_sale 971 16.06.19 09:25 Сейчас в теме
(6)
Жесть! А можете подсказать, в чём преимущество такого подхода по сравнению со стандартным хранилищем? Если честно, после того как поработал с гит в 1С и после вашего описания пока впечатление "гит ради гита". Не проще сделать хранилище 1С, программистам работать с хранилищем, потом для дженкинсов и прочих авторабот выгружать уже в файлы и дальше по сценарию? В результате - программисты работают с нормальным хранилищем, не нужны никакие договорённости, не нужен специально обученный человек для мёрджей и прочего контроля, не нужно решать кучу проблем на уровне неприспособленности платформы (прыгающие свойства, идентификаторы и т.п., не факт, что в новой платформе не прилетит чего-то нового-интересного).
27. ArchLord42 83 16.06.19 12:02 Сейчас в теме
(26) мы перешли ради код ревью и блейма, хотя блейм в через гитсинк можно получить с хранилищем. Но вот код ревью - нет, плюс блокировки МД достали, а возня с несколькими хранилищами вызвала дикое отторжение, т.к. некоторые кейсы вот вообще не как не воспроизвести.
Например когда 2 разраба, пилят фичи, которые потом нужны другому, через гит это решается банальным черри пиком, с хранилищами уже не как. Писать можно много, главное скажу, что наши разрабы не страдают, все банально просто, не сложнее понимания работы с хранилищем, а для продвинутых разрабов открываются большие возможности и это для нас жирный "+".

ЗЫ Воркфлоу может и жестью показаться, но он довольно простой.

неприспособленности платформы (прыгающие свойства, идентификаторы и т.п., не факт, что в новой платформе не прилетит чего-то нового-интересного).


это не баг, а фича, это касается ConfigDumpInfo, а он актуален только для конкретного состояния ИБ и должен быть в гитигноре, какой нибуть node_modules тоже всегда в гитигноре, не кто ж не ноет, что там что-то меняется))

В целом с 10 платформы уже все довольно стабильно, очень редко всплывают баги
28. for_sale 971 16.06.19 13:19 Сейчас в теме
(27)
блокировки МД достали

В каком смысле? У вас два программиста одну форму параллельно пилят??

Хотя нет, вот же вы пишите:
1) Блокировки нет, ну и таких ситуаций не возникает, т.к. у нас 2 разработчика менять 1 форму \ макет не могут не могут в один день.


О каких блокировках вы говорите?

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

Я ездил на отдых в ОАЭ, страну из топ 3 самого дорогого интернета в мире, поэтому работать через удалённый рабстол было невозможно. Соответственно, точно также, сделал гит-хранилище, выгружал туда изменения, загружал на битбакет, забирал локально, работал, потом в обратную сторону. Трафик я, конечно, сэкономил, цель была достигнута, не пришлось выгружать-загружать каждый раз гиговый цф. Но в остальном я проклял гит, 1С и всех адептов гита в 1С. Потому что выгрузка конфы в файлы занимает Ж = "жесть сколько времени", гит статус, гит адд, гит коммит занимают каждый по Ж времени (на каждой стороне!), на принимающей стороне должна быть развёрнута отдельная база, которая загружается (за Ж времени) из файлов, потом оттуда выгружается цф и объединяется с целевой базой на той стороне. Да, кстати, на моей стороне тоже была отдельная база для заливки из файлов, потому что тоже на поддержке.

И эффективность всего этого алгоритма - Ж большое! Прям огромное. Поэтому для работы с гитом вместо хранилища должны быть реальные основания. У вас, насколько я понимаю, примерно такое же Ж времени уходит на все танцы с гитом. При этом система - "все работают в хранилище 1С, кодревью происходит при заливке в рабочую" - просто таки в разы быстрее. Да, для всяких дженкинсов надо в файлы, но это можно действительно ночью без пользователя делать. А в работе программиста - я, если честно, так и не понял, какой выигрыш вы получили?
29. ArchLord42 83 17.06.19 06:48 Сейчас в теме
(28)

причём в удобном, разработанном для 1С виде, а не в текстовых файлах или, упаси боже, в консоли.


в VS code довольно удобный интерфейс для мержа, формы конечно никак не помержишь цивильным способом, но код очень легко.

В каком смысле? У вас два программиста одну форму параллельно пилят??


Формы офк нет, а модули, особенно в период активной разработки часто пересекались

(28)
Потому что выгрузка конфы в файлы занимает Ж = "жесть сколько времени", гит статус, гит адд, гит коммит занимают


выгрузка от 30 сек до 5 мин занимает, в замисимости от актуальности ConfigDumpInfo, а вот на счет статуса \ адд \ коммита, я хз как так у вас выходит, там что постоянно овермного файлов у вас при выгрузке чтоле?)
Просто все это занимает довольно мало времени измеряемое секундами, да и чего там вычислять, когда обычно ~2-5 файлов затронуто, при среднестатической задачи

У вас, насколько я понимаю, примерно такое же Ж времени уходит на все танцы с гитом.


у разраба уходит минут 10-15 утром на синхронизацию с главным репо, и пара минут на выгрузку задачи каждой и создания ПРа, так что я не скажу что это много времени)

Опять же размеры конфы имеют значение. Я без понятия как там с ERP дела будут, у нас конфа уровня БП по размеру и все довольно быстро происходит.

А в работе программиста - я, если честно, так и не понял, какой выигрыш вы получили?


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

Еще не так давно привязка конкретных задач к написанному коду + блейм очень помогли найти виновника и исправить довольно хитрый баг который случайно прошел в прод.

ЗЫ. Я думаю ваши возгорания были от того, что в вашей ситуации небыло верного иструментария, ибо наши движухи с гито приведены к 1 команде в сурс три.

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

"Выгрузить проект в файлы" - выгружает весь проект epf\erf\cf\cfe в файлы, с умным кешем обработок, для того, чтобы неизмененные epf\erf не грузить заного
"Загрузить" - загружает из гита весь проект, загружает так же только измененные части проекта

а внутри них там уже магия через oscript идет и коненому разрабу не надо тратить кучу времени именно на работу с гитом, все делает наша поделка.

Спецом глянул сейчас, наша дока по синхронизации с гит и выгрузкой в него, занимает 6 скринов и около 10 строк текста, все остальное автоматизировано)
30. for_sale 971 17.06.19 09:47 Сейчас в теме
(29)
Вы бы статью написали с вашим случаем, с картинками, командами, инструментарием и т.п. Я думаю, не только мне было бы интересно. Потому что я сейчас с гитом работаю только по внешним обработкам, по полной конфе (это была БП!) было Ж большое. Сейчас уже точно не вспомню, но очень приблизительно половина цикла (перенести из одной базы изменения в другую) занимало от получаса до полутора. Т.е. я утром запускал этот процесс, и также занимался своими делами, ходил на завтрак и т.п. Так вот, кто-то из команды вдруг что-то критичное менял и выкладывал в течение дня, мне было проще или код с экрана у себя переписать, или из выгрузки выдернуть файлы, которые изменены и через файловой хостинг перекинуть к себе.
31. ArchLord42 83 17.06.19 17:41 Сейчас в теме
(26) думал об этом не раз, ибо подобный разбор полётов веду не первый раз, наверное в ближайшем будущем сделаю это уже)
32. for_sale 971 17.06.19 18:16 Сейчас в теме
(31)
Буду ждать, потому что сам бы хотел применить в некоторых местах гит, но пока что этот печальный опыт не особо обнадёживает.
11. azhilichev 213 06.03.19 15:43 Сейчас в теме
По следам статьи из блога Яндекса на Хабре :) Провели эксперимент с использованием этого подхода в комментариях к коммитам. Оправдал себя. Теперь внедряем во всей команде.
12. Scorpion4eg 424 06.03.19 16:15 Сейчас в теме
(11)
По следам статьи из блога Яндекса на Хабре

Да, хотелось добавить личного опыта. Потому что ребята из Яндекса очень не любят им делиться.
"По всем рекомендациям надо сделать так" - а как делают сами, редко пишут.
15. metmetmet 81 16.03.19 11:57 Сейчас в теме
Добрый день, подскажите, пожалуйста, совет, рекомендацию, личный опыт при разработке с использованием git и precommit1c.
Например, ведется разработка внешней обработки, относительно последнего коммита были внесены изменения, но вдруг разработчика отвлекают, и он переключается на другую задачу. Когда он возвращается к свой первоначальной разработке, было бы удобно с помощью любимого приложения (sourcetree и т.д.) посмотреть внесенные изменения относительно последнего коммита. Я понимаю, что можно вручную запустить precommit1c и увидеть необходимый результат. Но очень хочется, чтобы не приходилось выполнять ручных операций.
Также очень хочется до помещения коммита видеть различия для дополнительного контроля помещаемых изменений, а precommit1c разбирает обработку на исходники, только при помещении коммита в репозиторий.
У кого какие практики?
16. Scorpion4eg 424 16.03.19 17:58 Сейчас в теме
(15) Для начала - с какими формами работаете: ОФ или УФ?
Если УФ то вполне можно работать с исходниками (Файл-Сохранить как-Внешняя обработка в XML формате). Тогда все изменения будут отражены сразу в читаемом виде. Ну или работать в EDT.
Если ОФ - то пока без альтернатив.
Как делаю сам. Если не закоммитил изменения и не помню что это - делаю коммит! )) Только надо отучится от практики - коммит и пуш. Тогда можно отменить ненужные изменения.
Дальше. В sourcetree есть механизм CustomAction - можно добавлять свои скрипты. Так проще вызывать разбор файла, чем лезть в консоль каждый раз.
Я перешел с SourceTree на SmartGit. В SmartGit на Custom actions можно установить комбинации клавиш. В ближайшем будущем есть желание перейти на работу только с исходниками.
Поработал, вызвал скрипт разбора, зафиксировал то что нужно. После смены ветки - вызвал скрипт сборки.
17. metmetmet 81 16.03.19 21:01 Сейчас в теме
(16) Спасибо за развернутый ответ. Разработка на УФ. CustomAction - неплохой вариант, и думаю потихоньку можно уже двигаться в сторону EDT.
18. Scorpion4eg 424 16.03.19 22:27 Сейчас в теме
(17)у меня было дикое отторжение от edt. Но поставил 10 версию, действительно хорошо оптимизирована. Заставил себя неделю поработать и привык, есть много интересных фишек, которых теперь недостает в конфигураторе
19. metmetmet 81 17.03.19 21:32 Сейчас в теме
(18)Вот ещё один вопрос, который меня мучает: при разработке внешней обработке хранить в репозитории саму обработку или хранить только ее стабильные версии как релизы?
С одной стороны во всех репозиториях программ на других языках, которые я видел, нет бинарных файлов, они прикладываются как релизы. Но с другой стороны, гораздо удобнее в каждом коммите уже иметь готовую для использования обработку.
20. Scorpion4eg 424 17.03.19 22:04 Сейчас в теме
(19) Пока храним обработки во всех коммитах. За 2500 коммитов размер репозитория вырос до 1,5 Гб. Но мы работаем и с ОФ.
В ближайших планах перейти на хранение только кодов. Ничто не мешает пересобирать обработку после смены ветки. Или можете хук на checkout повесить, чтобы сразу собирал
23. ArchLord42 83 22.05.19 03:09 Сейчас в теме
(20) Хук скорее перебором будет, особенно если надо просто перейти на ветку для каких-то действий относящихся к гиту непосредственно, обработки и так собираются довольно быстро, так же можно сделать проверку хешей файлов, на предмет того, что обработку надо действительно пересобрать, мы в общем то так и сделали, работает отлично)
34. for_sale 971 17.06.19 18:25 Сейчас в теме
(20), (23) - я думаю, вам можно написать статью (или цикл) с полным разбором от "Что такое гит" до "Хуки-блеймы-полный цикл". И рейтинга наберёте, и денег с инфостарта срубите, и карму поднимите)
33. for_sale 971 17.06.19 18:22 Сейчас в теме
(19)
Всегда же можно откатиться и собрать из файлов. Для получения готовой обработки определённой версии всё равно нужно откатиться, так что действия всё равно одни и те же (пару кликов добавляется), а размер страдает очень сильно.

Мы раньше хранили в двух хранилищах отдельно - в одном обработка, в другой её выгрузка. В результате выгрузка занимает копейки, а хранилище с обработкой пухнет. В результате первое забросили, только выгрузку храним. Надо будет получить историческую версию - откатимся, сделаем.
35. yaroslavkravets 24 01.10.19 09:42 Сейчас в теме
Интересный инструмент, но работает только в консоли виндовс. В git bash виделение цветом не происходит, но выбор стрелками происходит. Это только у меня так?
Оставьте свое сообщение