2011-11-17 10 views
10

Estoy utilizando la ramificación para crear e implementar instancias personalizadas de la plataforma externa. Estas instancias usualmente comienzan como una rama de la rama 'maestra', se personalizan un poco, se implementan en pruebas y producción, y finalmente se archivan.evitando la fusión de git a la rama maestra

Si se agregan nuevas características o correcciones de errores en el maestro, me gustaría poder buscarlas/fusionarlas en las instancias de mi proyecto (ramas), pero casi nunca quiero fusionar los cambios de las ramas al maestro. Esto ocurrió recientemente por error y ha creado algunos dolores de cabeza graves. Un git pull para actualizar un repositorio fusionó todo en la rama maestra y luego se volvió a colocar en el repositorio principal.

¿Hay alguna manera fácil de prohibir la fusión de nuevo en el maestro? ¿O al menos requiriendo alguna bandera de la fuerza?

Respuesta

2

Puede garantizar que no se fusionará con el maestro de otras ramas al prohibir que cualquiera presione la rama principal. Una persona con autoridad puede hacer eso. Gitolite es algo que le permite ajustar con precisión el acceso a las sucursales. También puede escribir sus propios ganchos del lado del servidor y rechazar la actualización de la rama principal a menos que sea un usuario específico.

+0

lo que pasa con el downvote? Déjame saber qué pasa con mi respuesta y lo aclararé. Gracias. –

+0

Hola Adam, no creo que rechacé tu respuesta. De hecho, estoy bastante seguro de haber subido. Pero si cometí un error, lo siento. También Gitolite es un poco demasiado para nuestras necesidades en este momento, pero puedo ver cómo los ganchos del lado del servidor podrían hacer lo que necesito. – balm

+0

gitolita es sorprendentemente fácil. Te recomiendo que le des un giro. El mayor beneficio es que simplifica enormemente la administración de claves. Ah, y no quise decir que fuiste tú quien votó negativamente. No puedes obtener esa información. Tenía mucha curiosidad por saber por qué mi respuesta no satisfizo a nadie o si cometí un error al respecto. –

-1

Si solo quieres evitar fusionarte en master, puedes usar el hook pre-merge para prohibirlo.

+1

No encuentro evidencia de que exista algo como un enlace previo a la fusión. – pjmorse

1

Git está muy contento de trabajar con múltiples repositorios remotos.

Recomendaría usar un repositorio remoto para cada instancia personalizada. Esto no cambiaría su flujo de trabajo, ya que Git puede fusionar dos ramas juntas independientemente de su origen.

para actualizar una "instancia a medida" con correcciones de errores de su "maestro remoto" debería escribir algo como

git checkout <custom-branch> 
git fetch main 
git merge main/master 

donde main es el repositorio remoto que usted se refiere como master (I cambió el nombre para evitar la confusión entre una rama y un mando a distancia)

para sus ramas locales, nomain especifique como la rama de seguimiento remoto, en lugar de especificar una distancia específica de la instancia. es decir, un repositorio remoto por instancia personalizada.

Para impulsar cambios en la instancia personalizada, utilice

git push 

En el raro caso de que usted necesita para empujar cambios aguas arriba hasta el "maestro" utilización rama

git push main 
+0

Gracias. Así es exactamente como trabajamos, pero de alguna manera alguien hizo un git push --todo y luego un git pull o algo así que fusionó todo. O al menos eso es lo que entiendo. – balm

+0

No use git pull. Git busca primero y luego actúa de acuerdo con las ramas de seguimiento remotas actualizadas con la fusión, el rebase o el restablecimiento de las sucursales locales. –

+0

Estoy de acuerdo con Adam, así es como lo hago. Solo asegúrate de no modificar la base una vez que presionas los cambios o las cosas se ponen feas. –

Cuestiones relacionadas