6

I'm developing an Android application and have been using Git throughout the entire development cycle. I've now come to a point where I would like to build and release experimental features for people to try out and install, while still having the original, stable, application installed on their devices.

Now, this means I need to use a different package-name, which changes a few fundamental files in the development-project. I'd also like to have a separate icon to clearly differentiate the applications.

I'm not used to Git enough to know which way to take here: Should I create an experimental branch which I branch off of when I want to make some lab-work or do I keep this experimental work as a separate git-repo?

I have a couple of problems with the actual flow of going either way.

  • If I make an experimental branch, I don't want to (mistakenly?) merge the changes of the package names and the clearly separating experimental details with the master branch; I only want to merge the working parts of the code, without the extra added modification.
  • If I make a separate repo, how do I merge the changes from experimental repo to master repo, considering the same wish to not replace ie. package names and icons?
shellström
  • 1,417
  • 13
  • 29

2 Answers2

8

That's exactly what branches are for. The one limitation is that git really sees commits, not files. So you typically would merge back one or a few commits from a different branch into master using the cherry-pick command. 

git branch branchx
git checkout branchx
... do work, commit (into branchx), repeat...
git checkout master   # return to master
git log branchx  # to find out the ID of the commit to merge back
git cherry-pick <commit ID from branchx>

That's the preferred approach. This implies that you should keep this in mind while working in your experimental branch. Your commits should be small enough to include only the files that are involved in a fix/feature.

Alternative, you can pick some files to merge back using

# from branch master do
git checkout branchx file1 file2 file3

See this related answer How do you merge selective files with git-merge?

Community
  • 1
  • 1
Bernard
  • 16,149
  • 12
  • 63
  • 66
  • Just for clarification and a sort of best-practice-approach question: Create the experimental-branch from master and the first thing I do is to create a commit that includes the experimental-specific modifications (package- and icon-change) and then move on with committing code changes as I flesh the experimental features out. Would this make for a practical cherry-picking back to the master at a later point? – shellström Mar 01 '12 at 09:18
  • 1
    Yes. Think of commits as instructions to perform on files, not files per se. You can apply these instructions at any point in your master. – Bernard Mar 01 '12 at 11:44
  • Neat and clearly stated answer. You get my accepted answer on this one. – shellström Mar 01 '12 at 11:53
2

I would certainly go for a branch. You would have to excercise some discipline in commits, make them small enough that you can cherry-pick only the parts you need and leave the others. But I don’t think that’s a problem, certainly not in comparison to merging changes between two separate repositories.

zoul
  • 102,279
  • 44
  • 260
  • 354