Стратегии ветвления в Git

При управлении кодом в разработке ПО выбор правильной стратегии ветвления напрямую влияет на командную работу, интеграцию и процесс деплоя.

Вот основные стратегии ветвления в Git:

1. Feature Branching (ветки под фичи)

Создаётся отдельная ветка для каждой фичи или багфикса. Разработчики работают с этими ветками независимо, а после завершения и ревью — вливают изменения в основную ветку (обычно main или develop).

Подходит для команд, где важен строгий код-ревью и фичи разрабатываются изолированно.

2. Gitflow

Модель ветвления с чётким процессом управления релизами. Используются ветки develop, release, hotfix, feature — каждая со своей ролью в процессе разработки.

Лучше всего подходит для крупных проектов с запланированными циклами релизов.

3. GitLab Flow

Комбинирует идеи Feature Branching и Gitflow, но делает их проще. С акцентом на деплой и интеграцию с issue-трекингом и CI/CD.

Стратегия включает основную ветку (main), которая отражает продакшен-код, и при необходимости — отдельные ветки под окружения (например, staging, production и т.д.).

Подходит для команд, использующих GitLab и практики непрерывной поставки (CD).

4. GitHub Flow

Лёгкий и понятный процесс на основе веток, отлично подходит под continuous deployment. Ветка main всегда должна быть в деплойном состоянии. Фичи разрабатываются в отдельных ветках от main, изменения проходят через pull request.

Хороший выбор для небольших команд и проектов с постоянными поставками.

5. Trunk-Based Development

Все разработчики коммитят напрямую в основную ветку (trunk). Фичевые ветки либо очень короткоживущие, либо не используются вовсе.

Подходит для команд, практикующих CI/CD, и проектов, где приоритет — скорость разработки.

Если ты только начинаешь работать с Git — начни с простой стратегии вроде GitHub Flow и эволюционируй по мере роста команды и сложности проекта.

Для больших команд или сложных процессов лучше использовать более структурированные подходы, такие как Gitflow или GitLab Flow.

Независимо от выбранной стратегии ветвления, важно:

- Настроить автоматическое тестирование, чтобы быстрее ловить баги.
- Согласовать стандарты по commit-сообщениям, нейминг веток и процессам слияния.

👉 Java Portal

Загрузка Java-модуля во время выполнения

Можно загрузить Java-модуль во время выполнения, создав экземпляр ModuleLayer:

// /tmp/ModuleLoad.java
void main() throws Exception {
    Path h2 = Path.of("/tmp/h2-2.3.232.jar");
    ModuleFinder before = ModuleFinder.of(h2);
    ModuleFinder after = ModuleFinder.of();
    Set<String> roots = Set.of("com.h2database");

    ModuleLayer parentLayer = ModuleLayer.boot();
    Configuration parentConf = parentLayer.configuration();
    Configuration conf = parentConf.resolve(before, after, roots);
    ClassLoader scl = ClassLoader.getSystemClassLoader();
    ModuleLayer layer = parentLayer.defineModulesWithOneLoader(conf, scl);

    ClassLoader cl = layer.findLoader("com.h2database");
    Class<?> c = cl.loadClass("org.h2.tools.Shell");
    Method main = c.getMethod("main", String[].class);
    Object args = new String[0];
    main.invoke(null, args);
}

Один из возможных кейсов — реализация плагин-системы в приложении.
Другой кейс — запуск всего приложения через начальный загрузчик, выполняя:

java Way.java

Иными словами, файл Way.java выступает в роли скрипта, который:

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

Это базовая идея, лежащая в основе Objectos Start.

👉 Java Portal

Вредные советы Java

Автор показывает соблазн простого распараллеливания задач на Java через Stream API и .parallel() вместо явных ExecutorService, Future, invokeAll и ручной обработки InterruptedException

Однако такой подход использует common ForkJoinPool, и его поведение не всегда предсказуемо, результаты могут отличаться между запусками, особенно при исключениях в задачах
(callsCounter может сильно варьироваться)

Если в процессе одна из задач выбрасывает Exception, выполнение остальных может продолжаться
даже после возврата ошибки.

Параллельные стримы группируют задачи по частям коллекции, и минимальной единицей
может быть блок из нескольких элементов, это может привести к «неравномерной» нагрузке и даже ухудшению производительности по сравнению с ручным управлением через ExecutorService.

Блокирующие операции внутри задач могут полностью "забить" common ForkJoinPool, что повлияет и на выполнение CompletableFuture.thenApplyAsync(), если вы не указали свой Executor

Читать подробнее<...>

👉 Java Portal

Учись проектировать через объектно-ориентированные паттерны на Java.

Интерактивный курс от профессора Computer Science Марка Махони.

Освоишь: Composite Pattern, Observer Pattern, Visitor Pattern и другие.

Интерактивный формат, всё по делу:

Курс → https://freecodecamp.org/news/object-oriented-design-patterns-with-java/

👉 Java Portal

Инструменты для проектирования архитектуры ПО

Лучшие бесплатные и платные инструменты для моделирования и создания архитектурных диаграмм.

