I’ve been learning git on a need to know basis over the last several months as I’ve been using it; I skimmed the Git Pro book but haven’t had time to spend on getting to understanding the intricacies yet.
I read an article about having what they call a “floating branch”. Which contains the config changes necessary on the production server. So my work-flow is I finish writing and testing a new feature on my development server, then push to a new branch over to the production server, checkout that new branch, then merge the so called “floating branch” config branch & then rebuild the source & restart the server.
If anything unexpected happens I can quickly checkout the last functioning branch & then rebuild the source & restart the server, reducing production downtime.
Obviously this is a messy work-flow, since the production server’s ends up with a new branch for every update. It also makes for a confusing branch hierarchy.
The other thing which keeps tripping me up is the fact that the “floating branch” config merge will not over write a change in the last commit.
So for example:
If I start a new database instance to test something on the development server & then follow the work-flow I’ve described when I merge the config branch it won’t over write the database name, I imagine because of the complex branch hierarchy created by this work-flow.
It’s a kind of lazy question, but some concise advice from an expert would certainly lessen my chronic cognitive overload. I’m a team of one & there are so many details to keep track of.
If anyone can give me some insight into a better work-flow. I see dozens of options on the net & here on stackoverflow, using a none-bare repository on a production server is bad form etc.
For now I’d just like to clean up the work-flow a little to avoid the sort of thing I’ve described. Maybe later I’ll have a few days to spend really getting into git internals. I doubt I’ve every be able to know my way around until I examine the git source itself
You’re making it more complicated than it has to be. The distributed nature of git means you can do all your messing around with temporary branches in your local repository, and make your central server look like changes are being appended onto one branch. I described a workflow that works well with maintaining separate configs for production and development here.