6

现在项目的根目录放了 .gitignore 文件,并且git远程仓库的项目根目录已经有了 logs文件夹。

由于每次本地运行项目,都会生成新的log文件,但是我并不想提交logs文件夹里面的内容,所以要在.gitignore写logs的规则。

我尝试过添加以下规则
logs/*.log
logs/
/logs/

但是运行git status的时候,始终能看到modified:logs/xx.log 。

请问是我的规则编写错误,还是我某个地方有理解错误?

5个回答

73

已采纳

tl;dr: 正确的做法应该是:git rm --cached logs/xx.log,然后更新 .gitignore 忽略掉目标文件,最后 git commit -m "We really don't want Git to track this anymore!"

具体的原因如下:

被采纳的答案虽然能达到(暂时的)目的,但并非最正确的做法,这样做是误解了 git update-index 的含义,而且这样做带来的最直接(不良)后果是这样的:

  1. 所有的团队成员都必须对目标文件执行:git update-index --assume-unchanged <PATH>。这是因为即使你让 Git 假装看不见目标文件的改变,但文件本身还是在 Git 的历史记录里的,所以团队的每个人在 fetch 的时候都会拉到目标文件的变更。(但实际上目标文件是根本不想被 Git 记录的,而不是假装看不见它发生了改变)

  2. 一旦有人改变目标文件之后没有 git update-index --assume-unchanged <PATH> 就直接 push 了,那么接下来所有拉取了最新代码的成员必须重新执行 update-index,否则 Git 又会开始记录目标文件的变化。这一点实际上很常见的,比如说某成员换了机器或者硬盘,重新 clone 了一份代码库,由于目标文件还在 Git 的历史记录里,所以他/她很可能会忘记 update-index

为什么会这样?答案就在 Git 的 man pages 里:

首先,git update-index 的定义是:

Register file contents in the working tree to the index(把工作区下的文件内容注册到索引区)

这句话暗含的意思是:update-index 针对的是 Git 数据库里被记录的文件,而不是那些需要忽略的文件。

接着看关于 --assume-unchanged 的几句相关的描述:

When the "assume unchanged" bit is on, Git stops checking the working tree files for possible modifications, so you need to manually unset the bit to tell Git when you change the working tree file. This is sometimes helpful when working with a big project on a filesystem that has very slow lstat(2) system call (e.g. cifs).

大致意思是:

应用了该标识之后,Git 停止查看工作区文件可能发生的改变,所以你必须 手动 重置该标识以便 Git 知道你想要恢复对文件改变的追踪。当你工作在一个大型项目中,这在文件系统的 lstat 系统调用非常迟钝的时候会很有用。

我们知道 Git 不仅仅是用来做代码版本管理的,很多其他领域的项目也会使用 Git。比如说我公司曾经一个客户的项目涉及到精密零件图纸文档的版本管理,他们也用 Git。有一种使用场景是对一些体积庞大的文件进行修改,但是每一次保存 Git 都要计算文件的变化并更新工作区,这在硬盘慢的时候延迟卡顿非常明显。

git update-index --assume-unchanged 的真正用法是这样的:

  1. 你正在修改一个巨大的文件,你先对其 git update-index --assume-unchanged,这样 Git 暂时不会理睬你对文件做的修改;
  2. 当你的工作告一段落决定可以提交的时候,重置改标识:git update-index --no-assume-unchanged,于是 Git 只需要做一次更新,这是完全可以接受的了;
  3. 提交+推送。

另外,根据文档的进一步描述:

This option can be also used as a coarse file-level mechanism to ignore uncommitted changes in tracked files (akin to what .gitignore does for untracked files).

这段描述告诉我们两个事实:

  1. 虽然可以用其来达成楼主想要的结果,但这是不讲究的做法(coarse);
  2. 同样的事情更应该用 .gitignore 文件来实现(针对未追踪的文件)。

随之而来的问题是:为什么我增加了 .gitignore 里的规则却没有效果?

这是因为我们误解了 .gitignore 文件的用途,该文件只能作用于 Untracked Files,也就是那些从来没有被 Git 记录过的文件(自添加以后,从未 add 及 commit 过的文件)。

之所以你的规则不生效,是因为那些 .log 文件曾经被 Git 记录过,因此 .gitignore 对它们完全无效。这也正是开头那段简短答案所做的事情:

  1. 从 Git 的数据库中删除对于该文件的追踪;
  2. 把对应的规则写入 .gitignore,让忽略真正生效;
  3. 提交+推送。

只有这样做,所有的团队成员才会保持一致而不会有后遗症,也只有这样做,其他的团队成员根本不需要做额外的工作来维持对一个文件的改变忽略。

最后有一点需要注意的,git rm --cached 删除的是追踪状态,而不是物理文件;如果你真的是彻底不想要了,你也可以直接 rm+忽略+提交。

1
回复 Arch

你的描述有一些细节我看不明白:为什么你修改了本地配置文件之后,git status 会提醒你“一大堆”文件需要添加?是因为你的本地配置文件太多还是?

我所描述的方法只是一种应急措施,并不是推荐使用的常规手段。不想要添加到 Git 中的文件始终应该放进 .gitignore 里面——这才是正道。

如果,仅仅如果是因为忘记放进 .gitignore 而导致的问题,可以用 git rm 的方式来解决,解决了之后还是不要忘记再添加 .gitignore 规则,这样才能保证以后不出一样的问题,而且也不会总是有一些文件需要你格外留意别去 git add(这是病态,不是常态)。

当然,配置文件总是 Git 使用的一个障碍,但也不是无法可施,我最近刚回答过关于配置文件的处理策略,你可以参考一下把思路理清楚,Git 的使用不应该是如此复杂的。

http://segmentfault.com/q/1010000000778120/a-1020000000778556

n͛i͛g͛h͛t͛i͛r͛e͛ · 2014年11月19日

1
回复 Yole

这个问题其实也好解决,很多项目都有这种必须要有的初始化文件,但是内容可能在每个开发端都不同。针对这一问题有很多种办法,比如说放一个占位文件 logs/xx.example.log,然后告诉团队成员第一次 _clone_ 回来改一下文件名。再比如说不放任何占位文件,而是在项目根路径下写一个初始化脚本,第一次 _clone_ 回来之后运行一下初始化脚本在你的本地生成一些必须要有的文件(但是不如版本控制系统)。比较推荐方法二,因为你可以用初始化脚本做一系列事情,而不只是个别文件,这也是开发构建自动化常用的一种措施。

n͛i͛g͛h͛t͛i͛r͛e͛ · 2014年04月15日

3

有时不想删除本地的文件, 只是想让git不再track, 这时可以使用 git rm --cached logs/xx.log

xhh · 2014年04月15日

展开评论
10

已经维护起来的文件,即使加上了gitignore,也无济于事。
用下面这个命令:
git update-index --assume-unchanged logs/*.log
这样每次提交就不会出现logs下面的文件了

4

自己来一段详细的答案
.gitignore只能忽略那些原来没有被track的文件,如果某些文件已经被纳入了版本管理中,则修改.gitignore是无效的。
正确的做法是在每个clone下来的仓库中手动设置不要检查特定文件的更改情况。

git update-index --assume-unchanged PATH    在PATH处输入要忽略的文件。

另外 git 还提供了另一种 exclude 的方式来做同样的事情,不同的是 .gitignore 这个文件本身会提交到版本库中去。用来保存的是公共的需要排除的文件。而 .git/info/exclude 这里设置的则是你自己本地需要排除的文件。 他不会影响到其他人。也不会提交到版本库中去。

.gitignore 还有个有意思的小功能, 一个空的 .gitignore 文件 可以当作是一个 placeholder 。当你需要为项目创建一个空的 log 目录时, 这就变的很有用。 你可以创建一个 log 目录 在里面放置一个空的 .gitignore 文件。这样当你 clone 这个 repo 的时候 git 会自动的创建好一个空的 log 目录了。

3

我发现最高票(n͛i͛g͛h͛t͛i͛r͛e͛)的答案压根没有理解题主的问题
反而是@FatGhosta的答案才是正确的

如果按照n͛i͛g͛h͛t͛i͛r͛e͛的方法进行操作 只是达到
“将不需要记录的文件从git中删除的同时在本地保留该文件 并在以后的提交中忽略”
而不是达到
“提交时忽略已在git中存在的文件”

其实场景应该是这样的 有一个配置文件 比如是数据库的链接信息
每个人的链接信息肯定不是一样的 但是又要提供一个标准的模板 用来告知如何填写链接信息
那么就存在git上需要记录一个标准配置文件 然后每个人根据自己的具体情况 配置一份链接信息自用 但是不会将该配置文件提交到库里的情况
因此FatGhosta的答案才是该题目下正确的回答

3
回复 ZhuHongQing

首先你要搞清楚顺序,我的回答其实是在题主总结答案之后才发布的,只是因为被采纳了才置顶的,所以并不是因为我的答案无法解决问题所以题主才自己总结答案。

事实上,题主总结答案的时候我就已经评论他会有后遗症,然后我才重新回答了问题。至于什么后遗症,我的答案里已经总结的很清楚了。

其实你的场景和题主根本就不一样,题主是不想要已经被 Git 记录在案的文件,而你是要保留一份模版,然后本地修改的版本不要提交。

对于你的场景来说,update-index 的确可以在表面上解决,但是有后遗症——再强调一遍,如果你实在无法理解后遗症,那就再认真看我答案的第三段以及下面的列表。

如果你仔细观察一下比较知名的一些开源项目,你会发现别人都是这样处理的:

  1. 对于充当模版的文件,在文件名上加以区分然后用 Git 记住。比如说实际的配置文件应该叫 database.conf,在写好模版之后可以更名为 database.conf.example。Git 记录 database.conf.example 但是忽略 database.conf

  2. 每一个人克隆下来之后,复制一份 database.conf.exampledatabase.conf 然后修改后者以符合本地的要求。由于后者是在 .gitignore 里的,所以不会被记录,也完全不需要 update-index

这样一来即避免了副作用,又不会产生冲突问题,这才是问题的真正解决之道。当然这种方式会需要大家事先做好约定,所以绝大多数的开源项目都是这样处理的。如果想要更进一步,那么可以利用系统环境变量来设置那些不需要记录在 Git 的配置(特别是一些秘钥等敏感信息)然后在项目里简单的写一个脚本或者脚手架程序来生成、设置、获取这些配置。

如果你不信的话,不妨去试试一些知名的框架,比如 rails 等,好好看看人家是怎么处理这种场景的。总之,如果都只能靠 update-index 的话,早就乱了套了。

n͛i͛g͛h͛t͛i͛r͛e͛ · 2016年05月25日

展开评论
1

把log文件删了,加ingore, 再commit

撰写答案