➖ Инструменты моделирования:

• Enterprise Architect
• Archi
• Structurizr
• Carbide
• StarUML
• Aplas
• GenMyModel
• Gaphor
• Archipeg
• Astah
• Mood

➖ Code-based инструменты

• PlantUML
• Structurizr
• Ilograph
• Graphviz
• Mermaid
• Diagrams

➖ Автоматизированные инструменты:

• Brainboard
• Hyperglance
• Hava
• Archium

➖ Инструменты для создания диаграмм:

• Visio
• Lucidchart
• [Draw.io](https://draw.io)
• Cloudcraft
• isoflow
• Visual Paradigm
• Cacoo
• Cloudviz
• Excalidraw
• CloudSkew
• Figma
• Whimsical
• Miro
• Mural
• Sketch

Полный список: softwarearchitecture.tools

👉 Java Portal

Алгоритмы Bloom Filter - быстрый поиск при минимальном потреблении памяти

🔸Во многих системах поиска, хранения и обеспечения безопасности данных проверка принадлежности элемента к большому множеству это серьёзная задача. Алгоритм Bloom Filter предлагает эффективное решение этой проблемы: он использует компактные структуры данных и позволяет быстро проверять наличие элемента без необходимости хранить всё множество целиком.

🔸В основе Bloom Filter - битовый массив и несколько хеш-функций. При добавлении нового значения хеш-функции определяют позиции в массиве и устанавливают соответствующие биты в 1. При проверке, если все указанные позиции уже установлены в 1, существует высокая вероятность того, что элемент присутствует во множестве. Этот подход применяется в поисковых системах, кэшах вроде Redis, системах фильтрации спама и сетевых фильтрах.

🔸Если вам нужен эффективный способ для быстрой проверки принадлежности к большим наборам данных, Bloom Filter это лёгкое и высокопроизводительное решение.

👉 Java Portal

Привет. Вот тебе самые топовые каналы по IT!

⚙️ Free Znanija (IT) — Самая огромная коллекция платных курсов, которые можно скачать бесплатно;

👩‍💻 IT Books — Самая огромная библиотека книг;

💻 Hacking & InfoSec Base — Крутой блог белого хакера;

🛡 CyberGuard — Всё про ИБ;

🤔 ИБ Вакансии— Всё, чтобы найти работу в ИБ;

👩‍💻 linux administration — Всё про Линукс;

👩‍💻 Программистика — Python, python и ещё раз python;

👩‍💻 GameDev Base — Всё про GameDev;

🖥 Coding Base — Мемы, полезные репозитории и инструменты, а так же софт:

😆 //code — Самые топовые мемы по IT:

А так же крутой блог админа: Rahol Jey | тг вайб

Как обработать 1 миллион API-запросов в минуту

1. Балансировка нагрузки

Проблема:
Один сервер не выдерживает 1M запросов/мин: перегрузка CPU и памяти, начинается дроп запросов.

Решение:

- Использовать балансировщик нагрузки (NGINX, HAProxy, AWS ELB) для распределения трафика между множеством серверов
- Добавить проверки состояния , чтобы не направлять трафик на нерабочие инстансы
- Настроить авто-масштабирование, чтобы запускать новые инстансы при всплеске трафика

2. Кеширование

Проблема:
Каждый запрос бьет по базе → база становится узким местом (исчерпание соединений, медленные запросы).

Решение:

Добавить уровни кеширования:

- CDN для статических ресурсов (изображения, CSS, JS)
- Redis/Memcached для повторяющихся запросов
- Настроить правила инвалидации кеша, чтобы данные оставались актуальными

> Вместо 1M запросов к базе, возможно, только 100K дойдут после кеширования.

3. Ограничение частоты запросов

Проблема:
Всплеск активности (например, от ботов или злоумышленников) перегружает инфраструктуру → хорошие пользователи получают 503.

Решение:

- Алгоритмы Token Bucket / Leaky Bucket: позволяют короткие всплески, но сохраняют стабильный поток
- Разные лимиты для аутентифицированных и анонимных пользователей
- Возвращать 429 Too Many Requests — корректно и информативно

> Защищает инфраструктуру: один плохой пользователь не портит всё остальным.

4. Асинхронная обработка

Проблема:
Некоторые запросы тяжелые (обработка файлов, аналитика, отправка писем). Если делать их синхронно — ответ замедляется.

Решение:

- Выносить тяжёлые задачи в очередь (Kafka, RabbitMQ, SQS)
- Отвечать сразу с кодом 202 Accepted, обработку запускать в фоне
- Воркеры обрабатывают очередь и выполняют задачи

> Пользователи получают быстрый ответ, тяжёлая работа происходит «за кулисами».

5. Мониторинг и обратное давление

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

Решение:

- Мониторить глубину очередей, задержки при доступе к БД, hit rate кеша
- Применять backpressure: замедлять запросы или отбрасывать нагрузку при приближении к лимитам
- Настроить алерты: Prometheus/Grafana, Datadog, New Relic

👉 Java Portal