git - remota - Fusionar rama de desarrollo con maestro

moverse a una rama en git

Question

Tengo dos ramas: master y development en un repositorio de GitHub. Estoy haciendo todo mi desarrollo en la rama de desarrollo como se muestra.

git branch development
git add *
git commit -m "My initial commit message"
git push -u origin development

Ahora quiero fusionar todos los cambios en la rama de development en el master . Mi enfoque actual es:

git checkout master
git merge development
git push -u origin master

Por favor, hágamelo saber si el procedimiento que estoy siguiendo es correcto.

Answer 1

1) En la rama Desarrollo, verifique el estado de git usando el siguiente comando:

git status

No debe haber ningún código no comprometido. Si es así, presione su código en la rama Desarrollo:

git add *
git commit -m "My initial commit message"
git push origin Development

2) En la rama de desarrollo, ejecute los siguientes dos comandos:

git branch -f master HEAD
git push -f origin master

Empujará su código de rama Desarrollo a rama principal.

Answer 2

Así es como normalmente lo hago. Primero, asegúrese de estar listo para combinar sus cambios en el maestro.

1. Compruebe si el desarrollo está actualizado con los últimos cambios de su servidor remoto con un git fetch
2. Una vez finalizada la búsqueda git checkout master .
3. Asegúrate de que la rama maestra tenga las últimas actualizaciones ejecutando git pull
4. Una vez que se hayan completado los preparativos, puede iniciar la fusión con git merge development
5. Presiona los cambios con git push -u origin master y listo.

Puede encontrar más información sobre la fusión de git en el artículo.

Answer 3

Basado en @Sailesh y @DavidCulp:

(on branch development)
$ git fetch origin master
$ git merge FETCH_HEAD
(resolve any merge conflicts if there are any)
$ git checkout master
$ git merge --no-ff development (there won''t be any conflicts now)

El primer comando se asegurará de que tenga todas las confirmaciones en sentido ascendente realizadas al maestro remoto, con una respuesta de Sailesh que no sucedería.

El segundo realizará una combinación y creará conflictos que luego podrá resolver.

Después de hacerlo, finalmente puede sacar el master para cambiar al master.

Luego fusionas la rama de desarrollo en el maestro local. El indicador no-ff creará un nodo de confirmación en el maestro para que la fusión completa sea rastreable.

Después de eso puedes comprometer y empujar tu fusión.

Este procedimiento asegurará que haya un compromiso de fusión desde el desarrollo hasta el dominio que las personas puedan ver, luego, si van a ver la rama de desarrollo, pueden ver los compromisos individuales que ha realizado en esa rama durante su desarrollo.

Opcionalmente, puede modificar su confirmación de fusión antes de presionarla, si desea agregar un resumen de lo que se hizo en la rama de desarrollo.

EDITAR: mi respuesta original sugirió un git merge master que no hizo nada, es mejor hacer git merge FETCH_HEAD después de obtener el origen / master

Answer 4

En general, me gusta fusionar el master en el development primero, de modo que si hay algún conflicto, puedo resolverlo en la rama del development y mi master permanece limpio.

(on branch development)$ git merge master
(resolve any merge conflicts if there are any)
git checkout master
git merge development (there won''t be any conflicts now)

No hay mucha diferencia en los dos enfoques, pero a veces me he dado cuenta de que no quiero fusionar la rama con la master aún, después de fusionarlas, o que todavía hay mucho trabajo por hacer antes de que puedan realizarse. fusionado, por lo que tiendo a dejar master intacto hasta las cosas finales.

EDITAR: De los comentarios

Si desea realizar un seguimiento de quién hizo la fusión y cuándo, puede usar la --no-ff mientras se fusiona para hacerlo. En general, esto es útil solo cuando se fusiona el development con el master (último paso), ya que es posible que deba combinar el master con el development (primer paso) varias veces en su flujo de trabajo, y crear un nodo de confirmación para estos puede no ser muy útil.

git merge --no-ff development

Answer 5

Explicación desde abajo para aquellos que vinieron aquí sin ningún conocimiento de las sucursales.

La lógica básica del desarrollo de la rama maestra es: usted trabaja solo en otras ramas y usa la máquina maestra solo para combinar otras ramas.

Comienzas a crear una nueva rama de esta manera:

1) Clonó el repositorio necesario en su raíz web:

$ cd /var/www
$ git clone [email protected]:user_name/repository_name.git

