I'm currently working on a my own neuroimaging toolbox that runs under MATLAB / SPM8 and most program files in my repository are MATLAB *.m
files. I have different feature branches and one analysis
branch, that I use for ongoing analyses using the current version. At the same time I am developing the code in master
and feature branches, that are then constantly merged to master
branch.
Now the problem is that, the analyses I'm running in analysis
branch do take a lot of time (even days), and during that time I'm not able to git checkout master
or git checkout new-feature
. This limits my productivity seriously.
So, as it's not possible to keep several branches open at the same time simultaneously,
I'm thinking to move the analysis
branch out of the development repository to its own repository. The question is, that if I git init
a new repository based on the current analysis
branch, is there a way to somehow git merge
every now and then from current master
branch (of the development repository) to be able to use newly developed code of my development repository in the new analysis repository?
If you
git clone
your existing repository into a new repository, you can thengit push
orgit fetch
from one to the other to match up the refs (branches) you've changed; no merges are involved. The contents of the repository will be automatically hard-linked to save disk space.If you use the
--mirror
option togit clone
andgit push
, you will omit having remote-tracking branches and just have the same branches in both, which is simpler and more symmetrical, but less of a conventional use of git. For maximal "follow the tutorials" simplicity, instead arrange a third "central" repository (which should be created--bare
) which both of your working repositories are clones of.No merges (other than "fast-forward merges" which aren't really merges, but replacing an old branch head with a newer descendant of it) should be required, because you are working on the same branches; you just have two copies of them. When your analysis is complete and you are able to update the analysis branch, just
git merge --ff-only master
while inanalysis
; you can do this in whichever repository is convenient, but don't forget to sync the changes back with agit push other-repository
.Another option (since Git version 2.5) is the
git worktree
command, which allows multiple independent working trees in which you cangit checkout
, etc., independently. The difference between this and the above option of making a clone is that here there is only one set of branches.However (as of version 2.8) this is still considered an “experimental” feature, and I have not personally used it to comment on its reliability and usefulness.
As an alternative to cloning the repo as explained by Kevin Reid, you could also just use
git-new-workdir
to create a second working copy for your repo. That way, both working copies will always automatically see the same branches, because they share one git repo.The advantage over cloning the repo is that there's no need for any manual synchronization/merging. The moment you commit in workdir A, the commit will be visible in workdir B (e.g.
git log
).Only caveat: When you change the repository (commiting, rebasing, resetting a branch etc.), you should not have the same branch checked out in the other workdir - otherwise git will get a bit confused (see git-new-workdir: Commit in working tree A causes bogus changes in tree B ).
See: git working on two branches simultaneously