国外优秀网站,古镇企业网站建设定制,网络品牌推广,河南建筑信息公共欢迎转载，但请在开头或结尾注明原文出处【blog.chaosjohn.com】 前段时间，公司开了一个新项目，买了另一家公司的源码做二次开发。 项目进行了几天后，我突然听到参与开发的几个同学在讨论，关于 “不想把我们修改的版本推给他们”。 我就顿感奇怪，买了源码还要遵循他们的开… 欢迎转载，但请在开头或结尾注明原文出处【blog.chaosjohn.com】 前段时间，公司开了一个新项目，买了另一家公司的源码做二次开发。 项目进行了几天后，我突然听到参与开发的几个同学在讨论，关于 “不想把我们修改的版本推给他们”。 我就顿感奇怪，买了源码还要遵循他们的开源协议？ 我跑过去问问怎么回事，一听就乐了。原来对方公司将代码部署在私有 git 服务器上，给了我们账号密码以供拉取源码。对方承诺对产品做后续的更新维护，新版本也发布在该 git 仓库上。但是我们对源码做二次开发，会进行很多改动，又不想把我们的改动推给他们。 啊这。。。明显是对 git 不熟悉啊，而且还不是一个同学，应该值得反省。平日里起草招聘需求时都会把 git 作为一个必备的技能项，结果轮到自己身上，却只略知皮毛。 我先代入他们的思维反过来推理：为什么一定要 push，他们的代码只做 pull，拉取新版合并到本地不就行了么。哦，原来不止一个小伙伴在协同开发，相互间要共享改动，比如 A同学 的改动 push 后 B同学 pull 后才能看到。那 push 后不就推送到了对方公司的 git 服务器了么。 所以小伙伴们还停留在一个 git 仓库只有一个远端的层面。 其实一个 git 仓库是可以配置多个远端 remote。 我们举个例子来模拟一下，我们从 github
