TowardsDataScience 博客中文翻译 2021（三百一十八）

原文：TowardsDataScience Blog

协议：CC BY-NC-SA 4.0

了解概率分布

原文：https://towardsdatascience.com/getting-to-know-probability-distributions-cc1dd1e2f22b?source=collection_archive---------1-----------------------

数据科学基础知识的回归

考考自己！你能解释这些核心统计概念中的多少？

CLT、CDF、分布、估计、期望值、直方图、峰度、MAD、均值、中值、MGF、众数、矩、参数、概率、PDF、随机变量、随机变量、偏度、标准差、尾部、方差

你的知识有缺口吗？请继续阅读！

注: 如果你在下面看到一个不熟悉的术语，请点击链接查看解释。

随机变量

随机变量(R.V .)是一种将现实转化为数字的数学函数。可以把它想成一条规则，在真实世界的事件发生后，决定你应该在你的数据集中记录什么数字。

随机变量是简化现实的规则。

例如，如果我们对六面骰子的滚动感兴趣，我们可以将 X 定义为随机变量，它将您对真实世界骰子滚动的感性体验映射到这些数字之一:{1，2，3，4，5，6}。或者我们可能只记录奇数/偶数的{0，1}。这完全取决于我们选择如何定义我们的简历。

图片:来源。

