git:每个遥控器都有不同的 .gitignore 文件

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/10475273/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-19 06:53:28  来源:igfitidea点击:

git: have different .gitignore file for each remote

gitgithubgitignore

提问by opensas

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...

我有一个远程仓库,我想在其中提交某些文件(编译后的文件以将它们部署在云计算平台上),但我不想将它们部署在 github 上...

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

有什么方法可以使用不同的 .gitignore 文件,每个遥控器一个?

采纳答案by Dougal

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.

这在 git 模型中没有任何意义。提交包含文件集;所有 .gitignore 文件所做的就是告诉 UI 不要自动添加匹配特定模式的文件。这实际上意味着具有几乎相同但仅包含文件子集的并行提交集。

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 分支中分离出来,并且是相同的,但包含额外的编译文件。这甚至可以使用 git hooks 自动编译文件并将它们添加到 repo。我正在设想这样的结构:

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.

即每次某个服务器在 master 上获得新提交时,它都会构建项目,将构建的文件添加到来自 D 的新提交,并将其提交到部署分支——然后不必将其推送到 github。

回答by Guilherme

I figure out a way to do this.

我想出了一种方法来做到这一点。

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

就我而言,我需要将项目与 heroku 和 github(作为公共仓库)同步。

But some files with private information were not interesting to be shared 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.

我所做的是再添加一个级别,并在其中创建另一个 git 存储库,其中 gitignore 会从我的项目中省略一些文件。

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.

所以这不是一个带有两个不同 gitignore 的远程存储库的 git 存储库。

There are two different repositories.

有两个不同的存储库。

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

在最里面,我只排除 IDE 生成的文件和运行时生成的一些文件。

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

在最外层,我排除了所有不能公开的文件。

回答by MKN Web Solutions

An automated solutionto 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.
  1. 设置根 .git 以忽略您想要以不同方式传输的子文件夹
  2. 在子文件夹中初始化新 git 并分配远程配置
  3. 根据传入的参数修改根文件夹的 .git/hooks/pre-push 文件以在这些子文件夹中执行 git push 。

回答by hobs

Another option is git submodules.

另一种选择是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.

例如,如果您希望代码和文档位于具有独立访问控制等的两个不同存储库中,这将非常有用。因此,您总共有 3 个存储库,一个用于文档的子模块存储库,另一个用于代码,以及“ master”(不是 git 子模块)repo 包含两者(可能用于 pypi 上传)。这是组织 CS 教科书项目的好方法。这两个项目都可以独立地愉快地进行,并在主存储库维护者的推动下在主要版本上同步。