CODEWITHSUNDEEP
pythondjangogitgithubdjango-database
sgarza62
sgarza62

Reputation: 6238

git merge conflicts with our database file (multiple developers)

A buddy and I are developing a Django app and are using git.

As we work, we make fake accounts on our site, login, and upload content to the database, etc..for testing purposes. Every time we merge branches, we get merge conflicts in our database file. The database file is in the repository, and, since we're testing separately, the local copies of the file develop differently.

How do I prevent the database file from being tracked, so we can each keep our local copies?

With the following, we've been able to avoid using a local path:

## settings.py


from os.path import dirname, join

PROJECT_DIR = dirname(__file__)

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': join(PROJECT_DIR, 'foo.db'),
        'USER': '',
        'PASSWORD': '',
        'HOST': '',
        'PORT': '',
    }
}

What would be ideal, is something like:

## settings.py


from os.path import dirname, join

PROJECT_DIR = dirname(__file__)

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': join('../../../', PROJECT_DIR, 'foo.db'), # this path is outside the repository (ie, 'Users/sgarza62/foo.db')
        'USER': '',
        'PASSWORD': '',
        'HOST': '',
        'PORT': '',
    }
}

How can we keep our database files from being committed?

Upvotes: 9

Views: 11224

Answers (4)

Garrett Hyde
Garrett Hyde

Reputation: 5597

First off, you'll want to remove the database file from your git repository.

git rm <database_file>

To prevent the file from being added to your repository, create a file named ".gitignore" inside your checkout of the repository, add the database file to .gitignore, and add .gitignore to your repository. (Documentation)

To prevent conflicts with settings.py, I also add settings.py to .gitignore. I then create a file called "settings.production.py", which contains all of the settings for the production server, and add it to the repository. On my local checkout, I simply copy this file into settings.py and modify variables as needed. On my production server, I make a symlink to settings.production.py.

ln -s settings.production.py settings.py

WARNING:

  1. If your repository is public, it should never store secret keys, passwords, certificates, etc. You don't want others to have access to these files.
  2. You should also verify that your web server does not serve ".git" folders. A hacker could gain access to your source code if http://example.com/.git is accessible.

Upvotes: 7

Victor &#39;Chris&#39; Cabral
Victor &#39;Chris&#39; Cabral

Reputation: 2173

This is a common problem. I would recommend not checking in the database and loading and saving data fixtures as needed. (https://docs.djangoproject.com/en/dev/howto/initial-data/)

Create a test_data directory and run the following commands to export your database to a database agnostic json file: ./manage.py dumpdata > test_data/test_file_1.json

Check that file in to source. At any point if you want to restore the database to that point simply run: ./manage.py loaddata test_data/test_file_1.json

This also has the advantage of being used for unit tests (read Loading fixtures in django unit tests)

from django.test import TestCase
class MyTestCase(TestCase):
    fixtures = ['/myapp/fixtures/dump.json',]

Upvotes: 1

Rafał Łużyński
Rafał Łużyński

Reputation: 7312

When you work on projects with other ppl sharing repo, you have to make local_settings.py and keep there all local settings :) Then in settings.py just add from local_settings import *. And add local_settings.py and database file to .gitignore file.

In example if your file name is database.db then in directory with this file create file with name .gitignore and write in it database.db or *.db to ignore all db files.

Upvotes: 1

Alex Krauss
Alex Krauss

Reputation: 10393

Add your database file to .gitignore. Then you can keep it in its current location, but it will not be under version control.

Upvotes: 14

Related Questions