0. Scorpion4eg 255 05.03.19 20:39 Сейчас в теме

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

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

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. infosoft-v 323 06.03.19 08:42 Сейчас в теме
Спасибо за подробное описание удобного инструмента.

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

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

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

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


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

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


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

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

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

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

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

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

5) Ведётся ли работа на конфигурации, основанной на типовой и находящейся на поддержке исходного поставщика?
Если да, то как организовали работу в этом случае? Все объекты сняты с замка? Как обеспечиваете обновление на новый релиз поставщика?
6. ArchLord42 68 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 1824 06.03.19 15:27 Сейчас в теме
(6) Большое спасибо за развёрнутый ответ. Звучит классно и действительно как применимый на практике процесс. Даже пул-реквесты в процесс разработки включили! Это наверняка требует умения и желания работать с git каждого разработчика.

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

Позвольте ещё один вопрос. Вы работаете с одним репозиторием, в котором исходники конфигурации и расширения разнесены по отдельным каталогам, или с двумя отдельными репозитоиями, отдельно для конфигурации и отдельно для расширения? Не принципиально конечно, но всё же интересно. Кажется, что при отказе от хранилища подход с одним репозиторием был бы удобнее.
13. ArchLord42 68 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 58 21.05.19 18:25 Сейчас в теме
(6) Спасибо за статью и пояснения! Есть небольшой вопрос по рабочему процессу, поясните пожалуйста:
1) Чтобы перейти из пункта 2 в пункт 3 пользуетесь стандартной выгрузкой конфигурации в файлы? А дальше уже коммит этих файлов и ПР?
2) При выполнении пункта 1 делаете апдейт своей локальной ветки из удаленного репозитория, а потом изменения как попадают в конфигурацию? Так же загрузкой конфигурации из файлов?
22. ArchLord42 68 22.05.19 03:06 Сейчас в теме
(21) Не за что, только статья не моя)

Да, синхронизация GIT <> конфа происходит, через выгрузку \ загрузку XML, по факту это делается не из самого конфигуратора (да и загрузить из конфигуратора мы не сможем ибо конфа на поддержке), а скриптами из source tree.
Отсюда и особенности процесса, что обновляем из апстрима по утрам, т.к. операция долгая довольно и по мимо сборки и загрузки CF еще делается бэкап текущего состояния конфы, т.к. некоторые люди у нас (в том числе и я) забывали выгрузить изменения и затирали кучу работы пару раз :)
Ну и уже ребята со скиллом и пониманием гита, делают несколько фич сразу (если они небольшие), а потом раскидывают нужное по коммитам, т.к. выгрузка бывает тоже не быстрой, особенно когда еще не создан ConfigDumpInfo (он удаляется после загрузки конфы из гита, и в целом находится в гитигноре), ну либо сразу правят исходники через VS Code
24. zlakizla 58 22.05.19 05:39 Сейчас в теме
(22) Спасибо за пояснения. Правильно понимаю, что запускаете скрипт из sourcetree, который обновляет файлы локального репозитория из удаленного, затем из этих файлов собирает cf, и далее этот cf натягивается на конфигурацию разработчика? Предварительно делая бэкап конфигурации разработчика.
25. ArchLord42 68 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 796 16.06.19 09:25 Сейчас в теме
(6)
Жесть! А можете подсказать, в чём преимущество такого подхода по сравнению со стандартным хранилищем? Если честно, после того как поработал с гит в 1С и после вашего описания пока впечатление "гит ради гита". Не проще сделать хранилище 1С, программистам работать с хранилищем, потом для дженкинсов и прочих авторабот выгружать уже в файлы и дальше по сценарию? В результате - программисты работают с нормальным хранилищем, не нужны никакие договорённости, не нужен специально обученный человек для мёрджей и прочего контроля, не нужно решать кучу проблем на уровне неприспособленности платформы (прыгающие свойства, идентификаторы и т.п., не факт, что в новой платформе не прилетит чего-то нового-интересного).
27. ArchLord42 68 16.06.19 12:02 Сейчас в теме
(26) мы перешли ради код ревью и блейма, хотя блейм в через гитсинк можно получить с хранилищем. Но вот код ревью - нет, плюс блокировки МД достали, а возня с несколькими хранилищами вызвала дикое отторжение, т.к. некоторые кейсы вот вообще не как не воспроизвести.
Например когда 2 разраба, пилят фичи, которые потом нужны другому, через гит это решается банальным черри пиком, с хранилищами уже не как. Писать можно много, главное скажу, что наши разрабы не страдают, все банально просто, не сложнее понимания работы с хранилищем, а для продвинутых разрабов открываются большие возможности и это для нас жирный "+".

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

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


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

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

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

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


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

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

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

И эффективность всего этого алгоритма - Ж большое! Прям огромное. Поэтому для работы с гитом вместо хранилища должны быть реальные основания. У вас, насколько я понимаю, примерно такое же Ж времени уходит на все танцы с гитом. При этом система - "все работают в хранилище 1С, кодревью происходит при заливке в рабочую" - просто таки в разы быстрее. Да, для всяких дженкинсов надо в файлы, но это можно действительно ночью без пользователя делать. А в работе программиста - я, если честно, так и не понял, какой выигрыш вы получили?
29. ArchLord42 68 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 796 17.06.19 09:47 Сейчас в теме
(29)
Вы бы статью написали с вашим случаем, с картинками, командами, инструментарием и т.п. Я думаю, не только мне было бы интересно. Потому что я сейчас с гитом работаю только по внешним обработкам, по полной конфе (это была БП!) было Ж большое. Сейчас уже точно не вспомню, но очень приблизительно половина цикла (перенести из одной базы изменения в другую) занимало от получаса до полутора. Т.е. я утром запускал этот процесс, и также занимался своими делами, ходил на завтрак и т.п. Так вот, кто-то из команды вдруг что-то критичное менял и выкладывал в течение дня, мне было проще или код с экрана у себя переписать, или из выгрузки выдернуть файлы, которые изменены и через файловой хостинг перекинуть к себе.
31. ArchLord42 68 17.06.19 17:41 Сейчас в теме
(26) думал об этом не раз, ибо подобный разбор полётов веду не первый раз, наверное в ближайшем будущем сделаю это уже)
32. for_sale 796 17.06.19 18:16 Сейчас в теме
(31)
Буду ждать, потому что сам бы хотел применить в некоторых местах гит, но пока что этот печальный опыт не особо обнадёживает.
11. azhilichev 149 06.03.19 15:43 Сейчас в теме
По следам статьи из блога Яндекса на Хабре :) Провели эксперимент с использованием этого подхода в комментариях к коммитам. Оправдал себя. Теперь внедряем во всей команде.
12. Scorpion4eg 255 06.03.19 16:15 Сейчас в теме
(11)
По следам статьи из блога Яндекса на Хабре

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

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

Вакансии


Программист 1С
Краснодар
зарплата от 80 000 руб. до 160 000 руб.
Полный день

Консультант 1 С
Краснодар
зарплата от 50 000 руб. до 150 000 руб.
Полный день

Консультант-методолог 1С
Краснодар
зарплата от 110 000 руб.
Полный день

Программист, аналитик, эксперт 1С
Санкт-Петербург
По совместительству