問題描述

小A和我在同時開發一個功能模塊，他在優化之前的代碼邏輯，我在開發新功能。

小A在我之前把代碼提交到了測試分支，我想提交我的新功能代碼到測試分支時發現巨多沖突，腦袋瞬間就炸了，Boom一聲驚雷響啊。

PS：因為小A的需求不急，但是改動巨大；我的需求很急，馬上要提測，否則就延期扣績效了，說真的，我著急了，哈哈哈。

分析一下

1. 首先解決沖突浪費時間，我的新功能代碼每次提測到測試分支都需要解決沖突。
2. 我在測試分支解決沖突，只能按照小A優化后的代碼邏輯的去解決，和我自己的分支邏輯并不一致。
3. 交付給測試同學的測試分支代碼，和我自己分支的代碼不一致，這種測試是沒有意義的。

反思出問題的原因

1. 工廠模式使用的不合理
2. 任務分配的不合理

代碼層面

TIPS:以下代碼示例語言為Go

因為是工廠設計模式，我負責的實現類A和他的實現類B雖然沒有直接關系。但是因為他修改了工廠類中的方法定義。

比如之前工廠類中的接口是這么定義的

package factory

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

但是小A優化(修改)了工廠類中的接口定義：

package factory

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

這樣就導致了一個問題：

我想合并我的代碼到測試分支也必須將我的實現類像小A一樣，修改傳參類型和返回類型。

但是我們都在不同的分支上開發，我是沒有他定義的類型ccc.cc,ddd.dd的。

我又不能直接把他定義的ccc.cc,ddd.dd要過來，在我自己的分支上開發，一是因為需求不一致，小A的上線周期會比我長；二是這種操作本身就不規范。

解決問題

1.代碼層面：

我們想到的方案是合理使用interface

工廠類中方法的入參和出參設置為interface{}類型

package factory

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

這樣就比較容易進行擴展了。

2.Git層面：

方法1的入參和出參設置為interface{}類型的方案，并沒有從根本上解決我們的問題。

原因是這樣的：

小A的需求是整體優化工廠類和各個實現類的入參、出參，優化內部邏輯，抽取方法。

小A的迭代優化修改變動很大，導致和我實現的新需求有比較大的沖突。

但是他的Git分支又在我之前提交到了測試環境，導致我無法正常提交我的代碼。

如果我要提交就要解決各種沖突，解決沖突就要按照小A的優化邏輯去改，提測分支和我自己分支的不一致，難頂啊。

考慮到小A的修改暫時不需要提測，上線周期也比較長。

最終方案：

最終的解決方案是這樣的：

1. 從遠程的測試分支拉取了一個備份分支，刪除小A提交的遠程測試分支
2. 把我本地需要測試的分支提交到測試分支，交付測試（因為我的需求很急，而小A的需求并不急）

相關命令

這波騷操作我也是第一次用，擔心閃了腰，所以不僅做了備份，也做了筆記，分享給大家：

Git 重命名遠程分支

1.先重命名本地分支

git branch -m 舊分支名稱  新分支名稱

2.刪除遠程分支

git push --delete origin 舊分支名稱

3.上傳新修改名稱的本地分支

git push origin 新分支名稱

4.修改后的本地分支關聯遠程分支

git branch --set-upstream-to origin/新分支名稱

本文轉載自微信公眾號「 程序員升級打怪之旅」，作者「王中陽Go」，可以通過以下二維碼關注。

轉載本文請聯系「 程序員升級打怪之旅」公眾號。