git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Handling non-git config files

From
IHIan Hobson <ian@ianhobson.co.uk>
Date
Feb 24, 2010, 18:27 UTC
Message-ID
<4B856FA6.4050808@ianhobson.co.uk>
In-Reply-To
<8440EA2C12E50645A68C4AA9887166513FC19C@SERVER.webdezign.local>
Richard Lee wrote:
Show 6 quoted lines
> So my quesstion is that is there any way to have several checked out
> copies of a git repo each with their own slightly different config
> files, yet still being able to perform git operations with respect to a
> centralised repository as if they were identical?
>
>   
Hi Richard,
Yes. They are called branches :)
What I do is have a branch for each version that I need.
To fix a problem I checkout master, make the repair, and commit.

Then to deploy that change I perform three steps (for each production version).

git checkout <clientBranch> git rebase master rsync to the production server (ignoring .git and temp files)

All the differences between versions - config files, images, logos, etc 
- are all included in the GIT,
repo and I don't have to worry about them. To set up the branches, I 
simply checked out a new branch for each and applied the changes for 
that production version, and committed. It works very well in practise. 
(Do take care to checkout the version you want to work on before you 
start work, or you may have to lose your work to recover!).
Ian
Previous: Tim MazidNext: Jon Seymour
Message 3 of 5 in “Handling non-git config files”
  1. Richard LeeFeb 23, 2010
  2. Tim MazidFeb 24, 2010
  3. Ian HobsonFeb 24, 2010
  4. Jon SeymourFeb 24, 2010
  5. rhleeMar 9, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.