Multiple projects in a single git repository.
August 6, 2008 9:23 PM Subscribe
How do I work on multiple projects in a single version control (hopefully git) repository. Alternatively, how do I transparently establish many repositories for different projects?
After an embarrassingly long time of poor version control, I decided that it's time to be careful about all my code and documents, and tried to establish a central repository. I have 2 machines: a server which acts as an occasional development machine and does backup, and my laptop. I'm hoping version control will help me keep my work synced between the two machines as well.
The key problem is that git commands operate on the whole repository, not just a particular directory. So if I make some changes in the work directory, and then modify elements of the play directory, running 'git status' inside the play directory informs me of the work changes. Branching in the play directory also puts the work directory on the same branch. With many subprojects, that's really annoying; I would much prefer git operations to apply only to the current and children directories, not parent ones.
Alternatively, I can imagine creating two repositories: a work and play one. However, then whenever I make a new project, I have to init a repository on one machine, pull it on the other; whenever I want to sync the 2 machines; I would need to git pull every single project. It feels like there has to be a better way.
I suspect that some branch trickery may work -- if every project is a separate branch in the same repository, that may be OK -- however, that won't solve the easy sync problem, and feels like a total abuse of branches. Any suggestions?
After an embarrassingly long time of poor version control, I decided that it's time to be careful about all my code and documents, and tried to establish a central repository. I have 2 machines: a server which acts as an occasional development machine and does backup, and my laptop. I'm hoping version control will help me keep my work synced between the two machines as well.
The key problem is that git commands operate on the whole repository, not just a particular directory. So if I make some changes in the work directory, and then modify elements of the play directory, running 'git status' inside the play directory informs me of the work changes. Branching in the play directory also puts the work directory on the same branch. With many subprojects, that's really annoying; I would much prefer git operations to apply only to the current and children directories, not parent ones.
Alternatively, I can imagine creating two repositories: a work and play one. However, then whenever I make a new project, I have to init a repository on one machine, pull it on the other; whenever I want to sync the 2 machines; I would need to git pull every single project. It feels like there has to be a better way.
I suspect that some branch trickery may work -- if every project is a separate branch in the same repository, that may be OK -- however, that won't solve the easy sync problem, and feels like a total abuse of branches. Any suggestions?
Here's a couple of thoughts.
1. As you've noted, git works best with one project per repository. So if you have cleanly-defined projects, it'd be best to have a separate repository for each one.
However, to save you time manually setting up repositories on each machine, remember that if you're just one person switching between two machines, you don't necessarily have to use git's built-in pushing and fetching to synchronise repositories. You could just use something like rsync to keep the files on both your machines in sync.
So maybe you'd set up a directory with a bunch of projects in it:
This actually has an advantage over the built-in git push/fetch, in that any uncommitted changes to your working directory/index/stash will also be transferred. So you can literally sit down again at the other computer and pick up where you left off, even if you're in the middle of changes. I use this approach myself, and I've not had any problems so far.
2. Keeping unrelated files in different branches within a single repository is not really an abuse of the system. The git project itself has a 'master' branch which contains the actual code, and then 'man' and 'html' branches which contain the documentation -- a completely different set of files. So I wouldn't worry about doing this, if this feels useful to you. But as you say, you'll probably want to have several copies of that repository on each machine, each with a different branch checked out, so this approach doesn't necessarily solve the mass-sync problem.
posted by chrismear at 2:53 AM on August 7, 2008
1. As you've noted, git works best with one project per repository. So if you have cleanly-defined projects, it'd be best to have a separate repository for each one.
However, to save you time manually setting up repositories on each machine, remember that if you're just one person switching between two machines, you don't necessarily have to use git's built-in pushing and fetching to synchronise repositories. You could just use something like rsync to keep the files on both your machines in sync.
So maybe you'd set up a directory with a bunch of projects in it:
Then, when you're about to switch computers, you can execute one rsync command to sync the entire directory tree to your other machine.allmystuff|-- project1| `-- .git|-- project2| `-- .git`-- project3 `-- .git
This actually has an advantage over the built-in git push/fetch, in that any uncommitted changes to your working directory/index/stash will also be transferred. So you can literally sit down again at the other computer and pick up where you left off, even if you're in the middle of changes. I use this approach myself, and I've not had any problems so far.
2. Keeping unrelated files in different branches within a single repository is not really an abuse of the system. The git project itself has a 'master' branch which contains the actual code, and then 'man' and 'html' branches which contain the documentation -- a completely different set of files. So I wouldn't worry about doing this, if this feels useful to you. But as you say, you'll probably want to have several copies of that repository on each machine, each with a different branch checked out, so this approach doesn't necessarily solve the mass-sync problem.
posted by chrismear at 2:53 AM on August 7, 2008
If the projects are unrelated I'd go with the seperate repositories for seperate projects scheme.
If I'm reading chrismear's rsync suggestion correctly it has the down side that you skip past git's merge machinery. Merging is one of fundamental reasons for using a DVCS. Without git controlling merging you would have to pay attention to which changes were on which computers. With one person working on alternating computers you might be able to manage it. If the number of computers or number of people increases, the likelihood that a mistake will be made keeps going up.
posted by rdr at 5:11 AM on August 7, 2008
If I'm reading chrismear's rsync suggestion correctly it has the down side that you skip past git's merge machinery. Merging is one of fundamental reasons for using a DVCS. Without git controlling merging you would have to pay attention to which changes were on which computers. With one person working on alternating computers you might be able to manage it. If the number of computers or number of people increases, the likelihood that a mistake will be made keeps going up.
posted by rdr at 5:11 AM on August 7, 2008
Why not simply write a script for these operations you want, "push in each project" and "pull in each project"?
posted by jepler at 5:57 AM on August 7, 2008
posted by jepler at 5:57 AM on August 7, 2008
With one person working on alternating computers you might be able to manage it.
Well, yes, that's the only situation I'd suggest this for. The problem we're trying to solve here is, IMHO, nothing to do with version control -- the focus is more on having the same working environment on both your computers, and a dumb syncing of the files is a quick way to achieve this.
posted by chrismear at 6:19 AM on August 7, 2008
Well, yes, that's the only situation I'd suggest this for. The problem we're trying to solve here is, IMHO, nothing to do with version control -- the focus is more on having the same working environment on both your computers, and a dumb syncing of the files is a quick way to achieve this.
posted by chrismear at 6:19 AM on August 7, 2008
This thread is closed to new comments.
posted by hattifattener at 9:55 PM on August 6, 2008