(如果这太专业了，就把随机变量想象成一种表示结果的方式:如果 X 是关于掷骰子的，那么 X =4 就是说我们掷出了一个 4。如果这还不够专业，你几乎可以肯定https://en.wikipedia.org/wiki/Almost_surely爱上一堂衡量理论课。)

随机变量

许多学生混淆了随机变量和随机变量。如果你是一个普通读者，跳过这一点，但爱好者会注意到:随机变量是像{1，2，3，4，5，6}这样的结果值*,而随机变量是将现实映射到数字上的函数**。你课本公式中的小 x 对大 X 。*

概率

P(X=4) 在英语中读作“我的骰子 4 朝上着地的概率。”如果我有一个公平的六面骰子， P(X=4) =1/6。但是…但是…但是…概率是什么，那 1/6 从何而来？很高兴你问了！在这里，我已经为你介绍了一些概率基础知识，组合学是额外的收获。

分销

分布是一种表达 X 可能取的整组值的概率的方式。

发行版以图形的形式向您提供受欢迎程度竞赛的结果。

概率密度函数

召唤分布的最好方法是说出它的真名:它的概率密度函数。这样的功能意味着什么？如果我们把 X 放在X*-轴上(没错)，那么 y 轴上的高度显示了每个结果的概率。*

一个概率密度函数给你整个人口的受欢迎度竞赛结果。基本上就是人口直方图。横轴:人口数据值。纵轴:相对知名度。要了解更多关于这张图和我省略的细节，请点击这里的。

*正如我在这里详细解释的那样，分布本质上是一个想象的理想化条形图(对于离散的 R.V.s)或直方图(对于连续的 R.V.s) 。*换句话说， *X 的更可能值的分布更高。对于所有结果，公平骰子的分布具有相同的高度(离散均匀”)；对于加重的芯片来说并非如此。

和分布图一样，你可以把条形图和直方图想象成流行度竞赛。或者小费罐。那也行得通。

累积密度函数

这是概率密度函数的积分*。用英语？该函数不是显示 X 的每个值的可能性，而是显示 X 及以下所有值的累积概率。如果你在考虑百分位数，那太棒了。百分位数是在 x 轴上的数值，百分比是在 y 轴上的数值。*

概率:在六面骰子上得到 3？1/6
累计:获得 3 分或更低？3/6
第 50 百分位是 3。3 在 x 轴，50%在 y 轴。

选择您的发行版

你怎么知道什么分布适合你的 X ？统计学家有两种最喜欢的方法。他们或者(1) 从他们的数据中估计 经验分布——使用，你猜对了，直方图！—或者他们(2)做出理论上的假设关于流行发行目录的哪个成员看起来最像他们认为他们的数据源的行为方式。(如果你有数据，用假设检验来检查那些分布假设是个好主意。)

选择分布的标准方法包括绘制直方图，并将其形状与目录中的理论分布形状进行比较，例如维基百科上的分布列表、教科书中的分布列表或上述分布图的销售页面。(现在你开始怀疑我到底是在开玩笑。)作者个人 plushie 系列图片。

当我们查看我们的目录时，我们注意到各种分布都有类似“正态”或“卡方”或“柯西”的名称……这给学生一个错误的印象，以为这些是唯一的选项。他们不是。他们只是有名的。就像人一样，发行版可能因为所有错误的原因而出名。

就像人一样，发行版可能因为所有错误的原因而出名。

从好的方面来说，命名发行版附带了整洁的 pdf 和一堆为您预先做好的计算。

不利的一面是，您的应用程序可能不适合目录中的任何内容。感谢上帝的经验选择。

因素

这是一个非常流行的分布的概率密度函数，正态分布(也称为高斯或钟形曲线):

实话实说吧，这些见解并没有跃然纸上。这就是为什么我们倾向于询问我们感兴趣的特定参数的问题。在统计中，参数概括了总体或分布。例如，如果您要问分布是否在零处达到峰值，您要问的是其众数(一个参数)的位置。如果你在问分布有多胖，你是在问它的方差(另一个参数)。在时刻，我将带你参观几个我最喜欢的参数。

但在此之前，让我来回答这个问题:与其计算汇总测量，我们为什么不画出这个函数并注视它？我们还没准备好。

*如果你看上面的函数，你会注意到里面有一些希腊字母:μ和𝜎.**这些是该分布的特殊参数；在我们用数字代替它们之前，我们还没准备好绘制任何东西。没有它们，我们所能做的只是对分布的抽象形状有一个模糊的感觉，就像这样:

图片:来源。

想要斧子吗？把数字放在希腊字母所在的地方。例如，μ= 0 vs . 5 vs . 10 和𝜎 = 1 的结果如下:

粉色μ = 0，蓝色μ = 5，绿色μ = 10

*还有更多希腊语可以享受，因为其他发行版使用其他字符来表示它们的特殊数量。最终，你会厌倦它，开始使用 *θ₁、θ₂、θ₃、等。对他们所有人来说。

还值得记住的是，分布及其参数是理论对象，涉及关于人口总数的假设，而直方图是一个更实用的对象——你拥有的样本数据的汇总。如果你把与样本和总体相关的概念分开，你会避免很多混乱，所以在这里有必要重温一下这些概念。

你可以在这里找到我的解释。

现在我们已经准备好参观我最喜欢的参数，在第二部分中继续。

感谢阅读！人工智能课程怎么样？

如果你在这里玩得开心，并且你正在寻找一个为初学者和专家设计的有趣的应用人工智能课程，这里有一个我为你制作的娱乐课程:

在这里欣赏整个课程播放列表:bit.ly/machinefriend

与凯西·科兹尔科夫联系

让我们做朋友吧！你可以在 Twitter 、 YouTube 、 Substack 和 LinkedIn 上找到我。有兴趣让我在你的活动上发言吗？使用表格取得联系。

脚注

从技术上讲，一个离散的 R.V .函数被称为概率质量**函数，而不是概率密度函数，但我还没见过有人在乎你是否把一个 PMF 叫做 PDF 。*

** 如果你有一个离散的 R.V .，那么它是和而不是积分。

** * 那个π没什么特别的。这只是我们在 3 月 14 日庆祝的常规节日。

用于更好绘图的 ggplot2 扩展

原文：https://towardsdatascience.com/ggplot2-extensions-for-better-plotting-1734f62c160c?source=collection_archive---------28-----------------------

帮助您更高效地创建更好的地块的扩展

拼凑—排列您的图表

patchwork的目标是让将独立的 gg 图组合成同一个图形变得简单得可笑。要开始使用这个伟大的库，你需要记住三个基本操作符:+ /和|。首先，让我们安装patchwork并创建一些情节。

基本用法

让我们将我们的图合并成一个大图，使用+操作符再简单不过了:

默认情况下，patchwork 会尝试保持网格为方形，并按行顺序填充它:

作者使用+运算符的拼凑式 ggplot2 排列-图像

定制安排

/和|操作符使您能够超越这种自动排列。|会将图并排放置，而/会将它们堆叠起来:

使用/和|运算符的拼凑式 ggplot2 排列-作者图片

还有很多其他功能，如添加注释，字幕和其他安排选项。如果你想了解更多关于这个了不起的包，你应该访问它的伟大的文档页面。

esquisse 通过用户界面交互式创建图表

该扩展允许您通过使用带有拖放界面的 ggplot2 包来可视化数据，从而以交互方式浏览数据。可以导出创建和样式化的图形，也可以检索它们的代码以获得再现性。要开始使用这个包，您只需要两行代码。

执行后，将会打开一个新窗口，这实际上是不言自明的:首先会要求您从指定的环境中打开一个数据框，随后，您可以简单地将数据框的特征拖放到 x、y、填充、颜色和大小的相应区域。底部的菜单使您能够进一步设计和调整您的绘图。

来自https://github.com/dreamRs/esquisse的 esquisse 可视化

要了解关于这个伟大的软件包的更多信息，它使创建令人惊叹的 ggplots 变得超级容易(特别是对于初学者)，请访问官方文档页面。

gganimate 为您的绘图制作动画

您是否厌倦了静态图表，并希望在演示文稿或 web 上的图表中添加一些额外的内容？使用 gganimate 您可以使用一个易于 ggplot2 用户学习的 API 来创建动画。要开始，您首先需要安装两个软件包:

不错！现在让我们创建一个动画。例如，如果您想要绘制著名的虹膜数据的花瓣宽度和长度，并创建一个过渡到物种的动画图(分别绘制它们)，您可以执行以下操作:

您可以看到创建绘图的标准 ggplot2 命令，随后是 transition_states() 函数，该函数通过声明动画的状态(您可以将其视为电影或动画中的帧)、两个状态之间的长度(延迟)以及状态长度来创建动画。

带 gganimate 的动画虹膜数据集—图片由作者提供

这个软件包的文档非常优秀，因此，如果你想更深入地了解 ggplot2 的动画，请访问https://gganimate.com/

ggplot 主题—为您的绘图添加一些风格

默认情况下 ggplots 看起来很棒，但有时我们希望创建符合某个主题的时尚剧情。以下是 ggplot 扩展的概述，它使您能够轻松地更改默认主题:

考普特

“ cowplot 包是 ggplot 的一个简单附件。它提供了各种有助于创建出版物质量的图形的功能，例如一组主题、对齐图形并将它们排列成复杂复合图形的功能，以及便于注释图形和/或将图形与图像混合的功能。”—来自https://github.com/wilkelab/cowplot

Cowplot 创造了一个看起来很棒的独特的最小视觉化。您可以通过简单地添加 **theme_cowlplot()将任何图转换为 cowplot。**如果你想给主题添加一个网格，你可以使用 theme_minimal_hgrid() 作为水平线。

另请注意，cowplot 包括用于排列图的函数，例如用于创建以下可视化的 plot_grid()函数:

典型的 cowplot 主题—作者图片

ggpubr

“ggpubr”包提供了一些易于使用的功能，用于创建和定制基于“ggplot2”的出版就绪图。—来自https://rpkgs.datanovia.com/ggpubr/

该软件包提供了创建时尚图形的自定义功能，接下来，我想向您展示我最喜欢的三个:

• gg 密度
• ggviolin
• ggdotchart

ggpubr 包中的密度、小提琴和点阵图—图片由作者提供

更多主题

ggplot 主题的世界似乎是无穷无尽的，不可能在本文中介绍所有的主题。然而，如果你没有足够的，这里有几个参考，希望能帮助你找到适合你的主题:

• 可用 ggplot 主题的详细列表:https://yutannihilation . github . io/allyourfigurearebelongtus/1/
• ggtech——包含基于 AirBnb、脸书和谷歌等大型科技公司的主题的包:https://github.com/ricardo-bion/ggtech
• hrbrthemes **-为 gg plot 2:**https://github.com/hrbrmstr/hrbrthemes 提供以排版为中心的主题和主题组件的包
• tvthemes - 根据《辛普森一家》、《权力的游戏》或《海绵宝宝》等人人喜爱的电视剧，收集各种 ggplot 主题:https://github.com/Ryo-N7/tvthemes

更好的情节的相关材料

1gg plot 2 扩展列表:https://exts.ggplot2.tidyverse.org/gallery/

【https://davidgohel.github.io/ggiraph/】用图形创建交互式 ggplots

**【3】**卡森·西沃特，基于网络的交互式数据可视化与 R，plotly，和 shiny:https://plotly-r.com/index.html

吉布斯采样解释

原文：https://towardsdatascience.com/gibbs-sampling-explained-b271f332ed8d?source=collection_archive---------15-----------------------

实践教程

通过视觉化建立直觉

介绍

从政治学到癌症基因组学，马尔可夫链蒙特卡罗(MCMC)已经被证明是各种不同领域统计分析的一个有价值的工具。在高层次上，MCMC 描述了一组迭代算法，这些算法从难以直接采样的分布中获取样本。这些基于马尔可夫链的算法与过去 30 年计算能力的惊人增长相结合，使研究人员能够从极其复杂的理论分布中进行采样。在软件中实现，如 BUGS (使用吉布斯采样的贝叶斯推理)和 JAGS (只是另一个吉布斯采样器)，吉布斯采样是最流行的 MCMC 算法之一，应用于贝叶斯统计、计算语言学等领域。

**在本文中，我们将通过一系列可视化来揭示吉布斯采样的工作原理，**通过一个二元正态目标分布的简单示例进行追踪。

设置问题

假设有一个 m 分量感兴趣的联合分布，很难从中采样。即使我不知道如何从联合分布中抽样，假设我知道如何从完全条件分布中抽样。也就是说，我可以很容易地从 m 个分量的每一个中取样，条件是另一个 m-1。在这些条件下，吉布斯采样基于全条件迭代地更新每个分量，以从联合分布中获得样本。

为了确切了解这是如何工作的，让我们考虑一个简单的例子。假设我只能访问基 R，它可以很容易地对单变量法线进行采样，但不能对多变量法线进行采样。假设目标分布是二元正态分布，其中边际是具有相关性 ρ的标准正态分布。

目标分布

利用多元正态分布的性质，我们得到以下全条件分布。

完全条件分布

由于这些条件只是单变量法线，我可以很容易地从中取样。那么，用于联合分布的吉布斯采样算法将如下:

吉布斯采样算法

这个算法起初看起来有点吓人，所以让我们用一些可视化的方法来分解它。

遍历算法的一次迭代

让我们一步一步地完成吉布斯采样器的第一次迭代，其中 ρ 等于 0.9。

第一步:初始化

这里没什么要做的，将(xₒ，yₒ)初始化为(0，0)并将迭代计数器 t 设置为 0。这是我们最初观点的一个非常无趣的情节。

步骤 1:初始化

步骤 2:给定 Y 的 X 的条件更新

现在，我们从给定 Y 等于 0 的 X 的条件分布中得出。

给定 Y 的 X 的条件更新

在我的模拟中，这个平局的结果是-0.4。这是我们第一次条件更新的图表。请注意，我们新点的 Y 坐标没有改变。

步骤 2:给定 Y 的 X 的条件更新

步骤 3:给定 X，有条件地更新 Y

现在，我们从给定 X 等于-0.4 的 Y 的条件分布中得出。请注意，在进行第 3 步的绘制时，我们使用了刚刚在第 2 步中绘制的 X 值。

给定 X 的 Y 的条件更新

在我们的情况下，这个平局的结果是-0.32。这一次，我们的新点的 X 坐标与步骤 2 中的点的 X 坐标相同。

步骤 3:给定 X 的 Y 的条件更新

第 4 步和第 5 步

增加迭代计数器 t 并返回步骤 2。吉布斯采样器的这个迭代的最终点是(-0.4，-0.32)。我们现在有两个吉布斯样本。一个来自我们的初始化，一个来自我们的第一次迭代。

第 4 步和第 5 步:增量和返回

更多迭代

如果我们继续运行我们的算法(即运行步骤 2 到 5)，我们将继续生成样本。让我们运行迭代 2 和 3，并绘制结果，以确保我们已经得到了模式。

迭代 2 和 3

放下条件更新的中间图，我们可以绘制吉布斯采样器的前 100 次和 10，000 次迭代。

吉布斯采样图，前 100 次迭代

吉布斯采样图，前 10，000 次迭代

上面图上的蓝线是目标二元正态分布的等高线。我们的样本似乎是根据需要从目标分布中抽取的！我们的 Gibbs 抽样器确实从联合分布中提取数据。

注意:为了方便起见，我没有在动画中使用真实的理论密度，而是使用了来自 MASS 包的 100，000 MVN 绘图的经验密度。

总结

本文展示了当我们能够访问完整的条件时，如何使用 Gibbs 抽样从复杂的联合分布中提取数据——从分层贝叶斯建模到计算集成，统计分析中的场景无时无刻不在出现。通过追踪一个二元正态目标分布的例子，我们对 Gibbs 抽样实际上是如何工作的建立了直觉。

延伸阅读:

1马克林，科里。“吉布斯采样”中【2020 年 10 月 2 日【https://towardsdatascience.com/gibbs-sampling-8e4844560ae5】T4。

【2】马尔可夫链蒙特卡罗(MCMC)抽样介绍，第二部分:吉布斯抽样。https://www.tweag.io/blog/2020-01-09-mcmc-intro2/。2021 年 5 月 23 日访问。

来源:

鸣谢:这篇文章的想法来自于我辅导哈佛统计学课程“Stat 171:随机过程介绍”我的学生让我帮助他们理解多布罗书中的例子 5.6，所以我创建了这篇文章中的 R 脚本。我为本文创建的算法和采样器来自 Dobrow 的例子。

长颈鹿:仔细看看 CVPR 2021 最佳论文的代码

原文：https://towardsdatascience.com/giraffe-a-closer-look-at-cvpr-2021s-best-paper-1ec81f593fa9?source=collection_archive---------12-----------------------

GIRAFFE 是一个基于学习的、完全可区分的渲染引擎，用于将场景合成为多个“特征字段”的总和

使用 GIRAFFE 旋转和平移 GAN 生成的汽车(作者使用https://github.com/autonomousvision/giraffe创建，麻省理工学院许可)。

CVPR 2021 已经结束了，多么棒的论文选择！深度学习继续主导计算机视觉领域，有 SLAM、姿势估计、深度估计、新数据集、GANs 的新方法，以及对去年的神经辐射场 [ 1 ]，或 NeRFs 的许多改进，仅举几例。

到现在为止，你可能已经听说过一篇名为“长颈鹿:将场景表示为合成生成神经特征场的论文。 [ 2 ]“这篇论文获得了今年最佳论文奖的大奖，它将 GANs、NeRFs 和可微分渲染结合在一起，生成了新颖的图像。然而，更重要的是，它提供了一个模块化的框架，以完全可区分和可学习的方式从对象构建和合成 3D 场景，让我们更接近神经 3D 设计的世界。在这篇文章中，我仔细查看了长颈鹿的源代码，并生成了一些快速的可视化示例。

神经辐射场

NeRF (YouTube)的可视化解释和演示。

简要回顾一下 NeRFs ，它们是一种根据 3D 体积中任何给定点的密度和亮度来描述和渲染 3D 场景的方法。它与光场的概念密切相关，光场是表达光如何穿过给定空间的函数。对于空间中给定的 (x，y，z) 视点，图片将方向为 (θ，φ) 的光线投射到场景中。对于沿着这条线的每个点，我们收集它的密度和视点相关的发射辐射，并以类似于传统光线追踪的方式将这些光线合成为单个像素值。这些 NeRF 场景是从各种姿势拍摄的图像集合中学习来的，就像你在结构来自运动应用中使用的那样。

长颈鹿

长颈鹿的视觉解释和演示(YouTube)。

概观

本质上，GIRAFFE 是一个基于学习的完全可区分的渲染引擎，它允许您将场景合成为多个“特征场”的总和，这是 NeRFs 中辐射场的概括。这些特征场是 3D 体积，其中每个体素包含一个特征向量。通过合成由接受潜在代码作为 3D 场景输入的 GANs 产生的学习表示来构建特征场。由于特征字段应用于 3D 体积，因此您可以应用相似性变换，如旋转、平移和缩放。您甚至可以将整个场景合成为单个特征字段的总和。该方法对 NeRFs 进行了以下改进:

• 可以用独立的变换表示多个对象(和一个背景)(最初的 NeRF 只能支持一个“场景”,不能分解单个对象)。
• 可以对单个对象应用姿势和相似性变换，如旋转、平移和缩放。
• 产生特征字段的 gan 可以独立学习并像组件一样重用。
• 拥有经过端到端培训的独特渲染引擎。
• 颜色值不仅仅支持 RGB，还可以扩展到其他材质属性。
• 使用位置编码(如转换器)来编码位置，这也“引入了感应偏差来学习规范方向上的 3D 形状表示，否则这些表示将是任意的。”

长颈鹿项目包括源代码，你可以用它来复制它们的形象，甚至组成你自己的场景。我简要介绍了它们的源代码，并展示了我们如何使用 GIRAFFE 来构建一些简单的神经 3D 场景。

源代码

GIRAFFE repo的结构考虑了配置。configs/default.yaml文件指定了应用程序的默认配置。其他配置文件如configs/256res/cars_256/pretrained.yaml使用inherit_from键继承这个配置文件，并通过指定其他键-值对覆盖默认值。这使我们能够用python render.py <CONFIG.yaml>渲染图像，用python train.py <CONFIG.yaml>通过自文档化的配置文件进行训练，而不是编写输入参数。

要自己尝试一些渲染，首先运行README.md文件中的快速启动指令。这将下载一个预训练的模型，并将一系列输出可视化(如下图所示)写入文件夹out。

对象随 Cars 数据集旋转(由作者使用https://github.com/autonomousvision/giraffe，麻省理工学院许可创建)。

配置文件只是采用默认值，并在 Cars 数据集上插入一个预训练模型。它提供了很多可视化的方法来操作底层渲染，比如外观插值、形状插值、背景插值、旋转和平移。这些可视化在render_program键下的configs/default.yaml中指定，其值是指定这些可视化的字符串列表。这些指定了长颈鹿渲染器在调用render.py时将调用的“渲染程序”。在im2scene.giraffe.rendering.Renderer的render_full_visualization方法中，你会看到一系列的if语句，寻找更多渲染程序的名字，比如‘object _ translation _ circle’、‘render _ camera _ elevation’和‘render _ add _ cars’。

为什么我们不试试这些呢？创建一个名为cars_256_pretrained_more.yaml的新配置文件，并添加以下内容:

这只是我们用默认配置文件的render_program键使用的先前的配置文件，它被我们想要的新渲染程序覆盖了。现在执行python render.py configs/256res/cars_256_pretrained_more.yaml来产生更多的可视化效果。您应该会得到这样的结果:

Cars 数据集的摄像机仰角。请注意相机视角在背景和汽车侧面上是如何变化的，就好像相机从上向下绕着汽车旋转一样(作者使用https://github.com/autonomousvision/giraffe，麻省理工学院许可创建)。

…还有这个:

使用汽车数据集添加汽车(由作者使用https://github.com/autonomousvision/giraffe，麻省理工学院许可创建)。

这些渲染程序实际上是如何放置、平移和旋转这些汽车的？要回答这个问题，我们需要仔细看看Renderer类。对于上面的'object_rotation'示例，调用了Renderer.render_object_rotation方法。

该函数为给定批次的成员生成一系列旋转矩阵r。然后，它迭代地将这个范围的成员(以及一些默认的缩放和平移)传递给生成器网络的forward方法，该方法由default.yaml中的generator键指定。如果你现在看im2scene.giraffe.models.__init__.py，你会看到这个键映射到im2scene.giraffe.models.generator.Generator。

现在，在我们看Generator.forward的时候，请耐心等待。它接受各种可选的输入参数，比如transformations、bg_rotation和camera_matrices，然后将它们传递给它的volume_render_image方法。这里是合成魔法发生的地方。场景中所有物体的潜在代码，包括我们的背景，被分离成它们的形状和外观部分。

在本例中，这些潜在代码是使用torch.randn函数随机生成的:

这是解码器正向传递将 3D 点和摄像机观察方向映射到每个对象的和 RGB(特征)值的地方。一个不同的发生器被应用于背景(为了可读性，省略了细节)。

然后，这些图由 σ max 或使用composite_function的平均值合成。

最后，通过沿着射线向量用 σ 体积对特征图进行加权来创建最终图像。最终结果是你在上面看到的那些动画之一的单个窗口中的单个帧(关于如何构造di和ray_vector的细节，见generator.py)。

现在总结一下，让我们试着创建自己的渲染程序。这个将简单地结合深度平移和旋转来创建一个汽车从左向右旋转和滑动的效果。为此，我们对rendering.py中的Renderer类做了一些简单的添加。

将这些添加内容复制粘贴到rendering.py中，然后创建如下配置文件configs/256res/cars_256_pretrained_wipeout.yaml:

现在，如果您执行python render.py configs/256res/cars_256_pretrained_wipeout.yaml,您应该能够产生如下所示的结果:

对象与汽车数据集“相消”。注意汽车从左向右移动时是如何旋转的(作者使用https://github.com/autonomousvision/giraffe，麻省理工学院许可创建)。

结论

长颈鹿是最近对神经纤维和甘的大量研究中令人兴奋的新发现。辐射场表示描述了一个强大且可扩展的框架，利用该框架我们可以以可区分且可学习的方式构建 3D 场景。我希望对代码的深入研究对您有所帮助。如果是这样的话，我鼓励你自己去看一看源代码和作者的论文。

参考

1 Ben Mildenhall，Pratul P. Srinivasan，Matthew Tancik，Jonathan T. Barron，Ravi Ramamoorthi，Ren Ng — NeRF:将场景表示为用于视图合成的神经辐射场(2020) ，ECCV 2020

[2] Michael Niemeyer，Andreas Geiger — 长颈鹿:将场景表示为合成生成神经特征场(2021) ，CVPR 2021

GIS tyc——基于 Python 的 GitHub GIST 管理工具包

原文：https://towardsdatascience.com/gistyc-a-python-based-github-gist-management-toolkit-ee507d5a0e7b?source=collection_archive---------33-----------------------

小窍门

GitHub GISTs 是在介质上显示代码片段的完美方式。但是，如何以可行的方式创建、更新和删除 GISTs，并将这样的过程集成到 CI/CD 管道中呢？

照片由rich Great在 Unsplash 上拍摄

使用 GISTs

媒体已经成为各种文章的重要来源。这还包括涵盖数据科学或机器学习主题的编程教程。但是覆盖实际的编码部分需要一样东西:适当的格式和编程语言依赖的颜色突出。有时人们会看到以下格式的代码片段:

# Import standard module
import time# Print the current Unix Time
print(time.time())

…这种格式对于几行代码来说完全没问题，但是用这些灰色的块来覆盖整个教程会让人读起来很累。相反，大多数 Medium 上的作者使用 GitHub GIST 。GitHub 提供了一个创建要点的简单链接，允许用户在介质上显示正确格式化的代码。以下要点…

要点示例

…只需在 Medium 文本编辑器中添加以下链接即可(灰色块样式阻止 Medium 正确格式化要点):

[https://gist.github.com/ThomasAlbin/1b42f2fbe6470ae54286b83b57f5acd6](https://gist.github.com/ThomasAlbin/1b42f2fbe6470ae54286b83b57f5acd6)

由 Finn Whelen 在 Unsplash 上拍摄的照片

维护要点的问题是

Medium 有数百甚至数千篇文章，涵盖了编程相关的主题。但是，旧的文章可能会引用已经过时的库和更新的工具，它们的功能发生了变化。结果是一些显示的要点代码片段不再工作了。提出的异常、警告和错误结果会抑制阅读有希望的标题或摘要后的兴奋感。考虑到作者对代码进行了测试，并且审阅者或编辑对文章进行了彻底的检查，我们只能假设最近的文章工作正常。

但是一个人(例如，一篇文章的作者)如何保持要点的更新呢？手动编辑大量的 GISTs 既乏味又麻烦。还有一个 GitHub GIST REST API ，但是有一个简单的解决方案会更好。

为此，我开发了一个具有 CLI 功能的基于 Python 的工具包，我想在这里介绍一下: gistyc 。 GISTsyc 应使用户能够从外壳或 Python 程序中创建、更新和删除 gist。它的功能、特性和 GitHub 动作集成(新的 GIST 代码的持续部署)是本文的一部分。

https://github.com/ThomasAlbin/gistyc

总的来说，gistyc 很容易理解。让我们举个例子:

• 您有一个想要向全世界展示的 Python 文件！就叫牛逼吧. py。
• awesome.py 要在一篇中等文章里详细解释。这个文件很大，有 200 多行代码。一个要点对于一篇教程文章来说太大了。
• 无论如何，你可以简单地将你的代码分割成单独的要点或者要点中的“子部分”。手动完成这个过程是乏味的…如果你以后需要更新它，由于一些读者抱怨错误，它变得更糟…
• awesome.py 具有专用的“编码块”，例如由“# % %”(Spyder-way)分隔。这些单元格应该是你想要显示的要点部分。
• 现在是GIS tyc:GIS tyc获取你的文件，将它分割成单独的部分(取决于代码块分隔符)并自动创建要点。如果你已经有了一个名为“awesome.py”的要点， gistyc 会相应地更新要点！第一个 GIST 代码-cell 的名称是“awesome.py”，第二个得到后缀“_1”，导致“awesome_1.py”等等。稍后你会看到一个例子。
• 您更新的要点会自动与您的中型文章同步，您就大功告成了！

这里只涉及几个陷阱:

1. 您应该坚持在您的 GIST 存储库中使用唯一的文件名(否则 gistyc 会与不明确的名称混淆并返回一个错误)。
2. 您还应该坚持代码单元格分隔。只编辑错误或异常，但不要改变代码的逻辑！否则你的中型文章不符合代码和你的读者越来越困惑后，你更新它！

先决条件和安装

在我们深入研究 gistyc 之前，我们需要满足一些先决条件才能使用它的全部特性列表。除了安装 Python，你还需要一个 GitHub 帐户来创建和存储 GISTs。之后，你只需要遵循这三个步骤:

1. 安装 Python ≥3.8(建议:使用虚拟环境)
2. 您需要一个 GitHub 个人访问令牌和 GIST 访问:

• 点击您的个人账户资料(右上角)
• 点击设置
• 在左侧菜单栏中，进入开发者设置，选择个人访问令牌
• 生成新的令牌并写下您的令牌的名称(注释)。注释不影响功能，但选择描述令牌用途的注释，例如 GIST_token
• 在要点 ( 创建要点)处设置一个标记，并点击页面底部的生成令牌
• 重要提示:显示的令牌只出现一次。将其复制并作为一个秘密存储在 GitHub 项目中和/或作为一个环境变量存储在本地。

3.通过以下方式安装 gistyc :

pip install gistyc

或者，可以随意下载库来下载和使用所提供的测试。

现在我们准备和吉斯泰克一起工作。以下部分描述了 Python 函数调用，第二部分概述了对 CD 管道更感兴趣的 CLI 功能！

Python 要点准备

请注意:当前版本仍处于测试阶段，仅适用于 Python(。py)文件。将来会有更新来涵盖更多的通用解决方案。

为了测试或使用 gistyc 在我们的设备上准备一个简单的 Python 文件。结局还得是*。py* 。

此外，要点可以被分成几个文件。这可能有助于将您想要一步一步解释的较大的教程脚本分割开来。下面的例子(我们将在后面更详细地讨论这个例子)给你一个印象，它意味着什么:

看一看 gistyc 提供的示例脚本:示例脚本

作为一个单独的要点，脚本存储在…

[https://gist.github.com/ThomasAlbin/77974cc3e14b2de8caba007dfa3fccf9](https://gist.github.com/ThomasAlbin/77974cc3e14b2de8caba007dfa3fccf9)

…格式为:

另一个 GIST 示例名为“gistyc_example2.py”

如你所见，提供了 Spyder 代码块分隔符“#%%”。gistyc 识别这些代码分隔符，并在单个 GIST 中创建单独的文件(或“子 GIST”)。分隔符可以由用户设置，但在本文中，我们将坚持 Spyder 风格。

以上示例是 gistyc 官方 GIST 示例的一部分，可在以下位置找到:

[https://gist.github.com/ThomasAlbin/caddb300ac663e60ae573b1117599fcc](https://gist.github.com/ThomasAlbin/caddb300ac663e60ae573b1117599fcc)

此外，这三个独立的块可以通过以下方式调用:

1.第一代码单元

[https://gist.github.com/ThomasAlbin/caddb300ac663e60ae573b1117599fcc?file=gistyc_example2.py](https://gist.github.com/ThomasAlbin/caddb300ac663e60ae573b1117599fcc?file=gistyc_example2.py)

gistyc_example2.py 的第 1 部分—通过https://gist . github . com/Thomas Albin/caddb 300 AC 663 e 60 AE 573 b 1117599 FCC 调用？file=gistyc_example2.py

2.第二代码单元

[https://gist.github.com/ThomasAlbin/caddb300ac663e60ae573b1117599fcc?file=gistyc_example2_1.py](https://gist.github.com/ThomasAlbin/caddb300ac663e60ae573b1117599fcc?file=gistyc_example2.py)

gistyc_example2.py 的第二部分—通过调用 https://gist . github . com/Thomas Albin/caddb 300 AC 663 e 60 AE 573 b 1117599 FCC？file=gistyc_example2_1.py

3.第三代码单元

[https://gist.github.com/ThomasAlbin/caddb300ac663e60ae573b1117599fcc?file=gistyc_example2_2.py](https://gist.github.com/ThomasAlbin/caddb300ac663e60ae573b1117599fcc?file=gistyc_example2_2.py)

gistyc_example2.py 的第三部分—通过调用 https://gist . github . com/Thomas Albin/caddb 300 AC 663 e 60 AE 573 b 1117599 FCC？file=gistyc_example2_2.py

总体而言，用户的(用户 ) GIST 及其值( GIST_VALUE )和相应的文件名( GIST_NAME )以及后缀依赖子节( ID )具有以下结构:

https://gist.github.com/USER/GIST_VALUE?fileGIST_NAME_ID.py

David Clode 在 Unsplash 上拍摄的照片

Python 中的 gistyc

Python API 目前提供 4 个通用函数来创建、更新和删除 GIST。此外，它允许用户获得所有可用 gist 的当前列表。

我们有以下参数:

• AUTH_TOKEN:是 GIST 访问令牌(字符串)
• FILEPATH:是 Python 文件的绝对或相对路径(string 或 pathlib。路径
• 要点 ID:要点(字符串)的 ID*。我们一会儿会谈到这个参数*

创建一个要点

基本上所有的 gistyc 调用都是从同样的两行代码开始的:首先是库的表面导入，其次是 gistyc 类的实例化(第 5 行)。这个类只需要 GIST 身份验证令牌。返回的类，这里命名为 gist_api ，然后用于调用相关的方法。

以下示例显示了如何创建要点。该类调用方法 create_gist ，其输入是文件路径。返回值( response_data )是来自 GitHub 服务器的回调 JSON，包含新创建的 GIST 的元信息(如时间戳、GIST 的 ID 等)。).

使用 gistyc Python API 创建 GIST

更新要点

有两种方法可以更新要点。首先，让我们假设所有的要点名称都是唯一的，不会重复。

同样，我们创建了这个类(第 5 行)并在第 8 行调用了方法 update_gist ,这里我们只是提供了文件路径作为输入。返回的 JSON 提供回调信息。

使用 gistyc Python API 更新 GIST(仅使用 Python 文件的文件路径)

然而，让我们假设你有几个同名的 gist***(顺便说一下:为了保持整洁，避免重复/同名的 gist！)*** 。如果只使用文件名调用更新函数，就会引发一个异常(我称之为 AmbiguityError)。在这种情况下，你还需要知道你要点的要点 ID。然后，您可以通过以下方式更新您的要点:

使用 gistyc Python API 更新 GIST(仅使用 Python 文件的文件路径和相应的 GIST ID)

获取所有 GISTs

有时候知道你所有的要点是有用的，尤其是当你有上百个要点的时候。在一个单独的数据库中维护它们或者手动获取所有的 GIST IDs 可能会令人精疲力尽…

为此，实现了 get_gists 方法，该方法通过所有的 GIST 页面调用 REST API，并将所有结果附加到最终列表中。每个元素都是一个 JSON 元素，代表一个要点。

使用 gistyc Python API 获得所有 GitHub GISTs 的列表

删除要点

最后，我们来看看如何删除一个要点。该过程类似于更新例程。如果您有具有唯一文件名的 GISTs，那么 FILEPATH 是唯一需要的输入参数…

使用 gistyc Python API 删除 GIST(仅使用 Python 文件的文件路径)

…否则，您需要提供一个要点 ID:

使用 gistyc Python API 删除 GIST(仅使用 GIST_ID)

gistyc 作为 CLI

使用 click 可以创建基于 Python 的 CLI 工具，可以从 shell 中直接调用这些工具。gistyc 也具有部分基于上述功能的 CLI 功能。

我们有以下参数:

• AUTH_TOKEN:是 GIST 访问令牌(字符串)
• FILEPATH:是 Python 文件(字符串)的绝对或相对路径
• GIST _ ID:GIST(字符串)的 ID

请注意:代码单元格分隔符必须是“#%%”。CLI 的分隔符输入参数将跟在后面。

创造一个要点

首先， gistyc 需要一个标记来指示所需的功能(创建、更新、删除),后跟输入参数。所有 CLI 调用都需要一个允许更改要点的身份验证令牌。

下面的 bash 片段基于 FILEPATH 创建了一个 GIST。

gistyc --create --auth-token AUTH_TOKEN --file-name FILEPATH

更新要点

类似地，如前所示，我们有一个 CLI 调用来基于文件名称更新 GIST，并且…

gistyc --update --auth-token AUTH_TOKEN --file-name FILEPATH

…如果文件名不唯一，则带有相应的 GIST ID:

gistyc --update --auth-token AUTH_TOKEN --file-name FILEPATH --gist-id GIST_ID

删除要点

类似地，可以通过 CLI 删除 GISTs 通过提供文件名…

gistyc --delete --auth-token AUTH_TOKEN --file-name FILEPATH

…或要点 ID:

gistyc --delete --auth-token AUTH_TOKEN --gist-id GIST_ID

gistyc 目录 CLI

为单个文件调用 gistyc CLI 是管理您的 GISTs 的一种快速可行的方法。然而，让我们假设您有一个更大的教程系列，包含几十个 Python 脚本和数百个代码单元。多次调用 gistyc 或者用几十个 gistyc 调用创建一个 bash 脚本可能会变得令人困惑。

为此，已经实现了第二个基于 gistyc 的 CLI:GIS tyc _ dir。

我们假设您将所有 Python 文件存储在一个名为 directory 的目录中。现在，您需要创建和/或更新所有相应的 GISTs。您只需拨打:

gistyc_dir --auth-token AUTH_TOKEN --directory DIRECTORY

请注意:文件名在 GIST repo 中必须是唯一的，因为这里不能提供 GIST ID。此外，您的文件也可以存储在子目录中。 gistyc_dir 递归搜索目录以找到所有 Python 文件。

调用 GISTsyc_dir 后，新的 GISTs 被创建，现有的 gist 也被创建！

Yancy Min 在 Unsplash 上拍照

CI/CD 中的 gistyc

gistyc 的 CLI 功能和 gistyc_dir 提供的目录功能是将其集成到类似 CI/CD 的管道中的良好基础。什么时候，为什么要为 GISTs 创造这样一个管道？

让我们考虑下面的例子:

• 您有一个主要的中型教程项目，其中涵盖了许多您希望存储在 GitHub GIST 上的 Python 示例。
• 所有 Python 脚本都存储在一个名为的目录下的相应 GitHub 存储库中。/例/ 。
• 每次你在上传新的脚本。/examples/ (例如，通过 Pull 请求并合并到主分支)应自动创建新的 GISTs。
• 此外，Pull 请求还可能包含一些读者已经解决的示例脚本的更正和错误修复。同样在这种情况下:您将您的更改合并到主分支中，管道会相应地自动更新相应的 GISTs。无需在繁琐的手动过程中更新 GISTs。

在 GitHub 上，CI/CD 管道被称为动作。管道逻辑存储在 YAML 文件中。下面的 YAML 文件展示了我的 gistyc GitHub 库中提供的一个例子。看一看【行动】，。github/workflow 目录和*。/examples/* 目录，以便更好地了解这个工作流是如何工作的。每次我在里改变一些东西。/examples/ ，创建一个 Pull 请求，最后合并到主分支，所有代码部分来自*。/examples/* 创建新的 GISTs 或相应地更新现有的 GISTs。

YAML gist-push.yml 如下所示，工作方式如下:

第 8–11 行:如果中有任何内容。/examples/ 文件夹发生变化，动作正在执行。

第 14–19 行:管道进一步检查主分支上是否已经执行了更改。我们不想更新来自另一个未审查或未测试分支的 GISTs。

第 21–36 行:GitHub 准备环境，其中…

第 37–38 行:… gistyc 正在安装(这里， gistyc 是从 pypi 安装的)

第 39–40 行:现在 gistyc_dir 被应用到上。/examples/ 文件夹。创建新的 GISTs，并更新现有的 GISTs。

gist-push.yml

这个 YAML 文件可以适用于任何其他 GitHub 存储的项目。您需要设置一个包含 GIST 标记的项目密码。此外，您还可以添加更多功能，例如，使用pytest测试您的 Python 脚本。现在，在成功合并到主分支之后，您就可以自动创建和/或更新 GISTs 了。也可以随意更改示例目录。

进一步的支持和想法

官方的 gistyc 库提供了一个示例目录和所示的 GitHub 动作 YAML 文件。如果您需要任何帮助或有任何想法，请使用 GitHub 问题页面，在本文下方写下评论或在 Twitter 上给我发消息。

贡献

另外，随时欢迎投稿！需要做一些事情，比如 CLI 的代码块分隔参数，或者替换“ gistyc 只考虑 Python 文件”——这是一个更通用的解决方案的功能。

请从一开始就为每个功能或测试驱动开发(TDD)风格的工作添加测试。严格执行 PEP8 标准、静态类型和其他要求，并对每个拉取请求进行检查。所有测试项目的列表可以在YAML 文件中找到。相应的配置文件存储在存储库的根目录中。

现在，我祝大家编码愉快。我期待您的评论和反馈，

托马斯

数据运营—为数据工程师和科学家提供 Git 行动和平台— GCP/AWS/Azure

原文：https://towardsdatascience.com/git-actions-terraform-for-data-engineers-scientists-gcp-aws-azure-448dc7c60fcc?source=collection_archive---------14-----------------------

在接下来的 10 分钟内，您将学到一些东西，从而丰富您的数据之旅。有了这个职位，数据工程师和科学家可以轻松地 CICD 基础设施。

我坚信，在 POC 一个新的设计或代码模板，并得到其他工程师的审查，因为你永远不知道你错过了什么有效的细微差别，它总是好的有一套新的眼睛审查代码。我倾向于使 POC 尽可能接近 MVP(最小可行产品),以使我自己和团队对设计更有信心，并且不会在以后的回归测试中浪费任何时间。这也有助于更好、更准确地评估我的交付任务。但是当我不得不依赖 DevOps 团队在开发环境中‘基础设施即代码’(IAC)我的项目时，问题就出现了。在生产环境中，最好让他们参与到基于他们所学的最佳实践的基础架构开发中，但是在开发环境中，只需等待他们对您的任务进行优先级排序，就可以让您的 MVP 脱轨。

因此，几年前我开始学习 DevOps/DataOps，并从 Cloudformation (CFN)和 Atlassian Bamboo 开始，因为我主要从事 AWS 工作，该组织正在使用 Bamboo。但是最近，我有机会接触 Terraform (TF)和 Github Actions，因为我被要求在 GCP 上工作，亲爱的，哦，亲爱的，它太容易掌握和学习了，因为有了 TF 和 Actions，你可以在任何云中部署。对于数据工程师、科学家或分析师来说，如果您知道 IAC 工具，它会变得非常方便。由于 Github 动作离你的代码更近，对我来说变得更加方便。

因此，我将把它分成三个简单的部分:

1. 将 TF cloud 集成到 Github
2. 运行 TF 步骤的 Github 操作工作流
3. 基于最佳实践的 TF 文件概述

将 Terraform 云集成到 Github

首先，TF 有一个社区版本，所以继续在那里创建一个帐户。下面是链接:【https://www.terraform.io/cloud。它会要求您确认您的电子邮件地址和一切，所以我假设这一步结束时已经完成。此外，为了完成这些步骤，如果您在 GCP 或任何云中有自己的帐户，那就太好了。还有你自己的 Github 账号。

步骤 2: TF 有其层次结构，其中每个组织有多个工作区，每个工作区与 repo 中的 IAC Github 分支有一对一的映射，您将在其中推送更新的 Terraform 文件(最佳实践)。文件是用哈希公司的配置语言(HCL)编写的，这有点类似于 YAML。因此，这个想法是，每当你将一个新的更新(或合并一个 PR)推送到 Github 分支时，Github-actions 将在 TF cloud 上执行并运行带有新变更集的计划。由于 TF cloud 链接到 GCP(稍后)，它将更新 GCP 的资源。

CICD 工艺流程

在您的 Terraform 社区帐户中创建一个组织和其中的工作空间。

**第三步:**假设您有自己的 GCP 帐户，在您希望部署资源的项目中创建一个服务帐户，复制它的密钥并将其作为 GOOGLE_CREDENTIALS 放入环境变量 Terraform 变量中。如果您使用 AWS，那么您需要输入 AWS_ACCESS_KEY_ID 和 AWS_SECRET_ACCESS_KEY。

此变量包含 JSON 中服务帐户机密的内容

此 GCP 服务帐户将用于部署资源，因此它应该具有编辑角色或有权部署资源的访问级别。

您也可以在 Github secrets 中创建一个秘密，如下所示，并使用${{ secrets 从那里传递凭证。Github 中的 GOOGLE_CREDENTIALS }}操作如下。

步骤 4: 在创建工作空间时，它会让你选择 github repo，这样它就可以在内部进行身份验证，否则你必须在 Terraform 中生成一个令牌，并将其保存在 Github secrets 中，以便在 Github actions 中的’ Setup Terraform’ 步骤中使用。

通过选择其中的任何一个，它将在需要时自动进行身份验证

运行 TF 步骤的 Github 操作工作流

需要放入以下 Github 操作脚本。github/workflow/ folder 作为 anyname.yml。这是一个特定作业中的连续步骤，当有人在 repo 中推出新的更改时该做什么。下面，github actions 将使用 ubuntu-latest 中的 bash 来检查代码、设置 terraform 并运行 terraform init、plan 和 apply。

name: 'Terraform CI'on:
  push:
    branches:
    - main
  pull_request:jobs:
  terraform:
    name: 'Terraform'
    runs-on: ubuntu-latest# Use the Bash shell regardless whether the GitHub Actions runner is ubuntu-latest, macos-latest, or windows-latest
    defaults:
      run:
        shell: bashsteps:
    # Checkout the repository to the GitHub Actions runner
    - name: Checkout
      uses: actions/checkout@v2# Install the latest version of Terraform CLI and configure the Terraform CLI configuration file with a Terraform Cloud user API token
    - name: Setup Terraform
      uses: hashicorp/setup-terraform@v1# Initialize a new or existing Terraform working directory by creating initial files, loading any remote state, downloading modules, etc.
    - name: Terraform Init
      run: terraform init
      env:
        GOOGLE_CREDENTIALS: ${{ secrets.GOOGLE_CREDENTIALS }}# Checks that all Terraform configuration files adhere to a canonical format
#    - name: Terraform Format
#      run: terraform fmt -check# Generates an execution plan for Terraform
    - name: Terraform Plan
      run: terraform plan
      env:
        GOOGLE_CREDENTIALS: ${{ secrets.GOOGLE_CREDENTIALS }}# On push to main, build or change infrastructure according to Terraform configuration files # && github.event_name == 'push'
      # Note: It is recommended to set up a required "strict" status check in your repository for "Terraform Cloud". See the documentation on "strict" required status checks for more information: [https://help.github.com/en/github/administering-a-repository/types-of-required-status-checks](https://help.github.com/en/github/administering-a-repository/types-of-required-status-checks)
    - name: Terraform Apply
      if: github.ref == 'refs/heads/master'
      run: terraform apply -auto-approve
      env:
        GOOGLE_CREDENTIALS: ${{ secrets.GOOGLE_CREDENTIALS }}

Terraform 文件概述

现在 terraform 只读取那些有。tf 扩展到它或。但是有一些文件需要按原样命名，而其他文件只是资源抽象，将按无序执行，除非您使用 depends_on 提到依赖关系。Main.tf、variables.tf 和 terraform.tfvars 是需要创建的同名文件。

数据工程项目的地形文件

main.tf:所有的资源及其适当的配置值都可以在这里提到。例如，如果您想要创建一个存储桶，则可以用 HCL 编写，如下所示:

resource “google_storage_bucket” “bucket” { 
    name = “dev-bucket-random-12345”
}

variables.tf:顾名思义，它有如下带有默认值的变量，您希望在其他资源或。类似 *${var.region}的 tf 文件。*这更像是把变量放在不同的 variables.tf 文件中的惯例，但是你也可以把它放在 main.tf 中。

variable “region” { 
    type = string 
    default = “australia-southeast1”
}

terraform.tfvars:这将包含上面定义的变量的实际值。本质上，如果下面没有提到 region，那么它将采用上面的默认值。

project_id = “bstate-xxxx-yyyy”
region = “australia-southeast1”

其余的文件将不同类型的资源抽象到不同的文件中。例如，networks.tf 将拥有 VPC 和子网资源，stackdriver.tf 将拥有警报和监控仪表板，dataproc.tf 将拥有集群和节点资源，类似的还有防火墙、GKE 等。

对于那些不知道的人，TF 和 CFN 都有文档，这些预定义的功能或资源配置可以帮助我们理解选项的含义。以下是 GCP:https://registry . terraform . io/providers/hashi corp/Google/latest/docs

示例监控通道

在以下示例中，为 Stackdriver 警报创建了一个监视通道。所有字段都是自解释的，来自 GCP Terraform 文档，在输出变量“gsingh_id”的帮助下，您可以在任何中直接使用它。tf 文件或者不想指定输出，可以直接这样用:Google _ monitoring _ notification _ channel . gsingh

resource "google_monitoring_notification_channel" "gsingh" {
  display_name = "xxxx@yyyy.com"
  type = "email"
  labels = {
    email_address = "xxxx@yyyy.com"
  }
}

output "gsingh_id" {
  value = "${google_monitoring_notification_channel.gsingh.name}"
}

下面创建了一个子网，VPC 以类似的方式被指定为该子网的依赖项。

resource "google_compute_subnetwork" "vpc_subnetwork" {
  name          = "subnet-01"
  network       = google_compute_network.vpc_network.self_link
  private_ip_google_access = true
  ip_cidr_range = "10.xx.xx.xx/19"
  region        = "australia-southeast1"
  depends_on = [
    google_compute_network.vpc_network,
  ]
}

结论

如前所述，每当您向这个 repo 推送新的变更时，Git actions 将从主分支签出代码，并运行 Terraform Init、Plan 和 Apply 以在云中部署变更。在接下来的几天里，我将发表一系列文章，介绍如何通过 Git 操作在 GKE 集群上部署 Flink 应用程序，这也将让您了解如何使用 Git 操作构建 Scala 应用程序。敬请关注。

面向数据科学家的 Git 和 GitHub 基础知识

原文：https://towardsdatascience.com/git-and-github-basics-for-data-scientists-b9fd96f8a02a?source=collection_archive---------3-----------------------

UCL 数据科学研讨会 8:什么是 Git，创建本地存储库，提交第一批文件，链接到远程存储库

照片由扬西·敏在 Unsplash 上拍摄

今年，作为 UCL 数据科学学会的科学负责人，该学会将在整个学年举办一系列 20 场研讨会，涵盖的主题包括数据科学家工具包 Python 和机器学习方法简介。每一篇文章的目标都是创建一系列的小博客，这些小博客将概述要点，并为任何希望跟进的人提供完整研讨会的链接。所有这些都可以在我们的 GitHub 资源库中找到，并将在全年更新新的研讨会和挑战。

本系列的第八个研讨会是 Git 和 GitHub 简介，我们将介绍什么是 Git 和 GitHub，创建您的第一个存储库，进行第一次提交，然后将其链接到远程存储库。关于分支、秘密文件和返回到先前提交的更多细节也可以在我们的 GitHub 页面上找到。

如果您错过了我们之前的任何研讨会，您可以在以下链接中找到最后三个:

Git 是什么，为什么？

据 Git 网站报道:

Git 是一款 免费开源 分布式版本控制系统，旨在快速高效地处理从小到大的各种项目。

包括:

• 充当工业生产标准
• 在黑客马拉松中使用
• 用于写书
• 用于保存讲义和实用笔记
• 任何其他用途…

Git 本身与 GitHub 的区别在于，Git 是一个管理项目版本控制的系统，而 GitHub 是一个使用 Git 托管项目的远程平台。这意味着，虽然可以使用 Git 系统，但不一定必须使用 GitHub，除非您希望在另一个平台上备份您的存储库。

你的第一个 Git 回购

为了与 Git 和 GitHub 进行交互，我们将不再使用我们已经拥有的 Jupyter 笔记本，而是使用命令线/终端进行交互。为此，特别是与 GitHub 操作相关的，我倾向于使用 GitBash，它允许我与 GitHub 很好很容易地交互，但是你可以在 Mac 上使用你自己的术语，或者在 Windows 上使用 Bash。

为了创建项目，我们需要为您的项目创建一个目录/文件夹。在命令行中，我们可以使用mkdir命令，后跟文件夹的名称，这将在您的机器上创建一个文件夹。

 mkdir my-novel

然后，我们使用cd命令通过命令行导航到该文件夹，这将允许我们按如下方式更改目录:

cd my-novel

一旦我们进入那个目录，我们就可以用 Git 初始化项目，这样 Git 就可以使用git init命令来管理项目的版本:

git init

现在，您的目录中应该有一个.git文件夹，它现在应该是不可见的。您刚刚创建的项目应该被称为本地工作区。

承诺回购

当然，现在我们已经创建了存储库，然后我们需要实际填充它！我们可以继续使用命令行创建我们小说的开头，使用nano命令打开一个文本编辑器开始创建一个文件。在我们的例子中，我们可以将这个 intro.txt 称为:

nano intro.txt

你可以继续写你自己的小说介绍。完成后，您可以使用命令ctrl o保存文件，然后使用ctrl x退出文件。

在我们提交我们的变更之前，为了确保我们在最初的工作过程中有一个记录，我们需要将我们的变更添加到阶段中(或者称为阶段化变更)。这是使用git add命令完成的，通过该命令，您可以指定您想要添加的文件名，也可以使用.来指定任何更改，如下所示:

git add intro.txt

然后，我们可以使用status命令检查我们的阶段，如下所示:

git status

我们将会看到

On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

	new file:   intro.txt

对我们来说关键的事情是，这告诉我们有新的文件intro.txt要提交，但是到目前为止我们还没有提交。

记住这一点，然后我们可以使用commit命令提交我们的更改。这里的关键是我们可以使用-m参数，在此之后，我们指定一个注释字符串来解释您正在提交的内容、您所做的任何更改以及为什么会这样。这只是确保你记住你所做的任何重要的改变，这样如果你的代码终止了，或者在我们的例子中，我们想要撤销我们小说的一个章节，我们知道根据消息返回哪个提交。这里我们可以这样做:

git commit -m "Initialise the novel with an intro chapter"

我们已经为这个项目做出了我们的第一份贡献！

促成远程回购

当然，在我们的本地机器上进行所有的修改对于版本控制来说是非常好的(不再有最终的最终版本 27.txt 文件！)，但是如果我们希望与其他人协作，或者我们希望有一个远程备份以防出现问题，该怎么办呢？为此，我们可以使用 GitHub 的魔力。

为此，我们需要创建一个 GitHub 帐户并初始化一个新的存储库。为此，一旦你建立了你的帐户，你需要创建一个新的存储库，但要确保你不要用自述文件、许可证或gitignore文件来初始化它，因为这会产生错误。不过不要担心，您可以在推送到远程存储库之后创建这些文件。

因为我们已经提交了我们自己的本地存储库，所以我们需要做的就是将远程存储库链接到我们自己的存储库。为此，我们需要使用存储库 url，它位于以下位置:

作者图片

在您的项目中，我们可以通过我们的终端使用git remote add origin链接该项目，如下所示:

git remote add origin <REMOTE_URL>

确保你使用的是你自己的网址。

然后，我们可以使用git remote -v来验证这个连接，它将打印出您指定的远程 url。现在我们已经连接到了我们的远程存储库！

然而，这里的一个问题是，我们没有设置推送到远程原点的确切位置。虽然我们有本地存储库，但在我们的远程存储库中还没有分支。为此，我们可以指定:

git push --set-upstream origin HEAD:master

这将告诉存储库的当前负责人将其推送到我们存储库中的主分支。

然后，我们可以通过指定按如下方式推送HEAD来首次推送我们的远程存储库:

git push origin HEAD

这意味着在我们添加并提交所有文件后，我们需要做的就是在将来使用git push，这很简单！您可以通过访问 GitHub 帐户中的存储库来检查以确保您的文件在远程存储库中，并且文件应该在那里。这将允许你不仅将你的工作存储在一个远程存储库上，还可以与其他程序员协同工作！

现在，您已经创建了您的第一个本地存储库，提交了您的文件，然后将它们推送到远程存储库。在实践本身中，提供了关于分支的更多细节。gitignore 文件(为了保密！)以及返回到以前的提交，这些都可以在这里 找到 。

如果您想了解我们协会的更多信息，请随时关注我们的社交网站:

https://www.facebook.com/ucldata:脸书

insta gram:https://www.instagram.com/ucl.datasci/

领英:https://www.linkedin.com/company/ucldata/

如果你想了解 UCL 数据科学协会和其他优秀作者的最新信息，请使用我下面的推荐代码注册 medium。

https://philip-wilkinson.medium.com/membership

我的其他媒体文章可在以下网址找到:

[## scikit-learn 决策树分类器简介

towardsdatascience.com](/introduction-to-decision-tree-classifiers-from-scikit-learn-32cd5d23f4d)

数据科学家 Git 备忘单

原文：https://towardsdatascience.com/git-cheat-sheet-for-data-scientists-fa0bfdd3690c?source=collection_archive---------28-----------------------

入门指南

由 Roman Synkevych 在 Unsplash 上拍摄

Git 是一个免费的开源版本控制系统。大多数程序员和数据科学家每天都与 git 进行交互。那么什么是版本控制呢？版本控制是我们作为程序员跟踪代码变更的一种方式，也是与其他程序员合作的一种方式。这允许我们回顾我们随着时间的推移所做的所有更改，这有助于我们了解我们在何时做了什么，以及如果需要的话，转换回先前的代码版本。你可能之前听说过 Github，可能想知道 Git 和 Github 有什么区别。需要注意的是，Git 和 Github 并不相同。Github 是一个基于云的托管服务，托管和管理 Git 存储库，它扩展了 Git 的基本功能。除了 Github，还有 Bitbucket、GitLab、Codebase、Launchpad 等很多其他服务。在本文中，我将分享一些常见的 Git 命令以及一些比较和它们的用例。

Git 如何工作的基本概述:

1. 用 git 托管工具(比如 Github)创建一个“存储库”(项目)

git init

当你输入git init的时候，确保你在你的项目的一个根文件夹中，否则，git 将会跟踪你电脑上的所有文件并且减慢所有的速度。如果你不小心在错误的地方输入了git init，你可以通过输入rm -rf .git来撤销。

2.添加远程存储库/将存储库复制(或克隆)到本地机器

//add the remote repository
▶️ git remote add origin <HTTPS/SSH>// clone the repository
▶️ git clone <HTTPS/SSH>

使用代码下拉列表查找 HTTPS/SSH URL。(作者截图)。参考:https://github.com/academic/awesome-datascience

3.创建一个“分支”(可选，但推荐)

//create a new branch and switch to it at the same time
▶️ git checkout -b <branch-name>
▶️ git switch -c <branch-name>//simply switch to an existing branch
▶️ git checkout <branch-name>
▶️ git switch <branch-name>

git switch不是一个新特性，而是重载的git checkout命令的附加命令。git checkout可以用来切换分支，恢复工作树文件，也可以混淆。为了分离功能，GIT 社区引入了这个git switch命令。

4.要使特征分支保持新鲜，并与主分支中的最新更改保持同步，请使用 rebase

▶️ git pull
▶️ git pull --rebase origin master

我们经常看到冲突发生在这一步。在此步骤中解决冲突有助于保持要素分支历史的整洁，并使最终合并更加容易。

虽然git pull和git rebase紧密相连，但它们不可互换。git pull从远程获取当前分支的最新变更，并将这些变更应用到分支的本地副本。一般来说，这是通过 git merge 完成的，即本地变更被合并到远程变更中。所以 git 拉同时类似于git fetch + git merge。

git rebase允许我们在远程主分支上应用我们的更改，这给了我们一个更清晰的历史。这是合并的替代方案。使用此命令，您所做的本地更改将基于远程更改之上，而不是与远程更改合并。

5.将文件添加到本地存储库中或对文件进行一些更改，然后在准备好保存更改时将其放入暂存区

//Add one file
▶️ git add <file-name>//Add all the new/modified/deleted files to the staging area
▶️ git add -A (note: -A is shorthand for --all)//Stages files in the current directory and not any subdirectories, whereas git add -A will stage files in subdirectories as well.
▶️ git add .//Stage all new and modified files. The previous commands will also remove a file from your repository if it no longer exists in the project. 
▶️ git add --ignore-removal//Stage all modified and deleted files
▶️ git add -u (note: -u is shorthand for --update)

5.“提交”(保存)更改

git commit -m “message about the changes you've made”

6.将您的更改“推”到您的分支

git push origin <branch-name>

git set-upstream 允许您为当前的本地分支设置默认的远程分支。您可以通过添加-u、git push -u origin <branch-name>来设置上游。这个命令将把<branch-name>分支设置为默认分支，这允许您推送更改，而不需要指定您正在推送的分支。设置了上游之后，下次当您将一些更改推送到远程服务器时，您可以简单地键入git push。

8.打开一个“拉请求”(又名“PR”)，请求将变更合并到主分支

拉式请求是一个让开发者更容易协作的特性。一旦开发人员创建了一个拉请求，团队的其他成员就可以检查代码，然后将新的变更合并到主分支中。

一旦您在特性分支中推送了新的变更，您现在就可以创建一个拉请求了(作者截图)

9.将你的分支“合并”到主分支

然后，主分支机构的管理员会看到这一点，他或她将合并您的拉请求，一旦代码已被审查。(作者截图)

有用的 Git 命令

1. git status —显示已暂存、未暂存和未跟踪的文件。
2. git log —显示整个提交历史。这里需要注意的一点是，黄色突出显示的数字是提交 ID。提交 ID 是提交中所有数据的 sha1 散列。两次提交具有相同的提交 ID 是非常罕见的，但这是可能的。

git 日志(作者截图)

3.git diff —比较变化。git diff可用于比较提交、分支、文件等。您可以从提交 ID 中复制前几个字符(> 4)，Git 将能够判断出您指的是哪个提交。利用上图，我们可以用 9b0867 和 51a7a。

//Show difference between working directory and last commit.
▶️ git diff HEAD//Show difference between staged changes and last commit
▶️ git diff --cached//Show difference between 2 commits
//To see what new changes I’ve made after the first 51a7a commit: 
▶️ git diff 51a7a 9b0867

4.git branch —列出您的回购中的所有分支。记得在按下代码之前检查这个。我肯定你不想不小心把你的代码推到主分支或者其他分支。

5.git branch -m <new-branch-name> —重命名分支机构名称

//Checkout to the branch you need to rename
▶️ git checkout <old-branch-name>//Rename branch name locally
▶️ git branch -m <new-branch-name>//Delete old branch from remote
▶️ git push origin :<old-name> <new-branch-name>//Reset the upstream (optional) branch for the new branch name
▶️ git push origin -u (optional) <new-name>

6.git revert —创建一个新的提交，撤销在<提交>中所做的所有更改，然后将其应用到当前分支。这必须在“提交级别”完成。

7.git reset —这可以在“提交”或“文件”级别完成。在提交级别，git reset丢弃私有分支中的提交或丢弃未提交的更改。在文件级，git reset可以从暂存文件中删除文件。

//Reset staging area to match most recent commit, but leave the working directory unchanged.
▶️ git reset//Move the current branch tip backward to <commit>, reset the staging area to match, but leave the working directory alone.▶️ git reset <commit>//Same as previous, but resets both the staging area & working directory to match. Deletes uncommitted changes, and all commits after <commit>. 
▶️ git reset --hard <commit>//Reset staging area and working directory to match most recent commit and overwrites all changes in the working directory. ▶️ git reset --hard

8.git stash —获取您未提交的更改(暂存的和未暂存的)，保存它们以备后用，然后从您的工作副本中恢复它们。默认情况下，Git 不会隐藏对未被跟踪或忽略的文件所做的更改。这意味着 git 不会隐藏未暂存的文件(即没有运行git add)和已经被忽略的文件。

//Stash your work: once you've stashed your work, you're free to make changes, create new commits, switch branches, and perform any other Git operations; then come back and re-apply your stash when you're ready.
▶️ git stash// re-apply stashed changes
▶️ git stash pop// list stack-order of stashed file changes
▶️ git stash list//discard the changes from top of stash stack
▶️ git stash drop

9.git fetch <remote> <branch> —从远程存储库中获取特定的<分支>。关闭<分支>以获取所有远程参考。

10.git rm <file> —删除文件。当使用此git rm命令删除一个文件时，并不意味着该文件从历史中删除。该文件将在存储库历史中保持“存活”，直到该文件将被完全删除。

摘要

现在，您已经理解了基本的 Git 命令，是时候使用它们并开始用 Github 构建您的数据科学组合了！

资源:

1. https://www.youtube.com/watch?v=RGOj5yH7evk
2. https://git-scm.com/
3. 【https://www.atlassian.com/git/tutorials
4. https://learngitbranching.js.org/
5. https://bluecast.tech/blog/git-stash/
6. https://www.atlassian.com/git/tutorials/cherry-pick

如果你觉得这很有帮助，请关注我，看看我的其他博客。敬请关注更多内容！❤

</10-tips-to-land-your-first-data-science-job-as-a-new-grad-87ecc06c17f7>

我作为软件开发人员的第一年学到的 18 个 Git 命令

原文：https://towardsdatascience.com/git-commands-cheat-sheet-software-developer-54f6aedc1c46?source=collection_archive---------0-----------------------

初级软件开发人员的实用 Git 备忘单

蒂姆·范德奎普在 Unsplash 上拍摄的照片

G 它是使用最广泛的免费开源分布式版本控制系统(VCS)。在过去的几年里，Git 已经从开发人员的首选技能转变为必备技能。很难想象一个没有 VCS 的项目，它简化了开发过程。

回到 2018 年，我开始了作为软件开发人员的职业旅程。我对软件开发很熟悉，但是 Git 是未知的领域。令人困惑和恐惧。后来我发现一些资深开发者还是很怕它。我很幸运有一个好的导师指导我每一步。

在我培训期间，我的经理让我从头开始做一个 web 开发项目。他给了我一个模糊的需求列表，并让我找出其余的。这是我第一次感到自己脱离了舒适区。也是我第一次用 Git。

以下是我作为软件开发人员第一年学到的 18 个 Git 命令。从技术上来说，有 18 个以上，但我把相关的命令放在一个标题下。你可以在这里找到完整的 Git 指南。

1)创建新的存储库

建立我的第一个职业发展项目既令人兴奋又令人恐惧。如果你不知道自己在做什么，这并不夸张。我被要求在 Gitlab 上添加这个项目。IT 团队已经在我的 Linux 系统上设置了 Git。是时候创建一个新的 Git 存储库了。

***git init***

Git 命令初始化或创建新的存储库——按作者排列的图像

执行该命令将创建一个带有默认主(或主)分支的本地存储库。

要将这个本地存储库连接到 Github，我们需要在 Github 上创建一个远程存储库。并将远程存储库的源与本地存储库连接起来。

***git remote add origin https://github.com/******YOUR-USERNAME/YOUR-REPOSITORY***

Git 命令将远程源添加到本地存储库——图片由作者提供

最后在 Github 上推主分支。

***git push -u REMOTE-NAME BRANCH-NAME***

Git 命令推送本地主分支——按作者排序的图像

**注意:**在项目工作目录下，通过终端(Linux)或 Git Bash(Windows)执行所有 Git 命令。

2)创建新的分支

实现一个新特性的黄金标准是创建一个新的分支，并将所有代码放入其中。这使得现有代码不会出现糟糕的实现。

***git checkout -b NEW-BRANCH-NAME***

Git 命令创建一个新的分支——作者的图像

如果存储库中不存在新分支，checkout 命令会创建新分支。而-b选项从当前分支切换或检出到新创建的分支。在创建新分支之前，最好先切换到主分支。主分支通常拥有最新的代码。

一旦我们创建了一个新的本地分支，它应该被推送到远程存储库——就像前面所做的那样。

Git 命令来推送新创建的分支——作者的图像

3)开关支路

当您开始处理一个新项目时，最好对存储库中的分支有一个大致的了解。

***git branch***

Git 命令列出存储库中的所有分支——按作者排序的图像

列出所有分支后，使用以下命令切换到所需的分支:

***git checkout BRANCH-NAME***

Git 命令切换分支——作者图像

如果在当前分支中没有未提交的更新文件，checkout 命令可以很好地工作。否则，这些未提交的更改将导致错误。在切换到另一个分支之前，最好提交或保存当前分支中的更改。

由于未提交的更改而导致签出错误—按作者排序的图像

4)隐藏/取消隐藏文件

解决签出错误的方法之一是隐藏更改。如果您还没有准备好提交这些变更，这通常是为了保存您在当前分支中已经完成的工作。

***git stash***

Git 命令隐藏未提交的更改—作者图片

要恢复或撤销隐藏的更改，我们可以回到我们隐藏更改的分支并弹出它们。

***git stash pop***

Git 命令恢复隐藏的更改—作者图片

5)检查分支状态

我有一个奇怪的习惯，经常检查分行的状态。它给出了关于分支机构当前状态的所有必要信息。我们可以检查所有已实施或未实施的变更。

***git status***

Git 命令检查分支的状态——作者的图像

6)重命名本地分支

分支重命名并不是最常用的 Git 命令之一，但是如果有输入错误，它会很方便。或者在我的例子中，重命名分支以形成一致的 Git 目录结构。

***git branch -m OLD-BRANCH-NAME*** ***NEW-BRANCH-NAME***

Git 命令重命名一个分支——作者图像

7)重命名远程分支

重命名本地分支后，就应该更改相应远程分支的名称了。

***git push origin :OLD-BRANCH-NAME NEW-BRANCH-NAME***

Git 命令重命名远程分支——作者图像

该命令删除旧名称的分支，并创建一个具有相同代码库的新分支。

8)同步分支变化

一旦在您的项目中创建了一个新文件或者更新了一个现有文件，我们就必须将这些文件添加到下一次提交中。

***# To add all changes
git add .
# To add a specific file
git add FILE-PATH***

Git 命令添加单个文件或所有文件——按作者分类的图像

当所有必需的更改都已添加到提交中时，就该提交这些更改并编写唯一的提交消息了。提交消息可以是任何可以用几句话描述您的工作的字符串。

***git commit -m "COMMIT-MESSAGE"***

Git 命令提交更改—作者图片

最后，使用*git push*命令将这个提交推送到远程存储库。您还可以更新或修改您的提交。

***git add*** ***FILE-PATH
git commit --amend -m "CHANGE-COMMIT-MESSAGE"***

Git 命令修改以前提交的图像(由作者提供)

这是我最喜欢的 Git 命令之一。当你在团队中工作时，代码审查是非常重要的。高级开发人员或团队领导经常指出代码中的重要问题。我们没有创建一个新的提交来解决这些问题，而是遵循了每个分支一个提交的惯例——*git amend*被证明是方便的。

9)克隆存储库

我为我的第一个实时项目执行的第一个 git 命令是*git clone* 。我被要求在我的本地系统上克隆项目，以理解代码，添加一些功能，并通过合并请求将代码推回。

***git clone*** ***https://github.com/YOUR-USERNAME/YOUR-REPOSITORY***

Git 命令克隆一个存储库——按作者的图像

10)检查提交日志

日志是软件开发的重要组成部分。软件维护日志文件来记录其生命周期中的所有步骤。Git 还提供了一个日志来跟踪所有的提交。

***git log***

显示提交日志的 Git 命令—按作者显示图像

11)重置到最后一次提交

拥有重置或撤销任务的权力是救命稻草。在我作为一名开发人员的早期，我曾经犯过一个错误，那就是更改实时生产代码。这是一个错误。令我惊讶的是，我没有被解雇。让我免于造成更多伤害的是重置命令。它允许我在一瞬间将所有更改恢复到最后一次工作提交。

***git reset --hard origin/BRANCH-NAME***

Git 命令将代码库重置为上一次工作提交—作者图像

12)将本地存储库与远程存储库合并

这就是奇迹发生的地方。当我们在开发软件时，我们通常会维护代码库的三个副本。

一个是本地副本，开发人员在其上工作并执行所需的任务。第二个是暂存副本或暂存服务器，在这里部署这些任务并与客户端共享。客户对软件的所有新变化给出反馈。然后，开发团队处理这些更改，并将它们部署回临时服务器。这个循环会一直持续到客户批准将这些更改部署到第三台也是最后一台生产服务器上。

每次部署新功能或更新现有功能时，我们都会执行合并操作。来自 Github 远程存储库的更新代码文件与这三台服务器上的本地存储库合并。

合并存储库时最常见的问题是合并冲突。必须解决这些冲突才能完成合并操作。

***# Fetch remote from github
git fetch REMOTE-NAME
# Merge remote branch with local branch
git merge REMOTE-NAME/BRANCH-NAME***

Git 命令将远程分支与本地分支合并——图片由作者提供

合并操作分两步执行。我们从 Github 获取或下载包含所需代码库的遥控器。然后合并远程和本地分支历史。

另一种执行合并的方法是*git pull*。拉取和合并的工作方式是一样的，还有取取的好处。*git pull*执行 fetch 和 merge — 合并两个或更多分支，而不是如上所示分别执行这两个操作。

***git pull REMOTE-NAME BRANCH-NAME***

Git 命令从远程分支提取变更，并将它们与本地分支合并——按作者排序

13)将提交从一个分支移动到另一个分支

当你在一个项目上合作时，最好是每个开发人员从事一个单独的特性——好得难以置信。根据任务的复杂程度，它被分配给多个开发人员。

高内聚和低耦合经常被忽略或不切实际。这在开发过程中产生了许多问题。

我做过几个这样的功能。在大多数情况下，我被要求从其他分支获取未完成的代码，并试图在牢记未完成部分的同时对其进行扩展。*git cherry-pick*起了重要作用。

***git cherry-pick COMMIT-HASH***

Git 命令将提交从一个分支移动到另一个分支——作者图片

这个命令在当前分支上应用所选择的提交，这在 bug 修复期间也非常方便。尽管精心挑选很有用，但并不总是最佳实践。这可能会导致重复提交，这就是为什么在大多数情况下首选合并的原因。

14)删除未被跟踪的文件和目录

使用*git clean* 可以很容易地从工作目录中删除尚未提交的文件和目录。我用它来删除我的 IDE 创建的不需要的文件和目录。

# To remove untracked files
***git clean -f***
# TO remove untracked directories
***git clean -fd***

Git 命令删除不需要的文件和文件夹-图片作者

15)删除本地存储库的一个分支

如果不再需要某个分支，最好通过删除该分支来清理存储库。要删除本地存储库中的分支，使用带有*-d*选项的*git branch*。

***git branch -d BRANCH-NAME*** # To forcefully delete a local branch. Be careful
***git branch -D BRANCH-NAME***

Git 命令删除本地分支——作者图片

16)删除远程仓库上的分支

删除远程存储库上的分支类似于使用相同的带有*--delete*选项的*git push*命令在远程上推送更新。

***git push REMOTE-NAME --delete BRANCH-NAME***

Git 命令删除远程分支——作者图片

17)忽略 Git 权限更改

我在一个基于 Linux 的系统上工作，在那里使用*chmod*设置文件权限对于安全性非常重要。在开发过程中，我们通常会将文件的模式更改为 777 以使其可执行。Git 获取这些权限变更，并在*git status*中将它们显示为更新的文件。

***git config core.fileMode false***

Git 允许我们通过将配置中的*fileMode*改为假来忽略这些变化。

18)修复。gitignore

。gitignore file 是一个福音，它帮助我们忽略将不需要的文件提交到存储库中。但是如果文件已经被 Git 跟踪了，那就麻烦了。

谢天谢地，有一个简单的解决办法。它需要移除缓存的。gitignore 索引并再次将其添加到存储库中。

# To create a new .gitignore file ***touch .gitignore***# To untrack the unnecessary tracked files in your gitignore which removes everything from its index. Specific filenames can also be used instead of dot(.).
***git rm -r --cached .
git add .
git commit -m "gitignore fixed untracked files"***

Git 命令检查状态——按作者分类的图像

要修复的 Git 命令。gitignore —作者图片

总结想法

这是冰山一角。像其他任何事情一样，Git 需要实践和实验。掌握 Git 要难得多。一年之内，我只能学会它的基础。

对于初级开发人员来说，还需要克服学习新事物的恐惧。没有 Git，开发人员的投资组合是不完整的——就像不带任何武器去打仗一样。

Git 命令科学家日常使用的数据

原文：https://towardsdatascience.com/git-commands-data-scientists-use-on-a-day-to-day-basis-40d588cd63f7?source=collection_archive---------4-----------------------

面向数据科学家的 GIT

适用于查看本地 PR 副本、带回混乱的文件或删除 PR 中的文件等情况。

在你问我为什么在 2021 年还在使用命令行 Git 之前，等等，我可以解释！所以你真的不喜欢使用命令行，尤其是当有这么多完美的图形用户界面存在的时候。

最近，我的大部分工作转移到了 Linux 机器上，我正在寻找一个 git 扩展或 GUI 来支持 Jupyterlab 远程服务器。在这个问题这里浪费了许多宝贵的时间之后，我最终决定系好安全带，作为一名数据科学家，学习一些可能对任何给定场景都有用的命令。同样，我希望在无法使用 GUI 并且 Git 命令行是唯一选择的服务器环境中工作时，学习这些知识会派上用场。

不仅仅是一个备忘单，我更愿意把这篇文章看作是一个假设的你会做什么的场景列表，一个我可能会比你们中的任何人使用得更多的场景(尽管如果它确实对你有帮助，嗯…越多越好！😃 ).有些场景是基本的，我相信你知道如何通过它们，其他的场景更具体，尽管我相信你能理解它们。

这绝不是一个详尽的列表，而是一些在我日常工作环境中经常出现的主题。

免责声明:本文是为具有一些 Git 基础知识的读者而写的。我的基本意思是，如果你拥有一个 Github 账户，并且当我说“检查一个分支”和“提交一个更改”时，你不认为我在说某种外星语言，那么你就一切就绪了！

术语和术语

在整篇文章中，每当我提到本地变更时，我指的是您在本地对您计算机上的项目副本所做的变更。远程变更意味着您正在对存在于 Github 服务器上的项目副本进行变更。

作为一个经验法则，在本地拷贝上玩你想玩的，但是在用你的本地改变修改远程拷贝时要非常小心。

考虑到所有这些，让我们浏览一下初学者可能面临的一些常见场景以及如何解决它们。

附言:这些场景没有特定的顺序。

场景 1

公司开始了一个新项目，你想参与其中，这样你就可以开始为之做出贡献。

一旦某个团队成员将您添加为协作者，您所要做的就是转到 Git bash 或 Mac 终端，根据您是想在桌面上还是下载文件夹中创建这个本地 repo 来执行cd Desktop或cd Downloads，然后执行以下操作:

git clone https://github.com/V-Sher/medium_demo.git

在这里，我试图克隆我为这篇文章创建的一个(私人)回购，但请随意用您自己的远程 URL 替换它。您感兴趣的 repo 的远程 URL 可以在该项目的 Github 页面上找到(参见下图中用蓝色突出显示的文本)。

图 1:蓝色突出显示的文本是 repo 的远程 URL。

场景 2

创建你自己的分支，开始工作并与同事分享。

创建一个分支并开始工作总是比搞乱main分支好。在这样做之前，最好先检查所有可用的本地分支:

git branch

您当前所在的分支旁边会有一个*。在我的例子中，我好像在main上，我想从这个分支创建一个名为agenda的分支。

git checkout -b agenda

这里的agenda是我的分支的名字，但是你可以随意选择你喜欢的名字。运行该命令将使agenda成为当前工作分支，如果再次运行git branch命令，您将看到*已经转移。

从这里开始，我将把两个文件添加到本地机器上的medium_demo文件夹中，分别名为agenda.py和fake_agenda.py，然后执行一个git add .操作，把这两个文件都添加到暂存区，然后使用git commit -m "Adding a real and fake agenda"提交这些更改。

现在，我的本地回购副本有两个额外的文件，我必须将它们推送到远程使用:

git push -u origin agenda

这里的origin是远程 Github 的名称(附注，我们将在文章末尾更详细地讨论这个问题),-u表示在“本地”agenda分支和“远程”agenda分支之间建立了跟踪连接。

现在回到您的回购的 Github 页面，您可以看到已经准备好成为拉取请求(PR)的一部分的更改:

您可以点击比较&拉动式请求按钮来创建一个 PR，并将您的同事/上司指定为其审核人。

一旦你的同事审阅了简历，他们可能会在简历上留下自己的评论，如下所示:

如你所见，审查员告诉我们必须删除不必要的fake_agenda.py文件。让我们在场景 3 中看看如何做到这一点。

场景 3

删除您作为拉请求的一部分错误添加的文件。

显然，我们不想让经理看到我们为这个项目创建的虚假议程。要解决这个问题，我们需要从 PR 中删除文件fake_agenda.py。

如果我们这样做:

git rm fake_agenda.py

您会注意到它会将文件从您的工作目录中完全删除。这不是我们想要的(或者至少不是我想要的)。我们想从 PR 中删除它，但不是从我们的本地回购中。

相反，让我们先把文件带回来:

git reset -- fake_agenda.py
git checkout -- fake_agenda.py

现在将它作为我们 PR 的一部分删除，使其成为一个未跟踪的文件:

git rm --cached fake_agenda.py

要提交此更改:

git commit -m "the file fake_agenda is gone from the repository"

最后，像上次一样提交:

git push -u origin agenda

如果您返回到 PR 的 Github 页面，您将看到添加了另一个 commit，描述如何删除不必要的文件。

此外，要确认该文件不再是 PR 的一部分，请查看“文件已更改”选项卡，它应该显示 1(之前是 2，因为有额外的fake_agenda.py文件)。

场景 4

当您在其他分支上工作时，将远程更改放到您的本地机器上。

当你忙于自己的分支(从main分支分出)本地时，在远程回购中的main分支，事情可能会发生变化。随着越来越多的人在一个项目上工作——每个人都在他们自己的分支上——过一段时间，他们的分支将开始与main分支合并(当然，一旦它通过了所有的检查和评审)。

例如，您团队中的高级数据科学家决定更新main“远程”分支中的自述文件。

但是这些变化不会出现在你的‘local’main分支中。因此，您应该掌握这些变更，以保持您的本地main分支是最新的(毕竟，这是您将来创建新分支的地方)。为此，我们首先检出main分支，然后引入变更。

git checkout main
git pull

现在，如果您打开自述文件，您将会看到附加行。这意味着你当地的main分支机构全部被赶上了。

然而，如果你回到你在本地工作的分支，即agenda

git checkout agenda

并打开自述文件，它仍将和以前一样，即没有变化。理想情况下，我希望将本地main中的所有变更合并为我正在处理的分支的一部分，这样我就知道我拥有项目的最新文件。

更一般地说，要使本地分支 X 达到本地分支 Y 的速度，请确保您已经首先检出了 X (在我们的示例中， X 将是本地agenda分支， Y 将是main)，然后进行合并:

git checkout agenda
git merge main

您之前在agenda分支中的所有文件将保持不变(以确认转到并手动检查文件)，并添加了一些由高级数据科学家引入的新内容。

有时，合并过程可能不像您希望的那样顺利。那到底是什么意思？这意味着在合并过程完成之前，可能会有一些问题需要解决——这是由两个人在完全相同的行上更改相同的文件引起的。让我们看看如何在下一个场景中修复它们。

场景 5

如何解决合并冲突？

从场景 4 继续，让我们假设您和高级数据科学家都在完全相同的行上更改了同一个文件。在这种情况下，从最后一个场景合并将会提示如下错误:

这条消息不言自明，告诉我们它不能合并 README.md，因为我和我的学长都试图修改完全相同的行。因此，我必须在合并之前解决这个错误。为此，在编辑器中打开文件(我个人偏好 VScode)，你会看到需要在<<<<<<<和>>>>>>之间解决的问题。

似乎我们都在试图修改最后一行(我想说苹果，她想说橙色)。此时，您可以接受即将到来的更改，或者坚持当前的更改，或者做其他事情。一旦您对更改感到满意，保存并关闭文件。回到终端，添加并提交此更改，最后推送它:

git add README.md
git commit -m "Apples and oranges issue averted"
git push

回到 PR 的 Github 页面，您可以看到新的提交已经作为 PR 的一部分被添加。

一旦你的评审者对所有的改变感到满意，她会将 remote 上的agenda分支与 remote 上的main分支合并，你可以在 Github 页面上看到。

一旦合并，您不再需要agenda分支——您甚至可以删除它。从现在开始，我强烈建议任何时候你想在项目的其他方面工作，在确保你已经将远程main分支的最新版本拉到你的本地main分支之后，你应该从本地main分支创建一个新的分支。

场景 6

把一个被你搞砸的同事的文件带回来，恢复原状。

有时，在您的分支机构工作时，您可能会弄乱您或您的同事创建的现有文件。例如，假设我错误地修改了agenda.py文件中的打印语句

从这个

print(“The agenda for this demo is as follows: Do A then B and finally C.”)

对此

print(“The agenda for this demo is as follows: Do A and finally C.”)

还使用提交了这些更改

git add agenda.py
git commit -m "Messing up the file by removing B's info"

要将其恢复到原始形式(即，它在上次提交时的样子)，只需执行git checkout <commit_id> — filename。在这里，如果您在 Github Web UI 上找到相关文件并选择其最新的提交号，就可以快速检索到commit_id。

为 Github 上的文件选择最新的提交 id(在“最新提交”之后的右边)

在我们的例子中，agenda.py文件的提交 id 是3c8ebf0。因此，要使它看起来就像上一次提交一样，只需

git checkout 3c8ebf0 -- agenda.py

其次是:

git add agenda.py
git commit -m "Restoring B's info in the agenda"

场景 7

一位同事邀请您在她现有的远程分支机构工作。

通常，你的一个已经在做某个分支的同事，比如说featureB，会邀请你去做这个分支。现在让我们假设这个分支除了 Readme 文件之外，还包含一个文件featureB.py。

要开始协作，您需要创建一个本地 featureB分支，并在远程和本地featureB 分支之间建立某种跟踪连接，以便您可以推送提交并对它们进行更改。

首先，确保同事的分支存在于远程服务器上——这意味着你的同事已经将她的分支推送到 origin 上——并且你可以访问它。要检查您有权访问的所有远程分支，请执行git fetch，然后执行:

git branch -r

看到我的同事希望我插话的分支，即origin/featureB，我们将简单地做:

git checkout --track origin/featureB

这将创建一个名为featureB的本地分支，您现在应该看到由文件featureB.py组成的本地回购。接下来，我将继续对该文件进行一些简单的更改(基本上添加我作为初级数据科学家的想法)，并使用git push origin featureB将其推送到远程分支。这是添加我的更改后文件在 remote 上的样子:

因为你们可以同时处理文件并对其进行修改，所以我强烈建议每次在开始处理featureB分支之前先做git fetch再做git pull。一如既往，您可能需要解决一些冲突，一旦解决完毕:

git add featureB.py
git commit -m "Resolved conflict"
git push origin featureB 

或者，如果您不希望在您同事的分支featureB的本地和远程副本之间建立跟踪连接，而是希望将其与您当前工作的分支(即<branch-name>)合并:

git checkout <branch-name>
git merge origin/featureB

场景 8

如何将采购申请提取到本地回购进行审查？

有些情况下，你会被指派为公关的“审查者”，这意味着你的工作是通过分析同事的分支来确保一切正常。作为审查过程的一部分，人们可以简单地在 Github Web UI 上浏览代码，但我通常更喜欢制作 PR 的本地只读副本，并在我的终端运行它。

附注:只读副本意味着您不能将变更推送到该 PR，这是理想的，因为我们不应该将变更推送到由其他人创建的 PR，只有 PR 的 作者 应该进行变更。

为此，先使用git fetch origin pull/PULL_REQUEST_ID/head:NEW-BRANCH-NAME，再使用git checkout BRANCH_NAME。

附言:您在上面的命令中看到的所有内容都是您需要提供的:

• PULL_REQUEST_ID 可以从 PR 的 Github 页面检索。它通常是#符号后面的一个数字。对我们来说，是 4。

图 Github Web UI 上的 PR 页面。它包含有关拉取请求 id 的信息，以及创建 PR 的分支。

• NEW-BRANCH_NAME 可以是您想称为 PR 的只读副本的任何名称。我喜欢叫我的review_***。

一旦你的猫咪里有了这两样东西，就去做吧:

git fetch origin pull/4/head:review_featureb1
git checkout review_featureb1

在review_featureb1分支上，你想怎么复习就怎么复习。一旦你完成了，你可以通过在 PR 的 Github 页面上留下评论来告诉作者需要做什么改变，或者你可以自己做这些改变，并使用git push -u origin patch-test_featureb1将它们推送到一个新创建的分支。

尽管我提到除了 PR 作者之外，任何人都不应该对 PR 进行更改，但有时您会希望直接对某人的 PR 进行一些更改——例如，一个非常小的打字错误需要修复——并将这些更改作为 PR 的一部分。

在这种情况下，您需要首先获得创建 PR 的分支的名称(让我们称之为<PR-branch-name>)。它通常会出现在 Github Web UI 的 PR 页面上，内容如下:<repo-author> wants to merge X commits into main from <PR-branch_name>(参见上面的图 2)。

在我们的例子中，公关似乎是从featureb1创建的。让我们使用以下方法之一来检查这个分支:

(a) git checkout featureb1(如果你在本地跟踪featureb1

运筹学

(b)情景 7 中描述的步骤(如果您没有在本地跟踪该分支机构)。

之后，您进行所需的更改，最后使用git push origin featureb1推送到遥控器上同名的分支，使其成为 PR 的一部分。

注意:在解释了两种评审方法之后，我强烈建议创建一个新的分支(而不是修改现有的 PR ),因为它给了某人一个评审你的工作(在合并之前)的机会，这样你就不会在不知不觉中弄乱某人的 PR。

场景 9

如何将我的本地更改推送到远程回购？

简而言之，这取决于你的场景。

如果您处于类似场景 2 的情况，即在本地创建的分支上工作，(这意味着它在远程还不存在)，您可以

git push -u origin <my_branch_name>

它会自动在遥控器上创建同名的分支，其中的<my_branch_name>会被您在本地创建的分支的名称所替换。

或者，如果您在场景 7 中，即在本地工作于远程跟踪的分支机构，则您可以:

git push origin <remote_branch_name>

其中<remote_branch_name>应该替换为远程 repo 上存在的分支名称，并且在运行命令git branch -r时可见。

场景 10

如何在 Github 上推送空目录？

要了解 Git 如何处理空目录，让我们做一个快速设置。

使用git checkout签出任何分支，并尝试在本地 repo 中创建一个空文件夹e_folder。

接下来，在终端中尝试:

git status

在理想的情况下，git 应该会提示您将这个新创建的文件夹添加到 staging area，但是没有发生类似的事情。现在继续向e_folder添加任何文件，使其不再为空:

如果您现在要做一个git status，您会看到一个提示，告诉您使用git add命令添加文件夹

简而言之，默认情况下，Git 只会跟踪非空目录——这在大多数情况下对我们来说不成问题。然而，有时我们会希望推送一个空目录。例如，我喜欢有一个空的目录作为占位符，告诉人们在使用我的模型时可以上传他们的自定义图像。

为了明确地通知 Git 跟踪我们的空目录e_folder，首先，让我们继续手动删除其中的img.jpeg文件。然后转到 Git 命令行:

cd e_folder
touch .gitignore
vi .gitignore

一旦进入可视化编辑器，

• 按下键盘上的i
• 将下面几行粘贴(或 Ctrl+V)在那里[Credits:stack overflow

# Ignore everything in this directory
*
# Except this file
!.gitignore

• 按下键盘上的esc
• 类型:wq

在 git 终端上，使用cd ..返回到medium_repo目录，然后

git status

您将看到现在 git 已经准备好将您的空文件夹添加到临时区域

继续添加它，提交它并推动它:

git add e_folder
git commit -m "placeholder for images"
git push

奖金方案 1

我检查了一个分支 X，在那里做了一些更改，使用 File -> Save 保存了这些更改。然后我继续检查另一个分支 Y，我可以看到与我在 x 中所做的相同的更改。为什么在一个分支中进行更改，git 会更改所有其他分支？

查看 Stackoverflow 上的长答案。

简而言之，如果您没有使用git commit提交您在一个分支中所做的变更，那么当您切换分支时，变更也会随之而来。这意味着当您签出其他分支时，您有无意中破坏它们的风险。所以尽可能多的提交，尽可能多的提交，尤其是在对代码做一些重大修改的时候！

奖金方案 2

在推送到远程之前，如何检查我提交(即更改)了哪些文件？

通常，我们会在几周甚至几个月的时间里在几个文件中提交大量的变更，而不需要将它们推送到远程。因此，当最终推送变更(以便您的同事可以查看您的工作)的时候，我们不确定我们将要推送什么文件！

要获得自上次推送以来修改过的文件名列表(并避免任何不必要的意外)，这个命令很有用:

git diff --name-only <local_branch_name> origin/<remote_branch>

将<local_branch_name>替换为您正在处理的本地分支的名称，将<remote_branch>替换为远程服务器上的分支的名称，您希望将您的更改推进到该分支中。--name-only标签将确保只列举文件名，并保留每个文件中更改的细节(例如，添加或删除了哪些特定的行)。

奖金方案 3

我的同事正在进行 Git 回购，我想推送/拉取/查看他们回购中的一些文件。

还记得我说的关于的来历吗？这是我们的远程 Github repo 的名称。要检查您可以访问哪些远程 Github repos:

git remote -v

到目前为止，我们主要在一个名为origin的 repo 上工作，但假设我也想在 GitHub 上托管的其他一些远程存储库上工作。添加我的同事 *ABC* 为他的一篇媒体文章创建的 Github repo 怎么样？我确信我能帮她复习一些内容。它的远程 URL 是[https://github.com/ABC/coworker_medium_repo.git](https://github.com/V-Sher/GANs_Pytorch.git.)。

首先要做的是添加这个远程存储库，即建立某种连接，并为它设置一个名称。我也不能命名我同事的 repo origin,因为它可能会混淆 Git 并导致致命错误。因此，最好使用与回购相对应的名称——我倾向于将它们命名为origin_***。

git remote add origin_medium [https://github.com/ABC/coworker_medium_repo.git](https://github.com/V-Sher/GANs_Pytorch.git.)

现在，如果您在终端中执行git remote -v命令，您将看到您可以访问的所有遥控器:

同样，你可以继续使用同事的回购 URL 创建对他们回购的引用。

注意:如果您需要复习如何定位回购 URL，请看图 1。

git remote add project1_origin http:github.com/XYZ/project1.gitgit remote add project2_origin http:github.com/MNO/project2.gitgit remote add project3_origin http:github.com/PQR/project3.git

现在，假设你的同事在 Github 上为项目 2 制作了一份 PR，你必须审阅它。场景 8 中已经讨论了这样做的步骤(确保您有适当的 PULL_REQUEST_ID)。这次您需要做的唯一更改是指向正确的来源，即正确的回购名称:

git fetch **origin_medium** pull/PULL_REQUEST_ID/head:REVIEW_FEATURENAME
git checkout REVIEW_FEATURENAME

您甚至可以获取它们的一个分支，并使用以下命令在本地跟踪它们:

git fetch **origin_medium** new_agenda
git checkout new_agenda

其中new_agenda是我同事的回购协议中的一个远程分支。接下来，进行一些更改——添加、提交和推送。你现在知道规矩了:

git commit -a -m "Some input from V-Sher's end as well"
git push

注意:请记住，在我们的示例中，存在一个由来自 *new_agenda* 分支的同事创建的 PR，我们刚刚推送到该分支的任何更改也将是 PR 的一部分(见下图)。如果这不是故意的，请制作 PR 的本地副本，创建一个新分支，并将其推送到同事的 repo。

您甚至可以将同事的一个远程分支机构拉入您自己的本地分支机构。也就是说，我将检查我的本地分支agenda，并尝试将我的同事的T2 分支拉入其中:

注意:坦白地说，我不知道我什么时候会用到它，因为这两个项目的提交历史是不相关的。如果你有想法，让我知道！

git checkout agenda
git pull **origin_medium** second_agenda --allow-unrelated-histories

使用场景 5 中的步骤可以解决一些冲突，但没有什么是我们不能解决的。

至理名言

• 你永远做不够git fetch和git status——前者通知你远程回购的新进展，后者提醒你本地回购中未提交的文件。
• 一旦你对你的代码做了一些重要的改变，就养成git commit的习惯。(不，文件- >保存不充分)
• 如果远程跟踪被启用*, git push(和git pull)将从当前检出的*分支向远程上的相应分支推送(和拉取)变更。如果未启用，将会引发一个错误，您必须通过显式声明 repo 名称和您希望拉入/推送的分支名称来修复该错误。
  注意:我比大多数人更偏执，所以你会发现我总是明确地说出回购协议名称和分行名称。例如git push origin_name branch_name。
  :要检查分支机构是否启用远程跟踪，请尝试git remote show origin。这将显示每个本地分支及其链接的远程分支。

恭喜你走到这一步…

我真的相信您能够在日常生活中使用这些 Git 命令。对于那些想要学习更复杂的命令的人(为了有一天可能在你的工作场所出现的场景)，我会说建立两个虚拟的 Github 帐户——你需要扮演两个合作者的角色——并开始练习你的疯狂的一生一次的场景。

一如既往，如果有更简单的方法来做我在本文中提到的一些事情，请让我知道。

直到下次:)

https://medium.com/swlh/how-i-would-explain-gans-from-scratch-to-a-5-year-old-part-1-ce6a6bccebbb

在协作工作空间中为数据科学家提供 Git 命令

原文：https://towardsdatascience.com/git-commands-for-data-scientists-in-a-collaborative-workspace-b528cfa5b235?source=collection_archive---------30-----------------------

简约 Git 生存指南——解释每个 Git 命令的基本原理和情况

是的，每个程序员最可怕的噩梦。虽然这个问题没有完美的答案，但我认为，与其靠蛮力记住每个 Git 命令，不如分享一个 Git 命令的紧凑列表和每天使用的情况对其他数据伙伴来说可能更本能🙃

注:总分行=总分行。基本上，它是部署在服务器上的代码库。为了避免混淆，在本文中我将把它称为主要分支。

I. git 分支& git 结帐

作者截图|来自 (1) — (4) ，“git branch”在您的本地机器上创建主代码库的快照。要切换到这个分支，使用“git checkout”切换到这个分支。这从终端中表示的“(myBranch)”中可以明显看出。

(3) 如果您忘记了您创建的分支的名称，只需运行git branch列出您本地机器上当前已创建的分支。

(4) 相反，如果你创建了过多的冗余分支，命令git branch -d <your branch name>会删除你指定的一个分支。

二。git 添加和 git 提交

*git add <file 1> <file 2>
git commit -m <your commit message>*

当你对代码库进行后续修改时，明智的做法是记录下你所做的每一个重要的代码编辑。随着一个项目经历多次迭代，评审 git 提交给团队一个项目进展的清晰画面。另一方面，git add允许您指定将哪个(些)文件存放到部署中。如果您希望暂存所有变更*，请使用:***

*git add .*

而是让你的生活更轻松。

三。git rebase

*git rebase -i main*

长话短说，上面的命令旨在解决您与主分支的代码冲突。

在协作环境中，期望至少有一个其他同事在同一个代码库工作。

回想一下，您正在处理代码库的快照。从你“分支”到你准备好部署你的代码的时候，其他的同事可能已经做了其他的改变，这些改变并没有反映在你的本地代码库中。因此，运行git rebase -i main将会运行你的代码库，通过你的团队所做的每一次代码提交，直到最后一次提交到最近部署中的主分支*。有两种可能的情况—***

场景(1) —代码完全自行解析，无需任何操作

这一部分不言自明。允许 Git 将您的代码提交与之前的代码提交自动合并。不幸的是，虽然 Git 相当聪明，但是当某些代码行与您当前的代码直接冲突时，我们更经常遇到:

场景(2)——发生代码冲突。进行手动更改的时间。

作者图片|运行 git rebase -i master 后的示例视图。|“I”代表交互，意味着 git 进入交互模式，这正是上面发生的情况。

虽然乍一看 Git 终端的输出似乎令人生畏，但是请注意这里输出的意图是 Git 用信号通知两件事情的方式— (1)它当前处于交互模式；(2)下面是您已经提交的代码列表 (需要解决)。

继续键入 :x (冒号(😃，然后是字母‘x’)，并选择*【Enter/Return】*键，让 Git 完成它的工作。

在某个时刻，预期会显示以下类似的输出:

Image by Author | 对于冲突类型 I ，Git 将继续陈述在您从主分支分支出来之后被其他人修改的文件列表

在您的 IDE/文本编辑器上，对于冲突类型 I ，Git 将通过以下标记指定哪些代码行是直接冲突的:

作者插图| Git 输出上面的标记，以便将代码的替代版本与您的当前代码并排进行比较

说明:【头】***>>>>>>>*之间的代码行属于另一版本的代码行。要将这些与您的更改结合起来，请修改代码以保留先前的特性，同时实现您的新更改。

⚠非常重要:请运行应用程序至少一次，以确保代码得到解决，没有问题。如果你的手动修改破坏了代码，那么当你退出重定基础模式时，修复这个小故障(“调试”)会困难得多。

最后，完成更改后，继续运行:

*git rebase --continue*

根据需要解决的代码提交的数量，上述迭代将继续，直到所有的代码提交与团队中其他人的代码提交同步🤗

四。git 合并

*git checkout main
git merge <your branch name>*

所以，如果你已经走到了这一步，给自己一个鼓励，因为你刚刚度过了最艰难的阶段。在通过运行git checkout main切换到主分支后，git merge myBranch会覆盖主分支上的代码库，以与您的重新基础代码同步。

动词 （verb 的缩写）git 推送

要在主分支上部署最新的代码，请运行以下命令:

*git push origin main*

此时，我们刚刚用 Git 完成了一轮代码版本控制😀

用于代码检查的两个基本 Git 命令

命令 1 — git 状态

*git status*

***经验法则:*当您感到困惑时，为了了解大多数情况下您的代码版本的当前状态，您应该首先运行上面的命令。

作者截图|使用 git 状态的例子。该命令总结了代码版本控制的最新状况。

命令 2 — gitk

要获得直观的概述，请运行:

*gitk*

令人惊讶的是，这是社区中提到最少的 Git 命令之一。

作者截图|在终端中运行 gitk 后显示的 UI 弹出窗口

Git 命令结束—

仅供参考和免责声明:虽然这些是我个人认为至关重要的最低限度的 Git 命令，但没有完美的答案，所以请记住，这个列表仅够日常使用(强调“日常”)。

最终，这一切都是为了找到与您的设置最相关的 Git 流！

非常感谢您的阅读，如果您发现这篇文章对您有帮助，请关注我的媒体❤

***https://geek-cc.medium.com/membership

如果上面的 Git 命令不太适用，那么这里有一些其他的文章可供参考😀：

作者:Soner Yildirim

</8-must-have-git-commands-for-data-scientists-ee6564e4631d>

作者瓦什塔·谢尔博士:

***

每位数据科学家必备的 GIT

原文：https://towardsdatascience.com/git-essentials-for-every-data-scientist-f2c016dda692?source=collection_archive---------63-----------------------

提高数据科学工具包效用的简单流程

图片由regal have来自 Pixabay

版本控制简介

版本控制就是管理一个或多个参与者对文件和目录的更改。Git 是一个非常受欢迎的版本控制系统，我们将在本课程中介绍它。

版本控制有很多好处，特别是 Git。包括对您的项目所做的历史更改的视图，自动通知冲突的工作，其中两个人有效地编写冲突的代码行，允许许多个人之间的协作，这允许团队成长。

版本控制是软件工程的一个主要部分，并且正在慢慢地被数据科学团队所采用，在这些团队中，数据科学家通常使用他们自己的技术和工作流在孤岛中工作。虽然一定程度的自主性至关重要，但是如果没有版本控制的相关流程，数据科学家之间高度协作的能力将会面临巨大的扩展困难。

什么是存储库？

你可能已经听过这个术语很多次了…仓库。

用 Git 管理的所有数据科学项目都有两个主要组件。第一个是您所做的与文件和目录相关的所有工作…你的脚本、模型，以及它们存储的位置和方式；另一部分是 Git 保存的信息，用于维护一段时间内对项目所做的所有更改的记录。

当你把这些碎片加在一起时，你就有了自己的储存库，或者像酷孩子们所说的……回购；)

你需要知道的基本命令

Git 状态

Git 状态让您知道“暂存区”中有什么

临时区域是您放置将要更改的文件的地方。这实际上是你准备了各种各样的信，并把它们放在一个盒子里准备发送。你是想从这里拿走东西还是添加更多的东西取决于你，但是当你把它们交给邮递员的时候，就再也收不回来了。这些变化将会发生。Git status 将为您提供关于准备好进入 main 的文件的信息。

Git 添加

如果你跑了git status并且发现在你的集结地没有任何东西，不要担心！您首先需要将文件添加到临时区域。你可以用git add filename这样做。您在此处添加的任何文件名都将被移动到临时区域。这意味着驻留在给定文件中的所有更改将准备好在 repo 中推送或更新。

Git 差异

现在我们可以看到什么文件在带有git status的暂存区中，但是对于您希望看到发生了什么变化的事件呢？可以用所谓的git diff。Git diff将返回原始文件和所有要做的更改之间的所有差异，分别表示为 a 和 b。

运行git diff时，你可能实际上运行的是git diff -r HEAD。HEAD将给出最近的提交，-r将与文件的特定版本进行比较。如果你想特别看到一个文件的变化，你可以在HEAD后面加上文件路径。大意是git diff -r HEAD filepath

Git 提交

一旦您将文件添加到您的暂存区域，您可以使用git commit将它们放入邮箱。请记住,“盒子”中的任何东西都是作为一个整体一起运输的。因此，如果您想撤销关于给定提交的任何操作，您必须回滚整个提交。

一个好的最佳实践是以良好的频率提交。

要记住的一件事是，你实际上不会只是运行git commit。您的命令实际上会像这样git commit -m "model updates"。这个-m是你的日志信息。这里的最佳实践是具体描述您对项目所做的更改。以后你会感谢自己的！

Git 日志

现在我要讲的最后一个命令是git log /

git log是你可以调出你的存储库的提交历史的地方。它提供了一些信息，如作者、提交日期和日志消息。

结论

我希望这是一个有用的 git 速成班！使用这些命令，让您自己和您的数据科学团队更有效地使用 Git！

在短短几分钟的时间里，你已经学会了:

• 什么是版本控制
• 知识库基础
• 5 个关键的 git 命令，当你把你的工作发布到一个仓库时，你会想要拥有它们

祝数据科学快乐！

面向数据工程师的 Git

原文：https://towardsdatascience.com/git-for-data-engineers-a8b979d8b2ab?source=collection_archive---------10-----------------------

潘卡杰·帕特尔在 Unsplash 上的照片

数据工程

面向数据工程师、数据分析师和数据科学家的简短源代码控制指南

在以前的生活中，我有时会发现自己丢失了正在进行的工作，因为它只发生在我的本地。Excel 表格、SQL 查询、Python 脚本，我已经在某个时候丢失了这些东西。尽管我在 Subversion 的职业生涯一开始就知道源代码控制，但我并没有在我的数据分析和数据工程项目中使用它。

这些年来，我意识到 Git 的应用不仅仅局限于编写后端代码、前端代码，甚至是数据库相关的东西；您可以将 git 用于任何基于提交的协作工作空间。人们可以有效地使用 Git 来模拟电视剧或超级英雄电影的编剧室。

如果 Git 本质上可以用于任何基于文本的工作，为什么你看不到人们提交 SQL 查询、数据库注释、技术文档等。，在他们的 Git 仓库里？在本文中，我将讨论你(和我——如果我不遵循我的建议，我的文章将毫无用处)应该致力于 Git 的事情。它还将讨论与 Git 相关的摩擦点和问题，这些问题使得团队很难采用它。

对一切都使用 Git(除了秘密和密钥)

SQL —查询、DDL、DML、DCL 等。

首先，使用 Git 存储数据库对象的 DDL 表、视图、存储过程等等。从结构上讲，您的数据库在任何给定的时间点都应该是可重构的。如果您将一切都提交给 Git 存储库，您将确保可重构性。然而，这并不意味着您也必须将数据存储在 Git 中。数据库结构和数据应该是分开的。无论是否使用 DDL，您的数据都应该单独备份。

其次，如果您使用数据库运行查询来进行分析和报告，那么您应该将查询推送到 Git。这主要是问题发生的地方。能够访问数据库的业务、营销、运营、分析团队通常不太了解 Git。他们将查询存储在基于浏览器的查询编辑器、文本编辑器或 SQL 客户端中。通常，这些东西都不直接与 Git 回购相关。人们可以将 Oracle SQL Developer 等 SQL 客户端和 VSCode 等代码编辑器直接与数据库引擎连接，以确保顺利开发和将代码推入 Git。尽管如此，这通常是产生摩擦的原因。

工作流/编排者

在数据工程领域，如果没有工作流引擎来协调工作，什么也做不成。无论是 AWS Step 函数和 Lambda 函数、 AWS Glue job s、 Airflow DAG s 的组合，你都需要确保底层代码被提交给一个存储库。这有两个简单的原因。首先，您将需要与其他人合作完成您的工作，如果您丢失了本地副本，请进行备份。其次，您需要它易于部署。

CI/CD 管道

在上一节中，我谈到了 ETL 作业的易部署性。CI/CD 管道，顾名思义，确保代码的持续集成和部署。除了为 ETL 管道部署代码，数据库结构的改变等。，您还需要将管道代码提交给 Git。这意味着您需要存储 Jenkins、Bamboo 和其他 CI/CD 工具的管道配置，并将其提交给 Git。

有关管理 GitHub 组织或 GitLab 团队下的多个存储库和分支的更多信息，请阅读 Jenkins 的 Pipeline-as-Code 。许多其他基于云的管道工具也内置了这些特性。

数据基础设施(Terraform/CF)

我们需要向 Git 承诺的一个更新的东西是基础设施。基础设施即代码不再是未来的事情。企业使用 CloudFormation、HashiCrop Terraform、Pulumi 等。，在内部和云中部署基础架构。使用像 Chef、Puppet 和 Ansible 这样的工具进行配置管理在很多年前就已经很流行了，但是 IaC 还是一个相对较新的东西。

莫希特·戈亚尔关于 Terraform 和 Azure DevOps 的 7 部分系列的最后一部分对使用 Git 库提交和管理基础设施代码的主题有许多很好的见解。

注释和文档

最后，在协作环境中，更多的时候，信息分布在聊天群、电子邮件、群呼(无处可去)，天知道还有哪里。它是杂乱无章的。你应该把笔记和文件集中起来。如果你使用的是像 Atlassian 的 Confluence 这样的集中式文档产品，那就没问题；另外，我发现在 Git 上编写文档很方便。

在将代码提交到您的分支之前，您倾向于在编写代码时编写更准确的信息。此外，当您在 Git 上编写文档时，文档感觉是代码的一部分，实际上也是，但是没有多少人认为是这样。如果你和一个团队一起工作，没有文档的代码不是一个好主意，尤其是一个没有 Shekher Kirani 所热衷的那些 10 倍工程师的的团队。

使用 Git 进行数据工程的经验法则

既然我们已经了解了向存储库提交什么，我们需要了解一些要遵循的基本规则和要避免的反模式。

提交代码，而不是数据

一个前同事正在做一个项目。尽管他作为数据分析师非常有经验，但他从未向 Git 提交过代码。因为笔记本电脑崩溃或操作系统损坏而丢失工作，这让他开始使用 Git。一旦他开始使用 Git，他立刻意识到了它的好处。他第一次向 Git 提交代码时，也在存储库中提交了巨大的 CSV 文件。显然，很多人都会犯这个错误。

数据文件不应该提交给 Git，原因有三

• 文件会变得非常非常大——例如 GitHub 对大于 50 MB 的文件有规定。这些规则是经过深思熟虑的。对于大多数用例来说，这是有意义的。记住，一个 50 MB 的文本文件大概相当于一百万行代码。
• **Git 是为了存储代码，而不是数据——**不在 Git 中存储数据背后的想法很简单——你应该隔离代码和数据。只要数据集符合特定的模式并遵循格式化和数据类型化的预期，代码就应该不管数据集中的确切数据如何都能正常工作。
• 数据可能包含 PII(个人身份信息)数据— 尽管 Git 存储代码是安全的，但了解许多开发人员、测试人员、数据工程师和数据分析师都可以访问代码库是至关重要的。如果您提交包含 PII 数据的哪怕是最小的文件，他们都能够看到，从而违反了数据隐私和治理规则。

永远不要保守秘密

将秘密提交给 Git 源于一个做**git add .**的坏习惯，它甚至将您的本地开发文件提交给 Git——这些文件中存储了 API 密钥、密码和用于开发目的的秘密。请务必将此类文件放在**.gitignore**中。

如果你没有制衡机制来防止这种情况发生，很有可能有人会这么做。您可以使用各种方法从 Git 存储库中移除敏感数据。像**git filter-branch**和**bfg repo-cleaner**这样的工具是一些受欢迎的选择。最好不要将凭证存储在文件中，即使是出于开发目的。您可以使用像 HashiCorp Vault、AWS Secrets Manager 和其他这样的工具来标记和回收机密。如果你想研究企业工具，有许多选项，如 Honeybadger 、夜幕和 GitGuardian ，它们可以帮助你防止 Git 灾难。

遵循分支策略

我之前写过关于菜鸟 Git 的错误。不遵循分支策略就是其中一个错误。当你在一个团队中工作时，你需要确定一个将代码拉入、开发、合并和推进到你的存储库中的过程。这就是代码升级如何从较低的环境到较高的环境发生(读取开发→测试，测试→生产前，生产前→生产，等等)。).

有效地使用 Git 是一项技能，您需要在前进的过程中不断努力。从最普通的拉取、推送提交和合并，您还应该了解精选、过滤分支、恢复等等。

离别的思绪

一直有人问我，如果想成为工程师，应该学习哪些技术，了解哪些概念。我通常的回答是，一个人必须真正了解 SQL 和一种用于编写脚本的编程语言(最好是 Python)。工具和技术的清单不断增加。下一次有人向我寻求建议时，在继续告诉他们学习 Airflow 或 Databricks 或 Kubernetes 之前，我一定会让他们先在 Git 中入门(**git init**——我是多么有趣，这几乎令人难过)。

如果你有兴趣阅读更多我的作品，请访问我的写作作品集。如果你想讨论数据库、仓库、基础设施或云计算，请通过 LinkedIn 联系我。

GitHub Copilot——新一代人工智能程序员

原文：https://towardsdatascience.com/github-copilot-a-new-generation-of-ai-programmers-327e3c7ef3ae?source=collection_archive---------14-----------------------

人工智能

GitHub、微软、OpenAI 都达到了一个新的里程碑。

妮可·沃尔夫在 Unsplash 上的照片

当 OpenAI 去年发布 GPT-3 时，人们对它从自然语言提示中生成代码的能力感到惊讶。 Sharif Shameem 和其他人兴奋地分享了他们的发现，很快炒作和担忧就一飞冲天了。但是 GPT 3 号远不是一个伟大的程序员。它能理解英文文本并将其转换成一段代码，这是一个值得注意的壮举，但它的表现平平。

OpenAI 和微软(现在资助他们的项目)在 GPT-3 的编码能力中看到了一个非常有前途的商业产品，并很快开始开发另一种语言模型；一个程序员 AI。新的模式将权衡，关于 GPT-3，一般语言技能的编码能力。这个“GPT-3 的后代”，正如 Greg Brockman 所说，被称为 OpenAI Codex，它是该领域最新突破背后的人工智能:GitHub Copilot。

两天前，OpenAI、GitHub 及其母公司微软展示了 GitHub Copilot ，这是一款由 OpenAI Codex 提供支持的人工智能工具，它可以作为一对程序员，帮助人类开发人员编写代码。这是未来几年将变得无处不在的新一代人工智能程序员中的第一个，也是自 GPT-3 以来该领域最重要的里程碑。这将为软件行业的彻底变革打开大门，但这些变革对劳动力有利或有害的程度仍是未知的。

GitHub Copilot——人工智能配对程序员

事实真相

GitHub Copilot(从现在开始 Copilot)是一个人工智能工具——目前正在技术评审中——它可以在程序员编写代码时向他们提出建议。微软已经在 Visual Studio 代码中实现了它，并将它集成到商业 VS 产品中。目前，它只对少数开发者开放(你可以试试你的运气这里)。

副驾驶并非同类产品中的首创；Tabnine 和 Kite 是两个涵盖相同功能的流行工具。然而，Copilot 之所以脱颖而出，是因为它由 Codex 提供支持，Codex 是 GPT-3 的后代，它提供了比其他助手更深入的背景理解。Codex 类似于 GPT-3，有一个重要的区别:它接受了来自 GitHub 知识库和其他网站的大量公开编码数据的训练。

Codex 是一种编程语言模型，OpenAI 将在今年夏天将其集成到他们的 API 中。它在这方面的能力大大超过了 GPT-3——或 GPT-J 。正如我在之前的一篇文章中所论述的，类似 GPT 的模型似乎在他们专注于一项任务时释放出一种潜在的力量。GPT-3，万能的杰克，在许多任务上是惊人的。相比之下，Codex 是编码大师。

但是 Codex 和 Copilot 都不是完美的。考虑到那些预先测试它的人的证词，这个工具工作得很好。但是，就像所有由人类编写的代码一样，副驾驶的代码应该经过“测试、审查和审核”GitHub 开发人员创建了安全机制来为用户提供最佳体验，但系统“有时可能会产生不希望的输出，包括有偏见的、歧视性的、辱骂性的或攻击性的输出。”Copilot 代码甚至可能无法编译，因为它不会测试输出的代码。简而言之，这是一种新工具的早期版本；它有缺陷，但它的承诺大大超过这些缺陷。

它的作用

在 GitHub 页面上，有 Copilot 惊人表现的例子。它可以完成代码行或编写完整的函数，将描述性注释转换成代码，自动填充重复的代码，或者为您的方法创建单元测试。它可以接受当前行以上的几百行作为输入，但是有一个重要的限制:不能从其他文件中输入代码。

它与 Python、JavaScript、TypeScript、Ruby 和 Go 配合得最好，但它“理解几十种语言”。但是，因为它有时会失败，所以在探索新的库或用未知的编程语言编写时，它可能更有用。否则，审阅 Copilot 的代码可能比自己编写代码要花更多的时间。

Copilot 基于一种类似于 GPT-3 的语言模型，所以它已经适应了它被训练的代码。但是，随着你使用它，它开始“理解”你的风格并适应你。而如果你不喜欢第一个建议，你可以要求它提供 top-k 的解决方案。

Copilot 的重要含义

语言模型的力量

GPT-2，GPT-3，开关变压器，LaMDA，MUM，悟道 2.0…预先训练的语言模型现在是人工智能的蛋糕，该领域的每个主要参与者都在争夺最大的份额。原因是这些模型工作得非常好。GPT-3 是最受欢迎的，这是理所当然的。当 OpenAI 发布 GPT-3 API 时，它让世界得以一窥它的威力，并且它生效了。GPT 3 号如此强大，性能如此之好，人们甚至敢称它为 AGI——其实不然。

然而，因为 GPT-3 是一种通用语言模型，所以可以合理地假设，如果做好充分准备，它可以提高在特定任务中的性能。基线 GPT-3 可以被描绘成一个万事通，而其专业版本将是他们的任务的主人。DALL E 是这种可能性的第一个暗示。OpenAI 在文本-图像对上训练该系统，这使得 DALL E 能够从字幕和更多内容中生成图像，在视觉创意方面表现出色。 GPT-J ，一个比 GPT-3 小 30 倍的类似系统，可以生成更好的代码，因为它在 GitHub 和 StackExchange 数据上进行了大量训练。 PALMS ，一种减少 GPT-3 偏差的方法，进一步加强了这个假设。研究人员通过在一个小型精选数据集上进行微调，显著改善了 GPT-3 的行为。

现在，Copilot 与 Codex 合作，已经明确证明了这一想法:语言模型可以专门化，成为它们的贸易大师。Codex 是编程大师，那么一个超级强大的专业语言模型还能掌握哪些领域呢？他们能掌握逻辑或数学等其他形式语言吗？他们能掌握 GPT 3 号的每一项功能吗？一个语言模型能写出莎士比亚、塞万提斯或托尔斯泰水平的小说吗？它能成为今年夏天最热门的歌曲吗？什么是可能的还不清楚。清楚的是，我们还没有发现它们的极限。

编码的未来

当 GPT-3 发布时，许多人看到了编码终结的另一个垫脚石；无代码接管的速度比我们想象的要快。现在，Copilot 将担忧提升到了前所未有的程度。顾名思义，它被设计成一个合作伙伴。GitHub 说“你是飞行员”，但是我们怎么能确定这在未来不会改变呢？

它的创造者希望 Copilot“让现有的工程师更有效率，减少手动任务，帮助他们专注于有趣的工作。”然而，在人工智能也能更快、更便宜、更准确地完成这项“有趣的工作”之前，还需要多少时间呢？GitHub 首席执行官 Nat Friedman 说“我们每天解决的问题可能会改变。但总会有问题需要人类去解决，”但也许不是同一批人会准备去解决新的问题。

未来是不可预测的，今天可能会出现两种情况:要么我们与人工智能建立共生关系，为每个人找到一席之地，要么人工智能将接管许多工作。即使它从未达到完美，Copilot 或它的继任者也可以消除程序员的必要性，只留下少数人来“测试、审查和审核”AI 的代码。我们只能希望，如果发生工作岗位的转移或替代，决策者将做出适当的反应，并为受影响的人提供安全网。

有用不可靠？

如果 Copilot 不是 100%可靠，它有用吗？到什么程度，在哪些情况下不使用比较好？一个不专业的程序员能利用它吗？或者它更适合专业程序员，他们会花更多的时间来检查代码而不是自己写代码。副驾驶的不可靠性引发了许多与实用性相关的问题。

乔尔·斯波尔斯基(Joel Spolsky)的一句名言现在派上了用场:“阅读代码比编写代码更难。”一个没有经验的程序员可能不知道 Copilot 代码的问题，而一个经验丰富的程序员更喜欢写代码，而不是阅读 Copilot 生成的代码。使用 Copilot 显然是值得的情况很少:一个有经验的程序员想要尝试一个新的库/语言/框架，或者想要基于手工制作的方法编写单元测试(尽管那些也需要被审查)。另一种情况是一个没有经验的程序员开始学习。

然而，还有比 Copilot 写低质量代码更大的问题。来自 GitHub 的常见问题:“世界上有许多公共代码存在不安全的编码模式、错误或对过时 API 或习惯用法的引用。当 GitHub Copilot 基于这些数据合成代码建议时，它也可以合成包含这些不良模式的代码。”一个值得考虑的问题是，Copilot 会减少还是增加这些问题的数量。

法律问题

*我不是律师，也绝对不是美国法律专家，*但是 Nat Friedman 开设的 黑客新闻 帖子提出了关于知识产权、许可证和版权侵权的重要问题。GitHub 在 Copilot 常见问题中表示，“大约 0.1%的时间”Copilot 的建议是“逐字来自训练集”。这意味着 Copilot 用户可能会采纳一个建议，该建议包含与项目目的相冲突的受版权保护的代码。这就提出了一个重要的问题:在这种情况下，谁应该承担责任，用户，GitHub/微软，还是拥有该项目的公司？

他们还提到“您应对您在 GitHub Copilot 的帮助下创建的内容负责。我们建议您像对待自己编写的任何代码一样，仔细测试、审查和审核代码。”这是否意味着，如果我们使用了 StackOverflow 提出的 Copilot 建议，而该建议恰好受到 GPL 许可，我们就要对侵权行为负责？怎么才能知道 Copilot 是否抄袭了一大块我们用不到的代码？公司会允许员工使用 Copilot 吗？还是会因为禁止从 StackOverflow 复制代码的原因而禁止使用 Copilot？

另一位用户指出，如果 GitHub 没有将 Copilot 培训限制在“一个合理的许可白名单(mit、BSD、Apache 等)”中，那么使用该工具从事“重要/创收”项目将是一个风险。没有信息表明这是真的还是假的，因此上述问题似乎是合理的。Nat Friedman 表示，关于知识产权和人工智能的辩论将在未来几年内发生，但就目前而言，使用 Copilot 可能会产生更多问题，而不是解决方案。

结论

GitHub Copilot 注定要改变全世界很多程序员的日常。尽管我强调了这些问题，但这项技术是一个重要的里程碑，将引领未来走向无代码，这是微软多年来一直追求的目标。

副驾驶感觉像一个拐点，没有人知道事件将如何从这里展开。程序员几年后会开始失业吗？我们会设法找到一个有益的飞行员-副驾驶协同作用吗？它会提供这样一种优势，以至于企业要么不得不适应它，要么就死掉吗？程序员会不得不以职业生存换取隐私吗？

自周二以来，出现了许多问题，还会有更多的问题出现。目前，答案还需要等待。GitHub Copilot 启动。让我们睁大眼睛，看看它将把我们带向何方。

跟我一起旅行到未来 了解更多关于人工智能、哲学和认知科学的内容！还有，可以在评论里随意提问或者在LinkedIn或者Twitter！😃

推荐阅读