Do you version control the invidual apps or the whole project or both?

Question

OK, so I have a Django project. I was wondering if I'm supposed to put each app in its own git repository, or is it better to just put the whole project into a git repository, or whether I should have a git repo for each app and also a git repo for the project?

Thanks.

Answer 1

If you have reusable apps, put them in a seperate repo.

If you are worried about the number of private repositories have a look at bitbucket (if you decide to make them open source, I advice github)

There is a nice way of including your own apps in to the project, even making use of version tags:

I recently found out a way to do this with buildout and git tags (I used svn:externals to include an app, but switched from svn to git recently).

I tried mr.developer first, but while not getting this to work i found an alternative for mr.developer:

I found out gp.vcsdevlop is very easy to use for this purpose.

see https://pypi.python.org/pypi/gp.vcsdevelop

I ended up, putting this in my buildout file and got it working at once (I had to add a pip requirements.txt to my app to get it working, but that's a good thing after all):

vcs-update = True
extensions =
    gp.vcsdevelop
    buildout-versions
develop-dir=./local_checkouts

vcs-extend-develop=git+git@bitbucket.org:<my bitbucket username>/<the  app I want to include>.git@0.1.38#egg=<the appname in django>

develop = .

in this case it chacks out my app and clone it to version tag 0.1.38 in to the project in the subdit ./local_checkouts/ and develops it when running bin/buildout

Edit: remark 26 august 2013

While using this solution and editing in this local checkout of the app used in a project. I found out this:

you will get this warning when trying the normal 'git push origin master' command:

To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.

EDIT 28 august 2013

About working in the local_checkouts for shared apps included by gp.vcsdevelop:

(and handle the warning discussed in the remakr above)

git push origin +master seems to screw up commit history for the shared code

So the way to work in the local_checkout dir is like this:

go in to the local checkout (after a bin/buildout so the checkout is the master):

cd localcheckouts/<shared appname>

Create a new branch and swith to it like this:

use git checkout -b 'issue_nr1' (e.g. the name of the branch is here named after the issue you are working on)

and after you are done working in this branche, use: (after the usuals git add and git commit)

git push origin issue_nr1

when tested and completed merge the branch back in the master:

first checkout the master:

git checkout master

update (probably only neede when other commits in the mean time)

git pull

and merge to the master (where you are in right now):

git merge issue_nr1

and finaly push this merge:

git push origin master

(with sepcial thanks to this simplified guide to git: http://rogerdudler.github.io/git-guide/) and after a while, to clean up the branches, you might want to delete this branch

git branch -d issue_nr1

Answer 2

I like Tom's or Alex's answers, except they lack real rationale behind them
("easier to have one repository per development team" ?
"substantial numbers of people might be interested in pulling out (or watching changes to) separate apps"
why ?)

First of all, one or several repositories is an server-side administration decision (in term of server resources).
SVN easily sets up several repositories behind one server, whereas ClearCase will have its own "vob_server" process per VOB, meaning: you do not want more than a hundred VOB per (Unix) server (or more than 20-30 on a Windows server).
Git is particular: setting a repository is cheap, accessing it can be easy (through a simple shared path), or can involved a process (a git daemon). The latest solution means: "not to much repositories accessed directly from outside". (they can be accessed indirectly through submodules referenced by a super-project)

Then there is the client-side administration: how complex will the configuration of a workspace be, when one or several repositories are involved. How can the client references the right configuration? (list of labels needed to reference the correct files).
SVN would use externals, git "submodules", and in both case, that adds complexity.
That is why Tom's answer can be correct.

Finally, there is the configuration management aspect (referenced in Alex's answer). Can you tag part of a repo of not ?
If you can (like in SVN where you actually make a svn-copy of part of a repo), that means you can have a component approach, where several groups of files have their own life cycle, and their own tags (set at their own individual pace).
But in Git, that is not possible: a tag references a commit which always concerns the all repository.
That means a "system-based" approach, where you only want the all project anyway (as opposed to the "watching separate apps - I've never observed it in real life" bit from Alex's answer). If that is the case (if you want the all system anyway), that is not important.

But for those of us who think in term of "independent groups of files", that means a git repository actually represents an individual group of files (with its own rhythm in term of evolutions and tagging), with potentially a super-project referencing those repositories as submodules.
That is not your everyday setup, so for independent projects, I would recommend only few or one Git repo.
But for more complex interdependent set of projects... you need to realize that by the very way Git has been conceived, a "repository" represents a coherent set of files supposed to evolve at the same pace as a all. And not "all" can always fit in one set of files (if "all" is complex enough). Hence, several repositories would be required in this case.
And a complex set of inter-dependent projects does happen in real life too ;)

Answer 3

Do those individual apps utilize shared code and libraries? If so, they really belong in the same repository .. which enables you to see the impact of new changes when running a single testing suite.

If they are completely separate and agnostic, it really doesn't matter. Just for sanity, ease of building and ease of packaging, I prefer to keep a whole project in a combined repository. However, we typically work in very small teams. So, if no shared code is involved, its really just a question of which method is most convenient and efficient for all concerned.

Answer 4

It really depends on whether those reusable apps are actually going to be reused outside of the project or not?

The only reason you might need it in a different repo is if other projects with seperate repos might need to use it. But you can always split it out later. Making a git repo is cheap so it's one of those things you can do later if it becomes necessary. Making things complicated up front is just going to frustrate you later so feel free to wait till you know it's necessary

YAGNI it's for more than just code.

Answer 5

Almost always easier to have one repository per development team, no matter how many products you have. Eventually you will want to share code between projects (even several seperate DJango websites!) and it is much easier to do with only one repository.

By all means set up a nice folder structure WITHIN that repository. However, a single checkout from git (probably from a subfolder) should give you all the files you need for your test website (python, templates, css, jpegs...), and then you just copy httpd.conf and so on to complete the installation.

Answer 6

I'm no git expert, but I don't believe the appropriate strategy would be any different from one for hg, or even, in this case, svn, so I'm going to give my 2 cents' worth anyway;-).

A repo per app makes any sense only if substantial numbers of people might be interested in pulling out (or watching changes to) separate apps; this could theoretically be the case but I've never observed it in real life -- mostly, people who are interested in the project are interested in it as a whole. Therefore, I would avoid complications and make the whole proj into one repo.