А расскажите про Git

Хуки – это всё баловство и ерунда. Что на самом деле улучшает жизнь, так это: worktrees, rerere.

Ну и всякие мелочи вроде git add -p, git rebase -i, git stash.

Из интересного - собирал репозиторий, где сабмодулями десяток других репо подтягиваются и дальше все это счастливо билдится в docker-compose. git submodule - интересная штука. Хуки - нет (и не надо, а вот CI нормальный надо).

Хуки - нет и не надо

а вот CI нормальный надо

открою страшную тайну, CI в git реализовывается именно с помощью хуков))

Нет, не про самую-самую базу (git init, clone, config

а, ну если для тебя конфиг гита это самая база и настройки вроде «подписывать коммиты ssh-ключом, который доступен только через ssh agent» или «использовать для проектов из папки work одни имя, email и ключ для подписи, а для всех остальных - другие» это что-то само собой разумеещееся, то ладно, расскажу только про git gc. Эта команда может почистить гигабайты мусора в хранилище обьектов, особенно в репах, с которыми ты давно и активно работаешь.

Я им особо не пользуюсь, но вот недавно заметил как разжирел каталог с репами, по итогу слепил что-то такое:

git clone --depth 1 --single-branch --branch master --shallow-submodules -j16

Хуки – это всё баловство и ерунда

Можно заставить коммитить по формату же строгому. Чтоб каждый коммит всегда начинался с того что он делает. Так читать проще и джунов с ии-шкой гонять строже

Я к тому, что средствами git мало кто это все делает. А так-то «я понимаю вашу иронию, профессор» (с) :)

git bisect, очень полезно

Можно заставить коммитить по формату же строгому.

Имитацией бурной деятельности занимаетесь, внося инновационные предложения? :)

Вспомните заветы мудрецов про «преждевременная оптимизация» и сразу поймёте, что коммит-сообщения вне общего стиля стоят где-то дальше третего десятка в списке топ-проблем джунов.

хуки зло (pre-commit). типа вымотавшийся после дебага пушишь себе в PR изменения и идешь на диван… но нет. будь добр длина строк 67 символов, два энтера запрещены, формат сообщения коммита не соответствует хрен пойми чему, обязательные табы, но не в отступах многострочных строк… господи да идите в сад

ах да забыл, совет то какой:

‘git commit –no-verify && git push -o ci.skip’

а завтра с чистой совестью можно весь день потратить на дрочево с код-стайл и ребейзнуть

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

а про более тонкие моменты, которые сильно облегчают жизнь

Если оно тебе будет нужно, загуглишь и сделаешь, зачем забивать себе голову когда хватает clone и commit?

Я лично обхожусь несколькими алиасами (co, bt, st), прекоммит хуком с запуском тестов и rebase.autoStash, rebase.autoSquash. Ну да, diff.noprefix ещё, потому что a/ и b/ придумали конченые.

вымотавшийся после дебага пушишь себе в PR изменения и идешь на диван… но нет.

Мне непонятно, что мешает иметь два инстанса git:

1. локальный, в который можно пушить изменения без проверок;
2. командный, в который можно пушить после того, как локально поработал несколько дней, но зато в соответствии с кодестайлом.

Вот тут возникла довольно странная задача выкачать все версии CSV-файла за много лет, и совместными усилиями поняли, что быстрее всего сделать sparse и выдёргивать diff-ы для каждого коммита: Скачать все версии одного файла

git clone --filter=blob:none --no-checkout https://github.com/{owner}/{project}
cd {project}
git sparse-checkout set {path/to/file}
git checkout
git format-patch --root -o {path/to/patches-directory} {path/to/file}

Вдруг пригодится? :)

перечитал два раза 1 и 2 и не совсем понял. Оно так и работает по умолчанию.

У человека, которому я отвечал, настроено не так. Из-за этого при коммите в локальный репозиторий у него срабатывают хуки и ругают его, не давая закоммитить результат рабочего дня.

