Семен

1. Гит в истории целые файлы, уже измененные, но сжатые (изменения хранит SVN, но у него другая модель работы)
2. Сравнение файлов происходит через сравнение хэша файла. История изменений хранится в виде графа, поэтому переключение - это по сути: 1. Найти общего предка 2. Откатиться до этого предка 3. Применить изменения до новой ветки. Дополнительно, если у тебя есть незакоммиченные текущие изменения, то гит тебе об этом скажет
3. Скачивается вся история изменений из удаленного репозитория и потом HEAD выставляется на ветку, которую клонировал (в основном это main/master)

Почитай как работает git

UPD: спасибо Saboteur за важное замечание

Вообще-то как раз гит хранит целые копии файла.
Для каждого файла создается его хеш, и файл-объект хранится под именем с этим кешом.

If you again examine your objects directory, you can see that it now contains a file for that new content. This is how Git stores the content initially — as a single file per piece of content, named with the SHA-1 checksum of the content and its header. The subdirectory is named with the first 2 characters of the SHA-1, and the filename is the remaining 38 characters.

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

Каждый коммит - содержит список файлов и хеш для содержимого.
А ветка - это просто ссылка на конкретный коммит и немного метаданных.

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

Чтобы посмотреть содержимое любого гит-объекта, юзай
git cat-file -p ID_объекта (где айди объекта это как раз его хеш)

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

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

Curses? В ней можно использовать методы clear() и refresh() для обновления данные консоли без мерцания.

Отнаследуйте любого продавана от базового класса, а дальше добавьте поле кто он такой

Это, по сути, наследование. Абстрактный класс-предок (поставщик) и конкретные классы-потомки (физлицо, ИП, организация). Наследование обычно выражается в структуре БД так: создаётся таблица "Поставщик", содержащая общие для всех классов поля и имеющая свой ключ.
Затем под каждый класс-потомок создаётся отдельная таблица, содержащая сведения, уникальные для этого класса. В этой таблице первичный ключ одновременно является внешним ключом, ссылающимся на таблицу "Поставщик". Иными словами, в таблице-потомке могут быть только записи с ключами, которые есть в таблице "Поставщик", а для каждой записи в "Поставщик" будет не более одной записи в таблице-потомке.

В таблице "Поставщик" также может быть поле, указывающее на конкретный тип поставщика (физлицо, ИП, организация), т.е. в какой таблице искать остальные данные. Наличие или отсутствие этого поля - вопрос вкуса. В принципе, если нам нужны сведения о конкретном типе поставщика, мы можем попытаться сделать INNER JOIN с нужной конкретной таблицей. Это отсеет все записи других типов.
Такой подход (без поля типа) позволяет избежать противоречий, когда запись находится в одной таблице-потомке, а поле указывает на другую. Но с другой стороны, если мы не знаем, какой конкретный тип у данного поставщика, нам придётся либо перебирать таблицы-потомки в рамках нескольких запросов к БД, либо делать LEFT JOIN со всеми таблицами-потомками, и смотреть, какие поля не будут NULL.

Слабая сторона такой схемы в том, что связь по внешнему ключу не запрещает существование записей в нескольких таблицах-потомках, ссылающихся на одну и ту же запись в "Поставщике". Это придётся контролировать отдельно, триггерами или хранимыми процедурами.

Просто берëшь и записываешь. В чëм проблема?

with open('test.hex', 'wb') as f:
    f.write(b'\x00\x01\x02')

Ссылка на файл на серверах Telegram - это плохо. Во-первых, она содержит токен бота (может утечь), во-вторых, она может меняться со временем. В большинстве ситуаций полагается передавать file_id, но для thumb_url надо передавать именно URL. Так что увы - придётся самому куда-то публиковать картинки.

Скачивание файла вызывает заголовок Content-Disposition ответа.

Я как раз сегодня сделал себе похожую вещь. Тоже благодаря помощи тут, так что я попробую и тебе помочь)
Без отправки хотя бы себе в личку способа не знаю, да и его нет наверное, так что вариант через отправку себе файлов.
Не знаю как тебе лучше будет хранить file_id, но я у себя сделал базу данных в sqlite(она встроена в питон).
Суть такова, настрой бота, что бы он из твоей директории отправлял фото в личку тебе, а после отправки сохранял file_id в базу данных.

from aiogram.types import InputFile
......
photos = InputFile(f'D:\\Code\\english\\photo\\{eng}\\{eng}.jpg') # это пример моей директории
id_photo = await bot.send_photo(chat_id=message.chat.id, photo=photos) # этот метод поможет получить file_id
id = id_photo['photo'][0]['file_id'] # это сам file_id

Я делал в aiogram у тебя должен быть похожий метод взять файл ботом из директории

Как настроить сохранение зависит уже от тебя, будешь ли ты добавлять этот id в базу данных или в переменную, да хоть в текстовый файл. Я лично настроил добавление в базу, и за 10 минут залил 600 фоток в тг с пометками что к чему относится, потом же удобнее будет их доставать

Я решал эту задачу так: при первой отправке файла я его отправлял как файл, запоминая file_id в словаре и в таблице в базе, а при следующей уже имел готовый file_id. При этом я могу в любой момент добавлять файлы, не задумываясь о том, загружал ли я их уже в Telegram или нет.

files = {}
def load_files():
  global files
  res = db.execute("SELECT file_name,file_id FROM files")
  files = {}
  for row in res:
    file_name, file_id = row
    files[file_name] = file_id

def save_file(file_name, file_id):
  global files
  db.execute("INSERT INTO files (file_name,file_id) VALUES (?,?) ON CONFLICT(file_name) DO UPDATE SET file_id=excluded.file_id", (file_name, file_id))
  files[file_name] = file_id

load_files()

...
        if item["photo"] in files:
          file_id = files[item["photo"]]
          print (f" send photo file_name={item['photo']} file_id={file_id}")
          bot.send_photo(call.message.chat.id, file_id)
        else:
          with open(os.path.join("menu", item["photo"]), "rb") as f:
            bot.send_chat_action(call.message.chat.id, "upload_photo")
            r = bot.send_photo(call.message.chat.id, f)
            file_id = r.photo[0].file_id
            save_file(item["photo"], file_id)
            print (f" uploaded photo file_name={item['photo']} file_id={file_id}")

Если речь об официальных Payments 2.0 то никак. Максимум - в качестве самозанятого.

Если когда нибудь подключат Qiwi, такая возможность, думаю появится