How to work simultaneously on several different versions of files with git?
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
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?
2 Solutions collect form web for “How to work simultaneously on several different versions of files with git?”
git clone your existing repository into a new repository, you can then
git push or
git 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 to
git clone and
git 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 in
analysis; you can do this in whichever repository is convenient, but don’t forget to sync the changes back with a
git push other-repository.
Another option (since Git version 2.5) is the
git worktree command, which allows multiple independent working trees in which you can
git 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.
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