Git: ignora un file de un subtree, pero realiza un seguimiento local y lo envía a una producción remota

Tengo un flujo de trabajo bastante específico y el motivo es que utilizo el git subtree para include un proyecto dentro de otro:

Debe tener un aspecto como este:

 code |--/.git |--.gitignore |--/styling | |--file1 | |--file2.v1 |--file3 styling-bare styling |--/.git |--.gitignore |--file1 |--file2.v2 

Hay dos casos de uso para el flujo de trabajo:

  1. cd en styling , pull de styling-exchange , luego cd en code , actualice el subtree de styling , realice algunos cambios en file1 y file2 y file3 , presione en production
  2. cd en el code , realice algunos cambios en file1 y file2 y file3 , presione cambios en styling-bare (subprocess push), cd en styling , pull desde styling-bare , presione cambios en styling-exchange

Me gustaría tener dos versiones completamente diferentes y separadas de file2 en los repositorys locales styling/styling-bare VS the code/production repositories de code/production . Necesito que todas las actualizaciones del subtree de styling conviertan en code/styling , pero necesito hacer un seguimiento del file2 solo dentro del code , sin ninguna actualización del styling .

Es decir, me gustaría actualizar el subtree de styling en el repository de code , pero conservo mi propia versión de file2 cuando hago eso (mientras sincronizo el file1 entre el styling y el code y el file3 sincronizado entre el code y la production ), de modo que puedo impulsar mi propio file versión (v1) del file2 a production más tarde.

¿Hay alguna forma elegante de hacer eso en git sin enlaces simbólicos o algunos ganchos sofisticados?

Tenga en count que he experimentado con:

  • .gitignore file2 en el repository de code : esto no funciona, el file está allí una vez que hago el subtree pull al subtree de styling ;

  • diferentes versiones .gitignore para diferentes twigs, pero esto se rompe una vez que me fusiono;

  • He intentado excluir file2 con .git / info / exclude_from_styling, esto no tiene ningún efecto;

  • He intentado eliminar el file2 del índice con git update-index --assume-unchanged styling/file2 , pero esto no soluciona mi problema;

  • esta solución no funcionará para mí, porque no podré llevar todo el directory de styling a production ;

  • No estoy seguro de que un controller de filter pueda ayudar a resolver el problema;

  • Necesito mantener el mismo nombre para el file2 en todos los repositorys, por lo que la solución con diferentes nombres tampoco es útil.

Solutions Collecting From Web of "Git: ignora un file de un subtree, pero realiza un seguimiento local y lo envía a una producción remota"

Sugerencias que vienen a la mente:

  • En lugar de una git subtree pull simple git subtree pull , puede usar una secuencia de commands para extraer los cambios en el depósito de code , lo que haría algo similar a lo siguiente:

    git subtree pull ... && git checkout branch/with/my/specific/file2 -- styling/file2.v1

  • Puede extraer los cambios del styling en una twig especial utilizada solo para tirar, y combinar los cambios en su propia twig. No lo he probado, pero debería haber forms de decir sistemáticamente "mantener mi versión de este file fusionada": decirle a git que use nuestra estrategia de fusión en files específicos

Yo no llamaría exactamente esto elegante, y cada método tiene sus defectos.

Mencionaste que querías evitar los enganches, pero también puedes poner la git checkout branch/with/my/specific/file2 -- styling/file2.v1 en un enganche post-commit, o en un "smudger" en el pago (solo descubrió acerca de los filters de git )

  1. Si uno se genera como una minificación , puede considerar tener un script que lo construya automáticamente. Como regla general: nunca, pero nunca ponga el código generado en un VCS.
  2. Si v1 es el mismo file aunque como v2, use

     git diff <sha>..<sha> 

    o incluso puede usar una GUI (por ejemplo, meld):

     git difftool <sha>..<sha> 
  3. Si no realiza cambios en ninguno de ellos, no agregue el mismo proyecto dos veces en su subtree, pero use un script para getlo en cualquier momento que lo necesite (la versión de solo lectura).

Ayudaría a conocer los idiomas, los frameworks en los que está utilizando este layout de proyecto.