Да проще просто отключить «лишние» хуки через git config hook.<friendly-name>.enabled

А локальный зачем?

Если ты что то хотишь там навасянить, то делаешь ветку и колхозишь, когда понял что типа тебя это устраивает. Создаешь запрос на слияние … ну и т.д. При локальном твой колхоз не одобрят.

Я надеюсь, ты пишешь с другой планеты. А лучше - с параллельной Вселенной.

Лично мне ещё git bisect нравится - помогает найти, какой именно коммит сломал что-то конкретное. А если это фломализуемо (например тест есть), то вообще в автоматическом режиме сделать можно.

хуки зло (pre-commit). типа вымотавшийся после дебага пушишь себе в PR изменения и идешь на диван… но нет. будь добр длина строк 67 символов, два энтера запрещены, формат сообщения коммита не соответствует хрен пойми чему, обязательные табы, но не в отступах многострочных строк… господи да идите в сад

тотальное зло, но по другой причине: коммичу изменения в побочный реп, и какого-то хрена у меня запускатся npx что-то там - это как минимум небезопасно

я вообще интерпретаторы у себя на хосте не держу, все изолированно по контейнерам

Хуки не использую. Тонкие моменты тоже не использую. Conventional commits не соблюдаю. Что такое gitmoji не знаю, в целом стараюсь оставаться в рамках ASCII в тексте коммитов, сам туда точно никакие смайлики вставлять не буду, да я и не умею.

Наверное то, как я его использую, можно назвать «максимально деревянно». Самое продвинутое, что я использую, это rebase перед слиянием побочной ветки в основную, чтобы сохранять линейную историю. Не люблю, когда история превращается в развесистый граф, не умею в них ориентироваться.

Честно говоря, хотя гитом я пользуюсь уже лет 15, но я его команды так и не запомнил. Уже и не пытаюсь, они там постоянно новые придумывают. То checkout, то switch, то reset, причём делают одно и то же. Раньше гуглил, сейчас ИИ спрашиваю и всё. А рутинные операции зачастую вообще через IDE делаю.

Из практического. Запустил как-то коллега тесты, ать - код поломан, когда поломал и где - не помнит. «Ну», - говорю, - «показывай коммит, где ещё не сломано». Слово за слово, три или четыре итерации сделали, благо собирать быстро и тесты простые, и нашли поломку.

Сильно облегчает жизнь как раз заучивание самой-самой базы, а остальное баловство.

Алиасы помогают. Можно git s вместо git status, d вместо diff, итд.

Лично я ещё предпочитаю всегда ребейзить свои коммиты через git pull --rebase. История получается чистая, без кучи шума из ненужных мерджей, и все расхожие страшилки про ребейз неактуальны.

Conventional Commits

Всё это нужно чтобы жонглировать коммитами и фичами. Где-то это очень важно и реально помогает, но для большинства не нужно. К примеру если делать браузер, который уже давно стабилен, очень большой, и фичи/исправления могут в конце принять в релиз или передумать, то оно того стоит. Иначе, если просто все коммиты рекой идут в релиз, это имитация полезной деятельности.

Я б ещё рекомендовал монорепу вместо отдельных реп под бэкэнды/фронтэнды и прочее. Чуть меньше будет менеджмента версий, сборок и прочего барахла.

у тебя ссылки на немецком.
не то чтобы это так уж сильно мешало, немецкий практически все уже выучили по фильмам про сантехников. но все-таки.

А зачем вы там ноду берёте? Лепите на том во что команда умеет. Я себе на питоне леплю. Но я же их и пишу сам.

А зачем вы там ноду берёте? Лепите на том во что команда умеет. Я себе на питоне леплю. Но я же их и пишу сам.

Ну локально у меня нету ни питона, ни ноды. И проект не мой

