За несколько месяцев активного внедрения git в компании я понял, что практически все обучающие статьи по этой теме бесполезны. Главная их проблема — они написаны для одиночек и почти полностью игнорируют аспекты командной работы именно технических специалистов. Технарям не нужно детально объяснять, как инициализировать новый репозиторий или как коммитить изменения, это всё ненужная механическая информация, которую легко найти, но вот даже базового понимания, как работает git, оно не даёт. К сожалению, в git очень много команд и очень много «непонятных» и «тупиковых» ситуаций, возникающих на ровном месте. Я специально пишу «непонятных», так как бо́льшая часть из них разруливается очень просто, нужно только понимать, что именно произошло.

Если вы хотите с разбега погрузиться во внутренности git, очень рекомендую статью Git from the inside out, в ней детально расписываются низкоуровневые механизмы работы репозитория.

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

Также я старался все разделы статьи упорядочить по мере усложнения и расширения концепции. Все примеры кода должны воспроизводиться у каждого. Крайне желательно иметь linux/macos с терминалом под рукой. О совсем примитивных вещах типа установки git я тут писать не буду.

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

В unix-системе питоновские пакеты совсем не обязательно нужно ставить в системные каталоги (в /usr/, например). Благодаря virtualenv, пакеты можно установить в любой каталог, инициализировать локально окружение в терминале через специальный скрипт и дальше пользоваться всеми установленными в том каталоге библиотеками и программами. Локальный набор пакетов очень удобен для разработчика, так как позволяет на одной системе переключаться между разными их версиями.

В статье я описываю не только концепт, но и всю процедуру подготовки локального окружения. Сразу же уточнение: всё работает только в терминале, то есть вы запускаете терминал, «активируете» в нём нужный каталог с пакетами и дальше в этом терминале работаете. Базовая операционная система — linux, *bsd или mac os x. Windows я не рассматриваю.

Итак, нам понадобится установленный системно python3. Для линукса он ставится из пакетов вашего репозитория, для макоси — скачивается с офсайта https://www.python.org/downloads/mac-osx/ или через brew. В принципе, можно пользоваться штатной версией из макоси, но она гарантированно не будет последней. Например, в Macos Sonoma 14.5 штатно установлен python3 версии 3.9.6, хотя через brew уже доступна 3.12.3 (июнь 2024 года).

Целевая аудитория этой статьи — айтишники, поверхностно знакомые с понятием цифрового сертификата и сопутствующими техническими стандартами.

Эта статья уже во многом устарела и я рекомендую вместо неё сразу читать новую и полностью переработанную: Ещё больше и лучше о цифровых сертификатах: X.509, PKI, PKCS

Цифровые (электронные) сертификаты используются повсеместно, самая известная область их применения — это шифрование HTTPS-трафика в браузере. В таком виде с сертификатами знакомы все, однако более-менее адекватного понимающих гораздо меньше. Многие статьи на эту тему с самого начала топят читателя в абстрактных и несущественных деталях (например, раз, два, три). Между тем, базовые концепции системы сертификатов очень простые и я о них расскажу в этой статье. Эти концепции в моём изложении не являются абсолютно точными, но зато они помогут «въехать» в тему.

Традиционный дисклеймер: все примеры ориентированы на линуксовую, юниксовую или макосную консоль. Если хотите самостоятельно повторить куски консольного кода, поставьте openssl, например, через sudo apt-get install openssl

По умолчанию GIMP подхватывает все системные шрифты макоси, а их очень много, причём бо́льшая часть бесполезна и только мешает. Из настроек программы это никак не регулируется.

Я предполагаю, что вы используете официальную сборку GIMP с официального сайта.

GIMP использует fontconfig для поиска доступных шрифтов, а конфигурационный файл для fontconfig хранится в /Applications/GIMP.app/Contents/Resources/etc/fonts/fonts.conf, поэтому просто открываем его любым редактором и комментируем строчки, содержащие пути к системным каталогам со шрифтами (это /Library/Fonts и /System/Library/Fonts). Можно также добавить свои каталоги, чтобы искать шрифты для редактора специально в них.

Вот пример уже отредактированной секции:

    <dir>/usr/share/fonts</dir>
    <dir>~/Library/Fonts</dir>
    <dir>~/Library/GimpFonts</dir>
    <!--<dir>/Library/Fonts</dir>-->
    <!--<dir>/System/Library/Fonts</dir>-->
    <dir prefix="xdg">fonts</dir>
    <!-- the following element will be removed in the future -->
    <!--<dir>~/.fonts</dir>

Здесь закомментированы каталоги /Library/Fonts и /System/Library/Fonts, а также добавлен каталог ~/Library/GimpFonts (в него я добавил симлинки на действительно нужные системные шрифты из /Library/Fonts и /System/Library/Fonts).

Дальше перезапускаем программу и всё.

Также я написал скрипт, который автоматизирует все описанные операции и делает чуть больше, его можно скачать с моего гитхаба fix-mac-gimp-fonts.

Дополнение 2025 года

Начиная с какой-то версии macos, уже нельзя просто так отредактировать приложение. Операционная система это определяет и не даёт его больше запускать, выдавая сообщение типа App Is Damaged And Can’t Be Opened. Отредактированные приложения попадают в карантин и его извлечь оттуда можно такой командой:

