2 版本软件：最佳 VCS 方法？
我想我最好解释一下我的情况：
我正在开发一些软件，并且我正处于一个阶段，我想将我的项目分成两个功能不同的分支。碰巧这个应用程序是一个我将在市场上部署的 Android 应用程序，它有一个限制，即每个应用程序都必须有一个唯一的包标识符（明智的，不是吗？）。
我当前的方法是克隆原始项目的 git 存储库，但这会导致包名称出现问题。我希望系统足够强大，以便一个分支上的错误修复/新功能能够合并到另一个分支中，但只有在我想要的时候才会合并。
有人有什么建议吗？
I suppose I'd better explain my situation:
I'm in the process of developing some software, and I'm at the stage where I'd like to split my project into two branches which differ in features. It so happens that this application is an Android application which I will be deploying on the Market, which has the constraint that every app must have a unique package identifier (sensible, no?).
My current approach has been to clone the git repo of my original project, but this causes issues with package names. I want the system to be robust enough so that a bugfix/new feature on one branch will merge into another branch, but only when I want it to.
Does anyone have any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我自己为具有相同代码库的付费应用程序和试用版处理了这个确切的案例。我使用的是 SVN，但任何支持分支的版本控制软件都可以工作。
我从主干创建了一个试用版分支。
然后我修改了试用版的AndroidManifest.xml以更改包名称，在末尾添加.Trial。然后我还必须更新所有活动 java 文件以引用正确的 R 类。
我的付费应用程序包是 com.hewittsoft.baby
我的试用应用程序包是 com.hewittsoft.baby.tri
在我的试用活动中，我分支我这样做
，这会导致对 R.id.textField （或其他内容）的任何引用起作用。
完成这些步骤后，我可以在主分支上进行开发，然后将任何更改合并到试用版本中，而不会造成太大的痛苦。
I handle that exact case myself for a paid app and trial version that have the same codebase. I am using SVN, but any version control software that supports branching would work.
I created a branch for the trial version from the trunk.
Then I modified the trial verion's AndroidManifest.xml to change the package name, adding .trial on the end. I then had to also update all the activity java files to reference the correct R class.
My paid app package is com.hewittsoft.baby
My trial app package is com.hewittsoft.baby.trial
In my activities on the trial I branch I do this
and that causes any references to R.id.textField (or whatever) to work.
After I did those steps I can develop on the main branch and then merge over any changes into the trial version without too much pain.
如果唯一的问题是打包和发布管理问题，您可以将这些步骤（重命名包，并在目标环境中测试它）与一个 Git 存储库中的历史记录周期隔离。
因此，您可以继续分离您的开发，每个分支一个功能，为两个分支保留相同的包名称（以便轻松地将修复从一个分支合并到另一个分支）。
但是，为了测试和部署这两个版本之一，您可以使用一个脚本来负责重命名包、重新编译、打包（jar）并将结果部署到目标测试环境中。
If the only issue is a packaging and release management issue, you could isolate those steps (rename the package, and test it in a target environment) from the historization cycle within one Git repo.
So you could go on, separate your development, one feature per branch, keeping the same package names for both (in order to easily merge fixes from one to another).
But then, to test and deploy one of those two versions, you could have a script in charge of renaming the packages, recompiling, packaging (jar) and deploying the result in the target test environment.
关于分支策略的几篇非常好的文章：
http://codicesoftware.blogspot.com/2010/03/branching-strategies。 html
http://nvie.com/git-model
A couple of very good articles on branching strategies:
http://codicesoftware.blogspot.com/2010/03/branching-strategies.html
http://nvie.com/git-model