96

I have a remote repo in which I want to commit certain files (the compiled files to deploy them on a cloud computing platform), but I don't want to deploy them on github...

is there some way to have to different .gitignore files, one for each remote?

opensas
  • 60,462
  • 79
  • 252
  • 386
  • http://stackoverflow.com/questions/1753070/git-ignore-files-only-locally? – Gohn67 May 07 '12 at 00:02
  • 1
    oops, just found this question: http://stackoverflow.com/questions/2456533/is-there-a-way-to-setup-remote-specific-gitignores – opensas May 07 '12 at 00:51
  • @opensas, I came through your play 2 openshift library and stumbled over the same problem, how to maintain a normal git repo for development (excluding all generated files) and one explicitly for deployment (containing all generated files). Did you find an good solution so far? – Bachi Jun 13 '13 at 07:56
  • 2
    Bachi: in the end I just went with a little bach script that just copies the while app to another directory and the runs openshift_deploy from there. That is, I keep two completely different git repos. I could have done it with branches, and different .gitignore for each branch, but I think this approach is cleaner. Besides it's easier to process/minify js files before deploying – opensas Jun 13 '13 at 11:31
  • @opensas Sorry to bump an incredibly old topic here, but how would you go about having different .gitignore files for each branch? I'm trying to figure that out myself... – Swivel Jun 19 '14 at 23:18

4 Answers4

51

This doesn't really make sense in git's model. Commits contain sets of files; all .gitignore files do is tell the UI not to automatically add files matching certain patterns. What this would effectively mean is to have parallel sets of commits that are almost the same, but containing only a subset of the files.

It'd be possible to do this with a branching scheme, where you have a "deployment" branch that splits off of master and is the same but contains the additional compiled files. This could even be automated with git hooks to automatically compile the files and add them to the repo. I'm envisioning a structure like this:

master:       A ---> B ---> C ---> D
               \      \      \      \
                \      \      \      \
deployment:      -> A'  -> B'  -> C'  -> D'

i.e. every time a certain server gets a new commit on master, it builds the project, adds the built files to a new commit from D, and commits that to the deployment branch -- which then doesn't have to be pushed to github.

Danica
  • 28,423
  • 6
  • 90
  • 122
  • 5
    good idea, I haven't thought bout using different branches, each with it's own .gitignore – opensas May 07 '12 at 00:50
  • 1
    I understand you suggestion, but if I want to include all branches to a publicly available mirror without sharing some files that should only being shared and tracked in an internal remote (internal Git server), how should I archive something similar to your suggestion? (or by any better solution) – jimmymcheung Dec 08 '22 at 13:50
19

Update: you will not be able to replicate this environment using git clone, so I don't think this is a good approach

I figured out a way to do this.

In my case, I needed to synchronize the project with heroku and GitHub (as my public repo).

But I was not interested in sharing some files with private information in a public repository.

Usually a simple project would have the following folder structure

Project folder (remote heroku)
    - .git
    - .gitignore
    - (folders and files)

What I did was add one more level, and in it create another git repository, with a .gitignore that would omit some files from my project.

Project public (remote GitHub)
    - .git
    - .gitignore
    - Project folder (remote heroku)
        - .git
        - .gitignore
        - (folders and files)

So this is not a git repository with two remote repositories with different .gitignores.

There are two different repositories.

On the innermost I only exclude the files generated by the IDE and some files generated at runtime.

At the outermost level, I exclude all files that cannot be make public.

Guilherme
  • 1,705
  • 1
  • 25
  • 45
  • 1
    I agree; this seems to definitely bug out git. It works if you don't clone it, but the moment you clone it, the Heroku submodule just breaks down, hence the name "sobmodules" – 1Ghasthunter1 Aug 30 '22 at 23:43
3

Another option is git submodules.

This can be useful if, for instance, you want your code and documentation to be in two different repos with independent access control, etc. So you'd have 3 total repos, a submodule repo for docs, another for code, and the "master" (not a git submodule) repo containing both (for pypi upload, perhaps). This is a decent way to organize a CS textbook project. Both projects can proceed merrily ahead independently and sync up at major releases, driven by the master repo maintainer.

hobs
  • 18,473
  • 10
  • 83
  • 106
3

An automated solution to the methods mentioned here:

  1. Set up the root .git to ignore the subfolder(s) you you want transmitted differently
  2. Init new git within the subfolder(s) and assign the remote configuration
  3. Modify the root folder's .git/hooks/pre-push file to exec git push at those sub folders based on the incoming arguments.
Michael Mikhjian
  • 2,760
  • 4
  • 36
  • 51
  • 1
    I ended up doing this on my own. If you truly wanted automation. make that folder a temp folder and remove ```cd ..; rm -rf temp_folder;``` after pushing. https://github.com/MichaelDimmitt/publicize_readme/blob/master/publicize_readme.sh https://github.com/MichaelDimmitt/publicize_readme/blob/master/publicize_readme.rb – Michael Dimmitt Aug 08 '17 at 12:01