Прежде всего, не существует такой стратегии слияния, как «одобрить последнее изменение по дате фиксации» из коробки. Вот список поддерживаемых стратегий
Из этого списка кажется, что «рекурсивная» стратегия с опцией «наши / их» может решить некоторую часть вашего примера:
Поскольку вы хотите использовать «rebase», это означает, что в качестве основы вашего слияния будет использоваться «origin / mybranch», а затем попытаться применить ваши новые коммиты поверх него.
Тогда есть 2случаи: либо ваше изменение произошло позже - в этом случае оно будет применено корректно, либо ваше изменение произошло раньше - и в этом случае вы говорите, что хотите применить их версию (то есть --strategy-option
«наша» или «их», ядумаю, что это "наше" для ребазинга, это сбивает с толку ...).
Проблема в том, что если ваше изменение произошло сегодня, а их изменение произошло вчера, но вы забыли синхронизировать утром,тогда даже если ваше изменение произойдет позже (по дате фиксации), оно все равно вызовет конфликт и будет разрешено не по их версии, а вместо вашей.
Если это не совсем товы можете, вероятно, написать собственный инструмент автоматического слияния, который при возникновении конфликта будет определять даты принятия, которые его вызвали, и выбирать наши / их в зависимости от того, какая дата принятия является самой поздней.
Затем выможет написать скрипт, который применяет rebase и ваш пользовательский инструмент слияния к каждому конфликту.
Краткая логика такого инструмента слияния
При наличии конфликтующего имени файла и знания удаленногои имена локальных веток, вы можете узнать коммит, при котором этот файл последний раз изменялся для каждой ветки - см. Как найти самый последний коммит git, который изменил файл?
Затем получите даты этих 2 коммитов и сравните их
и примите соответствующее решение о слиянии: скопируйте LOCAL или REMOTE.