Siempre ignore las carpetas específicas del repository remoto

Tengo este proyecto en el repository remoto, y necesito configurarlo para que siempre pueda enviar cualquier file (push), pero solo ALGUNOS files están disponibles y visibles, es decir, siempre recibe todo lo que envío pero solo devuelve Some carpetas.

  • push: envía las carpetas A, B, C, D y E
  • pull / status / checkout: mostrar / leer solo las carpetas A, B, C (D y E ignoradas)

Entonces, por ejemplo, mañana enviaré las carpetas F, G y H y el repository remoto lo recibirá. Pero después intentaré "pagar / retirar / estado" y mostraré SOLAMENTE las carpetas A, B, C (D, E, F, G, H ignoradas) de nuevo y para siempre.

En resumen, necesito que el repository remoto reciba TODO, pero solo haga que una parte esté disponible.

Push y fetch no se basan en files , están basados ​​en commits .

Cuando conecta su cliente Git a un server Git, usted elige si está haciendo esto para get commits ( git fetch ), o para darles commits ( git push ). Pero lo que obtienes o das es commits completos , nunca "un file" o "una carpeta" (directory). Por lo tanto, tus ejemplos son incorrectos.

Tenga en count que cualquier commit siempre contiene una instantánea completa de su tree. Es decir, si tiene a/file1.txt , a/file2.txt , b/file3.txt c/file4.txt en su repository, y toca uno de estos files y realiza una confirmación, el nuevo compromiso tiene copys de los cuatro files . (Para ahorrar espacio, reutiliza los originales sin modificar, pero el compromiso realmente contiene los cuatro files). Cuando envía este compromiso a otro Git, envía el compromiso completo , no solo parte del compromiso.

Si coloca el file, pueden sacar el file y, de forma pnetworkingeterminada, obtendrán todos los files. Git es compatible con algo llamado "extracción dispersa", que puede (¿?) Utilizar para este tipo de propósito, pero es probable que esta sea la forma incorrecta de hacerlo.

Las personas que hacen esta pregunta son, aproximadamente el 93,4% de las veces, 1 tratando de almacenar files de configuration en su repository, pero no quieren que esos files de configuration se copien a los clientes (excepto, algunas veces, como configuraciones pnetworkingeterminadas iniciales). De nuevo, esta es la forma incorrecta de hacerlo: en lugar de almacenar los files de configuration, haga que su sistema almacene los files de configuration pnetworkingeterminados . Los clientes recogerán estos files pnetworkingeterminados como de costumbre; los clientes que configuran sus propias configuraciones reales usarán su configuration en lugar de, o anulando, los valores pnetworkingeterminados; y no habrá conflicto entre "mi configuration local", que nunca se registra en este repository, y "la muestra y / o las configuraciones pnetworkingeterminadas", que se registran en este repository.


1 Esta estadística se inventó en el momento, al igual que el 42.7% de todas las statistics .