git rerere

Если у вас в репозитории Git появляется долгоживущая ветка, и вы регулярно делаете rebase на активно развивающийся master branch, то очень скоро заметите, что при следующем rebase приходится решать те же конфликты, которые уже были решены во время предыдущего rebase.
Аналогичный butthurt испытывают многие разработчики, вот ссылки на StackOverflow:

• git-rebase-resolve-conflicts-again-and-again
• resolving-same-conflicts-again-and-again-when-doing-rebasing-more-times
• tool-for-solving-trivial-conflicts-in-git

Собственно, решение приведено там же: git rerere (reuse recorded resolution). Если вкратце, то со включённой опцией

git config --global rerere.enabled true

git запоминает, как был решён данный конкретный конфликт, и при следующем его возникновении использует записанное решение. Записи сохраняются в каталоге
.git/rr-cache, некоторые предлагают при разработке в команде замаппить rr-cache всех разработчиков на один общий каталог на сервере.

Детальное описание и примеры:

• Rerere Your Boat...
• git-rerere(1) - Linux man page
• Fun with rerere
• are-there-any-downsides-to-enabling-git-rerere

Things to notice:

1. Rerere remembers how you chose to resolve the conflicted regions;
2. Rerere also remembers how you touched up outside the conflicted regions to adjust to semantic changes;
3. Rerere can reuse previous resolution even though you were merging two branches with different contents than the one you resolved earlier.

Even people who have been using rerere for a long time often fail to notice the last point.