# #git #github #gitlab
Вопрос:
Мы являемся разработчиком программного обеспечения, и мы будем работать над существующим программным продуктом клиента (компании). Они предоставили нам доступ к их существующему хранилищу. Над этим проектом будем работать исключительно мы. Однако в прошлом этот клиент нанял нескольких старших сотрудников из нашей команды, что имело для нас значительные последствия. Таким образом, мы не хотим, чтобы они знали имена/электронные письма наших сотрудников, которые работают над их продуктом, потому что они обязательно попытаются нанять их.
Мы планируем дублировать репо внутри компании. Наши сотрудники, как правило, совершают внутреннее репо со своими именами/электронными письмами. И мы планируем регулярно синхронизироваться с репозиторием компании.
Мы хотим заменить автора всех наших коммитов в репозитории компании более общей «Командой разработчиков» и Developers@ourCompany.com.
Вот что мы подумали:
- Первоначально нажмите/продублируйте существующий репозиторий компании на нашем внутреннем Github.
- Создайте компанию master_OurCompany, которая будет основана на их текущей главной ветви. Наши разработчики будут использовать это в качестве основного репо.
- Каждый час мы планируем создавать (а затем уничтожать) филиал на основе master_OurCompany с именем master_OurCompany_rebased.
- На master_OurCompany_rebased мы планируем использовать
git filter-branch --commit-filterкоманду для замены авторов в этой ветке нужной нам информацией. - А затем объединить master_OurCompany_rebased с главной ветвью компании.
Однако мы выяснили, что git filter-branch --commit-filter он опасен в использовании и имеет множество подводных камней. Мы не хотим, чтобы случилось что-то неприятное, от чего мы не сможем оправиться.
Какие могут быть более безопасные способы достижения наших вышеуказанных требований?
Комментарии:
1. Я думаю, что решение , основанное на двух внутренних репозиториях
git format-patch, иgit am, возможно, было бы лучшим выбором, но похоже, что вы пытаетесь решить социальную проблему с помощью технических инструментов, и я подозреваю, что любое программное решение на самом деле не решает правильную вещь.2. Если они не уважают ваши условия, то просто не работайте с ними.
Ответ №1:
Тем не менее, мы выяснили, что git filter-branch —commit-фильтр опасен в использовании и имеет множество подводных камней.
Ну, твердый сыр, как говорится. filter-branch или более новое filter-repo -это именно то, что вам придется использовать. Вы пытаетесь массово переписать историю, что всегда страшно. Сделайте резервную копию и сделайте решительный шаг.