Kevin Pei
Kevin Pei

Reputation: 5872

Git don't merge specific files (or even lines) when merging branches

First of all, I have a feeling that this has been covered somewhere else, however I was unable to find it despite searching both SO and Google. If this is indeed a duplicate please feel free to mark it as so

My git-based website is currently composed to two branches - Development and Production. (I'm currently the only developer on the team, so I didn't bother creating a release branch)

My project is done on top of a MVC Framework (laravel), and I would like to have branch-dependent files (don't update these when I merge development into production).

For example, in the production branch the config file is set to not output debug info when a server error occurs, while in the development branch I want it to output debug info.

As such, is it possible to get git to ignore specific files like the config file? Or even better, get it to ignore that specific line in the config file?

Note, this is a website - not a small project.

Upvotes: 2

Views: 376

Answers (2)

muxmuse
muxmuse

Reputation: 415

I found a solution for that (at least for the branch dependent files)

1) Create a custom merge driver that will ignore merge conflicts for the respective file. The driver has to be registered for each file in .gitattributes

2) Create merge conflicts at each commit in that file (otherwise, the merge is trivial and the merge driver will not be used). This can be done with a post-commit hook in .git/hooks/post-commit that changes that file in each branch after each commit.

I combined that in some scripts: https://github.com/keepitfree/faithfulgit

Upvotes: 0

Jmills
Jmills

Reputation: 2422

I'm pretty certain there is not, at least not without considerable effort. This idea is kind of confusing the purpose between version control software like git and build software like make or SCons. Typically you want everything that could be built/deployed in a managed repository, and then you have a build to manage bundling/deploying. It sounds like you are managing a website repository which doesn't seem like a great candidate for make and is the reason I actually use SCons to manage deploys (production and development) for a website and highly recommend it. If you definitely wanted to do it without a proper build software you could manage it by:

1) Making separate release trees/branches where changes to be saved to the master never get performed there, just create the differences in the files you want for development vs. production, develop elsewhere, push the updates into the isolated trees and use those for deploy. If you end up with edits that will cause conflicts in unmerged files, you would have to git stash and possibly edit manually to incorporate them. Obviously this is not great since certain things will never get checked into the master.

2) Do something with post-receive hooks, where you include the relevant different files that are under version control in a different location in the repository than where they would be in production (and would not be accessible to a user), to move the appropriate file into that location. To do this you'd have to have a repo where you want to deploy and where you develop (a bad idea - see below).

Those are really the only two I can think of, and I re-reviewed the git documentation in regards to your questions and could not find much else, but it would be much better just to use a proper build tool. It is the purpose of those types of tools and your comment "Or even better, get it to ignore that specific line in the config file?" just screams to use build-dependent defines to create the line you want based on a flag. You can additionally incorporate things like syntax checkers (JShint), web code minimizers (Google Closure) or static page templating (wpp) as part of your build process - I know nothing about laravel so maybe those would not be helpful, it's just some general ideas - so while some may think it's ok to push web files into production straight from git and building is not necessary for code that does not have to compile, I'd have to say that is a short-sighted idea. When you separate your code base from deployment in this regard, it also helps manage things that may be critical to your website that also don't belong in the web-accessible framework like server configurations, database migrations, cgi scripts, etc.

Upvotes: 1

Related Questions