Gitflow: git flow init falla en el repositorio clonado.

Tengo exactamente el mismo problema. Todavía no he creado una rama maestra localmente (ya que eso también me parece incorrecto), pero aún no he encontrado una solución diferente. Sin embargo, volveré a publicar si puedo encontrar algo.

Hasta ahora, la única solución que he encontrado es crear la rama maestra, incluso si no se está utilizando. No es agradable, pero funciona. ¡Ojalá haya una solución pronto!

¿No sería más prudente realizar un seguimiento de la rama maestra inicial, p. Ej.
git checkout -t origen / maestro

Claro ... ¡Si hay uno! Al crear nuevos proyectos, no presiono un
rama maestra vacía, y después de presionar desarrollar, no hay maestro en
github tampoco.

Entonces sigue siendo un problema.

Enviado desde mi Windows Phone (sí, lo leíste correctamente) De: shuane
Enviado: sábado 2 de julio de 2011 6:33
Para: [email protected]
Asunto: Re: [gitflow] git flow init falla en el repositorio clonado. (# 121)
¿No sería más prudente realizar un seguimiento de la rama maestra inicial, p. Ej.
git checkout -t origen / maestro

Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/nvie/gitflow/issues/121#issuecomment -1486906

+1 mismo problema ...

+1 mismo problema

¿Cuál es la razón filosófica detrás de no querer empujar la rama maestra inicial vacía (que se crea por defecto) cuando se crea el repositorio por primera vez?

Si no empuja la rama maestra (como parece que los comentaristas aquí no lo han hecho intencionalmente), entonces no puede convertirla en un clon. Git-flow tiene razón al no intentar crear una nueva, en caso de que haya olvidado verificar una rama maestra preexistente y luego tenga un conflicto si crea una nueva rama.

No hay nada filosófico en esto. Tiene que ver con el flujo de trabajo. Puedo impulsar una rama maestra, pero es posible que no impida que la gente se apropie solo de la rama de desarrollo.

Git-flow podría tener razón al no intentar crear uno nuevo. Pero en lugar de fallar, ¿por qué no me preguntas? "¿Quieres que cree una nueva rama o debo rastrear el maestro remoto por ti?"

¿Pensamientos?

En el caso de algunas personas aquí, no hay un maestro remoto porque piensan que sería incorrecto empujar una rama vacía. Sería útil para ellos realizar

git push --all origin 

para impulsar las ramas de desarrollo y maestra inicialmente para solucionar esa parte del problema.

Si hubiera un maestro remoto, sería útil hacer esa pregunta en ese momento, y no debería ser demasiado difícil de implementar para alguien. Es una alternativa simple y no afectará el flujo de trabajo de nadie más si ellos mismos crean la rama maestra.

Así es como nos encontramos con el problema. La mayor parte de nuestro desarrollo en este momento en nuestro repositorio de git se encuentra en ramas de características fuera de desarrollo.

Había configurado "desarrollar" como la rama predeterminada del repositorio en github. Quería trabajar en una rama de funciones de una nueva máquina. Cloné el repositorio, hice "git flow init" y falló.

@lorin Esto demuestra que hay un montón de formas en las que podemos ser mordidos por esto. Para mí tiene mucho sentido que git-flow maneje este caso, incluso si requiere un aviso molesto, es mejor que no trabajar en absoluto y confiar en que las personas lo averigüen por sí mismas.

Parte de este problema puede ser que git solo puede obtener una sola rama cuando ejecuta git clone, y si configura la rama predeterminada de GitHub para que sea algo diferente a master, como yo también lo hago, entonces master no estará allí como una referencia remota hasta que ejecute git fetch origin (creo). Si ese es el caso de muchas personas, es posible que la confirmación que agregó el cambio para git-flow-init para admitir la verificación de remotes / origin / master [1] deba extenderse para agregar una llamada "git fetch origin" antes de verificar si el amo existe.

[1] https://github.com/nvie/gitflow/commit/baf163e07d579bec3dd0e21d00297832e8848b8b

entonces el maestro no estará allí como referencia remota hasta que ejecute git fetch origin (creo).

La operación de clonación de git literalmente clona el repositorio como se indica en el inicio de progit , puede desconectar su cable de red y hacer:

git checkout -b master origin/master

git te creará la rama local llamada master como una copia de origin / master.

Nota:

git checkout master

es suficiente como si no se encontrara la rama pero hay una rama de seguimiento que se utiliza.

@kasterma ¡ gracias!

$ git flow init

Which branch should be used for bringing forth production releases?
   - develop
Branch name for production releases: [] 
Local branch '' does not exist.

$ git branch -a
* develop
  remotes/origin/HEAD -> origin/develop
  remotes/origin/develop
  remotes/origin/master

Para obtener la sucursal local:

$ git checkout master
$ git checkout develop
$ git branch -a
* develop
  master
  remotes/origin/HEAD -> origin/develop
  remotes/origin/develop
  remotes/origin/master

Ahora ejecute git flow init como de costumbre.

$ git flow init

git config gitflow.branch.master master para configurar su rama master correctamente cuando no puede "cancelar" un git flow init.

Lo mismo aquí, tengo el mismo problema.

+1 mismo problema

+1

Me encontré con esto. ¡Garrrgh! +1

Asegúrese de verificar el master al menos una vez en su repositorio local.

Lo haré, gracias

El 18 de noviembre de 2016 a las 6:41 p.m., "Rob Moore" [email protected] escribió:

Asegúrese de verificar el master al menos una vez en su repositorio local.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/nvie/gitflow/issues/121#issuecomment -261593726, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AVuyNjaPvHr8jyO9Zmy1bzynI0mhm0F_ks5q_eNRgaJpZM4AD0E_
.

+1 también me pasó a mí.

Hizo los siguientes pasos para solucionar el problema en el repositorio clonado

 git checkout -b master
 git checkout develop
 git flow init

Mi proceso de TeamCity CI puede envolver una compilación dentro de un _git flow release_ a través de scripts _ant_, pero aprendí en el camino que era necesario pagar tanto master como develop , y luego ejecutar la inicialización predeterminada antes de la construcción:

git flow init -d

¿No sería más prudente realizar un seguimiento de la rama maestra inicial, p. Ej.
git checkout -t origen / maestro

¡funciona para mi! gracias

La solucion es:
-git ckeckout master
-git checkout desarrollar
-git flow init

@ andres310597 Esa puede ser la respuesta para ti. No ayudó en mi repositorio.

➜  mobile_provider git:(develop) git checkout master   
Updating files: 100% (17199/17199), done.
Switched to branch 'master'
Your branch is up to date with 'origin/master'. 
➜  mobile_provider git:(master) ✗ git checkout develop
Updating files: 100% (17199/17199), done.
Switched to branch 'develop'
Your branch is up to date with 'origin/develop'.                                                            /3.1s
➜  mobile_provider git:(develop) git flow init       

Which branch should be used for integration of the "next release"?
   - bug/mstelly/prov/2449-leave-job-crash
   - master
   - poc/realmdb
Branch name for "next release" development: [develop]

Y mi archivo .gitconfig no contiene ninguna referencia a ninguna configuración de flujo. Entonces no sé dónde se almacenan los valores.

El hecho de que este problema haya permanecido abierto durante 9 años dice mucho sobre nuestras posibilidades de que se resuelva pronto. Sin embargo, acepté los valores predeterminados y recibí este mensaje:
To force reinitialization, use: git flow init -f
Entonces, no está roto. Supongo que no está bien documentado. Probablemente alguien debería cerrar este problema.