問題描述

小A和我并行開發(fā)，他在優(yōu)化之前的代碼邏輯，我在開發(fā)新功能。

小A在我之前把代碼提交到了測試分支，我想提交我的新功能代碼到測試分支時發(fā)現(xiàn)巨多沖突。

首先解決沖突浪費(fèi)時間，我的新功能代碼每次提測都需要解決沖突。

再者我再測試分支解決沖突，只能按照小A優(yōu)化后的代碼邏輯的去解決，和我自己的分支邏輯并不一致。

交付給測試同學(xué)測的代碼，和我自己分支的代碼不一致，這種測試是沒有意義的。

反思出問題的原因

• 工廠模式使用的不合理
• 任務(wù)分配的不合理

代碼層面

因?yàn)槭枪S設(shè)計模式，我負(fù)責(zé)的實(shí)現(xiàn)類A和他的實(shí)現(xiàn)類B雖然沒有直接關(guān)系。但是因?yàn)樗薷牧斯S類中的方法定義。

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

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)  
}

這樣就導(dǎo)致了一個問題：

我想合并我的代碼到測試分支也必須將我的實(shí)現(xiàn)類A修改傳參類型和返回類型。

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

我又不能直接把他定義的ccc.cc,ddd.dd要過來，在我自己的分支上開發(fā)，一是因?yàn)樾枨蟛灰恢?，小A的上線周期會比我長，二是這種操作本身就不規(guī)范。

解決問題

從代碼設(shè)計上優(yōu)化

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

把工廠類中要實(shí)現(xiàn)的接口方法的入?yún)⒑统鰠⒃O(shè)置為interface{}類型

package factory

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

這樣就比較容易進(jìn)行擴(kuò)展了。

從git操作上優(yōu)化

但是入?yún)⒑统鰠⒃O(shè)置為interface{}類型的辦法并沒有從根本上解決我們的問題。

原因是這樣的：

小A的需求是整體優(yōu)化工廠類和各個實(shí)現(xiàn)類的入?yún)ⅰ⒊鰠?，?yōu)化內(nèi)部邏輯，抽取方法。小A的修改導(dǎo)致和我的實(shí)現(xiàn)邏輯有比較大的沖突。

但是他的git提交又在我之前提交到了測試環(huán)境，導(dǎo)致我無法提交我的代碼，如果要提交就要解決各種沖突。解決沖突就要按照小A的優(yōu)化邏輯去改，給到測試同學(xué)測的有和我自己分支的不一致。難頂啊。考慮到小A的修改暫時不需要提測，上線周期也比較長。

最終的辦法是這樣的

從遠(yuǎn)程的測試分支拉取了一個備份分支，刪除遠(yuǎn)程的測試分支

把我本地需要測試的分支提交到測試分支，交付測試。

git 重命名遠(yuǎn)程分支

1.先重命名本地分支

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

2.刪除遠(yuǎn)程分支

git push --delete origin 舊分支名稱

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

git push origin 新分支名稱

4.修改后的本地分支關(guān)聯(lián)遠(yuǎn)程分支

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

到此這篇關(guān)于go語言實(shí)現(xiàn)Git 重命名遠(yuǎn)程分支  的文章就介紹到這了,更多相關(guān)go Git 重命名 內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論