Всем привет!
Сегодня речь пойдет не про разработку, а про одну малоизвестную фичу git.
Возможно кому-то пригодится.
Встречайте - git notes.
Что это такое?
notes, они же заметки дают возможность добавить какие-то данные к commit не меняя commit. Может возникнуть вопрос - есть же amend?
amend меняет commit, как файлы, так и его hash.
Формат заметок может быть любым, в т.ч. бинарным. Ограничений по размеру не нашел.
Где это может быть полезно?
В notes можно хранить данные о сборке из CI системы, информацию, о прошедшем код-ревью. В теории даже артифакты сборки можно хранить, но я этого не говорил)
Технически notes - это отдельные ветки с маcкой refs/notes/*
При этом каждая note связана с commit.
По умолчанию commit - текущий HEAD, ветка - refs/notes/commits.
notes из ветки по умолчанию отображаются в выводе git log.
Переключить текущую ветку можно в настройках
[core]
notesRef =
Заметки можно добавлять, удалять, обновлять, подробнее см. https://git-scm.com/docs/git-notes
Ветки с заметками можно мержить между собой, естественно, перед этим стоит продумать формат данных для избежания конфликтов.
Т.к. заметки хранятся в отдельной ветке, ее нужно отдельно пушить и пулить.
git push refs/notes/*
git fetch origin refs/notes/*:refs/notes/*
Также можно добавить ветки с notes в настройки git origin, и они будут забираться с сервера автоматически при git pull
git config --add remote.origin.fetch +refs/notes/*:refs/notes/*
На и наконец еще хорошая статья на эту тему: https://alblue.bandlem.com/2011/11/git-tip-of-week-git-notes.html
#git #devops
Сегодня речь пойдет не про разработку, а про одну малоизвестную фичу git.
Возможно кому-то пригодится.
Встречайте - git notes.
Что это такое?
notes, они же заметки дают возможность добавить какие-то данные к commit не меняя commit. Может возникнуть вопрос - есть же amend?
amend меняет commit, как файлы, так и его hash.
Формат заметок может быть любым, в т.ч. бинарным. Ограничений по размеру не нашел.
Где это может быть полезно?
В notes можно хранить данные о сборке из CI системы, информацию, о прошедшем код-ревью. В теории даже артифакты сборки можно хранить, но я этого не говорил)
Технически notes - это отдельные ветки с маcкой refs/notes/*
При этом каждая note связана с commit.
По умолчанию commit - текущий HEAD, ветка - refs/notes/commits.
notes из ветки по умолчанию отображаются в выводе git log.
Переключить текущую ветку можно в настройках
[core]
notesRef =
Заметки можно добавлять, удалять, обновлять, подробнее см. https://git-scm.com/docs/git-notes
Ветки с заметками можно мержить между собой, естественно, перед этим стоит продумать формат данных для избежания конфликтов.
Т.к. заметки хранятся в отдельной ветке, ее нужно отдельно пушить и пулить.
git push refs/notes/*
git fetch origin refs/notes/*:refs/notes/*
Также можно добавить ветки с notes в настройки git origin, и они будут забираться с сервера автоматически при git pull
git config --add remote.origin.fetch +refs/notes/*:refs/notes/*
На и наконец еще хорошая статья на эту тему: https://alblue.bandlem.com/2011/11/git-tip-of-week-git-notes.html
#git #devops
Bandlem
Git Tip of the Week: Git Notes - AlBlue’s Blog
Git Tip of the Week: Git Notes
Gtotw
2011
Git
Th...
Gtotw
2011
Git
Th...
Всем привет!
Пару слов про на мой взгляд достаточно важную, но часто недооцененную штуку, как комментарии к commit-ам в git. На самом деле к любой Version Control System, но у нас же на 95+% git)))
Что должно быть:
1) комментарии обязательны
2) в теле комментария должен быть тикет, по которому ведутся работы. В начале текста комментария. В идеале - один тикет. Если правка одной строки исправляет несколько багов\закрывает несколько задач - то лучше закрыть лишние тикеты как дубликаты. Если не хочется заводить тикет на каждый чих - можно завести и использовать тикет типа "мелкие правки"
3) любой комментарий должен быть содержательным, т.е. описывать суть изменений. Лучше не привязваться к именам файлов\классов, т.к. они меняются при рефакторинге, а оперировать понятиями предметной области
4) по длине рекомендую сильно не увлекаться, ограничиваться одной или несколькими фразами. Заодно и сommit-ы будут более атомарными, проще будет revert-ть.
5) формат сommit должен быть единообразным, можно даже контролировать это на сервере. Т.к. по моему опыту без контроля сложно придерживаться единообразия, периодически проскакивают неформатные комментарии)
6) конечная цель комментариев - чтобы список commit-ов нес полезную информацию и его можно было использовать как changelist сервиса
7) следствие из предыдущего пункта - можно и нужно использовать amend для слияния нескольких commit-ов в один. Единственное исключение - если ваш git server синхронизируется, в другую подсеть например, и синхронизация ломается при amend. Опять же при односторонней синхронизации проблему решить можно.
8) следующий уровень - перед созданием Pull request\Merge request можно отрефакторить список commit-ов - переименовать, слить несколько из середины. IDEA позволяет все это сделать. Также можно хардкорно, через коммандную строку с помощью rebase - https://habr.com/ru/post/201922/ С одной стороны так мы становится на путь перфекционизма, но помнить о такой возможности надо)
9) Описание формата commit должно быть в readme.md проекта
Отдельно хочу сказать про язык комментариев. Есть мнение о необходимости английского - я с ним не согласен. По желанию команды. Все-таки не все в совершенстве владеют английским, как среди текущих разработчиков сервиса, так и среди будущих. А читаемость прежде всего!) Да, в английском нет родов у глаголов, поэтому с ним проще. В русском лучшим вариантом кажется использовать стадательный залог - "сделано то-то". Добавление рода или числа - сделал\сделали\сделала - кажется лишней информацией.
Также отдельная тема - нужны ли какие-то специальные обозначения в commit message. Например, алиас для тип изменений: фича, багфикс, рефакторинг, конфиги, тесты. Или указание модуля, где менялся код. Считаю, что не обязательно, но может быть полезно.
#git #code_review
Пару слов про на мой взгляд достаточно важную, но часто недооцененную штуку, как комментарии к commit-ам в git. На самом деле к любой Version Control System, но у нас же на 95+% git)))
Что должно быть:
1) комментарии обязательны
2) в теле комментария должен быть тикет, по которому ведутся работы. В начале текста комментария. В идеале - один тикет. Если правка одной строки исправляет несколько багов\закрывает несколько задач - то лучше закрыть лишние тикеты как дубликаты. Если не хочется заводить тикет на каждый чих - можно завести и использовать тикет типа "мелкие правки"
3) любой комментарий должен быть содержательным, т.е. описывать суть изменений. Лучше не привязваться к именам файлов\классов, т.к. они меняются при рефакторинге, а оперировать понятиями предметной области
4) по длине рекомендую сильно не увлекаться, ограничиваться одной или несколькими фразами. Заодно и сommit-ы будут более атомарными, проще будет revert-ть.
5) формат сommit должен быть единообразным, можно даже контролировать это на сервере. Т.к. по моему опыту без контроля сложно придерживаться единообразия, периодически проскакивают неформатные комментарии)
6) конечная цель комментариев - чтобы список commit-ов нес полезную информацию и его можно было использовать как changelist сервиса
7) следствие из предыдущего пункта - можно и нужно использовать amend для слияния нескольких commit-ов в один. Единственное исключение - если ваш git server синхронизируется, в другую подсеть например, и синхронизация ломается при amend. Опять же при односторонней синхронизации проблему решить можно.
8) следующий уровень - перед созданием Pull request\Merge request можно отрефакторить список commit-ов - переименовать, слить несколько из середины. IDEA позволяет все это сделать. Также можно хардкорно, через коммандную строку с помощью rebase - https://habr.com/ru/post/201922/ С одной стороны так мы становится на путь перфекционизма, но помнить о такой возможности надо)
9) Описание формата commit должно быть в readme.md проекта
Отдельно хочу сказать про язык комментариев. Есть мнение о необходимости английского - я с ним не согласен. По желанию команды. Все-таки не все в совершенстве владеют английским, как среди текущих разработчиков сервиса, так и среди будущих. А читаемость прежде всего!) Да, в английском нет родов у глаголов, поэтому с ним проще. В русском лучшим вариантом кажется использовать стадательный залог - "сделано то-то". Добавление рода или числа - сделал\сделали\сделала - кажется лишней информацией.
Также отдельная тема - нужны ли какие-то специальные обозначения в commit message. Например, алиас для тип изменений: фича, багфикс, рефакторинг, конфиги, тесты. Или указание модуля, где менялся код. Считаю, что не обязательно, но может быть полезно.
#git #code_review
Хабр
Изменение коммитов в Git
Это пост для тех, кто начинает работу с Git. Все, что здесь написано по частям можно найти в многочисленных простынях о Git на Хабре. Но я подумал, что неплохо было бы иметь отдельный предельно...
Всем привет!
Давно хотел написать про основные модели ветвления при работе c исходным кодом.
Итак поехали!
1) великий и ужасный gitflow.
Картинка: https://habrastorage.org/r/w1560/webt/ah/aw/yf/ahawyfcuk_rids2mljkuocattzg.jpeg
Описание: https://github.com/SergeFocus/git-flow
Думаю, многие его знают, но на всякий случай напомню суть.
Основная работа ведется в фичных ветках, для багов есть специальные bugfix ветки. Все они вливаются в develop через Pull Request\Merge request. Для выпуска на ПРОД создается релизная ветка, код из которой после выхода на ПРОД попадает в master. Для выпуска hotfix также предусмотрены отдельные ветки.
Почему gitflow "великий":
а) дает контроль над тем, что и когда попадет в релиз. Поэтому любим в enterprise.
б) хорошо подходит для opensource проектов, т.к. там как правило много релизов и есть внешние коммитеры, качество кода которых нужно контролировать
в) дисциплинирует разработчиков
Почему "ужасный":
а) слишком громоздкий, т.к. master и hotfix ветки часто выглядят излишними
б) работа в фичных ветках может приводить к накоплению там большого количества кода и, следовательно, увеличивает вероятность конфликта при слиянии. Причем чем больше становится ветка, тем сложнее ее влить - и для автора из-за конфликтов, и для ревьюверов из-за объема кода. И сам принцип фичных веток на это провоцирует. Этакая положительная обратная связь, положительная в том смысле, что усиливает сложность вливания с каждым днем и каждой строчкой кода.
в) при плавной раскате на ПРОМ не понятно, в какой момент код должен попадать в master. Ведь в течение периода раскатки, а это может быть неделя +, на ПРОМ будет 2 версии. Кроме того, в этом случае о вливании в master часто забывают, т.к. все равно все работают с develop.
2) модификация gitflow с несколькими develop ветками. Может применяться в больших компаниях, когда критически важно, чтобы код той или иной фичи не попал в релиз Х без явного согласования, а feature toggle не аргумент)
Либо при переходе на новую версию платформы, когда код разных develop просто не совместим. Важная практическая особенность - git не позволит создать ветку develop/2.0 при наличии просто develop, т.к. у них одинаковый префикс. Поэтому лучше заранее определиться с моделью.
Хотя конечно всегда можно достичь требуемого с помощью создания промежуточных веток.
3) github flow. Как следует из названия придумана на GitHub-е, доступна на нем из коробки.
Картинка: https://user-images.githubusercontent.com/6351798/48032310-63842400-e114-11e8-8db0-06dc0504dcb5.png
Детали: https://docs.github.com/ru/get-started/quickstart/github-flow
По сравнению с gitflow сильно упрощена: выброшены develop, hotfix, release, bugfix, оставлены 2 типа веток: master и feature и Pull Request.
Для обозначения релизов можно использовать тэги, напомню, в git tag и branch технически одинаковы, разница лишь в UI того же Bitbucket, Github, Gitlab.
Плюсы:
а) очень простая модель
Минусы:
а) master нужно поддерживать в production ready состоянии -> feature toggles, модульные тесты и дисциплина в команде
#git #vcs #branching
Давно хотел написать про основные модели ветвления при работе c исходным кодом.
Итак поехали!
1) великий и ужасный gitflow.
Картинка: https://habrastorage.org/r/w1560/webt/ah/aw/yf/ahawyfcuk_rids2mljkuocattzg.jpeg
Описание: https://github.com/SergeFocus/git-flow
Думаю, многие его знают, но на всякий случай напомню суть.
Основная работа ведется в фичных ветках, для багов есть специальные bugfix ветки. Все они вливаются в develop через Pull Request\Merge request. Для выпуска на ПРОД создается релизная ветка, код из которой после выхода на ПРОД попадает в master. Для выпуска hotfix также предусмотрены отдельные ветки.
Почему gitflow "великий":
а) дает контроль над тем, что и когда попадет в релиз. Поэтому любим в enterprise.
б) хорошо подходит для opensource проектов, т.к. там как правило много релизов и есть внешние коммитеры, качество кода которых нужно контролировать
в) дисциплинирует разработчиков
Почему "ужасный":
а) слишком громоздкий, т.к. master и hotfix ветки часто выглядят излишними
б) работа в фичных ветках может приводить к накоплению там большого количества кода и, следовательно, увеличивает вероятность конфликта при слиянии. Причем чем больше становится ветка, тем сложнее ее влить - и для автора из-за конфликтов, и для ревьюверов из-за объема кода. И сам принцип фичных веток на это провоцирует. Этакая положительная обратная связь, положительная в том смысле, что усиливает сложность вливания с каждым днем и каждой строчкой кода.
в) при плавной раскате на ПРОМ не понятно, в какой момент код должен попадать в master. Ведь в течение периода раскатки, а это может быть неделя +, на ПРОМ будет 2 версии. Кроме того, в этом случае о вливании в master часто забывают, т.к. все равно все работают с develop.
2) модификация gitflow с несколькими develop ветками. Может применяться в больших компаниях, когда критически важно, чтобы код той или иной фичи не попал в релиз Х без явного согласования, а feature toggle не аргумент)
Либо при переходе на новую версию платформы, когда код разных develop просто не совместим. Важная практическая особенность - git не позволит создать ветку develop/2.0 при наличии просто develop, т.к. у них одинаковый префикс. Поэтому лучше заранее определиться с моделью.
Хотя конечно всегда можно достичь требуемого с помощью создания промежуточных веток.
3) github flow. Как следует из названия придумана на GitHub-е, доступна на нем из коробки.
Картинка: https://user-images.githubusercontent.com/6351798/48032310-63842400-e114-11e8-8db0-06dc0504dcb5.png
Детали: https://docs.github.com/ru/get-started/quickstart/github-flow
По сравнению с gitflow сильно упрощена: выброшены develop, hotfix, release, bugfix, оставлены 2 типа веток: master и feature и Pull Request.
Для обозначения релизов можно использовать тэги, напомню, в git tag и branch технически одинаковы, разница лишь в UI того же Bitbucket, Github, Gitlab.
Плюсы:
а) очень простая модель
Минусы:
а) master нужно поддерживать в production ready состоянии -> feature toggles, модульные тесты и дисциплина в команде
#git #vcs #branching
4) gitlab flow. Опять же из названия понятно, кто ее придумал и где она применяется по умолчанию.
Картинка: см. детали
Детали c объяcнением чем авторов не устроили gitflow и github flow : https://docs.gitlab.com/ee/topics/gitlab_flow.html
Основные отличия от gitflow:
1) ветка для ПРОДа необязательна, но при необходимости - возможна
2) релизные ветки необязательны, только если есть внешний заказчик и\или нужны явные релизы
3) добавляется возможность environment веток - stage, pre-production, что позволяет запускать CD pipeline по появлению изменений в ветке
4) разделение bugfix\feature не требуется, хотя и не запрещается.
5) hotfix нет
Плюсы:
1) самый гибкий из вышеперечисленных flow, т.к. по сути в простейшем случае сводится к github flow, а в самом сложном похож на gitflow + environment ветки.
Минусы:
1) если использовать все возможные фичи - environment ветки, релизные ветки, production - история загрязняется кучей merge commits
2) при использовании environment веток багфикс долго идет до ПРОМа
2) не строгая модель, кого-то это может напрягать
5) trunk based. Самая на мой взгляд малоизвестная модель. Но при этом с нее все начинают. Как такое может быть?
По сути это github flow на максималках. Фичные ветки или живут 1-2 дня, или вообще их нет. Ага, push-им сразу в master. Т.е. можно жить в git, который по сути пропагандирует быстрое создание веток, с одной веткой.
Как же при этом все не сломать:
1) feature toggle
2) принцип замкового камня - разработка фичи планируется так, что конечному пользователю в UI и API она будет видна с последним сommit-ом https://martinfowler.com/bliki/KeystoneInterface.html
3) много автоматических тестов
4) опытные разработчики в команде
5) маленькая команда
6) частые push-и, чтобы снизить вероятность конфликтов
7) парное программирование, когда ревью проходится до push
8) отложенное ревью, что требует высокой инженерной культуры в команде
Картинка: https://images.prismic.io/launchdarkly/36802d7a-391b-4d0b-b712-e841437418c4_TrunkBasedDev-02-1024x576.png?ixlib=gatsbyFP&auto=compress%2Cformat&fit=max&rect=0%2C0%2C1024%2C576&w=2000&h=1125
Детали: https://habr.com/ru/post/519314/
В качестве "внеклассного чтения" могу порекомендовать достаточно подробную статью Мартина Фаулера про ветки: https://martinfowler.com/articles/branching-patterns.html
Там есть варианты ветвления, не подпадающие под модели выше и сравнение разных моделей.
#git #vcs #branching
Картинка: см. детали
Детали c объяcнением чем авторов не устроили gitflow и github flow : https://docs.gitlab.com/ee/topics/gitlab_flow.html
Основные отличия от gitflow:
1) ветка для ПРОДа необязательна, но при необходимости - возможна
2) релизные ветки необязательны, только если есть внешний заказчик и\или нужны явные релизы
3) добавляется возможность environment веток - stage, pre-production, что позволяет запускать CD pipeline по появлению изменений в ветке
4) разделение bugfix\feature не требуется, хотя и не запрещается.
5) hotfix нет
Плюсы:
1) самый гибкий из вышеперечисленных flow, т.к. по сути в простейшем случае сводится к github flow, а в самом сложном похож на gitflow + environment ветки.
Минусы:
1) если использовать все возможные фичи - environment ветки, релизные ветки, production - история загрязняется кучей merge commits
2) при использовании environment веток багфикс долго идет до ПРОМа
2) не строгая модель, кого-то это может напрягать
5) trunk based. Самая на мой взгляд малоизвестная модель. Но при этом с нее все начинают. Как такое может быть?
По сути это github flow на максималках. Фичные ветки или живут 1-2 дня, или вообще их нет. Ага, push-им сразу в master. Т.е. можно жить в git, который по сути пропагандирует быстрое создание веток, с одной веткой.
Как же при этом все не сломать:
1) feature toggle
2) принцип замкового камня - разработка фичи планируется так, что конечному пользователю в UI и API она будет видна с последним сommit-ом https://martinfowler.com/bliki/KeystoneInterface.html
3) много автоматических тестов
4) опытные разработчики в команде
5) маленькая команда
6) частые push-и, чтобы снизить вероятность конфликтов
7) парное программирование, когда ревью проходится до push
8) отложенное ревью, что требует высокой инженерной культуры в команде
Картинка: https://images.prismic.io/launchdarkly/36802d7a-391b-4d0b-b712-e841437418c4_TrunkBasedDev-02-1024x576.png?ixlib=gatsbyFP&auto=compress%2Cformat&fit=max&rect=0%2C0%2C1024%2C576&w=2000&h=1125
Детали: https://habr.com/ru/post/519314/
В качестве "внеклассного чтения" могу порекомендовать достаточно подробную статью Мартина Фаулера про ветки: https://martinfowler.com/articles/branching-patterns.html
Там есть варианты ветвления, не подпадающие под модели выше и сравнение разных моделей.
#git #vcs #branching
Gitlab
| GitLab Docs
GitLab product documentation.
Всем привет!
Поговорим про комментариях к commit.
Вот статья, где приводится пример интересного комментария: https://dhwthompson.com/2019/my-favourite-git-commit
Вообще, я двумя руками за содержательные комментарии, объясняющие что изменилось и почему.
Но этот мне не нравится)
Почему?
1) это перебор. Время, которое мы можем потратить на разработку, конечно. Соответственно, размер комментария должен быть пропорционален его важности и\или объему измененного кода.
2) для того, чтобы поделится знаниями о проблеме, комментарии git не лучший вариант. Они не индексируются поисковиками, если речь про открытые проекты Github. В случае закрытых проектов часто доступ к git-у открыт не для всех. Какой выход - написать статью или пост о решенной проблеме.
3) даже для формирования what's new такой комментарий плохо подходит, т.к. слишком большой и отвлекает внимание на себя от других изменений.
Что думаете?
#git #code_review
Поговорим про комментариях к commit.
Вот статья, где приводится пример интересного комментария: https://dhwthompson.com/2019/my-favourite-git-commit
Вообще, я двумя руками за содержательные комментарии, объясняющие что изменилось и почему.
Но этот мне не нравится)
Почему?
1) это перебор. Время, которое мы можем потратить на разработку, конечно. Соответственно, размер комментария должен быть пропорционален его важности и\или объему измененного кода.
2) для того, чтобы поделится знаниями о проблеме, комментарии git не лучший вариант. Они не индексируются поисковиками, если речь про открытые проекты Github. В случае закрытых проектов часто доступ к git-у открыт не для всех. Какой выход - написать статью или пост о решенной проблеме.
3) даже для формирования what's new такой комментарий плохо подходит, т.к. слишком большой и отвлекает внимание на себя от других изменений.
Что думаете?
#git #code_review
dhwthompson.com
My favourite Git commit
I like Git commit messages. Used well, I think they’re one of the most powerful tools available to document a codebase over its lifetime. I’d like to illustrate that by showing you my favourite ever Git commit.
Всем привет!
Иногда возникает необходимость создать ветку в репозитории Git никак не связанную с уже существующими ветками.
Первым делом при такой потребности я хочу процитировать наверное самый популярный ответ на StackOverflow - а вам точно нужно это делать?) В данном случае он справедлив, т.к. не стоит хранить в одном репозитории слабосвязанный код:
а) приложение и его библиотеки
б) код и API\документацию\настройки\скрипты БД если их создают члены команды с разными ролями и разным подходом к код-ревью и слиянию - к примеру разработчики и аналитики
в) наоборот, если API\документацию\настройки\скрипты БД создают одни и те же люди - не стоит их разносить по разным веткам.
Но бывают кейсы, требующие нескольких несвязанных между собой веток. Например, две сильно различающиеся версии приложения.
Есть три способа решить эту задачу.
1) очевидный и неправильный - создать новую ветку на основе существующей, удалить все файлы и залить новые
2) изначально завести ветку c readme.md, от которой можно будет создавать новые чистые ветки
3) выполнить вот такие команды
git checkout --orphan newbranch
git rm -rf .
и далее как обычно.
#git
Иногда возникает необходимость создать ветку в репозитории Git никак не связанную с уже существующими ветками.
Первым делом при такой потребности я хочу процитировать наверное самый популярный ответ на StackOverflow - а вам точно нужно это делать?) В данном случае он справедлив, т.к. не стоит хранить в одном репозитории слабосвязанный код:
а) приложение и его библиотеки
б) код и API\документацию\настройки\скрипты БД если их создают члены команды с разными ролями и разным подходом к код-ревью и слиянию - к примеру разработчики и аналитики
в) наоборот, если API\документацию\настройки\скрипты БД создают одни и те же люди - не стоит их разносить по разным веткам.
Но бывают кейсы, требующие нескольких несвязанных между собой веток. Например, две сильно различающиеся версии приложения.
Есть три способа решить эту задачу.
1) очевидный и неправильный - создать новую ветку на основе существующей, удалить все файлы и залить новые
2) изначально завести ветку c readme.md, от которой можно будет создавать новые чистые ветки
3) выполнить вот такие команды
git checkout --orphan newbranch
git rm -rf .
и далее как обычно.
#git
Всем привет!
В продолжение темы функциональности IDEA и подготовки кода к code review, см. https://t.me/javaKotlinDevOps/148
Некоторые проверки и исправления можно подвесить на одно из двух событий:
1) на сохранение файла: Alt-Alt - Actions on Save. Рекомендую включить Reformat code и Optimize import.
2) перед commit на Git сервер - открыть окно Commit (Ctrl-K) и нажать там шестеренку. Рекомендую включить Analyze code, Check TODO и если выполнение тестов занимает приемлемое время - то еще и прогон тестов.
Легко заметить, что набор опций в обоих случаях похож, но на сохранении можно включить только те, где фиксы применяются без участия человека. В частности и Cleanup, и Analyze выполняют правила из набора инспекций (Inspections), только в первом случае включаются только те правила, где есть quick fixes, которые можно применить автоматически.
Насчет Cleanup - IMHO его вполне можно включить на commit, главное перепроверить набор активных правил: Shift-Shift - Inspections, а там включить фильтр Cleanup only. К слову - там еще есть профили с набором правил, можно добавить свой.
И еще важный момент - инспекции из IDEA можно запустить из командной строки, и т.об. включить в CI процесс: https://www.jetbrains.com/help/idea/command-line-code-inspector.html
Они частично повторяют проверки SonarQube, но не идентичны им.
#idea #code_review #clean_code #git
В продолжение темы функциональности IDEA и подготовки кода к code review, см. https://t.me/javaKotlinDevOps/148
Некоторые проверки и исправления можно подвесить на одно из двух событий:
1) на сохранение файла: Alt-Alt - Actions on Save. Рекомендую включить Reformat code и Optimize import.
2) перед commit на Git сервер - открыть окно Commit (Ctrl-K) и нажать там шестеренку. Рекомендую включить Analyze code, Check TODO и если выполнение тестов занимает приемлемое время - то еще и прогон тестов.
Легко заметить, что набор опций в обоих случаях похож, но на сохранении можно включить только те, где фиксы применяются без участия человека. В частности и Cleanup, и Analyze выполняют правила из набора инспекций (Inspections), только в первом случае включаются только те правила, где есть quick fixes, которые можно применить автоматически.
Насчет Cleanup - IMHO его вполне можно включить на commit, главное перепроверить набор активных правил: Shift-Shift - Inspections, а там включить фильтр Cleanup only. К слову - там еще есть профили с набором правил, можно добавить свой.
И еще важный момент - инспекции из IDEA можно запустить из командной строки, и т.об. включить в CI процесс: https://www.jetbrains.com/help/idea/command-line-code-inspector.html
Они частично повторяют проверки SonarQube, но не идентичны им.
#idea #code_review #clean_code #git
Telegram
(java || kotlin) && devOps
Всем привет!
Теперь перейдем к рекомендациям для авторов Pull Request (PR), они же Merge Request.
1) не нужно тратить время ревьювера на то, что могут сделать роботы) Я про чистку import и форматирование кода. Рекомендую поставить эти действия на автовыполнение…
Теперь перейдем к рекомендациям для авторов Pull Request (PR), они же Merge Request.
1) не нужно тратить время ревьювера на то, что могут сделать роботы) Я про чистку import и форматирование кода. Рекомендую поставить эти действия на автовыполнение…
Всем привет!
Уже прошел примерно год как появился ChatGPT. Его активно пытаются применить везде - для решения бизнес-задач, автоматизации рутины и конечно же написания кода. Какую же рутину можно автоматизировать в разработке? А например такую - https://github.com/Nutlope/aicommits
#git #commit
Уже прошел примерно год как появился ChatGPT. Его активно пытаются применить везде - для решения бизнес-задач, автоматизации рутины и конечно же написания кода. Какую же рутину можно автоматизировать в разработке? А например такую - https://github.com/Nutlope/aicommits
#git #commit
GitHub
GitHub - Nutlope/aicommits: A CLI that writes your git commit messages for you with AI
A CLI that writes your git commit messages for you with AI - Nutlope/aicommits
Всем привет!
Микросервисная архитектура, которая становится все более популярной, требует хранения кода каждого сервиса в отдельном репозитории. На всякий пожарный - про остальные требования к микросервисам можно почитать тут https://t.me/javaKotlinDevOps/55
Бонусом мы получаем "штатную" работы IDE, pipeline, механизмов код-ревью. Микросервис подразумевает небольшой объём кода, т.е. все инструменты будут отрабатывать достаточно быстро, с меньшей вероятностью тормозить или падать, меньше вероятность конфликтов merge и т.д.
Зачем же тогда могут понадобится гигантские монорепы?
А ведь примеров хватает:
Яндекс https://habr.com/ru/companies/yandex/articles/469021/
Гугл https://qeunit.com/blog/how-google-does-monorepo/
Microsoft Windows https://habr.com/ru/articles/795635/
И даже Юла: https://habr.com/ru/companies/oleg-bunin/articles/531632/
Отдельно я бы выделил три типовых кейса, не относящиеся к микросервисам:
1) собственно монолит. И причина понятна - странно части монолита собирать из разных репозиториев. Релизный цикл, pipeline все равно же общие
2) игры. Тоже по сути отдельный вид монолита - огромные размеры репо, особенность: основной объем занимают бинарные данные: текстуры, картинки, видео...
3) большие мобильные приложения, SuperApp или стремящиеся к ним. Тоже по сути отдельный случай монолита.
Но в списке выше есть и микросервисы, зачем им лезть в монорепы? Суммируя, можно выделить такие причины:
1) проще контроль над своевременностью обновления библиотек
2) возможность одним PR занести кросс-сервисную фичу. Кстати, полезная штука
3) обучение новичков и обмен знаниями на примерах из других сервисов. Кажется, что это можно сделать и с разными репо, но в монорепе, конечно, удобнее
4) облегчение работы с общим кодом - не надо подключать новые модули явно в каждый сервис, просто работаем с тем, что есть в develop. Опять же все ошибки при выпуске новой версии общего кода ловятся быстрее, т.к. все тесты в одном месте. Конечно тесты, а точнее достаточное тестовое покрытие, должно быть) Рефакторинг, застрагивающий все части системы, как правило связанный с изменением общего API, также проводить проще
5) легче обеспечить унификацию требований к коду. Тоже - можно решить на уровне pipeline и commit hook, но в одном репо проще
6) т.к. модули в монорепо скорее всего работают вместе, а иначе зачем их код хранится вместе - с монорепо можно развернуть тестовый стенд проще, чем с отдельными микросервисами
Что касается минусов - про то как их побороть, можно глянуть статьи выше. Особенно полезна статья про Microsoft, содержащая технические советы по обслуживанию репо на уровне git-а. Часть я знал и ранее, и даже использовал, часть для меня стало сюрпризом. Что особенно важно - все доработки из своего форка git Microsoft портировала в master git. Вот краткий список советов:
1) sparse checkout - выкачивание только нужных папок
2) shallow copy - выкачивание ограниченного числа версии из истории изменений, как правило, только последней
3) клонирование без blob (--filter=blob: none) В blob хранится содержимое файлов. Ясно, что без содержимого файлов разработка невозможна, но в этом режиме git во-первых подкачивает blob для последней версии, а во-вторых - будет подкачивать необходимые ему файлы по требованию
4) также может быть полезно клонирование без checkout, опция --no-checkout, т.е. без копирования собственно файлов в рабочий каталог. Так мы сможем избежать случайного копирования всех файлов до того, как будет проведена фильтрация
5) запуск git maintenance в фоне - обновление графа коммитов, ускоряет выполнение некоторых команд git
6) фоновый монитор файловой системы, настройка git config core.fsmonitor true. Слушает уведомления об изменений файлов в каталоге с исходниками, поэтому git status отрабатывает быстрее.
Более того, в состав Git есть отдельная утилита scalar, из коробки делающая многое из перечисленных выше пунктов.
Итоги: если можно обойтись без монорепо - так и нужно делать. Но если все же решили его использовать - боль можно облегчить)
#git #microservices #monorepo
Микросервисная архитектура, которая становится все более популярной, требует хранения кода каждого сервиса в отдельном репозитории. На всякий пожарный - про остальные требования к микросервисам можно почитать тут https://t.me/javaKotlinDevOps/55
Бонусом мы получаем "штатную" работы IDE, pipeline, механизмов код-ревью. Микросервис подразумевает небольшой объём кода, т.е. все инструменты будут отрабатывать достаточно быстро, с меньшей вероятностью тормозить или падать, меньше вероятность конфликтов merge и т.д.
Зачем же тогда могут понадобится гигантские монорепы?
А ведь примеров хватает:
Яндекс https://habr.com/ru/companies/yandex/articles/469021/
Гугл https://qeunit.com/blog/how-google-does-monorepo/
Microsoft Windows https://habr.com/ru/articles/795635/
И даже Юла: https://habr.com/ru/companies/oleg-bunin/articles/531632/
Отдельно я бы выделил три типовых кейса, не относящиеся к микросервисам:
1) собственно монолит. И причина понятна - странно части монолита собирать из разных репозиториев. Релизный цикл, pipeline все равно же общие
2) игры. Тоже по сути отдельный вид монолита - огромные размеры репо, особенность: основной объем занимают бинарные данные: текстуры, картинки, видео...
3) большие мобильные приложения, SuperApp или стремящиеся к ним. Тоже по сути отдельный случай монолита.
Но в списке выше есть и микросервисы, зачем им лезть в монорепы? Суммируя, можно выделить такие причины:
1) проще контроль над своевременностью обновления библиотек
2) возможность одним PR занести кросс-сервисную фичу. Кстати, полезная штука
3) обучение новичков и обмен знаниями на примерах из других сервисов. Кажется, что это можно сделать и с разными репо, но в монорепе, конечно, удобнее
4) облегчение работы с общим кодом - не надо подключать новые модули явно в каждый сервис, просто работаем с тем, что есть в develop. Опять же все ошибки при выпуске новой версии общего кода ловятся быстрее, т.к. все тесты в одном месте. Конечно тесты, а точнее достаточное тестовое покрытие, должно быть) Рефакторинг, застрагивающий все части системы, как правило связанный с изменением общего API, также проводить проще
5) легче обеспечить унификацию требований к коду. Тоже - можно решить на уровне pipeline и commit hook, но в одном репо проще
6) т.к. модули в монорепо скорее всего работают вместе, а иначе зачем их код хранится вместе - с монорепо можно развернуть тестовый стенд проще, чем с отдельными микросервисами
Что касается минусов - про то как их побороть, можно глянуть статьи выше. Особенно полезна статья про Microsoft, содержащая технические советы по обслуживанию репо на уровне git-а. Часть я знал и ранее, и даже использовал, часть для меня стало сюрпризом. Что особенно важно - все доработки из своего форка git Microsoft портировала в master git. Вот краткий список советов:
1) sparse checkout - выкачивание только нужных папок
2) shallow copy - выкачивание ограниченного числа версии из истории изменений, как правило, только последней
3) клонирование без blob (--filter=blob: none) В blob хранится содержимое файлов. Ясно, что без содержимого файлов разработка невозможна, но в этом режиме git во-первых подкачивает blob для последней версии, а во-вторых - будет подкачивать необходимые ему файлы по требованию
4) также может быть полезно клонирование без checkout, опция --no-checkout, т.е. без копирования собственно файлов в рабочий каталог. Так мы сможем избежать случайного копирования всех файлов до того, как будет проведена фильтрация
5) запуск git maintenance в фоне - обновление графа коммитов, ускоряет выполнение некоторых команд git
6) фоновый монитор файловой системы, настройка git config core.fsmonitor true. Слушает уведомления об изменений файлов в каталоге с исходниками, поэтому git status отрабатывает быстрее.
Более того, в состав Git есть отдельная утилита scalar, из коробки делающая многое из перечисленных выше пунктов.
Итоги: если можно обойтись без монорепо - так и нужно делать. Но если все же решили его использовать - боль можно облегчить)
#git #microservices #monorepo
Telegram
(java || kotlin) && devOps
Всем привет!
Поговорим про микросервисы. Статей будет несколько, от плюсов и минусов до саги и прочих паттернов.
Для начала что такое микросервис. Я дам определение в виде набора обязательных признаков. Обязательны все из них.
1) одна команда
2) отдельная…
Поговорим про микросервисы. Статей будет несколько, от плюсов и минусов до саги и прочих паттернов.
Для начала что такое микросервис. Я дам определение в виде набора обязательных признаков. Обязательны все из них.
1) одна команда
2) отдельная…
Всем привет!
Нашел вот такую интересную штуку для работы с git - https://gitbutler.com/ По сути ребята взяли идею IDEA ))) с change list-ами, и сделали из change list полноценную ветку. Ну как полноценную - виртуальную, git про них не знает, вся информация о такой ветке хранится локально. change list-у можно дать название и закоммитить отдельно, а в виртуальной ветке, как и в обычной, кроме того можно делать коммиты, а также объединять, переименовывать и откатывать их. Вот видео с основными фишками https://www.youtube.com/watch?v=PWc4meBj4jo
Цель утилиты - одновременная работа над несколькими ветками. Причем судя по видео создание новых веток и переключение между ними реально быстрое, у меня даже иногда возникала мысль - а не ускорили ли они видео) Ну и надо сказать, утилита пропагандирует минимально возможные изменения в коммите и в ветках, в пределе - одно изменение = один коммит, что также способствует скорости работы. В этом она мне напомнила https://darcs.net/Features, где тоже идет упор на то, что каждая строчка с изменением может стать отдельным коммитом. Но в отличие от Darcs GitButler полностью совместим с Git. И активно развивается.
Еще небольшая полезная плюшка - автоматическая генерация текста коммитов, то самое применение AI, о котором недавно писал.
Да, для индивидуальных пользователей утилита бесплатная.
Главное неудобство - нельзя работать с ветками в IDEA, т.к. git client, встроенный в IDEA, ничего не знает о виртуальных ветках.
Второй момент - пока доступно только для Mac и Linux, а так я бы попробовал(
#git
Нашел вот такую интересную штуку для работы с git - https://gitbutler.com/ По сути ребята взяли идею IDEA ))) с change list-ами, и сделали из change list полноценную ветку. Ну как полноценную - виртуальную, git про них не знает, вся информация о такой ветке хранится локально. change list-у можно дать название и закоммитить отдельно, а в виртуальной ветке, как и в обычной, кроме того можно делать коммиты, а также объединять, переименовывать и откатывать их. Вот видео с основными фишками https://www.youtube.com/watch?v=PWc4meBj4jo
Цель утилиты - одновременная работа над несколькими ветками. Причем судя по видео создание новых веток и переключение между ними реально быстрое, у меня даже иногда возникала мысль - а не ускорили ли они видео) Ну и надо сказать, утилита пропагандирует минимально возможные изменения в коммите и в ветках, в пределе - одно изменение = один коммит, что также способствует скорости работы. В этом она мне напомнила https://darcs.net/Features, где тоже идет упор на то, что каждая строчка с изменением может стать отдельным коммитом. Но в отличие от Darcs GitButler полностью совместим с Git. И активно развивается.
Еще небольшая полезная плюшка - автоматическая генерация текста коммитов, то самое применение AI, о котором недавно писал.
Да, для индивидуальных пользователей утилита бесплатная.
Главное неудобство - нельзя работать с ветками в IDEA, т.к. git client, встроенный в IDEA, ничего не знает о виртуальных ветках.
Второй момент - пока доступно только для Mac и Linux, а так я бы попробовал(
#git
GitButler
GitButler software development platform
Всем привет!
Я уже рассказывал про 5 возможных моделей ветвления в git https://t.me/javaKotlinDevOps/95
Нашел еще одну, причем уверен некоторым читателям этого блога она покажется знакомым)
Встречайте stacked pull requests.
Вот краткое описание https://www.michaelagreiler.com/stacked-pull-requests
А вот еще более краткое от меня:
1) работаем через Pull Requests (PR), они же Merge Requests
2) PR выстраиваем в лесенку
3) вливаем в обратном порядке
4) при изменениях в родительском PR, например, по результату код-ревью, проталкиваем изменения во все дочерние PR
Основное назначение данной схемы:
1) упор на ревью небольших кусочков кода, разделение фичи на мелкие commit-ы, удобные для ревью
2) разного рода миграции, когда на промежуточных стадиях код не компилируется и тесты не проходят, а все вместе - неудобоваримо для код ревью
Данная модель может работать поверх любого их описанных выше flow, за исключение trunk based. trunk based, напомню, вообще убирает Pull Requests, а процесс ревью осуществляется либо при парном программировании, либо пост-фактум.
Альтернативой является один PR с предположим 10 commits. Но преимущество данной схемы в том, что создавая вместо этого 10 PR автор скорее задумается о том, чтобы каждый из них представлял атомарное изменение, удобное для ревью.
#git #vcs #branching
Я уже рассказывал про 5 возможных моделей ветвления в git https://t.me/javaKotlinDevOps/95
Нашел еще одну, причем уверен некоторым читателям этого блога она покажется знакомым)
Встречайте stacked pull requests.
Вот краткое описание https://www.michaelagreiler.com/stacked-pull-requests
А вот еще более краткое от меня:
1) работаем через Pull Requests (PR), они же Merge Requests
2) PR выстраиваем в лесенку
3) вливаем в обратном порядке
4) при изменениях в родительском PR, например, по результату код-ревью, проталкиваем изменения во все дочерние PR
Основное назначение данной схемы:
1) упор на ревью небольших кусочков кода, разделение фичи на мелкие commit-ы, удобные для ревью
2) разного рода миграции, когда на промежуточных стадиях код не компилируется и тесты не проходят, а все вместе - неудобоваримо для код ревью
Данная модель может работать поверх любого их описанных выше flow, за исключение trunk based. trunk based, напомню, вообще убирает Pull Requests, а процесс ревью осуществляется либо при парном программировании, либо пост-фактум.
Альтернативой является один PR с предположим 10 commits. Но преимущество данной схемы в том, что создавая вместо этого 10 PR автор скорее задумается о том, чтобы каждый из них представлял атомарное изменение, удобное для ревью.
#git #vcs #branching
Telegram
(java || kotlin) && devOps
Всем привет!
Давно хотел написать про основные модели ветвления при работе c исходным кодом.
Итак поехали!
1) великий и ужасный gitflow.
Картинка: https://habrastorage.org/r/w1560/webt/ah/aw/yf/ahawyfcuk_rids2mljkuocattzg.jpeg
Описание: https://github.…
Давно хотел написать про основные модели ветвления при работе c исходным кодом.
Итак поехали!
1) великий и ужасный gitflow.
Картинка: https://habrastorage.org/r/w1560/webt/ah/aw/yf/ahawyfcuk_rids2mljkuocattzg.jpeg
Описание: https://github.…