年终奖没了，还要扣我的业绩。没办法，哈哈。这波骚Git操作，我也是第一次使用。我担心自己会瘦腰，所以我不仅做了备份，还做了笔记分享给大家。问题描述我和小A同时在开发一个功能模块。他在优化之前的代码逻辑，我在开发新的功能。小A先于我把代码提交到测试分支。当我想将我的新功能代码提交到测试分支时，我发现了很多冲突。我的脑袋瞬间炸开，轰的一声炸响。PS：因为小A的需求不急，但是变化很大；我的需求很紧急，必须马上提交测试，否则绩效扣分会顺延。说实话，我很着急，哈哈哈。分析浪费时间先解决冲突。我的新功能代码每次测试到test分支都需要解决冲突。我是在test分支解决冲突，只能按照小A优化的代码逻辑来解决，和我自己的分支逻辑不一致。交付给测试同学的测试分支代码和我自己分支的代码不一致。这种测试是没有意义的。反思问题的原因。工厂模式使用的任务分配不合理。不合理的代码级别TIPS：以下代码示例语言是Go，因为它是工厂设计模式。虽然我负责的实现类A和他的实现类B没有直接关系。但是因为他修改了工厂类中的方法定义。比如之前工厂类中的接口定义为packagefactorytypexxxinterface{GetXxxx(ctxcontext.Context,reqaaa.aa)(resbbb.bb,errerror)}但是小A优化（修改）了工厂类接口定义：packagefactorytypexxxinterface{GetXxxx(ctxcontext.Context,reqccc.cc)(resddd.dd,errerror)}这导致了一个问题：我想将我的代码合并到测试分支中，我必须A的实现类就像小A一样，修改参数类型和返回类型。但是我们都是在不同的分支开发，我没有他定义的类型ccc.cc和ddd.dd。我不能直接导入他定义的ccc.cc和ddd.dd，在自己的分支上开发。第一，因为需求不一致，小A的上线周期会比我的长；其次，这种操作本身并不容易。规格。解决问题1.代码层面：我们想到的解决方案是合理使用接口工厂类中方法的输入输出参数，将其设置为interface{}typepackagefactorytypexxxinterface{GetXxxx(ctxcontext.Context,reqinterface{})(resinterface{},errerror)}这样更容易扩展。2.git层面：方法一的输入输出参数设置为interface{}类型，并没有从根本上解决我们的问题。原因是这样的：小A的要求是对工厂类和各个实现类的输入输出参数进行整体优化，优化内部逻辑，提取方法。小A迭代优化修改变化很大，和我实现的新需求产生了比较大的冲突。但是他的Git分支先于我提交到测试环境，导致我无法正常提交代码。如果我要提交，我要解决各种冲突，而要解决冲突，我需要按照小A的优化逻辑进行更改。测试分支和我自己分支的不一致是困难的。考虑到小A的修改暂时不需要测试，上线周期比较长。最终解决方案：最终解决方案是这样的：从远程测试分支拉一个备份分支，删除A提交的远程测试分支，将我本地需要测试的分支提交到测试分支，交付测试（因为我的需要很急，小A的需求不急）这波秀操作我是第一次使用相关命令，怕闪腰，所以不仅做了一个备份，也做了笔记分享给大家：gitrenameremotebranch1.先重命名本地分支gitbranch-moldbranchnamenewbranchname2.删除远程分支gitpush--deleteoriginoldbranchname3.上传新修改名称的本地分支gitpushorigin新分支名称4.修改后与远程分支关联的本地分支gitbranch--set-upstream-toorigin/new分支名称推荐阅读【Git必知与知乎]多人协同开发，紧急修复在线bug操作指南。总结开发一段时间爽，维护火葬场。Git操作不规范，战友们持刀来相见！呼应开篇，这是一个临时解决方案的经验分享。一定有最优解，但对我来说无所谓。如果不使用show操作，应该扣除性能。年终奖没了，还要扣我的业绩。没办法，哈哈。你的年终奖怎么样？欢迎在评论区讨论。共同进步如果你觉得这篇文章不错，请点赞评论。我的思维声望什么时候能到100！？
