Jasper Tandy
Jasper Tandy

Reputation: 335

git pull with local changes

I have a development clone and a live clone of a git repository, pushing from development and pulling to live. I'm having a problem in that configuration files need to be changed once they get to the live working copy. This was all working fine until I changed the structure of one of my configuration files - when I went to pull it down, there were 2 problems:

  1. my configuration file wasn't up-to-date, so the changes couldn't be pulled to that particular file (I was expecting that things would just be merged)
  2. I then tried to git pull again, and saw that everything was up-to-date, when viewing the file showed that it clearly wasn't up-to-date.

There's probably something fundamental I'm not understanding about how git works - is it best to create a live branch for modifying configuration files, then merging after pulling to master, or is there a way around this I'm not seeing?

Upvotes: 2

Views: 1480

Answers (2)

Jasper Tandy
Jasper Tandy

Reputation: 335

I've worked around this by creating a "live" branch, purely for configuration and things like that. Means that all my configuration can go into there, then I checkout the live branch on the live server and merge changes into it any time I need to set things live. Thinking about it, I should've really done this all along anyway - git forced me to improve the way I do this! Thanks, git.

Upvotes: 1

Ben James
Ben James

Reputation: 125277

The problem of keeping locally modifiable configuration files in version control is a classic one.

I've answered this here: Is there a way to make TortoiseSVN temporarily ignore versioned files?

(That particular question mentions Subversion, but both problem and solution are not specific to any one VCS. I use the same technique for Git repositories, too.)

Upvotes: 2

Related Questions