Git cambia el nombre de la sucursal remota | Operación irregular, dos líneas de lágrimas para los familiares.

¡Continúe creando, acelere el crecimiento! Este es el octavo día de mi participación en el "Nuevo plan diario de Nuggets · Desafío de actualización de junio", haga clic para ver los detalles del evento

CONSEJOS: El siguiente lenguaje de ejemplo de código es Go

Descripción del problema

Xiao A y yo estamos desarrollando en paralelo, él está optimizando la lógica del código antes y estoy desarrollando nuevas funciones.

Xiao A envió el código a la rama de prueba antes que yo, y encontré muchos conflictos cuando quería enviar mi nuevo código de función a la rama de prueba.

Resolver conflictos primero es una pérdida de tiempo, y necesito resolver conflictos cada vez que se prueba mi nuevo código de función.

Además, cuando pruebo la rama para resolver el conflicto, solo puedo resolverlo de acuerdo con la lógica de código optimizada por Xiao A, que no es consistente con mi propia lógica de rama.

El código entregado a los compañeros de prueba es inconsistente con el código de mi propia rama, este tipo de prueba no tiene sentido.

Reflexionar sobre lo que salió mal

  1. Uso irrazonable del modo de fábrica

  2. Asignación irrazonable de tareas.

nivel de código

Debido a que es el patrón de diseño de fábrica, la clase de implementación A de la que soy responsable no está directamente relacionada con su clase de implementación B. Pero porque modificó la definición del método en la clase de fábrica.

Por ejemplo, la interfaz en la clase de fábrica anterior se define así

package factory

type xxx interface {
   GetXxxx(ctx context.Context, req aaa.aa) (res bbb.bb, err error)  
}
复制代码

Pero Xiao A modificó la definición de interfaz en la clase de fábrica:

package factory

type xxx interface {
   GetXxxx(ctx context.Context, req ccc.cc) (res ddd.dd, err error)  
}
复制代码

Esto lleva a un problema:

Si quiero fusionar mi código en la rama de prueba, también tengo que modificar el tipo de parámetro y el tipo de retorno de mi clase de implementación A.

Pero todos nos estamos desarrollando en diferentes ramas, y no tengo el tipo definido por ccc.ccél ddd.dd.

No puedo definirlo directamente ccc.cc. ddd.ddQuiero venir y desarrollar mi propia sucursal. Primero, debido a los requisitos inconsistentes, el ciclo en línea de Xiao A será más largo que el mío. Segundo, esta operación en sí no está estandarizada.

Resolver el problema

Optimizar desde el diseño del código:

La solución que pensamos es usar la interfaz razonablemente

Establezca los parámetros de entrada y salida del método de interfaz que se implementará en la clase de fábrica al interface{}tipo

package factory

type xxx interface {
   GetXxxx(ctx context.Context, req interface{}) (res interface{}, err error)  
}
复制代码

Esto facilita la expansión.

Optimizar desde operaciones de git:

Pero el método de establecer los parámetros de entrada y salida como interface{}tipos no resolvió fundamentalmente nuestro problema.

La razón es esta:

El requisito de la pequeña A es optimizar los parámetros de entrada y salida de la clase de fábrica y cada clase de implementación en su conjunto, optimizar la lógica interna y extraer métodos.

La modificación de la pequeña A genera un gran conflicto con mi lógica de implementación.

Pero su envío de git se envió al entorno de prueba antes que yo, por lo que no pude enviar mi código. Si quería enviarlo, tenía que resolver varios conflictos. Para resolver el conflicto, debemos cambiarlo de acuerdo con la lógica de optimización de Xiao A, y las pruebas dadas a los estudiantes de prueba son inconsistentes con mi propia rama.

Difícil de superar.

Teniendo en cuenta que la modificación de la pequeña A no necesita ser probada por el momento, el ciclo en línea también es relativamente largo.

La solución final es esta:

Sacó una rama de respaldo de la rama de prueba remota

eliminar la rama de prueba remota

Envíe la sucursal que necesito probar localmente a la sucursal de prueba y entregue la prueba.

git cambiar el nombre de la rama remota

1. Cambiar el nombre de la sucursal local primero

git branch -m 旧分支名称  新分支名称
复制代码

2. Eliminar la sucursal remota

git push --delete origin 旧分支名称
复制代码

3. Sube la sucursal local con el nuevo nombre modificado

git push origin 新分支名称
复制代码

4. La sucursal local modificada se asocia con la sucursal remota

git branch --set-upstream-to origin/新分支名称
复制代码

Resumir

Es genial desarrollar y mantener un crematorio.

La operación no está estandarizada y los familiares lloran.

Al final

Gracias por leer y bienvenidos a todos: me gusta, favorito,moneda(concentrarse en)! ! !

8e95dac1fd0b2b1ff51c08757667c47a.gif

Supongo que te gusta

Origin juejin.im/post/7104258964732575775
Recomendado
Clasificación