Ignorar los cambios en un file en Github entre todas las bifurcaciones, sin eliminar el file del repository

Hay un file config / auth.js en mi repository github (que tiene muchas bifurcaciones). Deseo ignorar cualquier cambio adicional en este file. Después de search encontré las siguientes tres forms pero ninguna de ellas me funciona:
1. git rm –chaced
esto borra el file.
2. git update-index –assume-unchanged config / auth.js
esto está funcionando en mi máquina, pero luego todos los contribuidores tendrán que ejecutar este command en su fork también (lo que no quiero que hagan).
3. git update-index –skip-worktree config / auth.js
mismo problema que en el caso 2
Básicamente, no quiero que los demás sepan que sucedió nada y cuando sincronizan su fork (rebase) los cambios en el file se ignoran automáticamente.

Cualquier solución para hacer lo que estás pidiendo va a tener un montón de "detrás de la magia de la escena" que podría salir mal en cualquier momento; No lo recomiendo

El problema es que si quieres ignorar su cambio en un file determinado, pero no quieres que vean ningún efecto de lo que has hecho, entonces necesariamente necesitas mirar un set diferente de confirmaciones de lo que son . Por ejemplo, si tiene

x --- x --- x <--(master) 

y clonan, entonces tienen

 x --- x --- x <--(origin/master)(master) 

y luego hacen algunos cambios, incluida una edición de la configuration, por lo que tienen

 x --- x --- x <--(origin/master) \ O <--(master) 

para que su repo "ignore" el cambio al file de configuration significa que terminará con

 x --- x --- x --- O' <--(master) 

después de incorporar sus cambios. O' es necesariamente un compromiso distinto de O El cliente esperará ver a O en el origin/master y, de hecho, sería muy perjudicial si los presentara con la "realidad" de que el origin/master está ahora en O' .

Entonces, para que las cosas funcionen orderadamente, debes almacenar O y representar a la horquilla que la stream ascendente del master apunta a O Dado que tiene más de una bifurcación, cada una de las cuales puede tener sus propios cambios en su file de configuration, debe hacer lo siguiente:

1) Cree un repository de "puente" para cada horquilla y, por lo tanto, cambie la URL remota que utilizan para dirigirse a usted.

o

2) Mantenga en su repository de origen un set separado de twigs para cada horquilla, requiriendo que las horquillas configuren un refspec apropiado.

Realmente hacer este cambio "invisible" simplemente no es posible. Suponiendo que quiere el "peso más ligero" de esas dos opciones, que creo que sería (2), terminaría con algo así como

 x --- x --- x --- O <--(master) \ O' <--(fork-a/master) 

y ahora tendrías que usar ganchos para automatizar el reajuste de cambios entre master y fork-a/master (mientras se filtran los cambios al file de configuration de las rebases). No veo más que oportunidades para el desastre allí.

La otra opción (repositorys puente) todavía se parece mucho a la anterior. Simplemente evita que las cosas se vean peor en un solo repository, dado que en realidad tiene muchas horquillas. Estructura la forma en que los cambios fluyen entre las horquillas, supongo, pero luego tienes que coordinar entre todos los repos.

No puedo ver ninguno de los que realmente funcionan.

 git rm --cached 

Esto desaparece un file del índice . No tiene un efecto duradero en un repository.

 git update-index --assume-unchanged config/auth.js git update-index --skip-worktree config/auth.js 

Como ha indicado, estos funcionan en su índice local, pero no se comparten (al igual que la primera opción).

Creo que todo lo que tienes que hacer es agregar la ruta a .gitignore en el repository y confirmar .gitignore .

Dado que .gitignore simplemente le dice a Git que ignore la ruta al hacer add / commit, cualquier cambio que la gente haga en su copy local será ignorado durante add / commit, y lo mismo aplica para su copy. Por lo tanto, no se deben introducir cambios en el file.

Al mismo time, .gitignore no es una varita mágica para borrar el historial existente del file. Por lo tanto, su estado actual debería permanecer allí y permanecerá en su historial y git-log. Ya no podrá modificarlo más (a less que se elimine de .gitignore ).