2) Crea una nueva rama. Contendrá los últimos archivos de su repositorio de rama maestro

$ git branch new_branch

3) Cambia la rama de git a new_branch

$ git checkout new_branch

4) Hacer codificación, cometer, como de costumbre ...

$ git add .
$ git commit -m “Initial commit”
$ git push (pushes commits only to “new_branch”)

5) Cuando el trabajo haya finalizado en esta rama, fusionar con la rama "maestra":

$ git merge master
$ git checkout master (goes to master branch)
$ git merge development (merges files in localhost. Master shouldn’t have any commits ahead, otherwise there will be a need for pull and merging code by hands!)
$ git push (pushes all “new_branch” commits to both branches - “master” and “new_branch”)

Answer 6

Personalmente, mi enfoque es similar al tuyo, con algunas ramas más y algunos intentos de rechazo cuando vuelven al maestro.

A uno de mis compañeros de trabajo no le gusta tener que cambiar de rama tanto y se queda en la rama de desarrollo con algo similar a lo siguiente, todo ejecutado desde la rama de desarrollo.

git fetch origin master
git merge master
git push origin development:master

La primera línea se asegura de que tenga cualquier compromiso ascendente que se haya hecho para dominar desde la última vez que se actualizó su repositorio local.

El segundo extrae esos cambios (si los hay) del maestro al desarrollo

El tercero empuja la rama de desarrollo (ahora completamente fusionada con el maestro) hasta el origen / maestro.

Puede que tenga su flujo de trabajo básico un poco mal, pero esa es la esencia principal de ello.

Answer 7

Sí, esto es correcto, pero parece un flujo de trabajo muy básico, en el que solo estás guardando los cambios antes de que estén listos para la integración. Debes buscar flujos de trabajo más avanzados que soporte git. Es posible que le guste el enfoque de rama temática , que le permite trabajar en múltiples funciones en paralelo, o el enfoque de graduación que extiende un poco su flujo de trabajo actual.

Answer 8

Sería genial si puedes usar el comando Git Flow. Se fusiona desarrollar rama a maestro fácilmente.

Lo que quieres hacer es seguir las instrucciones de flujo de git que se mencionan aquí.

http://danielkummer.github.io/git-flow-cheatsheet/

pasos.

• configurar el proyecto de flujo git
• Crea ramas y compromete todo para desarrollar.
• ejecuta el comando "git flow release start"
• A continuación, dar un mensaje completo significado para el lanzamiento
• ejecuta el comando "git flow release finish"
• fusionará todo en master y cambiará la rama a master.
• ejecute el comando "git push" para confirmar los cambios en el maestro.

Compruebe el enlace de arriba para más información.

Answer 9

Si está en Mac o Ubuntu, vaya a la carpeta de trabajo de la sucursal. En la terminal

supongamos que harisdev es el nombre de la rama.

git checkout master

Si hay archivos sin seguimiento o sin confirmar, recibirá un error y tendrá que confirmar o eliminar todos los archivos sin seguimiento o sin confirmar.

git merge harisdev
git push origin master

Un último comando para eliminar la rama.

$ git branch -d harisdev

Answer 10

git pull (rama de desarrollo actual)

git checkout master

git pull

desarrollo de git merge

git push master master

Answer 11

Paso 1

Cree y cambie a una nueva rama "dev", donde sus archivos git locales están sincronizados con el remoto, pero la rama "dev" todavía no existe.

git branch dev # create
git checkout dev # switch
# No need to git add or git commit, the current
# branch''s files will be cloned to the new branch by-default.
git push --set-upstream origin dev # push the "dev" branch to the remote.

Paso 2

Realice los cambios en la rama "dev" (su actual si sigue el paso 1), confírmelos y colóquelos en la rama "dev" remota.

git add .
git commit -S -m "my first commit to the dev branch" # remove the -S if you''re not "secure", secure = when you already setup crypto private and public keys (i.e "verified" green sign in github)
git push -u origin dev # push the changes to the remote, -u origin dev is optional but good to use.

Paso 3

Combina tu rama "dev" en el "maestro".

git checkout dev # switch to "dev" branch if you''re not already.
git merge master # optionally, this command is being used to resolve any conflicts if you pushed any changes to your "master" but "dev" doesn''t have that commit.
git checkout master # switch to "master", which is the branch you want to be merged.
git merge --no-ff dev # merge the "dev" branch into the "master" one.