$ xattr -dr com.apple.quarantine /Applications/GIMP.app

После чего запускаем снова и оно должно открыться.

В современном андроиде версии 4 или выше через кабель невозможно нормально добраться до главного раздела, так как доступ к нему открыт только через глючный и тормозной MTP, а с линуксом ещё хуже — там вообще нет нормальной поддержки MTP.

Многие выкручиваются так: поднимают на девайсе какой-нибудь сервер (обычно FTP), а дальше к нему подключаются через Wi-Fi; затем можно через любой FTP-клиент копировать файлы с девайса и назад. Есть и недостатки: не очень безопасно и часто очень медленно.

Но выход есть и называется он USB-tethering.

По умолчанию в Time Machine бэкапится практически всё, включая совершенно ненужные файлы и каталоги — кеши, временный файлы и т.п.

В исключения надо добавить вот такие каталоги (для добавления произвольного каталога в селекторе файлов нужно нажать Shift+Cmd+g):

/var/vm

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

/Library/Caches

~/Library/Caches

Разнообразные бесполезные для бэкапа кеши

~/Downloads

Скачанные файлы тоже в бэкапе не нужны

Также дополнительно нужно исключить:

~/Library/Application Support/Google/Chrome/Default/Application Cache

~/Library/Application Support/Google/Chrome/Profile 1/Application Cache

~/Library/Application Support/Yandex/YandexBrowser/Default/File System

Браузерные кеши, если вы пользуетесь профилями в браузере, то придётся ещё и кеши для них исключать (Profile 1 и т.д.).

Образы ненужных виртуальных машин.

Примонтированные защищённые разделы, например, через encfs.

Разнообразные медиа-каталоги, например, ~/Movies.

Каталоги с временными файлами, например, /tmp и ~/tmp (если вы такой локально используете).

Возможно, имеет смысл исключить из бэкапа сетевые хранилища типа Dropbox или YandexDisk.

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

Есть ещё один подозрительный каталог — /private/var/folder, в него складывает скачиваемые файлы app store, например. И если установка какого-нибудь пакета сорвалась, этот файл будет там валяться. Система иногда при перезагрузке этот каталог чистит, поэтому я рекомендую перед бэкапом перезагружать машину, на всякий случай.

См. также http://essentialmac.co.uk/apple-mac-iphone-how-to/what-folders-to-exclude-from-time-machine-backups/

Если запускать Chrome в KDE с выключённым режимом Use system title bar and borders, то кнопки в заголовке окна всегда будут выравнены по правому краю:

Никакими штатными настройками такое поведение изменить невозможно — Chrome при запуске определяет, в каком Desktop Environment он запускается, и если это Metacity/Compiz/Unity, то берёт часть настроек из gconf, в частности — расположение кнопок в заголовке.

Традиционный дисклеймер — все советы ниже годятся для Debian/Ubuntu.

Заставить Chrome «увидеть» себя в другом DE просто, достаточно выставить в переменной окружения XDG_CURRENT_DESKTOP значение Unity. Глобально это не надо делать, лучше всего сделать отдельный sh-скрипт для запуска такого «модифицированного» браузера. Также необходимо установить пакет gconf2, а затем выставить нужный порядок кнопок, например, выполнив такую команду в терминале (это нужно сделать всего один раз):

gconftool-2 --set /apps/metacity/general/button_layout --type string "minimize,maximize,close:"

Получится примерно так:

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

Естественно, есть и проблемы — настройки прокси теперь будут искаться в настройках gnome/unity, поэтому если хотите их конфигурить, ставьте соответствующие пакеты (например, gnome-control-center) или указывайте прокси в аргументах запуска браузера, а также можно пользоваться стандартными переменными окружения типа (http_proxy, auto_proxy, auto_proxy и т.п.)

А вот готовый скрипт:

#!/bin/sh

export XDG_CURRENT_DESKTOP=Unity
google-chrome

Для второго питона:

python -m SimpleHTTPServer 9090

Для третьего:

python3 -m http.server 9090

Вместо порта 9090 можно указать другой. По умолчанию цепляется ко всем сетевым интерфейсам, но можно указать и конкретный, например:

python3 -m http.server --bind 127.1.2.3 9090

В питоне есть модуль logging, через который приложение может выводить логи, например, в терминал при отладке программы. По умолчанию вывод выглядит просто как сплошной поток текста, однако его можно раскрасить, чтобы разные типы сообщений (DEBUG, INFO и т.п.) печатались разными цветами. Для этого нужно сконфигурировать форматер логов и протащить его в программу, сделать это можно разными способами в ini-файле проекта или внутри самой программы.

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

Чтобы результат селектов в консольном клиенте sqlite3 выглядел по-человечески, нужно в конфиге программы (файл ~/.sqliterc) написать такое:

.headers on
.mode line

При таком конфиге выводе селектов будет примерно таким:

sqlite> select * from track limit 2;
       id = 1
   dir_id = 3
 filename = 01 - хора.mp3
    title = хора
  modtime = 
artist_id = 1
 genre_id = 1
 album_id = 1
    track = 1
   length = 232
     year = 2003

       id = 2
   dir_id = 3
 filename = 02 - айда, недо.mp3
    title = айда, недо
  modtime = 
artist_id = 1
 genre_id = 1
 album_id = 1
    track = 2
   length = 184
     year = 2003