分叉我的应用程序的新版本
我正在寻找一些关于如何对我的应用程序进行分支以便拥有其功能受限版本的想法。
让我做一个假设。假设我的桌面应用程序与所有网络浏览器交互。我与 Google Chrome 的人员建立了合作伙伴关系，他们想要发布一个仅适用于他们的浏览器的应用程序版本，并且不包括 IE、Firefox 等。
我将如何去做呢？我可以在 git 中创建一个单独的分支，然后运行构建脚本两次，同时在之间切换分支。我也可以复制完整的代码目录，并从每个目录构建。
我预见到的一个问题是，我希望完整程序中的错误修复也能在有限版本中自动更新。可能还有其他我还没有意识到的问题。所以我正在寻找指导。
谢谢
I am looking for some ideas as to how to branch my application so as to have a feature limited version of it.
Let me give a hypothetical. Lets say my desktop app interacts with all web browsers. I get into a partnership with the guys at Google Chrome who want to release a version of my app that works ONLY with their browser, and will exclude IE, Firefox, etc.
How would I go about doing this? I could create a separate branch in git, and then run my build script twice, while switching branches in between. I could also just copy the full code directory, and build from each dir.
A problem I forsee, is that I want bugfixes in my full program to automatically be updated in limited version as well. There are probably other problems that I don't realize yet as well. So I'm looking for guidance.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您修复了完整程序中的某些内容，那么您显然会运行构建脚本来检查回归错误，对吧？因此，也许有针对性的构建脚本是一个选择。我会这么说，或者考虑调整标志的使用（Asana 的人是 大粉丝）。
If you fix something in your full program then you'll obviously run your build script to check for regression bugs right? So maybe a targeted build script could be an option. I'd say that or look into adapting the use of flags (the guys at Asana are big fans).
根据应用程序的类型，您希望尽可能使其具有多平台性。如果您创建两个单独的源，那么您实际上有两个单独的程序 - 更好的做法是拥有两个单独的存储库（其中一个存储库可能是另一个存储库的分支）。
分支有其切线子项目的位置，例如“feature-kitchensink”或区分开发版本（“develop-1.1”）和主版本（“master”）。这个想法是，您希望每个分支中的源足够相似，以便稍后合并。
git 中的分支和存储库很便宜，不要害怕使用你需要的东西。
Depending on the kind of app, you want to leave it as multi-platform as possible. If you create two separate sources, you really have two separate programs - it is better practice to have two separate repositories (where one might be forked off the other).
Branches have their place for tangent sub-projects, such as "feature-kitchensink" or to distingush between a develop version ("develop-1.1") and master ("master"). The idea is that you want the sources in each branch to be similar enough to be merged later.
Branches and repos are cheap in git, don't be afraid to use what you need.
您可以在分支之间挑选提交，假设它们不与当前工作树冲突。如果您对一个分支进行尽可能精确的修复提交，那么您应该能够将它们挑选到另一个分支上——您可能需要根据当前代码自定义修复，但无论如何都会发生这种情况。
You can cherry-pick commits in between branches, assuming that they don't conflict with the current working tree. If you make the fix commits as exact as possible for one branch, you should be able to cherry pick them onto the other just fine -- you might need to customize the fix though according to the current code, but that would happen regardless.
通常，如果功能分支与父分支的不同主要在于删除了某些代码部分，则从父分支拉取将按预期更新所有公共代码。如果删除的部分发生更改，您很可能会遇到冲突，但解决起来相当容易。
另一方面，在这种情况下，我想说添加一个在构建期间禁用某些功能的配置将是一个更简单的解决方案。 （如何执行此操作将取决于您使用的语言和构建工具。）您仍然可以在单独的分支上拥有此有限版本，并且添加
代码而不是删除不需要的代码，很可能会使合并更容易。
Usually if a feature branch differs from the parent branch mainly by removing some sections of code, pulling from the parent branch will update all the common code as expected. If the deleted sections is changed you will most likely get a conflict but it's fairly easy to resolve.
On the other hand, in this scenario, I'd say adding a configuration that disables some features during build would be a simpler solution. (How you do this will depend on the language and build tool you use.) You could still have this limited version on a separate branch, and adding
in the code, instead of deleting the code you don't need, will most likely make the merges easier.