publicar - git tags best practices

git mancha/filtro limpio entre las ramas

Question

Hay muchas preguntas relacionadas que involucran filtros de manchas / limpieza. Pasé algunas horas leyendo, y probando varias opciones, pero aún fallando. Espero poder preguntar de manera que obtenga una respuesta que funcione para mí.

Específicamente, he leído en la página la mayoría de estas respuestas con enlaces a:

• Personalizando Git - Atributos Git

tl; dr

Es una pregunta detallada, pero el resumen es:

• ¿Puedo almacenar DEBUG = false en un archivo en una rama, y DEBUG = true en otra rama, usando filtros de borrado / limpieza para administrar ese archivo? ¿Y cómo?

Fondo

Tengo varios repositorios remotos alojados en bitbucket. Estoy usando SourceTree en Win8, para clonar los repositorios remotos en mi computadora portátil. Creo diferentes sucursales para desarrollo, características, lanzamientos, etc. (siguiendo un modelo de bifurcación de Git exitoso para bien o para mal).

Tengo una clase java de Android llamada Dbug.java que contiene un booleano que activa / desactiva varias funciones de registro de depuración, burlas, etc. en mi código.

public static final boolean DEBUG = false;

Me gustaría que este valor fuera false en mi rama de "producción" (maestro), y que sea true en mis ramas de características.

• ¿Es esto posible usar filtros, o ya entendí mal el caso de uso?
• No estoy seguro de si los filtros funcionan así entre 2 ramas del mismo repositorio alojado localmente, o si los filtros solo funcionan entre 2 repos.

Creando los filtros

Trabajando localmente, revisé la rama de producción. debug_flag.txt un archivo de prueba llamado debug_flag.txt con el siguiente contenido:

// false on production branch
// true on other branches
DEBUG = false;

.gitattributes un archivo en la raíz de mi repositorio local llamado .gitattributes y le agregué la referencia del filtro:

debug_flag.txt filter=debug_on_off

.git/config archivo .git/config con la definición del filtro:

[filter "debug_on_off"]
    clean = sed -e ''s/DEBUG = true/DEBUG = false/''
    smudge = sed -s ''s/DEBUG = false/DEBUG = true/''

• Según tengo entendido, esto debería garantizar que mi archivo siempre tenga un valor falso en la producción, pero tendrá un valor verdadero cuando me baje de la producción.
• ¿Es este un correcto entendimiento?

Probando los filtros

Creé una nueva test rama usando:

git checkout -b test

Revisé el contenido de mi archivo:

$ cat debug_flag.txt

// false on production branch
// true on other branches
DEBUG = false;

• Esperaba ver el valor true en el archivo.
• ¿No debería haberse ejecutado el filtro de "manchas" cuando revisé el archivo?

Agregué una nueva línea al archivo, y me comprometí. Luego volví a la rama de producción, y aquí es donde las cosas se ponen extrañas .

Si miro el archivo en SourceTree, no hay cambios en esta rama desde que se creó. Eso es lo que esperaría, ya que el único cambio se realizó en una rama diferente.

Si miro el archivo en el terminal, o Notepad ++, veo que mi valor ha cambiado:

$ cat debug_flag.txt

// false on production branch
// true on other branches
DEBUG = true;

Todavía no he fusionado el cambio a través de la rama de prueba, no he realizado un compromiso en la rama de producción, pero el archivo ha cambiado .

• Parece que el filtro de manchas se ejecutó en el archivo dentro de esta rama, pero no entre las ramas.

Me falta una pieza vital del rompecabezas, y espero que sea algo simple que pueda ser descubierto por alguien con experiencia haciendo esto.

Mi apuesta es que esto es un simple malentendido del concepto.

Mensaje de Pls para cualquier información que falta ...

Actualización basada en la respuesta de VonC

La configuración de los filtros básicos funcionó bastante bien. Definió el filtro en el archivo de config como:

[filter "debug_on_off"]
    clean = sed -e ''s/DEBUG = true/DEBUG = false/''
    smudge = sed -s ''s/DEBUG = false/DEBUG = true/''

