Xeli

Можно ли удалить опубликованную ветку хотфикса?

git push origin --delete serverfix
Где origin имя удаленного репозитория, а serverfix имя ветки.

И как обновить git flow?

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

не смержили с боем

Что за бой? Корпоративный сленг? Общепринятое название главной ветки master

Каким бы сервисом Git вы бы пользовались

Сервисом аренды выделенного сервера

если бы хотели максимального размера репозитория и файла?

Максимально поддерживаемый размер файла в файловой системе ext4 16 тебибайт.

Как предовратить утечку,

В смысле утечку? Кражу репозитория с исходниками? Надо шифровать файлы. Желательно на лету. Boxcryptor это умеет делать, правда не знаю может ли он это для индивидуального сервера. Поэтому думаю вам стоит посмотреть в сторону LUKS. Во первых GPL, во вторых программа родная для линукса, следовательно ее можно будет спокойно автоматизировать с помощью bash и cron.
help.ubuntu.ru/wiki/luks_cloud

Нужно воспользоваться такой фишкой как параметр --squash (сплющить коммиты) функции rebase. Смысл этой функции в том, что маленькие коммиты объединятся в один большой, потом выполнится слияние с master. После чего ветку разработки можно будет удалить. В результате должно получится 3 коммита в ветке master. Один первый начальный, второй результат "сплющивания" и третий результат мержа первого коммита мастера с коммитом "сплющенными" т.к. при rebase ветки разработки она будет опережать мастер и нужно будет выполнить слияние master c перенеснной "сплющенной" веткой .
В подробностях тут

Как его не перетереть?

git не даст его перетереть. Он предложит скачать опережающую ветку затем сделать слияние, а затем уже можно будет отправить патч на сервер.
В любом случае можно будет откатиться на коммит вашего напарника без какой либо головной боли Работать в мастере можно, чтобы тут не говорили, просто это не удобно. Git поддерживает философию работы с ветками. Т.е. для каждой подзадачи создается ветка которая потом мержится или ребейзится к мастеру.
И самое главное никогда не делайте ребейз комитов которые не находятся у вас локально.

Как обезопасить себя от бекдоров, слива инфы и прочего недобросовестного отношения программиста-фрилансера?

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

Может ли программист как-то влиять на эти записи и удалить лог именно по спорной записи - т.е. она будет на продакшен сервере, а в логах version control ее не будет и он свалит все на прошлого программиста, мол это до меня было?

Если используете git то это распределенная система где об изменениях узнают все участники проекта, сделанные изменения в мастере сохраняются у всех участников проекта(в зависимости от расграничения прав доступа), в каждом коммите указывается информация об авторе кода + коммиттере человеке который внес этот коммит. Если этот коммит содержал в себе вредоносный код, то очень легко доказать в суде, что это именно этот негодяй его внес, для большего спокойствия используйте цифровую подпись GPG и обяжите работать только через нее.

Попробуй сделать так

git pull <псевдоним удаленного сервера> --allow-unrelated-histories

. Затем как выполнишь слияние git push должен уже проходить без проблем.

В корне репозитория находится файл .gitignore . Посмотрите, что в нем описано.
п.с. Хорошей практикой считается индексировать только непосредственно рабочие файлы. Сторонние библиотеки и фреймворки индексировать смысла нет и трудозатратно.