Есть ли канонический способ задним числом разделить git-репо на публичный и приватный вариант?

Question

У меня есть git-репозиторий, содержащий файлы, в которых есть некоторые конфиденциальные данные, возможно, жестко закодированные или формально жестко закодированные и в настоящее время находящиеся в некоторых точках истории git.

В целях обеспечения доступности проекта для общественности, чтобы программисты моглисхожие интересы могут принести пользу от него и внести изменения обратно, я хочу его обработать и очистить оскорбительные файлы.

Процедура, которую я рассмотрел, была следующей:

1. Мелкий / Общий клонрепо локально в новое локальное местоположение, эта папка станет общедоступным вариантом.Последующие шаги выполняются в новом репо.
2. Разветвите мастер в ветку public-master
3. Удалите все другие ссылки на ветки.
4. Очистите public-master
5. Squash public-master
6. git reflog expire --expire-unreachable=now --all && git gc --prune=all --agressive удалить все недоступные ссылки, которые теперь являются любыми объектами, не находящимися в публичной ветке
7. git push добавить общедоступный мастер обратно в частный репозиторий.
8. Установить исходный удаленный доступ к общедоступному URL репозитория, перейти на master.Push to origin.

Достаточно ли этого для очистки моего репо или можно ли восстановить конфиденциальные данные после этого.Есть ли более разумный и распространенный способ решения этой проблемы?Являются ли какие-либо шаги посторонними?

Например, могу ли я сделать все это в одном репозитории, или природа git-пакетов означает, что я все еще могу нажать obj, который содержит конфиденциальную информацию?

Answer 1

Объединение ответов @VonC и @ b-fg. Я думаю, что наиболее разумное решение заключается в следующем.Заметьте, что очень легко загрязнить новый публичный репозиторий объектами, которые могут содержать конфиденциальную дату, вместо этого создайте новый, чтобы он был публичным.

1. Разветвьте частный репозиторий в public
2. Sanitize public
3. Инициировать новый репозиторий для общего доступа.
4. git --work-tree=/path/to/private add -p . Заставить git работать с открытым индексом, но с закрытым рабочим деревом.Публичное хранилище теперь имеет все рабочее дерево очищенной ветви, подготовленное так: git commit.
5. Локальный репозиторий имеет рабочее дерево из очищенной ветви в индексе, но не имеет рабочего дерева, другими словамипохоже, что все в текущем рабочем дереве было удалено из индекса.« Восстановить » файлы в рабочем дереве нового репозитория с помощью git reset --hard
6. Вернитесь в частный репозиторий и добавьте общедоступный репозиторий в качестве удаленного.git remote add public file://path/to/public/repo
7. История private/public и public/master теперь не пересекаются.Таким образом, мы должны привить их вместе.Установите восходящий поток для private/public, используя git branch -u public master, теперь вытягивая, позволяя разделять историю git pull --allow-unrelated-histories
8. Установите общедоступную ветвь как способную только читать, но не записывать изменения, чтобы предотвратить случайное загрязнение публичного репо git remote set-url public --push "This Branch is Read-Only"

Теперь включайте только новые функции в общедоступном репозитории и возвращайте их в частный репозиторий по мере необходимости.

Answer 2

Единственная проблема в том, что я хочу иметь возможность извлечь из частного репо, и тогда у них будет неразделенная история.

Это кажется неизбежным, так как вы изменили историю ветоки раздавить его.

Вместо того, чтобы извлекать из нового публичного репо, я просто рассмотрел бы изменения, внесенные в новый клон репо, и решил бы, какой из них я хочу добавить в локальный клон старого частного репо:

# update local content of new repo
cd /path/to/public/repo 
git pull

# check what needs to be added
cd /path/to/clone/of/old/repo
git --work-tree=/path/to/public/repo add -p .

Вы увидите различия между старым и новым, происходящие из возможной новой эволюции, сделанной в публичном репо.