Empujar a la twig maestra remota desde la sucursal local

Estoy usando Git como mi VCS. He comprobado el maestro y he creado la twig local del maestro para trabajar con un ticket específico (por ejemplo, fileuploadbranch). Se hicieron cambios de código, se agregaron los files modificados. Luego comprometa los cambios usando

git commit -m "xxxx" 

Ahora traté de presionar al maestro remoto usando

 git push -u origin --all 

Entonces, en mis services de alojamiento bitbucket, puedo ver dos twigs, a saber, master y fileuploadbranch.

Me di count de que se debía a dar el empujón git con la opción "–all". Esto hace que todas las twigs sean empujadas a remoto.

Así que ahora probé con push con

 git push -u origin master 

Creo que se moverá solo al maestro remoto. Pero en la vista bitbucket commits, muestra el nombre de la sucursal local (fileuploadbranch) en el lado derecho y me indicó que el push procede de la sucursal local.

  1. Si estos cambios estarán disponibles en el maestro remoto, incluso lo hemos enviado desde la sucursal local.
  2. ¿Por qué muestra el nombre de la sucursal local (RHS) en la vista de commits en bitbucket?

Cualquier ayuda será apreciada !!! …

Gracias

Si desea enviar su sucursal local a la que ha llamado file_upload_branch (agregué guiones bajos aquí para la legibilidad-tenga en count que esto afecta a cada incidencia a continuación), pero llámelo master en el control remoto:

 git push origin file_upload_branch:master # see below about -u 

El último argumento para push aquí se llama "refspec", y se deletrea con dos partes: un identificador de lado local (típicamente un nombre de twig) y un identificador de lado remoto (otro, posiblemente diferente, nombre de twig). El personaje de dos puntos : sirve para separar los dos.

Si usa solo un nombre, omitiendo el dos puntos, git supone que desea el mismo nombre en cada lado. (Lo que acabas de decir no es lo que querías).

Si omite por completo el refspec (y no utiliza opciones como --all ), git elige qué empujar basándose en varias variables de configuration. Si no ha configurado ninguna de ellas, todas las versiones actuales de git utilizan el método llamado matching : 1 su git, haciendo la operación push , le pregunta al git de la otra parte "qué twigs tiene ahora", toma la list resultante y ve cuál las sucursales locales tienen ese partido, y los empuja.

Con --all como un (pseudo) refspec, su lado simplemente le pide que presione cada nombre de twig que tenga, con el mismo nombre en el control remoto (como descubrió).

(La syntax :branchname , dado como refspec, le pide al control remoto que elimine la twig nombrada. Probablemente quiera usar esto para eliminar file_upload_branch en el control remoto).

Si configura la variable de configuration push.default como upstream , 2 esto cambia la acción pnetworkingeterminada para push sin refspec para usar el nombre "upstream" de la twig actual. Es decir, si usted está en file_upload_branch y su nombre "upstream" en el control remoto ( origin ) es master , un simple:

 git push origin 

actuará como si usted escribió:

 git push origin file_upload_branch:master 

Aquí es donde entra en file_upload_branch el argumento -u : después de que file_upload_branch es exitosamente file_upload_branch a master en origin remoto, git push establecerá file_upload_branch's "upstream" en origin/master . Solo necesita hacer esto una vez por twig; habiendo establecido el push.default ascendente y establecido push.default en el push.default upstream , los push.default futuros automáticamente "harán lo que quieran".


1 En la versión 2.0 de git, el valor pnetworkingeterminado para remote.pushdefault va a cambiar a simple . Si configura su --global remote.pushdefault como simple ahora, estará preparado (y por lo tanto no afectado por) este cambio. O bien, si prefieres el upstream como pnetworkingeterminado personal, puedes configurarlo y aún así debería funcionar en 2.0.

2 Tenga en count que remote.pushdefault puede configurarse en su configuration de git por usuario (es decir, --global ) y también en una configuration por repository. La configuration por reposition anulará la configuration global cuando ambas estén configuradas. También puede establecer una matriz bastante vertiginosa de configuraciones adicionales, aunque yo no haría nada de eso todavía :-): remote.origin.push , branch.file_upload_branch.remote , y branch.file_upload_branch.pushremote pueden afectar el comportamiento. de git push . Ver la documentation de configuration de git para más detalles.