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 reposito

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:/.git@0.1.38#egg=

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/

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