Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 20
2. Совет отстал лет на пять и стал вредным? Писать номер таска в заголовке - плохая практика, о чём уже давно говорится во всех мануалах по Git и о чём регулярно напоминают его авторы! И даже очень хорошо объясняется почему. Таски нужно писать в полях метаинформации собщения и только там! Я, кстати, не полностью с этим согласен, но если уж говорить о современных "лучших практиках", то они именно такие.
3. Не все исправления можно декмопзировать, а периодический "тяжёлый" рефакторинг по-хорошему нужен любому серьёзному проекту: точно угадать структуру проекта и внутренние API с первой строчки - это из области фантастики. А искусственное/принудительное разбиение задачи иногда приводит к написанию большого количества "кода ради кода" (когда, который нужен только на период на рефакторинга). А это мало того, что в разы может увеличить трудоёмкость, но ещё и повышает вероятности ошибок.
4. "Комитить слишком мелкую кашу" Вот просто ради интереса - что делать если вы решаете какую-то задачу и увидели какую-то мерзкую опечатку или ошибку в форматировании? Или даже просто локальный бардак с white-space. Ведь вы же говорите, что комбинировать с другими тасками нельзя. Делать микрокомит из двух символов? Игнорировать? Я, вот, для себя даже не могу точный ответ дать, но обычно считаю наименьшим из зол добавление исправлений опечаток и форматирования к каким-то другим задачам. Ну или как-то их (опечатки и ошибки форматирования) комбинировать, но это в этом случае они теряются забываются и имеют тенденцию разрастаться.
5. Да, но в реальности при большом рефакторинге иногда приходится менять и форматирование, и структуру кода и даже процес сборки. И без этого нельзя получить даже минимально-компилируемую версию. Но в целом это конечно редкость. Но и когда говорят "нельзя", это тоже неправда, это же советы про которые "вполне опытные синьоры" забывают? А именно они и решают такого рода задачи, по идее. Аналогично, комбинация с предыдущим пунктом - что если при рефакторинге найдены минорные проблемы с форматированием, комментариями, опечатками? Править отдельными комитами? Но как же пункт 4?
8. Ну, какую схему бранчинга использовать это вообще сложный и местами религиозный вопрос. Как можно так однозначно говороть? Их же штук пять и у всех свои плюсы-минусы. Тем более что можно и всякие комбинации делать.
Короче, довольно странно эти рекомендации для "вполне опытных синьоров" читать, так как это в любом случае лишь общие рекомендации, которые совершенно точно будут (и должны) нарушаться в реальных проектах. Зачастую вижу людей, которые вот такие рекомендации считают неприрекаемыми правилами, высеченными в граните и унаследованными от утерянных предыдущих цивилаций, и в результате устраивающими какой-то невообразимый неподдерживаемый бардак в проектах или тратящих кучу ресурсов на бессмысленное следование каким-то рекомендациям в ущерб реальной разработке проекта.
Джунам, да, такое нужно регулярно показывать, но с оговоркой (если мы их реально учим), что это можно нарушать (как правило, не им), если есть чёткое понимание причины и последствий. Иначе вырастают "вечные джуны" которые без шаблонных практик и алгоритмов ни строчки кода написать не могут.
"Не все исправления можно декмпозировать "
- по моей практике декомпозировать можно многое и в большинстве случаев это надо делать.
" что делать если вы решаете какую-то задачу и увидели какую-то мерзку опечатку или ошибку в форматировании? "
- в этом примере говорится о крайностях, что если одни разработчики склонны делаать один огромный коммит, то у других наблюдается обратное. и обеих крайностей лучще избегать
"Писать номер таски" - тут акцент на то что его в принципе надо писать и связь коммита и таски в трекере крайне полезна. Очень много встречал что его не пишут ни в сообщении ни в метаинформации совсем ни где.
Но спасибо дополню, что самый правильный вариант писать номер в метаинформации
А я вижу, что иногда на ранних стадиях лучше периодически тормозить разработку и приводить проект в порядок, перетряхивая внутреннюю структуру, чтобы не скатиться легаси через пол года разработки. Причём сейчас народ обычно сопротивляется и рассказывает про декомпозицию и необходимость того, чтобы всё обязательно компилировалось (им так диды завещали). В результате вязнут в неподъёмной трудоёмкости и скатываются в болото легаси, а потом, через каких-то 6 месяцев, рассказывают про "архитектурные ограничения проекта".
По мере развития и роста проекта это, само-собой, можно делать всё реже и реже - и дорого, и ошибки лишние не нужны. Разве что на уровне каких-то новых модулей.
По моему опыту чем раньше заложить правильную структуру проекта в широком смысле тем лучше.может даже и перетряхивать не придется.
Ну, это из области фантазий. Чтобы сразу угадать со всеми бизнес-требованиями, интеграциями и нагрузкой - так не бывает. Обязательно после начала коммерческой эксплутации оказывается, что в реальности всё не так, как казалось на этапе проектирования. Даже если изначальные требования были чётко прописаны и в них так же чётко попали с архитектурой, то по-моему ещё не было ни одного случая, чтобы по мере равёртывания системы эти требования три раза не менялись.
тут на все 100% согласен.
я скорее про то что есть минимальный набор хороших практик, принятых в рамках команды и вот его надо как можно раньше.
А то что бизнес тестирует гипотезы и реальность потребностей пользователей не знают даже сами пользователи - это факт и скорее всего придется что то менять в проекте по мере обнаружения требований.
2. Нет уж, потрудитесь написать почему это плохо) Потому что "нам не нравится, у нас это в плохо читается когда прилетает строго как plain text письмо с патчем на e-mail" - это проблемы вполне конкретных луддитов, а не всея Интернета. Остальным вполне себе норм дёргать штатные штуки гита типа
git shortlog --no-merges HEAD --not $(git describe --tags --abbrev=0)
git log $(git describe --tags --abbrev=0)..HEAD --onelineА то и вовсе прямо в GitLab открыть линк вида gitlab/project/-/compare/PREV_TAG…LAST_TAG и прямо оттуда из списка коммитов скакать в таски, даже если они ведутся не в гитлабе (минимальной интеграции через Custom Issue Tracker уже достаточно чтобы сильно упростить жизнь).
А то и вовсе вывести список "чем занимался" за последние несколько дней и прямо из списка скакать по нужным таскам и трекать время. Например таким алиасом
report = "!me=$(git config user.email); git log --all --author-date-order --since=1 --reverse --no-merges --pretty=time --date=format:'%Y-%m-%d %H:%M:%S' --author=\"$me\" --color=always | sort | uniq | grep `date '+%Y-%m'`"Опять же сильно мотивирует не лепить 100500 тасок в один коммит
@Politura ветка пушится и... команда видит все коммиты, ведь Git прекрасно хранит историю. Вы где-то забыли про squash написать или как минимум про интерактивный ребейз?
@Politura ветка пушится и... команда видит все коммиты, ведь Git прекрасно хранит историю. Вы где-то забыли про squash написать или как минимум про интерактивный ребейз?
Не, мне просто без разницы если кто-то увидит промежуточные коммиты в ветке которая при мерже все равно удалится. :) За прошедшие годы никто никаких комментариев на их счет не делал, хотя там бывали коммиты с некрасивыми комментариями. :) Ну и самому мне лень смотреть такие чужие коммиты когда чей-то PR ревьюю, смотрю только конечные изменения, я полагаю большинство также делает.
C метаинформацией (к которой относятся номера тасков и прочее) всё даже проще - для этого давно изобретены "commit message trailers". Вот пример прямо от самого git:git commit -m "Fix timeout" -m "Issue-Tracker: #412" -m "Reviewed-By: Alice"
git log --format="%(trailers:key=Issue-Tracker,valueonly=true)"
Именно trailers и есть сейчас рекомендуемый и удобный способ хранения дополнительной машино-читамой информации о комите.
И чтобы два раз не вставать имеет смысл сразу упомянуть notes, которые предназначены для хранения изменямой информации о комите (результат прохождения тестов, ход и результат review, примечания вида "не трогать! я отпуске и убью каждого, кто полезет в этот код своими грязыми руками до моего возвращения!" и т.п.). GitHub, кстати, активно этой фиче противится, так как она позволяет легко реализовать очень многое из того, что они через свои дополнительные API и web-интерфейс реализуют. А значит: "вещь хорошая, нужно брать".
Выглядит интересно, но... shortlog к примеру знать ничего не знает про trailers. Нужно костылить обвязку, после чего тупые и лаконичные скрипты формирования черновика release notes обрастают лапшой и ломаются на каждый чих, а сопровождать их может только автор)
Про notes расскажите, пожалуйста, как именно вы их используете? Прям с примерами. Я несколько раз присматривался, но так и не увидел примера, который бы мне зашёл и который бы не стрёмно было бы ещё и в команде внедрять. Видел какие-то сомнительные примеры с хранением логов артефактов сборки... но как по мне это только раздувание репозитория. И инструментов вокруг этого, кроме как руками в консоли махать, я тоже не заметил
Я их использую для каких-то долговременных примечаний в локальных ветках, которые по какой-то причине нельзя или не имеет смыла выность в комит. Например о том, что ещё нужно бы сделать при рефакторинге, какие шаги планировались и такого рода вещи. Что-то из этого можно в коммит записать, но это не всегда уместно, так как может не относиться к текщей ветке или фиче, да и многое выясняется уже после того, как комит сделан.
Но вообще от них бывает польза для всякой автоматизации. Например через них можно достаточно удобно управлять процессом CI/CD - писать туда машиночитаемые команды и статусы. И туда же цеплять результаты тестов и замечания.
Вот сделали вы какой-то релиз - где резултаты тестов сохранить? Или список to-do или багов? Вне репозитория во внешних инструментах? Но эта информация непосредственно привязана к конкретной версии (и комиту). В результате складывается ситуация, когда наличия одного только репозитория недостаточно - есть обязательная завязка на какие-то внешние данные, что концептуально плохо.
В принципе, местами действительно удобно и единственный серьёзный минус - это противодействие со стороны GitLab и GitHub, которые удалили у себя из интерфейса поддержку notes. Но если работаешь с локальными или какими-то собственными репозиториями, то альтернативы особо и нет. Вообще есть какое-то массово "предубеждение" (?!) против "git notes". Даже тот же GItKraken их не поддерживает, хотя при качественной поддержке это был бы офигенный инструмент.
Короче, задумка хорошая и применений её масса, но поддержка со стороны сторонних инструментов хомает на обе ноги :(
Астрологи объявили неделю постов про гит?
4. Коммитить слишком мелкую кашу
9. Не проверять историю перед push
Не понял, вы прям в мастер пушине чтоли? Если да, то вы нулевое и очень важное правило сами себе забыли написать. Если нет, то кому не плевать на историю ветки, которая автоматически будет удалена после слияния пул-реквеста?
Отвечая на ваш вопрос : нет.
История ветки часто важна , как минимум во время работы над ней. И если товарищи по команде будут смотреть и если сам возвращаешься к своим же коммитам. Иногда приходится делать несколько шагов назад по ветке например.
Мы, возможно, о разных вещах говорим. Никто не спорит про важность истории мейна, я про другое.
Как обычно происходит работа: берешься за таску, делаешь локальную ветку и начинаешь коммитить в нее по ходу работы. Сколько там коммитов, на каждую строчку или нет, какие именно комментарии - все это совершенно не важно, все это короткоживущее и имеет смысл только для исполнителя пока работаешь над таской - часы, в крайнем случае несколько дней.
Когда все сделано - ветка пушится на ремоут сервер и создается пул-реквест, который уже оформляется по всем правилам.
Пул-реквест посмотрели другие разработчики и заапрувили - изменения мержатся в мейн, с ссылкой на тикет, с правильным комментарием, а ветка просто удаляется автоматически. Она нужна была только в контексте работы над тикетом.
Смысл в том, что пуши делаются только для этих веток работы над тасками. Никаких других пушей просто нет. В мейн (мастер) должен стоять запрет на пуш, туда изменения должны приходить только пул-реквестами. А если так, то нет никакого смысла проверять историю временной ветки перед пушем. И нет никакого смысла ограничивать себя в коммитах в эту временную ветку.
тут видите зависит от специфики задачи. то что вы говорите на определенном подмножестве задач справедливо.
Иногда бывают ветки которые разрабатывают большую фичу или экспериментальный рефакторинг и по факту работа в них ведется коллективно: автор конечно есть, но по мере развития туда и остальные смотрят и больше того иногда неудачные шаги откатываются и ветка продолжается с удачного шага уже с другим подходом например.
в таком случае соблюдать правила есть смысл и в таких ветках.
В общем есть частные случаи где это применимо и где не применимо
Ветка удалится, но ее история то в мастере останется, если конечно вы сквошем не балуетесь.
Не знаю, как у вас, а у нас ветка оформляется ПЕРЕД созданием merge request, а не после, чтобы не загрязнять обсуждения в GitLab (там же выводится список коммитов после любого push). В процессе разработки можно как угодно коммиты делать. Но в историю должны пойти чистые и аккуратные коммиты
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как не надо работать с Git'ом