Flujo de trabajo GIT: volviendo a una rama de características de la rama de lanzamiento

Question

Estoy tratando de entender un problema en la creación de un flujo de trabajo GIT

Estamos pensando en desarrollar varias características a la vez usando sucursales de características, así que digamos que tenemos:

- F1 (Feature 1)
- F2 (Feature 2)
- F3 (Feature 3)

Acabamos de completar las características 1 y 3, y fusionarlas en nuestra sucursal de desarrollo para las pruebas de integración:

-F1---Commit1---Commit2----------------------------------
-F2--------Commit1---------------------------------------
-F3--------------------------Commit1---------------------
-Development-------Merge-F1------------Merge-F2----------

La sucursal de desarrollo es el borde de sangrado y se libera como parte de una construcción nocturna.Cuando estamos contentos con esto, esta sucursal se fusiona en una rama de puesta en escena, que luego se usa para la revisión del cliente:

-F1---Commit1---Commit2---------------------------------------------
-F2--------Commit1--------------------------------------------------
-F3-------------------------Commit1-----Commit2---------------------
-Development-------Merge-F1------------Merge-F2---------------------
-Staging-------------------------------------------Merge-Development

El cliente revisa este lanzamiento en el entorno de prueba, pero no está contento con F1.Durante este tiempo, F3 está completo del código y el cliente desea revisar.

q: ¿qué tan usando git nos pondríamos en una posición en la que nuestra rama de estadificación tiene solo F2 y F3 para revisión, pero no F1 que el cliente ha rechazado ahora?

Answer 1

Un flujo de trabajo muy popular es git-flow .Esto es básicamente un modelo que es muy flexible.Eso no significa que tenga que hacerlo exactamente como se describe allí, pero puede inspirarlo.

En este caso, una buena resolución sería crear una rama temporal específica de revisión que use para mostrarle al cliente.

Esta sucursal puede basarse directamente en desarrollarse, o según la puesta en escena con las características específicas fusionadas en.

Después de que el cliente haya revisado, puede fusionar las funciones aceptadas en la sucursal de la ubicación, o en una rama de lanzamiento específica, y se puede eliminar la rama de revisión temporal.

De esta manera, no tiene que reescribir la historia para las ramas de larga vida.

Answer 2

You have basically two choices here:

1. revert the F1 merge in Development and then merge that into Staging.
   F1 will vanish from Development and Staging.

2. reset Staging to the commit before merging F1 and merge F2 and F3 by hand.
   You will end up with Staging not being a subset of Development.
   F1 will vanish from Staging only.

Answer 3

You can use the git revert command to revert merge commits.

You have to specify the merge commit you want to revert and the parent lineage to keep.

Development $ git revert -m 1 <Merge-F1 SHA>

Warning. Reverting a merge commit declares that you will never want the tree changes brought in by the merge. As a result, later merges will only bring in tree changes introduced by commits that are not ancestors of the previously reverted merge. This may or may not be what you want. (See git revert)

Comment on the warning. In case you will want to re-introduce F1, you will have to rebase the F1 commits, that way it should be possible to merge them in nevertheless.

Answer 4

We have a very similar flow in our project. The way we work is that we have two environments where we demo our customer:

• Development
• Test

We first deploy from the development branch to the Development environment. The customer tests the features individually in this environment.

Then, we merge to the staging branch only the features that the customer was happy with.

Finally, we deploy the final pre-release version to the Test environment for final review.

In this case we never have to remove a feature but maybe small fixes.