Al crear una nueva rama se corrige falso -> verdadero, fusionando los cambios verdaderos -> falso.

La limitación del cambio a solo la rama de producción (maestra) requería secuencias de comandos personalizadas que conocían la rama desde la que se ejecutan. Así que el archivo de config convirtió en:

[filter "debug_on_off"]
    clean = ./scripts/master_clean.sh
    smudge = ./scripts/master_smudge.sh

master_clean.sh:

#!/bin/sh
branch=$(git rev-parse --symbolic --abbrev-ref HEAD)
if [ "master" = "$branch" ]; then
    sed -e s/DEBUG = true/DEBUG = false/ $1
else
    cat $1
fi

master_smudge.sh:

#!/bin/sh
branch=$(git rev-parse --symbolic --abbrev-ref HEAD)
if [ "master" = "$branch" ]; then
    sed -e s/DEBUG = false/DEBUG = true/ $1
else
    cat $1
fi

En este punto, me estoy encontrando con inconsistencias entre lo que SourceTree está viendo y lo que se muestra en Notepad ++ para el contenido del archivo de depuración. SourceTree está mostrando los cambios, pero Notepad ++ no lo está.

Estoy aceptando la respuesta de VonC , ya que responde a la pregunta básica que formulé.

Sin embargo, es probable que esté implementando la solución que escribí , ya que resuelve el problema subyacente que estoy tratando de resolver, de una manera más fácil (para mí): conservar un archivo de configuración diferente en sucursales separadas.

Answer 1

Esperaba ver el valor verdadero en el archivo.

Acaba de crear una nueva rama, no desprotegió su contenido (debido a que su contenido es el mismo que la rama en la que estaba)

Para forzar que la mancha se ejecute, hazlo en la parte superior del repositorio:

git checkout HEAD --

Todavía no he fusionado el cambio a través de la rama de prueba, no he realizado un compromiso en la rama de producción, pero el archivo ha cambiado.

Esa es la idea de un controlador de filtro de contenido: modifica el contenido, sin afectar el git status (que aún informa que el archivo modificado no ha cambiado).

Para que una mancha actúe de manera diferente por rama, recomendaría llamar a un script que comience mirando el nombre de la rama actual.
Vea un ejemplo en mi respuesta anterior " Mejores prácticas - Automatización de Git + Build - Mantener las configuraciones separadas ".

#!/bin/sh
branch=$(git rev-parse --symbolic --abbrev-ref HEAD)

Answer 2

Echa un vistazo a expandr . Es un script que le permite configurar diferentes configuraciones en diferentes ramas usando smudge / clean. Básicamente justo lo que originalmente pedías.

En este momento, el mayor problema es que después de cambiar de sucursal a veces necesito hacer una git checkout HEAD -- "$(git rev-parse --show-toplevel)" para que el directorio de trabajo se manche correctamente. Otras veces, sin embargo, parece funcionar bien; Todavía no he descubierto por qué. ¿Pienso que podría tener que ver con "fusionar renormalizar" estar activado, causando algunos problemas? No estoy seguro. (Lo tengo puesto.)