А если не твой то не пофиг? Всё равно сорцы любого проекта сложнее хеллоуворлда сами по себе могут вредоносы содержать без всяких там хуков, которые не столь уж и велики, относительно его кодовой базы. Как по мне ерунда, если ЯП на котором хуки пишутся знают те кто с ними работают. Единственное что надо помнить - чужой софт которому не доверяешь всегда в виртуалке или подробно полностью изучается до любых make и прочего. Вон в zx в систему сборки уязвимость вкладывали, чтоб она её в код вносила. А могли просто майнер включить.

нахрена какие-то два инстанса, если есть «–no-verify», и есть официальный полноценный доступ к гит серверу? только ответственный за проект прогер вахтер, другие там адекватно настроили ci в мастере. смысл пуша что бы по-быстрому задаблить изменения. так то можно и в локальной репе работать, или зеркала поднимать, но суть в том что бы не отвлекаться когда есть инфра компании

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

да какая другая планета. там, что ли, на хабре вышла статья про pre-commit, так что мейнтенеры повтыкали модные конфиги на любые ветки

Не, я к тому что не хотел бы, находиться на одной планете с человеком, который два энтера не осилил. А вещи, перечисленные Вами должны автоматически делаться форматтером, а не вылавливаться линтером. Линтеру же остаются вещи типа названия переменных или цикломатической сложности. Первые поправить не сложно, а вторые должны выводиться как воринги, ибо не всегда понятно, что с ними делать.

Впрочем, если Вы про криво настроенный пре-коммит, тогда понимаю. Но это не значит, что хуки - зло по определению.

Эм, я хабр не читаю, конфигам лет 8.

И вообще он сильно опционален. У меня Visual Studio Code занимается форматированием кода в момент сохранения. Мне хватает.

А чего за двойной энтер? Мне даже интересно стало :-/

Например про хуки. Что используете в своих проектах? А на работе? Соблюдаете ли Conventional Commits

Собрал эту балалайку на PET проекте. Да, хуки, не пускают всякую срань в сообщении мимо соглашения при попытке закоммитить. Правда, как правильно дробить scope тоже не рассказывает.

Да в общем-то базы хватает, локальные хуки не нужны. Ну rebase и cherry-pick еще часто использую последнее время.

В оригинале было:

два энтера запрещены

Так что за подробностями к @zendrz.

Но вообще, в Питоне, например, двумя пустыми строками принято отделять сущности нулевого уровня (классы и функции), тогда как сущности первого и последующих (методы и вложенные функции) - одной. Про всё это знают форматтеры и линтеры. Ничего интересного, расходимся.

нахрена какие-то два инстанса

Один - инстанс команды. Второй - инстанс разработчика.

Второй нужен, чтобы разработчик через Web мог показать, что работа идёт, не вливая свой код в инстанс команды.

Вот как то относительно давно у меня ни как получалось прикрутить на git lfs. Вроде все по инструкции но работает не правильно.

И когда Федора перешла на открытый ФоргеЖо, тут все сразу возрулило. Можно даже посмеяться над клоунами с гитхаб-актионс ;)

Алиасы:

• git s - git status
• git d - git diff
• git l - git log –oneline -n 10

Git cherry-pick

Git blame

Git hooks

При коммитах всегда пишу тип действия и компонент:

• chore: backend: Adds new endpoint
• fix: db: Fixes indices
• tests: frontend: Adds initial tests
• chore: docs: Adds readme.md

Вроде из основного и всё

Бывают случаи, когда ваш напарник затирает код на сервере с флагом force, который вы писали 2 недели. Так вот, когда сотрёте свои отпечатки пальцев и следы крови бывшего напарника с канделябра, можете воспользоваться замечательной командой git reflog.

более тонкие моменты, которые сильно облегчают жизнь

$ man git-extras

Самое большое открытие по git за последний год - теперь ИИ отлично рулит ветками за тебя. Так что про изучение консольных команд можно забыть)

https://medium.com/engineering-playbook/i-ran-the-5-git-commands-before-opening-any-new-codebase-and-it-saved-me-3-hours-every-single-b7062b946196

Ты ветки изобретаешь?

Ветки могут попасть под все те проверки и хуки, о которых написано выше