社区精选｜Git 操作不规范，战友提刀来相见！

今天小编为大家带来的是社区作者 王中阳 GO 的文章，让我们一起来学习这波 Git 操作。

---

这波 Git 操作我也是第一次用，担心闪了腰，所以不仅做了备份，也做了笔记，分享给大家。

问题描述

---

小 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/新分支名称

推荐阅读

【 Git 必知必会】多人协同开发，紧急修复线上 bug 的操作指南。

https://mp.weixin.qq.com/s?__biz=MzIyNjM0MzQyNg==&mid=2247484571&idx=1&sn=171f65de5635a8c5a10b375225e39fbb&chksm=e870abf6df0722e088d39b683389f244da0718c37c54ab1f48e6429e90ad9caa33bd13952199&token=181779644&lang=zh_CN#rd

总结

开发起来一时爽，维护起来火葬场。

Git 操作不规范，战友提刀来相见！

呼应一下开篇，这是临时解决办法的一个经验分享。肯定还有最优解，但是对我来说不重要，再不使用骚操作就该扣绩效了。

---

点击左下角阅读原文，到 SegmentFault 思否社区 和文章作者展开更多互动和交流，“公众号后台“回复“ 入群 ”即可加入我们的技术交流群，收获更多的技术文章~

- END -

关注公众号：拾黑（shiheibook）了解更多

赞助链接：

关注数据与安全，洞悉企业级服务市场：https://www.ijiandao.com/
四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/