Это не отменяет возможность наличия этого файла на устройстве где-то в профиле пользователя или в корне карты :)

редактирование коммитов это базовый функционал git, не имеет отношения к процессам. Процесс предписывает поместить в девелопкоммит с ключом --no-ff. До этого или после

этого редактируйте коммиты, что такое "красиво", "некрасиво" это не относится к процессу

Про процесс редактирования коммитов, утекших на сервер обычно везде пишут "не вздумайте так делать". А во всех инструкциях к мердж реквестам пишут "Вы это, овнера не нервируйте, сквашните всю фигню в приличный вид".
Вот я пытаюсь понять, как должно разрешаться это противоречие. Например в рамках гит-флоу. Даже [особенно] если сам гит-флоу это не определяет.

А разве сравнение двух соседних коммитов девелоп не даст искомый результат? Зачем блуждать по коммитам фича-ветки?

Это уже "религиозный вопрос" есть две школы одни считают правильным видеть "красивую картинку" например в ядре линукс, без лишних подробностей. Другие считают, единственно версией реальную последовательность работы. Выбирайте тот лагерь который вам ближе и используйте любые команды.

Затем, что в ней пять юзкейсов и два рефактроринга (входной и выходной) . Анализировать разницу между, грубо говоря ЕРП 2,4 и ЕРП 2,5 сравнивать одним куском то еще удовольствие.

Ну в каком я лагере вроде видно, но я не хочу использовать любые команды. Я хочу методичку как в вашем посте про вливание в девеолоп, которая приведет в условиях гитфло к красивой истории и не нарушит флоу.
Самому такую методичку изобрести мне опыта не хватает. А "любые команды" часто приводят к любому результату, вместо нужного. Например:
- отрастить длинную ветку на сервере, а потом просто грохнуть её это нормально, или может расстроить кучу народа?
- Или не может, потому, что от фича-веток в гитфлоу ветвиться противопоказано, так что кто отпочковался сам себе злая буратина.
- Или вообще, для целей сохранения работы на сервере нужно завести себе приватный репозитарий и синхронизироваться с ним, даже если работаете в одной команде, а растить ветки, которые не планируешь никуда вливать это совсем плохая идея.

а какая "библия" содержит однозначных ответ по вопросу расположения фигурных скобок java vs c++, CamelCase vs camelcase и прочему, это ни на что не влияющие вещи. Код работает, а не комментарии.

Ну гит-просто-хаб-лаб, Trunk Based - это точно такие же ни на что кроме удобства разработчиков не влияющие вещи. Просто соглашения о порядке, которые по мнению многих задают удобный порядок. Работает то вообще не код, а скомпилированный и развернутый код.

А вы юзаете мобильное приложение?
Почему решили использовать клиент?
Мы тоже сейчас пробуем. Вроде очевидно, что клиент удобнее приложения. Но проблемы все равно встречаются.

Нет, юзаем мобильный клиент. Решили потому не нужно городить интеграции мобильного  приложения с учётной системой

@vbondarevsky в библиотеке Коннектор есть достаточно серьезная проблема
https://github.com/vbondarevsky/Connector/issues/60
методы, ожидающих ответ от сайта в формате Json, не умеют обрабатывать исключения от сайта не в формате json

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

что скажешь? я готов сделать ПР для исправления

Почему нельзя? Получить тело как текст и узнать таки что выдает сайт

это можно ,конечно, но если юзать методы-обертки для json, то нельзя.
т.е. получается, что эти методы в проде юзать нельзя, т.к. могут упасть при проблемах, а суть проблемы ты никак не узнаешь.
если же переписать код без их использования, зачем они тогда нужны? )

или каждый вызов таких методов обмазывать попытками и чтением тела не очень солидно, когда это можно сделать внутри самой библиотеки

А какое решение ты видишь? Можно конечно прочитатьJson завернуть в попытку и если упал в исключение ВызыватьИсключение с текстом из тела ответа (правда там могут быть хтмлки от сайта и в ЖРе это будет так себе анализировать), ну или все тело упаковать в структуру со свойством "error_message" или типа того и возвращать его

ну да, завернуть в попытку и писать в ЖР или еще куда тело ответа
и вызывать исключение

тут можно
- либо писать в ЖР с телом реального ответа и подробным представлением ошибки и просто ВызватьИсключение; (проброс ошибки наверх)
- Либо запись в ЖР с телом реального ответа и подробным представлением ошибки
и ВызватьИсключение с эти же телом

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

Можно, правда ковырять хтмлки в ЖРе такое себе удовольствие но а целом решение.
Со структурой это вариант для того что бы дать принимающей стороне возможность самостоятельно разрулить ситуацию, что-то типа:
Объект = JsonВОбъект();
ПроверитьВозвратВебСервиса(Объект); // тут проверка это структура с ошибкой и возможно внутри вызов исключения
Далее всякий бизнес код