Tratar con compromisos previos al abrir un proyecto

¿Hay alguna manera de ocultar las confirmaciones de ciertos usuarios? Quiero hacer público un repository privado pero no quiero que la gente vea todos mis compromisos anteriores. Algunos de ellos tienen passwords y keys API. Otros simplemente son irrelevantes para lo que deseo proporcionar.

El repository privado se encuentra alojado actualmente en GitHub. Quiero activar el interruptor y hacerlo público y de código abierto, pero eso revelaría los compromisos anteriores que no quiero que la gente vea.

Sé que una de las forms en que podría hacerlo es crear un repository completamente nuevo, pero he alcanzado el límite de repo para mi count. Buscando la forma más rápida y fácil de resolver el problema. Abierto a cualquier enfoque que funcione, incluida la creación de un nuevo repository, si es que es la mejor manera.

Si efectivamente "ocultas" esas confirmaciones, estás creando efectivamente un nuevo repository. El SHA1 de una confirmación depende de todo su contenido y de sus padres, por lo que cambiar una única confirmación lo cambia todo después.

Si el scope de las cosas que esconder es enorme, es mejor que no exporte ningún historial. Pero afortunadamente las cosas están bastante aisladas, y puedes resolver tus problemas con git filter-branch . La página de manual describe sus capacidades bastante bien, incluidos algunos ejemplos de juguetes (por ejemplo, cómo eliminar files del historial), y hay muchos más ejemplos en línea, incluso aquí. Puede terminar haciendo múltiples pases, por ejemplo, uno para eliminar ciertos files, y uno para eliminar ciertos types de confirmaciones.

Las cosas key que pueden serle útiles:

  • --index-filter te permitirá eliminar o cambiar el nombre de un set determinado de files o directorys; solo te permite modificar el índice, sin verificar los files, por lo que es rápido;

  • --env-filter te permitirá reescribir muy rápidamente la información del autor / --env-filter ; y

  • --tree-filter , el último recurso, realmente revisará todo el tree en cada paso, y le permitirá modificar los files in situ (por ejemplo, search y replace para eliminar passwords)

filter-branch reescribe completamente todo el historial en cualquier reference que especifiques, y deja las references originales en refs / originales en caso de que las necesites. Por una variedad de razones, una de las cuales es la security, lo mejor es utilizarla en un clon nuevo.

No hay forma de ocultar una confirmación en el repository para otro usuario.

En el lado positivo, puede hacer todo lo que desee en un repository local, incluido el historial de reescritura para aplastar u omitir esas confirmaciones.

Luego, tome otro clon del repository privado para mayor security, elimínelo, cree uno nuevo y envíe desde esa versión modificada al nuevo repository.

Eso aprovecha el hecho de que cualquier clon de un repository de git es todo …

Sin embargo, puede aplastar los commits juntos o exportar el código actual a un nuevo repository, lo que realmente frustra el propósito de abrir un proyecto. ¿Qué pasa si alguien detecta un error, quiere rastrear cómo entró en el código y no puede, porque se introdujo en uno de los commits que aplastó?