Git: no se puede entender por qué se están produciendo/fusiones de ramas (tema) en la rama principal

Question

Nota: No estoy seguro de si esto ya se ha preguntado, ya que no encuentro ninguna pregunta adecuada a mi contexto (o soy incapaz de entender los "contextos" de las preguntas existentes)

Estoy amando a Git en estos días. Especialmente, el tema se ramifica. Estoy trabajando en una pequeña aplicación para compartir códigos. Y tengo ramas (locales) como "maestro", "autenticación", "marcadores", "comentarios", "nariz", etc ...

Mi flujo de trabajo (previsto) es algo como esto: Crear una rama temática ==> Trabajar en la rama de tema ==> Confirmar los archivos en la rama ==> Fusionar los cambios de rama de tema con la rama "principal". (Y más tarde eliminar la rama de tema)

He intentado hacer lo mismo para un par de ramas. Funcionó bien Pero más tarde, cuando revisé el gráfico de git, incluso si seguía el mismo flujo de trabajo, todas las posibilidades pasaban en el "maestro". ¡No hay líneas de árboles divergentes y convergentes! Muestra una sola línea con múltiples compromisos a partir de entonces. No estoy seguro ¿por qué? Soy de la impresión, ¿me jodí algo con el puntero HEAD?

Para dar una visión práctica, aquí es mi gráfico git: http://github.com/none-da/zeshare/network

Estos son los comandos que utilicé:

>> git branch authentication_feature 
>> git checkout authentication_feature 
>> # I work with all the files here in "authentication_feature" branch 
>> git commit -m "Authentication_feature is up" # commiting to the branch 
>> git branch # just to confirm, which branch I am working on 
>> git checkout master # trying to shift to master branch 
>> git merge --no-commit authentication_feature # I merge in two steps. This is step 1 
>> git status;git add; git commit -m "Authentication_feature" merged to "master". # This is the step 2 
>> git log --graph --pretty=oneline # confirming the graph 
>> git push origin master # pushing to the remote server(github) 

Answer 1

Pero más tarde, cuando he comprobado el gráfico git, aunque he seguido el mismo flujo de trabajo, todas las posibilidades estaban sucediendo en el "dominar".¡No hay líneas de árboles divergentes y convergentes!

Bueno ... Veo algunas de sus sucursales y se funde.

Usted encontrará en esta page all the possible merge scenarios
(compilado en el momento - a finales de 2007 - por ahora tan colaborador: Jakub Narębski)

Usted podría estar en un caso de avance rápido, lo que explicaría por qué sus fusiones harán todas sus confirmaciones parecen dominar una vez que han finalizado:

2/Avance rápido; No hay se comete A, B, C, y a empezar desde el siguiente situación:

1---2---3    <-- trunk <-- HEAD 
      \ 
      \-a---b---c <-- branch 

2,1/"git merge branch"

1---2---3   /----- trunk <-- HEAD 
      \   v 
      \-a---b---c <-- branch 

resultados de avance rápido en simplemente moviendo la cabeza del tronco.
No crea una confirmación, por lo tanto:

2.2/"git merge --no-commit branch"

Al igual que en el punto 2.1, ya que el avance rápido no crea una confirmación.

Así que si usted no cometió el maestro ya se bifurcó, y luego hacer una fusión de maestro, todo lo que hace es restablecer cabeza principal ...

---

Otra causa de las ramas para no se visualiza es la "lista de tareas pendientes efecto" descrito en el presentation page of the GitHub Network Graph visualizer (que es el "gráfico de Git" se está refiriendo a aquí)

Pero usted está viendo cada confirmación sólo una vez. Deje que se hunda por un segundo.
Me parece que muchos codificadores están tan acostumbrados a un SCM centralizado que no tienen en cuenta que Graph Display muestra y conecta repositorios dispares.

Si dibujo el gráfico conmigo mismo como usuario root, el gráfico muestra una especie de lista de cosas por hacer que aún no he incluido en mi repositorio.
Cuando quiero ponerme al día sobre lo que la comunidad ha estado haciendo en sus bizcos de mi repositorio, puedo ver el gráfico y ver de inmediato lo que otros han estado haciendo.
Si tuviera que ver con los cambios de Bertg, la próxima vez que vea el gráfico, Bertg ya no se mostrará porque ya no tendrá ningún compromiso que yo no realice.
Siga pensando en la lista de tareas pendientes y comprenderá el gráfico.

Entonces, si eso es cierto para las fusiones de otras ramas de repos (es decirya no ves esas ramas una vez que están fusionadas), eso puede ser cierto para las fusiones desde tus propias ramas de repositorio: una vez fusionadas, ya no las ves en tu gráfico.

Pero yo, desde:

• no soy el dueño del proyecto.
• Es posible que desee retirar mis cambios de repositorio de cualquiera de sus sucursales.

Answer 2

Usted no ha dicho qué comandos efectivamente utilizadas, pero mi conjetura es que Creó su rama con git branch pero no la revisó para moverla a la sucursal. Puede hacerlo en un solo paso de la siguiente manera:

git checkout master -b topic22 

Esto hace que sea menos probable que se comprometa inadvertidamente con el maestro.

Ahora que ha agregado la secuencia de comandos que hizo, veo que realizó la extracción de la sucursal.

La secuencia de comandos se ve bien. Creo que la razón por la que parece que no hubo una sucursal es porque no hubo una intervención intermedia en la rama principal. Después de la fusión, parece un flujo de desarrollo secuencial. Esto se discute bien en una de las otras respuestas, así que no hay necesidad de explicarlo aquí.

Answer 3

¿Está utilizando algo así como

git show-branch 

para mostrarle las ramas y check-ins, una vez que fusionaron sus ramas para dominar no se puede ver más revisiones - no estoy seguro por qué.

No puedo encontrar ninguna explicación sobre el comportamiento pero no parece haber ningún problema con el repositorio de git ya que git log muestra todas las confirmaciones para cada rama.

Así que supongo que es solo la forma en que la herramienta muestra el gráfico de ramas.

Answer 4

Soy totalmente nuevo para git y github (y el enlace aún está abajo), pero después de ver sus pasos, ¿podría ser porque no empujó la rama real a github? Esto parece estar funcionando para mí hasta ahora (insertar el comando push):

... 
>> git commit -m "Authentication_feature is up" # commiting to the branch 
>> git branch # just to confirm, which branch I am working on 
>> git push origin authentication_feature # push the branch to github 
>> git checkout master # trying to shift to master branch 
... 

Answer 5

Apuesto a que está buscando el interruptor --no-ff en git merge. De manera predeterminada, merge simplemente actualizará el HEAD a la punta de la nueva bifurcación, si no hay una confirmación intermedia.

Si desea dejar la combinación de fusión para ayudar con la agrupación de sus confirmaciones, pase --no-ff.

Answer 6

Como una alternativa al uso git merge --no-ff:

Si quieres cometer el efecto del desarrollo de la rama tema a la rama principal, pero no todos de la persona comete, a continuación, puede utilizar git merge --squash. Cuando hace esto, la confirmación no está marcada como una fusión y no tiene un segundo padre de la rama de tema. La lista de confirmaciones individuales se incluye en el comentario de confirmación para la fusión aplastada, ya que se enumerarían en git log.

Hemos estado utilizando esto en un proyecto que está vinculado a SVN (por git svn), por lo que nuestra rama principal tiene un historial lineal. De esta forma, no tenemos que aplanar el gráfico de confirmación de git antes de ejecutar git svn dcommit.