1

I have a different settings.py for my local project and my live project (Bitbucket repo). So I have added settings.py to my .gitignore so when I make changes to either file, they don't get sent to the other repo when my git is pulled or pushed.

However, I just did a git pull from my local repo - and it did a merge and changed the settings.py file to the Bitbucket settings.py.

What is going on?

Edit - Gitignore file:

/lib
/media
.env
/include
/reports
.DS_Store
*.pyc
celerybeat-schedule.db
__pycache__/
db.sqlite3
log.django
settings.py
static/
/static
Zorgan
  • 8,227
  • 23
  • 106
  • 207

4 Answers4

1

If there is a settings.py file already in your repo, adding it to .gitignore won't stop the file from being pulled. The only way to do that is to remove it completely from the repo.

But this is the wrong thing to do. You should not exclude the whole settings file from version control. Almost all of the settings will remain the same between dev and production; there are plenty of techniques for maintaining those that differ, from a separate local_settings file to using environment variables.

Daniel Roseman
  • 588,541
  • 66
  • 880
  • 895
  • Isn't the whole point of `.gitignore` to stop my issue from occuring? Also - how would environment variables fix it? I'm using environment variables on my production settings but the variables are stored in a hidden `.env` folder on my remote server (using python-decouple) - and `.env` is in my `.gitignore` so doesn't leave the server. – Zorgan Feb 28 '18 at 09:29
  • No, the whole point is to stop you being prompted to add the file to git in the first place. And if you have your production settings in environment variables already, I don't understand why you want to exclude the whole file from version control. – Daniel Roseman Feb 28 '18 at 09:36
  • I don't want to have my environment variable values living on my local files for security reasons. – Zorgan Feb 28 '18 at 11:48
  • 1
    No, indeed. That's why you use local values for local development, and production values in production. – Daniel Roseman Feb 28 '18 at 11:48
  • There is no local value equivalent for things such as my AWS S3 Secret Key. – Zorgan Feb 28 '18 at 11:52
  • Yes. So you don't need to set it in development. I don't understand how any of this is related to what you're doing. – Daniel Roseman Feb 28 '18 at 11:55
  • It means not everything can be put in an environment variable so the development settings.py and the production settings.py are going to have to be different. Which then leaves me with the initial problem. Do I create a `local_settings.py` and then add `local_settings.py` to gitignore? – Zorgan Feb 28 '18 at 12:00
  • No this really doesn't make sense. Those things that only apply in production, or have different values in production, are perfect candidates for env variables. – Daniel Roseman Feb 28 '18 at 12:03
0

To make git stop tracking the settings.py completely including the previous commits.

git does not ignore a file that has already been tracked before a rule was added to .gitignore file to ignore it.

In such a case the file must be un-tracked first with this command: git rm --cached <filename>.

So if you are trying to ignore this file after the initial commit, run this: git rm --cached settings.py, and you should be good to go.

To make git stop tracking future changes in settings.py, apart from the initial commit.

Refer this answer.

Pankaj Singhal
  • 15,283
  • 9
  • 47
  • 86
0

I think you've already pushed the settings.py file to remote. So when you pull from remote. Your local file will also change even you've added this file to .gitignore. git will continue to track any files that are already being tracked.

A simple way to resolve this issue. First: git rm -r --cached . git add .

and then: git commit -am "Remove ignored files"

For more please refer this answer.

Kevin Law
  • 814
  • 4
  • 15
  • Just tried this and had the same outcome - still pull the `settings.py` after I do `git pull` – Zorgan Feb 28 '18 at 09:54
  • Before issue those commands I listed. You are required to add the **settings.py** file to **.gitignore** file. Thus when you issue `git add .`, **settings.py** will not be staged anymore. – Kevin Law Mar 01 '18 at 02:55
0

You can use git stash. It will keep you current settings.py as stash, then you can perform git pull. Then once pull is done, you can do git stash apply, this will restore all stashed files like settings.py and merge them is any thing is changed.