Я много лет продвинутый git пользователь. Недавно я обнаружил, что у меня возникает следующая проблема, и я не могу найти описание / решение в Интернете, что наводит меня на мысль, что, возможно, я пытаюсь решить проблему неправильно:
У меня 20 python репозитории Есть много вещей, которые я, кажется, дублирую между репозиториями (mypy.ini файлы, файлы конфигурации flake8, файлы, которые запускают все тесты в docker контейнерах после некоторых проверок работоспособности, setup.py файлы). Эти файлы на 90% одинаковы между всеми репозиториями, с небольшими (предполагаемыми) изменениями; и некоторые изменения произошли из-за того, что я улучшил некоторые вещи в 1 репо, а затем не успел перенести изменения во все остальные репозитории.
Недавно мне потребовалось некоторое время, чтобы все почистить, и теперь У меня есть 1 «базовый» набор файлов, который должен существовать во всех репо (и во всех новых репо). Я мог бы скопировать их во все репозитории, но это означало бы, что для каждого небольшого улучшения мне нужно вручную копировать это во все остальные репозитории (и проверять, не был ли файл изменен в этом репо, или объединить изменения).
Решение, которое я придумал:
Я сделал репо base; здесь я фиксирую эти файлы.
В каждом репо я объединяю базу:
git remote add base git@github.com/XXXX/base.git
git config remote.base.pushurl "you really didn't want to do that" # make sure one cannot accidentally push to base
git fetch base
git merge base/master --allow-unrelated-histories -m "merging base" --no-fast-forward
git push
Теперь позже, когда я обновляю что-то в базе, я могу объединить это с отражением репо в моем собственный досуг (скажем, когда я работаю над этим репо в любом случае), выполняя
git fetch base
git merge base/master
git push
Он будет (должен) делать то, что хорошо git: проверить, что изменилось в базе после последнее слияние, посмотрите, не приведут ли какие-либо локальные изменения к конфликтам, слить все это и беспокоить меня, только если есть что-то, что мне нужно для ввода (конфликт слияния).
Теперь вот что беспокоит меня при таком подходе
- Может быть, я просто недостаточно хорошо выгляжу, но я не могу найти никого, кто бы описывал эту стратегию в Интернете, заставляя меня думать, что, вероятно, есть причина, по которой ее не следует использовать. Чего мне не хватает?
- У меня есть некоторые проблемы с git "свертыванием слияния". Что я имею в виду под этим; после слияния (и некоторых коммитов и повторных слияний) все должно выглядеть следующим образом:
master -----*---*---*---*---*---*----*----*----*-----*---------*----*----*----*---*
/ / /
base/master --*--------*---------------*---------------*-----*---*---------*
(поэтому в этой ситуации база / мастер сливаются 3 раза в мастер, последнее слияние коммитов еще не выполнено объединено)
Однако, что я получаю (иногда; на 100% не уверен, когда еще), это:
master -----*---*---*---*---*---*----*----*----*-----*---------*----*----*----*---*
base/master --*--------*---------------*---------------*-----*---*---------*
Изменения в основном, но не как слияния от основного / основного. Это означает, что в следующий раз, когда я попытаюсь выполнить слияние, система будет жаловаться, что для двух ветвей нет общей истории. Теперь я догадываюсь, что это потому, что у меня нет --no-fast-forward в команде git merge (после первоначального слияния). Это предположение правильно? Если это так, то сейчас это легко исправить, но как мне избежать полной путаницы в моей истории, если в следующий раз я забуду добавить --no-fast-forward?
Другие подходы, которые я рассмотрел
- Использование git субмодулей / git поддеревьев : Проблема в том, что многие файлы, которыми я хочу поделиться, должны быть root dir. Я думаю, я мог бы попытаться сделать символические ссылки на все из них, но это все еще означает некоторую ручную работу для каждого проекта.
- Использование пакетов pypi : та же проблема, что вещи должны быть в root реж. Кроме того, некоторые вещи, которые я имею в общем каталоге, особенно полезны для установки pypi.