Git: eliminar las credenciales del repositorio

Question

Al principio: Esto es (con suerte) no duplicado de this o this.

El estado actual: He asignado un archivo con credenciales para una base de datos interna a mi repositorio de Git. Esto estuvo bien, ya que lo usé solo. Luego mi grupo comenzó a clonar, empujar y jalar en este proyecto. Ahora tenemos varios repositorios Git (uno central y algunos desarrolladores).

El problema es: Ahora queremos dar acceso público al código fuente, y al repositorio de Git o al menos dejar que Git administre los detalles de otros que contribuyen al código.

La pregunta: ¿Cuál sería una buena estrategia para

a) eliminar el archivo con las credenciales de la central o de todos los repositorios, o

b) establecer un nuevo repositorio Git como tipo de 'interfaz' para el mundo exterior?

Si elige (b), ¿cómo podríamos comunicar fácilmente los cambios al repositorio principal?

Debido a la distribución ya generalizada, realmente nos gustaría no hacer un git rebase o un git filter-branch en cada repositorio actual.

Answer 1

Lo sentimos, pero tiene que ejecutar git filter-branch si desea eliminar las credenciales del repositorio principal. Consulte Removing sensitive data, escrito por la gente de GitHub.

Debido al diseño de git, no hay forma de forzar a los clones existentes a eliminar el archivo de sus respectivos historiales.

Se puede desinfectar una sola rama y que sea la base para el desarrollo futuro:

$ git checkout -b old-master master 
$ git filter-branch ... master 

Ahora lo que se necesita para empujar el maestro desinfectados a una nueva operación, que contiene sólo el amo limpia:

$ git push new-central master 

Los repos existentes pueden agregar los nuevos cambios remotos y git cherry-pick de sus ramas anteriores al nuevo maestro limpio si es necesario.

Para el nuevo repositorio, ponga algún tipo de barrera en su lugar para evitar que alguien le envíe datos confidenciales para que no tenga el mismo problema una vez más. Esta barrera podría ser un ser humano que controla el nuevo repositorio central y revisa todos los parches para decidir qué entra.

Answer 2

No hay forma de que puedas hacer a) sin usar rebase o filter-branch. Pero diría que probablemente sea mejor hacerlo de esta manera ahora, que tener que luchar con ocultar la historia para siempre. Supongo que b) podría hacerse dividiendo el historial después de una confirmación que elimine las credenciales. El resultado sería más o menos dos historias, colocadas en dos repositorios diferentes; uno antes de la limpieza, y uno que "se reinicia" justo después. La historia de estos dos repos podría estar conectada a través del graft-points en los repositorios de aquellos que necesitan alcanzar la historia anterior.

De cualquier forma, vas a tener que lidiar con una carga completa de sh * t, y yo recomendaría ir para a) y filtrar-ramificar incluso si es mucho trabajo.

Answer 3

Simplemente cambie la contraseña de su base de datos interna y cualquier otro servicio que tenga la misma contraseña. (y lo mismo para cualquier otra contraseña que existió en algún lugar de su historial).

Answer 4

Así que, hemos terminado y me gustaría compartir cómo lo hicimos finalmente.

Estábamos en la posición afortunada de que nadie tenía una rama personalizada en un momento determinado. Entonces, básicamente lo que hicimos fue que todos presionaron por última vez sus cosas al depósito central.

Luego usamos filter-branch como lo describe el equipo de GitHub en él. Teníamos entonces un repositorio central claro.

Finalmente (y eso funcionó solo porque nadie tenía una sucursal local como se mencionó) eliminamos nuestros repositorios locales y clonamos los nuevos de la central que ahora está limpia.

Para decirlo en pocas palabras: De esta manera fue un procedimiento bastante rápido e indoloro. No es elegante, pero funcionó.