为什么干净的git clone会修复失败的构建?

时间:2017-03-20 10:45:30

标签: git webpack continuous-integration

我有一个依赖webpack构建的项目。我有一个团队成员的新分支,我检查了一下git reset --hard。运行构建后,它会出错。当我清理git clone并查看新分支时,它可以正常工作。是什么赋予了?我怎样才能这样做,所以我不必再次完全克隆项目?

我得到的错误如下:

ERROR in [at-loader] ./webpack.config.ts:312:5
    TS2339: Property 'replace' does not exist on type '{}'.

ERROR in [at-loader] ./webpack.config.ts:317:103
    TS2339: Property 'value' does not exist on type '{}'.

ERROR in [at-loader] ./webpack.config.ts:545:5
    TS2339: Property 'getProperty' does not exist on type 'LoDashExplicitObjectWrapper<NodeConfig>'.

ERROR in [at-loader] ./webpack.config.ts:545:17
    TS7006: Parameter 'n' implicitly has an 'any' type.

步骤如下:(这会产生错误)

git checkout extract_css
git reset --hard
yarn

或者,有一个干净的回购:(这有效)

git clone <url> new
cd new
git checkout extract_css
yarn

1 个答案:

答案 0 :(得分:1)

您可能需要-x。其余部分从my comment above

扩展而来

准确地考虑哪些文件git clean进行清理非常重要。正如the documentation所说:

  

通过递归删除不是的文件来清理工作树   在版本控制下,从当前目录开始。

     

通常情况下,只删除Git未知的文件,但如果是-x选项   指定时,也会删除被忽略的文件。例如,这可以是   有用的删除所有构建产品。

第一段留下未定义的含义&#34;不受版本控制&#34;。然而,第二个段给了我们一个强有力的线索,-d论证的描述巩固了它 - 也就是说,我们有一个明确的定义&#34;未跟踪& #34;:

  

-d

     
    除了未跟踪的文件外,还删除未跟踪的目录。 ...

有一个很好的,简单的Git特定的跟踪与未跟踪的定义:未跟踪的文件是不在索引中的文件(因此当然跟踪的文件是索引中 的文件。

请记住,Git的索引是,您可以在其中构建下一个提交。索引开始匹配当前提交 - 您运行的提交git checkout,即当前分支的提示。该提交中的每个文件也位于当前索引中。 Git将文件提交,复制到索引,再转到工作树,将其放入表格中计算机可以处理(提交内部和索引中的内部形式基本上只是一个Git形式)。

工作树在索引中保存的其他文件是很正常的。任何时候我们使用从我们的源构建东西的程序 - 例如,来自C或其他编译代码的.o.so文件,或.pyc.pyo字节编译的Python文件,或者其他通常被称为build artifacts的东西 - 我们最终得到的东西不是,也不应该是版本控制的。我们不会将它们添加到索引中,因此它们未被跟踪。

然而,Git喜欢以各种方式将它们分开。未经跟踪的文件可能会令人讨厌:Git一直在纠缠我们,警告这个文件和那个文件是未跟踪的,我们是否可以添加它们?我们知道我们不应该这样做,所以我们告诉Git请关闭,通过列出文件 - 路径名称或文件模式(如*.o)或其中包含的内容一个.gitignore文件。这让Git闭嘴。

但它也改变了git clean处理这些文件的方式。默认情况下,git clean仅删除抱怨的。由于我们主要告诉Git 忽略构建工件,因此普通git clean -f不会删除它们。我们需要git clean -fx

请注意,当未跟踪的文件存在于其中没有跟踪的文件的目录(或&#34;文件夹&#34;)中时,Git通常会将它们全部归为一起用于报告目的,并且说整个目录都没有跟踪。在这种情况下,git clean -fx仍会保留原来的那些:您需要git clean -dfx删除它们,然后还需要现在为空的目录本身。 (请注意,如果该目录中有任何跟踪文件,则此规则不再适用。)

正如描述所提到的,这一切都必须从工作树的顶层运行,因为它从当前目录&#34;开始。同样重要的是要注意任何子Gits或子模块都会阻止git clean在该子目录中工作;对于这些情况,最好在单独的Git存储库中重复git clean。 (例如,对于子模块,您可以使用git submodule foreach访问每个子模块并进行清理。)