Hacer que Git retenga contenido de sección diferente entre sucursales

Estoy desarrollando un UserScript que mis empleadores me han pedido que comience a administrar a través de Git.

En este momento, tengo un archivo estable y un archivo beta, para que todos en la organización puedan instalar el código estable, pero pueden elegir ayudar a probar las adiciones beta en su lugar, si así lo desean. Algunas partes de ese archivo deben seguir siendo diferentes, el contenido y los cambios no se deben fusionar entre sucursales.

Por ejemplo, si convierto el archivo Beta en una Sucursal Git, y luego decido que los cambios Beta son estables y fusionaré la Beta nuevamente en el código Estable (que no habrá cambiado) el proceso Git Merge, como lo entiendo, será “útil” “actualice los encabezados de definición Stable Greasemonkey en función de los valores que estén en esas líneas en la twig Beta. Esto es totalmente indeseable, ya que estos encabezados contienen una URL de actualización automática que Greasemonkey verificará si hay actualizaciones.

// ==UserScript== (stable) // @downloadURL -- StableURL File Location // ==/UserScript== // ==UserScript== (beta) // @downloadURL -- BetaURL File Location // ==/UserScript== >Git Merge< // ==UserScript== (stable) // @downloadURL -- BetaURL File Location // ==/UserScript== 

Quiero conservar la capacidad de tener URL distintas entre el código Beta y el código estable, pero no he podido identificar un método para hacer que el proceso de fusión de Git ignore las líneas que Greasemonkey necesita para hacer sus cosas correctamente, pero si no lo hago Tengo la versión Beta como una twig separada, no estoy seguro de cómo usar Git para migrar fácilmente el código cambiado de Beta a Stable, que es la razón indicada para pedirme que adopte la funcionalidad de Git. (Bueno, la otra razón es facilitar que otros contribuyan e identifiquen la historia del proyecto …)

Cualquier ayuda es muy apreciada.

Todos los cambios deben fusionarse, excepto los cambios en esos valores, lo que hace que no sean como los demás, no cambios en el contenido intrínseco, sino cambios específicos de la implementación. Esos podrían ser mejor aplicados en el gancho post-checkout. Aquí hay una muestra, un procesador incluye por twig

 cat <<\EOF >.git/hooks/post-checkout #!/bin/sh if branch=`git symbolic-ref HEAD --short -q`; then for file in `git ls-files -cix*.@branch`; do echo "* making ${file%.@branch} from $file with branch-specific includes" echo '/^@include-branch-specific ([az/]*)$/ { s//cat \1.'$branch'/e }' \ | sed -rf- $file >${file%.@branch} done fi EOF chmod +x .git/hooks/post-checkout 
 # testing git checkout beta cat <<\EOF >config.@branch // ==UserScript== @include-branch-specific config // ==/UserScript== EOF echo >config.stable '// @downloadURL -- StableURL File Location' echo >config.beta '// @downloadURL -- BetaURL File Location' git add config.* # git rm --cached config git commit -m'setting up per-branch configs' git checkout git checkout stable git cherry-pick beta git checkout 

En su repository, cree tres archivos, llamados header.master , header.branch y main.js Luego puede mantener diferentes versiones de main.js en diferentes twigs, pero mantener los archivos de encabezado iguales, uno para cada twig, y ​​todos los archivos de encabezado estarán en todas las twigs.

Cree un script de construcción, llamado build.sh , que se ve así:

 #! /bin/sh cat header.$(git rev-parse --abbrev-ref HEAD) main.js >myscript.js 

Cualquiera de los usuarios debe ejecutar su script de comstackción, o debe proporcionar el script de usuario preconstruido usted mismo, pero supongo que ya está haciendo lo último, ¡ya que tiene una URL de descarga!

Podría escribir un controlador de combinación personalizado para git, y configurar git para usarlo, pero esto probablemente sería más problemático de lo que vale.

Elimine la línea @downloadURL de todos los archivos.

Desde la documentación de @downloadURL , cuando se omite la línea, Greasemonkey verificará la URL desde la que se cargó originalmente el script para las actualizaciones. Los usuarios de la versión se actualizarán desde la ubicación de la versión y los usuarios beta actualizarán desde la ubicación beta.

Si un usuario desea cambiar de una twig a otra, simplemente elimina la secuencia de comandos primero y luego la carga desde la twig correspondiente.

Del mismo modo, los scripts tampoco deberían tener una línea @updateURL .