Fusionar en Git le permite unir dos o más trabajos de desarrollo creados con la rama de git en una sola rama. Incorpora los cambios de las confirmaciones con nombre y los diverge en la rama actual. Antes de realizar una opción de fusión, asegúrese de que la sucursal receptora y la sucursal fusionada estén actualizadas con los últimos cambios remotos.
¿Qué son las estrategias de fusión?
Git proporciona varios métodos para fusionar diferentes confirmaciones en una confirmación base. Estos métodos se denominan Merge Strategies . Estas confirmaciones base se combinan para formar confirmaciones de fusión. Una confirmación de combinación es como la confirmación normal, excepto que tiene dos confirmaciones principales. De las múltiples estrategias para el proceso de fusión, el git elegirá automáticamente una si no se especifica explícitamente. Esta selección automática de la estrategia de fusión se basa en las ramas proporcionadas para la fusión.
Hay varios tipos de estrategias de fusión:
- Avance rápido
- recursivo
- Nuestro
- Pulpo
- Resolver
- subárbol
Git merge will combine multiple sequences of commits into one unified history. In the most frequent use cases, git merge is used to combine two branches. Any of the upgiven strategies can be used to perform the merging process according to the needs of the project. The most commonly used strategies are Fast Forward Merge and Recursive Merge.
Fast Forward Merge:
In this most commonly used merge strategy, history is just one straight line. When you create a branch, make some commits in that branch, the time you’re ready to merge, there is no new merge on the master. That way master’s pointer is just moved straight forward and history is one straight line.
Command:
$ git rebase
Recursive Merge:
In Recursive merge, after you branch and make some commits, there are some new original commits on the ‘master‘. So, when it’s time to merge, git recurses over the branch and creates a new merge commit. The merge commit continues to have two parents.
Command:
$ git merge--no-ff
Nota: No hay nada correcto o incorrecto en ninguna de las estrategias, pero con la combinación de avance rápido tiene una línea recta de historial y con la combinación recursiva , es de múltiples líneas.
Fast-Forward merge vs Recursive merge:
Avance rápido | recursivo |
---|---|
No hay nuevas confirmaciones en el maestro | Nuevas confirmaciones en el maestro |
Historia lineal | Comprometer a 2 padres |
Sin compromisos de fusión | Se crea la confirmación de fusión |
git rebase | git merge-no-ff |
Ours Merge:
This merge strategy resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede the old development history of side branches.
Note: This strategy is different from the -Xours option to the ‘recursive‘ merge strategy.
Command:
$ git merge -s ours
Octopus Merge:
Octopus Merge strategy resolves cases with more than two heads but refuses to do a complex merge that needs manual resolution. It is primarily meant to be used for bundling topic branch heads together. This is the default merge strategy when pulling or merging more than one branch.
Command:
$ git merge -s octopus
Resolve Merge:
This strategy can only resolve two heads (i.e. the current branch and another branch you pulled from) using a 3-way merge algorithm. It tries to carefully detect criss-cross merge ambiguities and is considered generally safe and fast.
Command:
$ git merge -s resolve
Note: ‘-s resolve‘ solves only trivial conditions. If code differs between branches, the conflict has to be solved manually.
Subtree Merge:
This is a modified recursive strategy. When merging trees A and B, if B corresponds to a subtree of A, B is first adjusted to match the tree structure of A, instead of reading the trees at the same level. This adjustment is also done to the common ancestor tree.
Command:
$ git merge -s subtree
Manually call named merge strategy
-s<Strategy> and –strategy=<Strategy>: These strategies can be supplied more than once to specify them in the order they should be tried. If there is no -s option, a built-in list of strategies is used instead (git merge-recursive when merging a single head, git merge-octopus otherwise).
Dominio:
$ git merge -s recursive $ git merge --strategy=octopus
Publicación traducida automáticamente
Artículo escrito por ayushmankumar7 y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA