How to work simultaneously on several different versions of files with git?

Question

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

Answer 1

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.

Answer 2

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