1️⃣Структурированный формат: каждое сообщение коммита следует определенному формату:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)], где
•
type обозначает тип изменений (например, feat, fix, chore).•
scope является необязательным и указывает часть проекта, к которой относится коммит (например, компонент или файл).•
description — краткое описание сделанных изменений.2️⃣Семантическое версионирование: поддерживает семантическое версионирование, позволяя автоматически генерировать версии и записи изменений.
3️⃣Четкое разделение: помогает разделять различные типы изменений для более четкого понимания и организации истории изменений.
4️⃣Автоматизация: позволяет разработчикам использовать скрипты для автоматизации различных частей рабочего процесса разработки, таких как генерация заметок о выпуске или определение следующей версии.
5️⃣Совместимость с другими системами: соглашение обеспечивает совместимость с другими системами и инструментами, которые могут обрабатывать семантику сообщений коммитов.
#советыдляразрабов
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔Хотите знать, что происходит под капотом Git? Достаточно просто включить подробные логи выполняемых действий. Возможные значения приведённых ниже переменных окружения: true/1/2; вывод осуществляется в stderr.
🔹GIT_TRACE задаёт логирование действий, не подпадающих под какую-либо определённую категорию:
$
🔹GIT_TRACE_PACK_ACCESS задаёт логирование обращений к pack-файлам:
$
🔹GIT_TRACE_PACKET задаёт логирование пакетов при операциях с сетью:
$
🔹GIT_TRACE_PERFORMANCE задаёт логирование данных о производительности:
$
🔹GIT_TRACE_SETUP задаёт логирование информации о репозитории и окружении, с которым взаимодействует Git:
$
#советыдляразрабов
🔹GIT_TRACE задаёт логирование действий, не подпадающих под какую-либо определённую категорию:
$
GIT_TRACE=true git lga🔹GIT_TRACE_PACK_ACCESS задаёт логирование обращений к pack-файлам:
$
GIT_TRACE_PACK_ACCESS=true git status🔹GIT_TRACE_PACKET задаёт логирование пакетов при операциях с сетью:
$
GIT_TRACE_PACKET=true git ls-remote origin🔹GIT_TRACE_PERFORMANCE задаёт логирование данных о производительности:
$
GIT_TRACE_PERFORMANCE=true git gc🔹GIT_TRACE_SETUP задаёт логирование информации о репозитории и окружении, с которым взаимодействует Git:
$
GIT_TRACE_SETUP=true git status#советыдляразрабов
🤔Если вам необходимо интегрировать Git в приложение, то здесь есть два основных кейса: запустить шелл и выполнять команды Git в нём или добавить библиотеку Git и использовать её.
🧰Git из командной строки — простой способ, при котором вы порождаете шелл и используете Git для выполнения задач. Этот подход имеет как плюсы, так и минусы.
➕Каноничность и поддержка всех возможностей Git. Это наиболее простой подход, т. к. большинство сред исполнения предоставляют достаточно простые средства вызова внешних процессов с параметрами командной строки.
➖Результат выполнения команд представлен в виде простого текста.
➖Отсутствие восстановления после ошибок.
➖Необходимость управления порождённым процессом.
🧰Использование библиотеки Libgit2. Это свободная от внешних зависимостей реализация Git, ориентированная на предоставлении API другим программам.
🧰Использование библиотек для конкретных ЯП, таких как JGit (Java), go-git (Go) и Dulwich (Python).
👉 Подробнее
#советыдляразрабов #инфографика
🧰Git из командной строки — простой способ, при котором вы порождаете шелл и используете Git для выполнения задач. Этот подход имеет как плюсы, так и минусы.
➕Каноничность и поддержка всех возможностей Git. Это наиболее простой подход, т. к. большинство сред исполнения предоставляют достаточно простые средства вызова внешних процессов с параметрами командной строки.
➖Результат выполнения команд представлен в виде простого текста.
➖Отсутствие восстановления после ошибок.
➖Необходимость управления порождённым процессом.
🧰Использование библиотеки Libgit2. Это свободная от внешних зависимостей реализация Git, ориентированная на предоставлении API другим программам.
🧰Использование библиотек для конкретных ЯП, таких как JGit (Java), go-git (Go) и Dulwich (Python).
👉 Подробнее
#советыдляразрабов #инфографика
💡Как сделать неправильный код заметным: по мотивам статьи 2005 года от Joel Spolsky, автора Trello и сооснователя Stack Overflow
Джоэл обсуждает идею о том, что писать код так, чтобы упростить обнаружение потенциальных проблем. Для этого он предлагает различные конвенции именования и структурирования кода, а также расширяет уже существующие.
📌 Несколько примеров кода, основанных на материалах статьи:
1. Венгерская нотация для разделения безопасных и небезопасных строк:
✔️ Небезопасная строка (например, ввод пользователя):
✔️ Безопасная строка:
Пример использования:
2. Использование типов для предотвращения ошибок: вместо использования обычных типов, создайте новые типы, которые будут явно указывать на специфику использования.
Пример на C++:
3. Семантическая разница между похожими действиями:
✔️Явное разделение функций с похожими действиями, но разными последствиями.
Пример на Python:
#советыдляразрабов #холивар
Джоэл обсуждает идею о том, что писать код так, чтобы упростить обнаружение потенциальных проблем. Для этого он предлагает различные конвенции именования и структурирования кода, а также расширяет уже существующие.
📌 Несколько примеров кода, основанных на материалах статьи:
1. Венгерская нотация для разделения безопасных и небезопасных строк:
✔️ Небезопасная строка (например, ввод пользователя):
usUserInput✔️ Безопасная строка:
sSafeStringПример использования:
char *usUserInput = getUserInput();
char *sSafeString = sanitizeInput(usUserInput);
2. Использование типов для предотвращения ошибок: вместо использования обычных типов, создайте новые типы, которые будут явно указывать на специфику использования.
Пример на C++:
struct SafeString { std::string value; };
struct UnsafeString { std::string value; };
SafeString sanitize(UnsafeString us) {
// ...
return SafeString{/* ... */};
}
3. Семантическая разница между похожими действиями:
✔️Явное разделение функций с похожими действиями, но разными последствиями.
Пример на Python:
def delete_file_safe(file_path):
# Безопасное удаление файла с проверками
pass
def delete_file_force(file_path):
# Принудительное удаление файла без проверок
pass
#советыдляразрабов #холивар
Joel on Software
Making Wrong Code Look Wrong
Way back in September 1983, I started my first real job, working at Oranim, a big bread factory in Israel that made something like 100,000 loaves of bread every night in six giant ovens the size of…
📌 Git flow — стратегия ветвления, полезная для команд, у которых есть четкие процессы выпуска и необходимость поддерживать стабильность своих продакшн-окружений.
Однако зависимость от множества веток и правил добавляет много сложности к процессу. Это может быть непосильно для новых членов команды и может привести к конфликтам из-за несоблюдения принципов непрерывной интеграции.
📌 GitHub flow — легковесная стратегия ветвления, хорошо подходящая для команд, практикующих непрерывный деплой. Эта стратегия подчеркивает совместную работу, частые выпуски и упрощенный процесс разработки.
Учитывая ее простоту, GitHub flow лучше всего подходит для небольших команд и проектов. Однако по мере увеличения размера и сложности становится сложно управлять изменениями во всей кодовой базе.
📌 Trunk-based development — стратегия ветвления, при которой разработчики работают над кодом в одной ветке, называемой
trunk. Она требует прямых пушей в trunk и совместной работы разработчиков для поддержания стабильной ветки trunk. Поскольку изменения непрерывно интегрируются в
trunk, существует более высокий риск внесения изменений, которые могут повлиять на стабильность всей системы.📌 Space Git flow — стратегия ветвления от JetBrains, похожая на GitHub flow, но с бо́льшим акцентом на безопасность при внесении изменений в ветку
main и возможностью масштабирования до крупных проектов и команд. 💬 Каждая стратегия имеет свои сильные и слабые стороны, и лучший выбор зависит от конкретных потребностей вашей команды, а также таких факторов, как размер команды, процесс разработки, частота деплоя и требования к качеству кода.
👉 Подробнее здесь и здесь
#советыдляразрабов
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
merge) и перебазирования (rebase) в Git может быть сложной и трудозатратной, особенно в больших проектах или при частых изменениях. Здесь на помощь приходит малоизвестная, но мощная функция Git — git rerere (reuse recorded resolution). 🛠 Этот инструмент позволяет Git запоминать, как вы разрешали конфликты, и автоматически применять эти решения в будущем, существенно упрощая процесс разрешения повторяющихся конфликтов.
📌 Существует несколько ситуаций, в которых данный функционал может пригодиться:
1️⃣ Один из примеров состоит в том, чтобы обеспечить в будущем простоту слияния некоторой долгоживущей ветки, не создавая при этом набор промежуточных коммитов слияния.
При использовании
rerere вы можете время от времени выполнять слияния, разрешать конфликты, а затем откатывать слияния. Если делать это постоянно, то итоговое слияние должно пройти легко, так как rerere сможет разрешить все конфликты автоматически.Такая же тактика может быть использована, если вы хотите сохранить ветку легко перебазируемой, то есть вы не хотите сталкиваться с одними и теми же конфликтами каждый раз при перебазировании.
2️⃣ Другая ситуация возникает, когда вы изредка сливаете несколько веток, относящихся к ещё разрабатываемым задачам, в одну тестовую ветку. Если тесты завершатся неудачей, вы можете откатить все слияния и повторить их, исключив из них ветку, которая поломала тесты, при этом не разрешая конфликты снова.
📌 Для включения функциональности
rerere достаточно изменить настройки следующим образом:$ git config --global rerere.enabled true
После этого Git начнет автоматически записывать и применять решения для конфликтов.
👉 Подробнее
#советыдляразрабов
Please open Telegram to view this post
VIEW IN TELEGRAM