共计 1741 个字符，预计需要花费 5 分钟才能阅读完成。
年终奖都没了，还要扣我绩效，门都没有，哈哈。
这波骚 Git 操作我也是第一次用，放心闪了腰，所以不仅做了备份，也做了笔记，分享给大家。
问题形容
小 A 和我在同时开发一个功能模块，他在优化之前的代码逻辑，我在开发新性能。
小 A 在我之前把代码提交到了测试分支，我想提交我的新性能代码到测试分支时发现 巨多抵触，脑袋霎时就炸了，Boom 一声惊雷响啊。
PS：因为小 A 的需要不急，然而改变微小；我的需要很急，马上要提测，否则就延期扣绩效了，说真的，我焦急了，哈哈哈。
剖析一下
- 首先解决抵触浪费时间，我的新性能代码每次提测到测试分支都须要解决抵触。
- 我在测试分支解决抵触，只能依照小 A 优化后的代码逻辑的去解决，和我本人的分支逻辑并不统一。
- 交付给测试同学的测试分支代码，和我本人分支的代码不统一，这种测试是没有意义的。
反思出问题的起因
- 工厂模式应用的不合理
- 任务分配的不合理
代码层面
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 的批改临时不须要提测，上线周期也比拟长。
最终计划：
最终的解决方案是这样的：
- 从近程的测试分支拉取了一个备份分支，删除小 A 提交的近程测试分支
- 把我本地须要测试的分支提交到测试分支，交付测试（因为我的需要很急，而小 A 的需要并不急）
相干命令
这波骚操作我也是第一次用，放心闪了腰，所以不仅做了备份，也做了笔记，分享给大家：
Git 重命名近程分支
1. 先重命名本地分支
git branch -m 旧分支名称 新分支名称2. 删除近程分支
git push --delete origin 旧分支名称3. 上传新批改名称的本地分支
git push origin 新分支名称4. 批改后的本地分支关联近程分支
git branch --set-upstream-to origin/ 新分支名称举荐浏览
【Git 必知必会】多人协同开发，紧急修复线上 bug 的操作指南。
总结
开发起来一时爽，保护起来火葬场。
Git 操作不标准，战友提刀来相见！
响应一下开篇，这是长期解决办法的一个教训分享。必定还有最优解，然而对我来说不重要，再不应用骚操作就该扣绩效了。
年终奖都没了，还要扣我绩效，门都没有，哈哈。
你的年终奖还好吗，欢送在评论区探讨。
一起提高
如果你感觉这篇文章不错，欢送点赞，评论。
我的思否声望什么时候能到 100 呀！？