Всем привет!

Сегодня речь пойдет не про разработку, а про одну малоизвестную фичу 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

Всем привет!

Пару слов про на мой взгляд достаточно важную, но часто недооцененную штуку, как комментарии к 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

Всем привет!

Давно хотел написать про основные модели ветвления при работе 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

Всем привет!

Поговорим про комментариях к commit.
Вот статья, где приводится пример интересного комментария: https://dhwthompson.com/2019/my-favourite-git-commit

Вообще, я двумя руками за содержательные комментарии, объясняющие что изменилось и почему.
Но этот мне не нравится)
Почему?
1) это перебор. Время, которое мы можем потратить на разработку, конечно. Соответственно, размер комментария должен быть пропорционален его важности и\или объему измененного кода.
2) для того, чтобы поделится знаниями о проблеме, комментарии git не лучший вариант. Они не индексируются поисковиками, если речь про открытые проекты Github. В случае закрытых проектов часто доступ к git-у открыт не для всех. Какой выход - написать статью или пост о решенной проблеме.
3) даже для формирования what's new такой комментарий плохо подходит, т.к. слишком большой и отвлекает внимание на себя от других изменений.

Что думаете?

#git #code_review

Всем привет!

Иногда возникает необходимость создать ветку в репозитории 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