El otro problema es que debe proteger los archivos .gitattributes de cada rama con merge=ours al poner una línea que dice .gitattributes merge=ours y, por supuesto, activar el controlador para eso (como ya mencionó). Lo que tenemos aquí es que después de crear cada rama por separado, ahora debes ir a cada archivo .gitattributes y modificar cada uno (recomiendo ahora agregar un comentario como #touched for merge=ours on master , #touched for merge=ours on test branch , etc., así que recordarás por qué estaba allí). Debe hacer esto porque merge=ours solo protegerá a un archivo para que no cambie a la versión de la rama entrante en una combinación si ese archivo se ha cambiado después de la creación de la rama tanto en la rama entrante como en la rama principal. (Recuerde que git se ocupa de los cambios, no de los archivos).

Answer 3

La solución más sencilla sería actualizar su makefile para incluir una comprobación de qué rama está actualmente activada. Si la rama es parte de una lista con nombre, defina un nuevo argumento de construcción -DDEBUG = true o -DDEBUG = false de lo contrario.

Vea Cómo determinar mediante programación la rama de Git que está actualmente en uso.

branch_name=$(git symbolic-ref -q HEAD)
branch_name=${branch_name##refs/heads/}
branch_name=${branch_name:-HEAD}

PROD_BRANCHES := master /
                QA
debug_flag=
ifneq ($(filter $(branch_name),$(PROD_BRANCHES)),)
    debug_flag="-DDEBUG=true"
endif
ifeq($debug_flag,)
    debug_flag="-DDEBUG=false"
endif

Answer 4

El consejo de VonC aborda la pregunta exacta que planteé, pero no pude resolver los detalles finales (según mi Actualización de la pregunta). Esta respuesta da los detalles de cómo he hecho las cosas.

Actualizar

El siguiente método funcionó para la primera fusión. Pero después de eso ya no está funcionando. Lo dejo aquí, ya que representa el estado actual de mi investigación.

Parece que los controladores de combinación ya no están siendo llamados.

También probé varias modificaciones de las preguntas relacionadas con la exit 0 , touch %A o un controlador de combinación de secuencia de comandos personalizado ( https://.com/a/930495/383414 ) en lugar de true como se presenta a continuación.

Encontré una solución a esto que usa una estrategia de merge personalizada para resolver el problema subyacente, que es:

• Quiero tener los archivos de compilación en mi rama de compilación siempre configurados para que todos los valores de depuración estén desactivados.
• Esto evita cualquier lanzamiento accidental del producto con la configuración simulada, la configuración del host local, el registro activado, etc.

He basado lo siguiente en la información de esta pregunta: .gitattributes y estrategia de fusión individual para un archivo

1) Defina un controlador de combinación personalizado en el archivo .git/config la siguiente manera:

[merge "ours"]
    name = "Keep ours merge"
    driver = true

No estoy seguro de si este paso es necesario, pero parece que puede ser una solución para un error en algunos sistemas (¿más antiguos?).

(para detalles: https://.com/a/13000959/383414 )

2) Configure un archivo .gitattributes en la construcción / producción / rama prístina para que el indicador de depuración especial use la estrategia de combinación anterior.

Entonces, usando los archivos de mi pregunta, vaya a la rama de "producción" y agregue la siguiente línea al archivo .gitattributes :

debug_flag.txt merge=ours

Cada vez que se realiza una fusión en la rama de "producción", git buscará la estrategia de fusión definida como "nuestra" e impedirá que se sobrescriba debug_flag.txt.

3) En las otras sucursales, configure su archivo .gitattributes sin esa estrategia de fusión personalizada.

4) El último paso (pero importante) del proceso de configuración, es configurar el archivo debug_flag.txt correctamente en todas las ramas, y confirmar los cambios en cada rama.

Ahora debería tener 2 sucursales, cada una con versiones diferentes de los archivos .gitattributes & debug_flag.txt. Esto asegura que cada vez que se fusionen, haya conflictos.

Sin conflictos, la estrategia de fusión "nuestra" personalizada no se llama, y ​​los archivos podrían sobrescribirse.

(para detalles: https://.com/a/16739788/383414 )

5) Finalmente, fusione su nueva sucursal de nuevo en "producción". Tendrá conflictos de combinación debido a los pasos 3 y 4. Resuelva los conflictos para que las 2 ramas mantengan sus diferencias. Cometer los cambios.

Todas las fusiones futuras entre estas 2 ramas ignorarán el archivo debug_flag.txt a la perfección.

Esto logra el objetivo de tener 2 archivos de configuración diferentes en diferentes sucursales, de modo que pueda separar fácilmente la depuración del código de producción, etc. Parece ser un caso de uso común, con muchas preguntas relacionadas en este foro, pero aún así me tomó un par de días para hacerlo bien.