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
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.
A couple of very good articles on branching strategies: http://codicesoftware.blogspot.com/2010/03/branching-strategies.html http://nvie.com/git-model
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
import com.hewittsoft.baby.trial.R;
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.