🤯 Работа с конфликтами слияния (merge) и перебазирования (rebase) в Git может быть сложной и трудозатратной, особенно в больших проектах или при частых изменениях. Здесь на помощь приходит малоизвестная, но мощная функция Git — git rerere (reuse recorded resolution).

🛠 Этот инструмент позволяет Git запоминать, как вы разрешали конфликты, и автоматически применять эти решения в будущем, существенно упрощая процесс разрешения повторяющихся конфликтов.

📌 Существует несколько ситуаций, в которых данный функционал может пригодиться:

1️⃣ Один из примеров состоит в том, чтобы обеспечить в будущем простоту слияния некоторой долгоживущей ветки, не создавая при этом набор промежуточных коммитов слияния.

При использовании rerere вы можете время от времени выполнять слияния, разрешать конфликты, а затем откатывать слияния. Если делать это постоянно, то итоговое слияние должно пройти легко, так как rerere сможет разрешить все конфликты автоматически.

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

2️⃣ Другая ситуация возникает, когда вы изредка сливаете несколько веток, относящихся к ещё разрабатываемым задачам, в одну тестовую ветку. Если тесты завершатся неудачей, вы можете откатить все слияния и повторить их, исключив из них ветку, которая поломала тесты, при этом не разрешая конфликты снова.

📌 Для включения функциональности rerere достаточно изменить настройки следующим образом:

$ git config --global rerere.enabled true

После этого Git начнет автоматически записывать и применять решения для конфликтов.

💡Помните, что такими долгоживущими ветками не стоит злоупотреблять. Хорошая ветка живёт день-два и уезжает в main (ну или в версию, если у вас одновременно живёт несколько веток).

👉 Подробнее

#советыдляразрабов

Пикассо однажды сказал: «Главный враг творчества — здравый смысл»

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

😎 Поэтому сегодняшний материал про искусство overkill, но с упором на веб-разработку. Автор размышляет про выбор хостинга, API, потоковой передаче данных, базы данных, системы полнотекстового поиска, мер безопасности, мониторинга, логирования и стратегий кэширования. Где-то с ним можно согласиться, где-то — нет. Но посыл о том, что не стоит усложнять там, где это не нужно, абсолютно верный!

🤯 И чтобы у вас больше не было такого:

Мой простенький блог размещён в S3 buckets за CDN и генерируется с помощью кода Python, который применяет HTML-шаблоны на основе Jinja к файлам Markdown. Почему? Потому что я могу!

👉 Читайте статью на Medium или в PDF (в комментариях к посту)

😳🧰 Сеньор фиксит баги на проде — обычный рабочий момент

#жиза