私有化部署并对 nei 进行个性化修改，那如何与 nei 之后发布的 feature 进行合并

[lilywang711]

你提的 Feature 是否和某个问题有关？ 是这样的场景，目前 NEI 里提供的一些功能例如工程规范、客户端在我们公司中是不会用上的，于是想通过源码来进行个性化修改，但这样就会产生一个问题，之后 NEI 官方发布的 features，我本地想要使用，那应该要怎么合并呢？

请描述你想要的解决方案 除了手动去 merge 时剔除掉不需要的功能，是否有更简单的方式去处理 feature 之间的合并呢？

请描述你能接受的其他方案 如果有的话，可以精简的描述一下。

其他信息 其他信息可以填这里。

[huntbao]

这确实是一个问题。以后的功能更新，我们也会提供一个对应的分支并尽可能地减少 Commit 次数。

大家有什么建议也可以提下。

[windylaugit]

我司以前对待类似的三方开源项目二改后，后续同步更新的问题， 都是做手动的合并，有几点建议如下： 1、私有化部署后，如果有需要二改，最好不要动核心的驱动 2、若要二改，可尝试将nei独立成一个三方包，然后在外部业务层，进行override。 3、对于某些较内核的功能，需要二改，但是又无法通过override的方式进行修改的，可以来原项目提feature，期待原项目提供相应的可扩展的接口。 4、对于后续原项目的更新？如果做了前面几步，那么就很好处理了，更新某个包而已。

[windylaugit]

我司以前对待类似的三方开源项目二改后，后续同步更新的问题， 都是做手动的合并，有几点建议如下： 1、私有化部署后，如果有需要二改，最好不要动核心的驱动 2、若要二改，可尝试将nei独立成一个三方包，然后在外部业务层，进行override。 3、对于某些较内核的功能，需要二改，但是又无法通过override的方式进行修改的，可以来原项目提feature，期待原项目提供相应的可扩展的接口。 4、对于后续原项目的更新？如果做了前面几步，那么就很好处理了，更新某个包而已。

当然，如果官方能增加更多的个性化扩展点就是最好的了，这也依赖于大家的积极反馈。