views:

answers:

+6 Q:

How to use git to manage one codebase but have different environments

I'm using git for a personal project at the moment and have run into a problem of having one codebase for two different environments and was wondering what the cleanest way to use git would be.

Main Desktop

I Use this machine for most of my development. I have a git repository here that I cloned off of an empty repository that I use on my internal server. I do most of my work here and push back to the internal server so I can use that as a master of truth and to ease making backups.

Laptop

I sometimes want to code on the road, so I did a clone from the internal server and created a new branch called "laptop-branch". Unfortunately some directories MSVC++ version are different than from the Main Desktop environment. I just modified the files in the "laptop-branch" and committed them there.

Now I did a lot of changes while on vacation with my laptop, and want to push them to origin, but don't want the changes I made that were related to directories and compiler versions to be pushed back to origin.

What would be the best way to get this done?

edit: In this case it is not a config file, but a VC++ solution/project files that are changed.

+4 A:

The way I do it...

...is not commit environment specific files via .gitignore.

In CodeIgniter this means

.htaccess
database.php
config.php

That's about it.

Depending on how your application is setup this can have differing effects. Mostly I will have say config.example.php and example.htaccess which I will commit. Then if I have to setup an environment I will modify those and rename them in the process. Because they are ignored by git you don't have to worry about it.

If you have lots of environment specific code then you need to rethink the layout of your application.

Josh K 2010-06-02 23:19:46

I have also done this for a web application I am working on, but ran into some issues when I was working on my deploy method. I ended up managing my environments in the config file (it is a Django app, so you can use Python in the config file), but still think of it as a dirty hack.

emostar 2010-06-02 23:27:32

It's *not* a dirty hack. It's standard operating procedure for managing multiple environments, which is *almost all the time*. Local environments, development environments, staging environments, live environments.

Josh K 2010-06-03 00:00:18

It is hard to test, so it is a dirty hack imo.

emostar 2010-06-03 00:38:41

@emostar: What do you mean *"hard to test?"*

Josh K 2010-06-03 03:30:24

Maybe we are talking about different things then... I'm talking about using python in a Django config file, and that makes doing a test of the environment hard to do, based on the what python code you wrote.

emostar 2010-06-03 05:02:19

I think it is too late for the .gitignore solutions.

I would :

create a laptop branch on your desktop machine machine
pull your changes from your laptop on this branch
checkout the config file which should not have changed from the master branch
verify it works and twiddle till it does
commit it
checkout the master branch
merge it with the laptop branch

Peter Tillemans 2010-06-03 08:09:40

Hmm, wouldn't it be better to have a desktop branch, that way both machines can sync with the master branch? And then I do work on desktop branch from the desktop and laptop branch from the laptop, and merge/rebase from master?

emostar 2010-06-03 09:35:41

Yes, that is a better approach. But you really want to exclude those machine dependent files for git all togetheras Josh mentioned. They have little to no value and even if you woul need them they would probably no longer be compatible with your IDE when you check them out again. It is more trouble than it's worth.

Peter Tillemans 2010-06-03 10:20:24

ansaurus

tags: