Sharing files across branches in Git

Question

There are a bunch of files in my project that are sometimes modified but always shared among many different branches. Examples include build scripts, batch files that include paths, etc. Even the .gitignore file itself is an example.

I want this stuff in source control, but I don't want individual branches to keep track of changes to them.

How do you handle this situation?

Do you track everything related to your project in Git? What's your approach to shared objects?

Is .gitignore my only option?

Answer 1

Keep your build scripts and batch files in a separate repo?

Answer 2

For simple systems, I'll create base versions of these files that are in version control that are then adapted for each instance, the files for which are in .gitignore.

If I'm using a more sophisticated tool chain, I'll create source XML files that describe the base pieces, XML files that describe the specific instance variations then run an XSLT using a profile or command line property to generate the locally appropriate versions as part of the build configuration/script depending on your poison. This doesn't have to be XML/XSL, I just deal in XML a lot, you could use any kind of munging system that works with your build environment, say text files with perl scripts or just sed/awk.

Answer 3

I would create one branch to include all these shared files. Whenever a branch needs a shared file, it can get it using

git checkout workingbranch
git checkout sharedbranch <needed file>

Later you can update simply using the same command

git checkout sharedbranch <needed file>

Answer 4

You can achieve the same affect as .gitignore files by setting the skip-worktree bit of tracked files.

git update-index --skip-worktree <path_to_file>

Git will now pretend that your files are up-to-date.

Answer 5

Instead of relying on submodules, have you considered git-subtree?

As stated in the documentation:

Subtrees are not to be confused with submodules, which are meant for the same task.

Unlike submodules, subtrees do not need any special constructions (like .gitmodule files or gitlinks) be present in your repository, and do not force end-users of your repository to do anything special or to understand how subtrees work.

A subtree is just a subdirectory that can be committed to, branched, and merged along with your project in any way you want.

Below are some posts giving some feedback and explaining the pros of subtrees over submodules:

• http://ayende.com/Blog/archive/2011/01/10/the-problem-with-git-submodules.aspx
• http://ayende.com/Blog/archive/2011/01/10/git-subtree.aspx
• http://hobocentral.net/blog/2010/07/28/git-subtree/
• http://h2ik.co/2011/03/having-fun-with-git-subtree/

A very interesting (and somewhat heated) thread, from the git mailing-list, discussing pros and cons of git-subtree and submodule

• http://amailbox.org/mailarchive/git/2010/7/21/34793

Answer 6

The other answers did not address my problem as cleanly as I would like, but they did push me to research more options.

First off, git doesn't have the concept of tracking individual files, only whole repositories and branches.

There is no built-in way to choose a set of files that should be maintained in source control and managed independently of other individual branches.

In my project, virtually all the shared files are in one particular subdirectory. Whereas the rest of the source tree could change and should be managed by individual branches, this "configuration" fileset can be shared among various branches to keep the repository in a "live" state.

I couldn't find the solution because I haven't read books on git and I didn't know the right search term. Git's solution for this situation is submodule.

If, instead, my configuration information was spread among individual files that aren't contained in an individual directory, a submodule wouldn't be a good fit.

In that case, a remote git repository should be set up and the files would be maintained in the separate repository using git-push.