[英]how can I add an untracked file in my Github repo?
I have an untracked config.js
that stores a few development-mode variables in my local repo and a corresponding config.js
on my VPS with the production-mode versions of the same variables.我有一个未跟踪的
config.js
,它在我的本地存储库中存储了一些开发模式变量,并在我的 VPS 上存储了一个相应的config.js
,其中包含相同变量的生产模式版本。 But I want to try out Github Pages.但我想试试 Github Pages。 How do I add such an untracked
config.js
to my Github repository so that it doesn't get replicated when I do a git pull
on my laptop?如何将这样一个未跟踪的
config.js
添加到我的Github存储库,以便在我的笔记本电脑上执行git pull
时它不会被复制? Or, if there is no way I can do this, is there any other way I can achieve this?或者,如果我无法做到这一点,还有其他方法可以实现吗? That is, store some variables separately from the repo but use them for Github Pages website?
也就是说,将一些变量与 repo 分开存储,但将它们用于 Github Pages 网站?
You can't.你不能。 There's a technical wording glitch here, but "you can't" is the short answer.
这里有一个技术措辞故障,但“你不能”是简短的回答。 See below for details.
详情见下文。
Is there any other way I can achieve this?
还有其他方法可以实现吗? That is, store some variables separately from the repo but use them for Github Pages website?
也就是说,将一些变量与 repo 分开存储,但将它们用于 Github Pages 网站?
There are several options;有几种选择; I have no idea which ones might be good on GitHub Pages specifically.
我不知道哪些可能在 GitHub Pages 上特别好。 This is, in fact, a Frequently Asked Question from the Git FAQ, where it's disguised as "How to I tell Git to ignore tracked files?"
事实上,这是 Git FAQ 中的一个常见问题,它伪装成“我如何告诉 Git 忽略跟踪的文件?” :
:
A common reason to ask this question are configuration files which are added to a project as an example or default, but which individual developers may want to change.
问这个问题的一个常见原因是配置文件作为示例或默认添加到项目中,但个别开发人员可能希望更改这些文件。 Keeping uncommitted changes around is undesirable in the long run, because git diff will always show the changes and they will be added for commit if commands such as
commit -a
oradd -u
are used.从长远来看,保留未提交的更改是不可取的,因为 git diff 将始终显示更改,并且如果使用诸如
commit -a
或add -u
之类的命令,它们将被添加以进行提交。This problem can be solved in different ways:
这个问题可以通过不同的方式解决:
- Option a: Rename the configuration file to config.template or something like that, and tell the user to use it as a template.
选项 a:将配置文件重命名为 config.template 或类似的名称,并告诉用户将其用作模板。 The install script for your system could also copy the template configuration to the appropriate location.
您系统的安装脚本也可以将模板配置复制到适当的位置。
- Option b: Allow configuration options to be overwritten in a seprate file.
选项 b:允许在单独的文件中覆盖配置选项。 For example, in Makefiles it is common to add a line
-include config.mak
, which allows users to add custom configuration inconfig.mak
, rather than changing the Makefile itself.例如,在 Makefiles 中添加一行
-include config.mak
是很常见的,它允许用户在config.mak
中添加自定义配置,而不是更改 Makefile 本身。- Option c: Make Git ignore changes to the configuration file.
选项 c:让 Git 忽略对配置文件的更改。 There is no automatic centralized way to do that.
没有自动集中的方式来做到这一点。 But on a per-clone basis you can tell Git to do it using either
git update-index --assume-unchanged <file>
or sparse checkout (see the corresponding section in git-read-tree(1) for details).但是在每个克隆的基础上,您可以告诉 Git 使用
git update-index --assume-unchanged <file>
或sparse checkout来执行此操作(有关详细信息,请参阅git-read-tree(1)中的相应部分)。 Note that neither feature was designed for that purpose.请注意,这两个功能都不是为此目的而设计的。 Use at own risk.
使用风险自负。
I generally prefer the "template" option (option A).我通常更喜欢“模板”选项(选项 A)。 Your software can typically do something like:
您的软件通常可以执行以下操作:
if exists("real-config-file"):
load("real-config-file")
else:
print("notice: using template config as fallback")
load("template-config-file")
and now you get a working system even if you haven't configured it, but once you do configure it, you get a working system with your configuration .现在即使您没有配置它,您也可以获得一个工作系统,但是一旦您配置它,您就会获得一个具有您的配置的工作系统。 The "install script" trick can also copy the template into place as the default initial configuration, provided there's an install phase in whatever system you're using.
“安装脚本”技巧还可以将模板复制到适当的位置作为默认初始配置,前提是在您使用的任何系统中都有安装阶段。
The phrase tracked file , in Git, refers specifically to any file currently in the index .在 Git 中,短语tracked file特指当前在索引中的任何文件。 "The index" is a thing that Git calls by three different names: index , staging area , or cache .
“索引”是 Git 用三个不同名称调用的东西:索引、暂存区域或缓存。 I'm using "index" here because of the
git update-index
command and because the word "index" is relatively meaningless (which means it doesn't drag in too many false assumptions).我在这里使用“index”是因为
git update-index
命令并且因为“index”这个词相对没有意义(这意味着它不会拖入太多错误的假设)。
The index isn't actually part of any commit, and a repository is primarily a collection of commits.索引实际上不是任何提交的一部分,存储库主要是提交的集合。 So whether some file exists in some commit or not isn't the right question to ask—at least, not yet .
因此,某个文件是否存在于某个提交中并不是正确的问题——至少,目前还没有。 The right question is: How, when, and why do files wind up in the index?
正确的问题是:文件如何、何时以及为什么会出现在索引中?
The answer to why is the easiest.为什么的答案是最简单的。 A file goes into the index because you would like that file to be in your next commit.
一个文件进入索引是因为您希望该文件出现在您的下一次提交中。
The answer to when and how are trickier, because git add
and git rm
let you manipulate the index one file at a time , and other Git commands manipulate the index en-masse.何时和如何的答案比较棘手,因为
git add
和git rm
让您一次操作一个文件的索引,而其他 Git 命令可以操作索引。 The big important ones are perhaps these:最重要的可能是这些:
git checkout
or git switch
, fills in the index (and your working tree) from a commit.git checkout
或git switch
签出提交的行为会从提交中填充索引(和您的工作树)。git reset
command (in its "entire commit" mode) can reset the index to match a particular commit. git reset
命令(在其“整个提交”模式下)可以重置索引以匹配特定的提交。 It will do so unless you use --soft
.--soft
,否则它将这样做。git merge
command uses the index to achieve the merge; git merge
命令使用索引来实现合并; the merge result is in the index (and your working tree). So, if some file is in some particular commit, checking out that commit, or merging with it, will cause that file to wind up in the index.因此,如果某个文件在某个特定的提交中,则检查该提交或与其合并,将导致该文件在索引中结束。 As such, that file will be a tracked file .
因此,该文件将是一个跟踪文件。
But just because some file ( index.js
or whatever) is in commit a123456
doesn't mean that that file is in commit b789abc
.但仅仅因为某个文件(
index.js
或其他文件)在提交a123456
中并不意味着该文件在提交b789abc
中。 If you switch to commit b789abc
and that commit lacks index.js
, the file will be removed from the index, if it's there now (provided that the git switch
or git checkout
succeeds).如果您切换到提交
b789abc
并且该提交缺少index.js
,则该文件将从索引中删除,如果它现在在那里(前提是git switch
或git checkout
成功)。
The thing is, if it's removed from Git's index, it's also removed from your working tree.问题是,如果它从 Git 的索引中删除,它也会从您的工作树中删除。 That is the effect you wish to avoid.
这就是您希望避免的效果。 So you must therefore avoid switching away from a commit where the file does exist, and therefore has been put into your index, to a commit where the file does not exist, and therefore is removed from your index and your working tree.
因此,您必须避免从文件确实存在并因此已被放入您的索引的提交切换到文件不存在的提交,因此从您的索引和工作树中删除。 Well, except when you want to observe the resulting behavior , which is in fact every time you're using that commit!
好吧,除非您想观察结果行为,实际上是每次您使用该提交时!
So Git is (sort of) doing what you want.所以 Git 正在(有点)做你想做的事。 It's what you want to want that's not reasonable.
这是你想要的,这是不合理的。 😀 More seriously, there definitely is something problematic here, but it's really really hard to pin down how something should behave other than to fall back to those three options in the Git FAQ.
😀 更严重的是,这里肯定存在一些问题,但是除了退回到 Git FAQ 中的这三个选项之外,真的很难确定某些东西应该如何表现。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.