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 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. 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 ).
来源：https://stackoverflow.com/questions/10665752/how-to-work-simultaneously-on-several-different-versions-of-files-with-git