您好,登錄后才能下訂單哦!
本文小編為大家詳細介紹“如何利用go語言實現Git重命名遠程分支 ”,內容詳細,步驟清晰,細節處理妥當,希望這篇“如何利用go語言實現Git重命名遠程分支 ”文章能幫助大家解決疑惑,下面跟著小編的思路慢慢深入,一起來學習新知識吧。
小A和我并行開發,他在優化之前的代碼邏輯,我在開發新功能。
小A在我之前把代碼提交到了測試分支,我想提交我的新功能代碼到測試分支時發現巨多沖突。
首先解決沖突浪費時間,我的新功能代碼每次提測都需要解決沖突。
再者我再測試分支解決沖突,只能按照小A優化后的代碼邏輯的去解決,和我自己的分支邏輯并不一致。
交付給測試同學測的代碼,和我自己分支的代碼不一致,這種測試是沒有意義的。
工廠模式使用的不合理
任務分配的不合理
因為是工廠設計模式,我負責的實現類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的上線周期會比我長,二是這種操作本身就不規范。
我們想到的方案是合理使用interface
把工廠類中要實現的接口方法的入參和出參設置為interface{}
類型
package factory type xxx interface { GetXxxx(ctx context.Context, req interface{}) (res interface{}, err error) }
這樣就比較容易進行擴展了。
但是入參和出參設置為interface{}
類型的辦法并沒有從根本上解決我們的問題。
原因是這樣的:
小A的需求是整體優化工廠類和各個實現類的入參、出參,優化內部邏輯,抽取方法。小A的修改導致和我的實現邏輯有比較大的沖突。
但是他的git提交又在我之前提交到了測試環境,導致我無法提交我的代碼,如果要提交就要解決各種沖突。解決沖突就要按照小A的優化邏輯去改,給到測試同學測的有和我自己分支的不一致。難頂啊。考慮到小A的修改暫時不需要提測,上線周期也比較長。
從遠程的測試分支拉取了一個備份分支,刪除遠程的測試分支
把我本地需要測試的分支提交到測試分支,交付測試。
1.先重命名本地分支
git branch -m 舊分支名稱 新分支名稱
2.刪除遠程分支
git push --delete origin 舊分支名稱
3.上傳新修改名稱的本地分支
git push origin 新分支名稱
4.修改后的本地分支關聯遠程分支
git branch --set-upstream-to origin/新分支名稱
讀到這里,這篇“如何利用go語言實現Git重命名遠程分支 ”文章已經介紹完畢,想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會,如果想了解更多相關內容的文章,歡迎關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。