这是一个创建于 2768 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题
例如一个文档或者接口管理工具，一开始找到这个项目的时候，可能可以满足需求，但是有一些细节需要修改，这个时候就要分情况了。
- 这个需求对他人也有用，那我可以提一个 pull request 贡献代码。
- 这个需求可能对他人无用，只是跟手头的项目紧耦合，但需要修改一下项目的源码。注意：当这个需求完成后，我已经修改了源码。
然后，这样的情况可能会有不少，假设现在修改了一二十个文件，1000 来行代码。
<>现在，这个开源项目发布了一个大版本。之前一直没有从 Git 更新过这个开源项目，只有本地的修改。现在我要更新这个大版本吗？
又要分情况了：
- 这个大版本没有什么新颖的功能，现在的版本能满足需求，那就不更新了。
- 这个大版本有几个大的新功能，想要用在手头的项目中。那我要怎么更新呢？直接拉下来代码的话，肯定会有冲突，而且可能不太好解决。
我能想到的办法是，自己建一个本地分支，给手头公司的项目用，master 始终保持和这个开源项目的 master 分支同步。然后合并的时候一点一点做。。。
不知道各位大佬平时是怎么做的？
 | 1 Arnie97 2018-05-23 00:54:45 +08:00 via Android 合并上游修改确实比较头疼，随着上游的更新不断 git pull --rebase 可能会比一口气合并大版本简单点… |
 | 2 param 2018-05-23 02:36:53 +08:00 via Android 如果是自用的话，就应该 fork 一份出来修改了吧。修改的过程中注意一下兼容，用扩展的方式来修改，只加功能不减功能。修改的时候保持最少的修改量。合并上游难不难，取决与你修改的代码数量。一二十个文件，1000 来行代码，如果都是在上游代码中直接修改而不是新增的话，合并起来就很头疼了。 |
Select Language