Best way to sync work on a repo between different remote machines

Question

I have multiple VMs set up that have the same repo and with slight differences. I use these VMs to prototype or run different experiments. Sometimes I sync or merge between them and from different branches.

I want to avoid polluting the repository's commit history as a way to rsync between them. Rsync is too dangerous to run, as each VM can have their own independent changes as well.

I thought of forking the repository or creating a private clone from which I can only work and then when ready just apply my changes to original repo.

1. Would that be a valid use-case of forking?
2. Is there a better more efficient way?

Answer 1

It sounds like you are running your app direct from the code base and skipping the build and deploy stages?

These stages would normally force you to commit changes to a branch and be a bit more rigorous about stuff like not cherry picking bits of code from all over and choosing what branches you deploy.

Generally I wouldn't worry about "polluting the commit history" you can always filter out non-merge-to-master commits if you want to view a summarised history.

Although forking can be used to separate developer access, this is commonly done on public codebases. If you own all the branches there's no reason to fork rather than branch.

Answer 2

From git's point of view, there is nothing special about the copy of the repo on GitHub. All changes do not have to pass through it. You can push directly from one VM to another VM, or from your local copy to a VM. Essentially every clone/copy of a repo is a fork.

There's also no real reason to avoid having lots of branches on your GitHub copy of the repo. That's what it does. Just do what you need to do to keep it organized. If you have a lot of branches, you can put slashes in the names to organize them, like vm1/experiment2.