¿Es posible comunicar dos git-repos locales?

Tengo un escenario muy extraño hoy en el trabajo que involucra repositorys git. La idea es tener dos repositorys con las siguientes restricciones

local-RepoA

  1. tiene todo mi código fuente, por ejemplo, ShareOk.cpp y ShareNok.cpp
  2. empuja a http: //remote-RepoA.git

local-RepoB

  1. solo debería tener esos files de RepoA que están bien para compartir con otras personas, en este caso solo ShareOk.cpp
  2. antes de empujar los cambios a control remoto, necesita hacer una limpieza de código
  3. empuja a http: //remote-RepoB.git

¿Hay alguna manera de "empujar" ciertos files de local-RepoA local-RepoB a local-RepoA local-RepoB para hacer la limpieza del código y luego enviar los cambios a remote-RepoB ?

Esto no tiene sentido para mí, pero me pidieron que verificara alguna forma de vincular los dos repos locales.

EDITAR

De la respuesta que se proporciona a continuación, creo que mi descripción no estaba completa, así que la ampliaré más.

Hay dos grupos de desarrollo.

El grupo A posee todo el código fuente y solo trabaja en repoA cuya connection ascendente está configurada en http://repoA.git . Todo el código fuente puede ser complicado y con código no probado.

El Grupo A quiere darle al Grupo B el código hasta un cierto punto / compromiso de repoA que se sabe que funciona perfectamente, con código limpio y probado. Entonces, el Grupo A quiere tener una forma de poner en repoB con http://repoB.git este código que preserva el historial de cambios para los files que se comparten con el Grupo B.

Finalmente, el Grupo B simplemente clona / extrae de http://repoB.git y verifica que el código se comstack y se ejecuta y luego hacen otras cosas con él.

Dudo que empujar commits / files desde un repository a otro sea realmente lo que quieres. A partir del context proporcionado, no puedo decidir si esto se aplicaría, pero en general recomendaría que Repo B sea su repo upstream (principal) y trabaje en eso (públicamente), como lo haría con cualquier package o module que quiera compartir.

En RepoA puede configurar RepoB como una dependencia, y aplicar cualquier personalización o modificación extendiendo RepoB, mientras que solo se comprometen las anulaciones en RepoA.

Esto también evitaría que tengas que 'censurar' los files o los commits que quieras publicar públicamente.

El Grupo A quiere darle al Grupo B el código hasta un cierto punto / compromiso de repoA que se sabe que funciona perfectamente, con código limpio y probado. Entonces, el Grupo A quiere tener una forma de poner en repoB con http: //repoB.git upstream este código que preserva el historial de cambios para los files que se comparten con el Grupo B.

Parece que repoB debería ser un clon desnudo de repoA. Entonces solo necesita administrar el process de sacar B de A.

Asumiendo que alguna twig de liberación, o una label que indique qué cometer en A es el punto "bien conocido" B que debería seguir, solo necesita ejecutar git pull KnownGoodPoint:master mientras está en el directory repoB.

Esto también supone que nadie en el grupo B está retrocediendo a repoB, por lo que debe rechazarlo.