Я не уверен, является ли это природой вашей проблемы, но по умолчанию git log иногда отфильтровывает коммиты, которые он считает "не полезными" или "интересными", чтобы понять окончательное состояние дерево коммитов. От git log документов :
Иногда вас интересуют только части истории, например коммиты, модифицирующие конкретный . Но есть две части Упрощение истории , одна часть выбирает коммиты, а другая - как это сделать, поскольку существуют различные стратегии для упрощения истории.
Следующие параметры влияют на способ упрощения:
Default mode
Упрощает историю до самой простой истории, объясняющей конечное состояние дерева. Проще всего, потому что он сокращает некоторые боковые ветви, если конечный результат один и тот же (то есть объединение ветвей с одинаковым содержимым).
Вместо того, чтобы использовать режим по умолчанию, вы можете передать флаг --full-history в вашем файле и посмотреть, обнаружится ли «пропущенная» фиксация таким образом:
git log --full-history -- backend/theimportantfile.js
Из git log документов:
--full-history
То же, что и режим по умолчанию, но не удаляет некоторую историю.
Редактировать
Я знаю, что иногда это работает, потому что я столкнулся с ситуацией, когда у меня был коммит X в master, который содержал изменение в файле theFile. Коммит X был затем выбран сотрудником в anotherBranch, поэтому давайте назовем новый коммит Y. Затем anotherBranch был объединен в master.
Когда мы сделали
git log -- theFile
мы бы не увидели Y в списке коммитов, просто X, но когда мы использовали
git log --full-history -- theFile
только тогда появятся и X, и Y. Я думаю, что Git не показывал Y по умолчанию, потому что он внес идентичное изменение в конечное состояние дерева коммитов, так как он был выбран из X.