1、说明    需要本地有安装有git，从官网下载https://git-scm.com/downloads选择对应系统版本。2、配置本地的git    打开git Bash生成新的密钥，email可以为任何email地址ssh-keygen -t rsa -C "您的email"复制秘钥Windows:clip < ~/.ssh/id_rsa.pubMac:pbcopy < ~/.ssh/id_rsa.pubLinux (requires xclip):xclip -sel clip < ~/.ssh/id_rsa.pub写入到华为SSH秘钥管理中3、使用git clone项目到本地打开git Bash输入命令git clone {git地址}成功后即可在该目录看到克隆下来的项目4、推送至远端仓库在项目目录下打开git Bash，输入命令git push即可将新代码推送至主干5、git使用教程推荐https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000

上传文件到华为云1、点击桌面右键，选择“Git Base Here”，进入后，切换到指定目录，先将项目拉取到本地，形成本地仓库2、就需要上传的文件复制到该项目目录下3、给上传的新文件添加备注，并将新文件上传到华为云4、登录华为云，查看是否上传成功遇到错误将华为云文件拉去到本地，手动（点击右键，选择“Git Clone”），当输入用户名或密码错误时，会出现如下错误解决方法：控制面板，选择“凭据管理器”，选择“Windows凭据”，点击删除即可

漏洞描述:Gitlab是一款基于Git 的完全集成的软件开发平台，且具有wiki以及在线编辑、issue跟踪功能、CI/CD 等功能。2021年3月18日Gitlab官方发布安全更新，修复了一处远程代码执行漏洞，攻击者可构造恶意请求，在Gitlab服务器上执行任意代码，控制服务器。提醒Gitlab用户尽快采取安全措施阻止漏洞攻击。漏洞评级:Gitlab markdown 远程代码执行漏洞 严重。影响版本:Gitlab CE/EE < 13.9.4Gitlab CE/EE < 13.8.6Gitlab CE/EE < 13.7.9安全版本:Gitlab CE/EE 13.9.4Gitlab CE/EE 13.8.6Gitlab CE/EE 13.7.9安全建议:1. 升级Gitlab至安全版本。2. 将Gitlab服务器部署于内网，或通过设置安全组仅对可信地址开放。相关链接:https://about.gitlab.com/releases/2021/03/16/security-release-gitlab-13-9-4-released/#remote-code-execution-via-unsafe-user-controlled-markdown-rendering-options

root@ecs-385f:~/go/src/golang.org/x# git clone https://github.com/golang/sync.git Cloning into 'sync'... remote: Enumerating objects: 23, done. remote: Counting objects: 100% (23/23), done. remote: Compressing objects: 100% (19/19), done. remote: Total 153 (delta 9), reused 12 (delta 4), pack-reused 130 Receiving objects: 100% (153/153), 60.66 KiB | 149.00 KiB/s, done. Resolving deltas: 100% (68/68), done. root@ecs-385f:~/go/src/golang.org/x# git clone https://github.com/golang/crypto.git Cloning into 'crypto'... ^C root@ecs-385f:~/go/src/golang.org/x# git clone https://github.com/golang/crypto.git Cloning into 'crypto'... ^C root@ecs-385f:~/go/src/golang.org/x#  root@ecs-385f:~/go/src/golang.org/x#  root@ecs-385f:~/go/src/golang.org/x#  root@ecs-385f:~/go/src/golang.org/x#  root@ecs-385f:~/go/src/golang.org/x#  root@ecs-385f:~/go/src/golang.org/x# git clone https://github.com/golang/sys.git Cloning into 'sys'... fatal: unable to access 'https://github.com/golang/sys.git/': gnutls_handshake() failed: The TLS connection was non-properly terminated. root@ecs-385f:~/go/src/golang.org/x#github下拽包的时候，有时候能通，大部分时候不通。解决的办法可以修改/etc/host文件## GitHub Start 140.82.112.4 github.com 192.30.253.112 github.com 192.30.253.113 github.com 151.101.184.133 assets-cdn.github.com 199.232.69.194 github.global.ssl.fastly.net 151.101.185.194 github.global.ssl.fastly.net 192.30.253.112 github.com 192.30.253.113 github.com 192.30.253.118 gist.github.com 151.101.185.194 github.global.ssl.fastly.net 151.101.129.194 github.global.ssl.fastly.net 151.101.65.194 github.global.ssl.fastly.net 151.101.1.194 github.global.ssl.fastly.net 151.101.193.194 github.global.ssl.fastly.net 151.101.77.194 github.global.ssl.fastly.net 151.101.229.194 github.global.ssl.fastly.net 151.101.113.194 github.global.ssl.fastly.net 151.101.196.133 assets-cdn.github.com 151.101.24.133 assets-cdn.github.com 185.199.111.153 assets-cdn.github.com 185.199.110.153 assets-cdn.github.com 185.199.108.153 assets-cdn.github.com 185.199.109.153 assets-cdn.github.com 151.101.112.133 assets-cdn.github.com 151.101.112.133 avatars0.githubusercontent.com 151.101.112.133 avatars1.githubusercontent.com 151.101.184.133 avatars2.githubusercontent.com 151.101.12.133 avatars3.githubusercontent.com 151.101.12.133 avatars4.githubusercontent.com 151.101.184.133 avatars5.githubusercontent.com 151.101.184.133 avatars6.githubusercontent.com 151.101.184.133 avatars7.githubusercontent.com 151.101.12.133 avatars8.githubusercontent.com 151.101.184.133 raw.githubusercontent.com 151.101.112.133 gist.githubusercontent.com 151.101.184.133 cloud.githubusercontent.com 151.101.112.133 camo.githubusercontent.com 52.216.227.168 github-cloud.s3.amazonaws.com 192.30.253.112 github.com 185.199.108.153 assets-cdn.github.com 151.101.185.194 github.global.ssl.fastly.net 140.82.113.10 codeload.github.com # 下载慢问题 219.76.4.4 github-cloud.s3.amazonaws.com ## GitHub Endreboot后测试有效。root@ecs-385f:~/go/src/golang.org/x# git clone https://github.com/golang/crypto.git Cloning into 'crypto'... remote: Enumerating objects: 91, done. remote: Counting objects: 100% (91/91), done. remote: Compressing objects: 100% (83/83), done. remote: Total 5915 (delta 29), reused 20 (delta 8), pack-reused 5824 Receiving objects: 100% (5915/5915), 4.68 MiB | 59.00 KiB/s, done. Resolving deltas: 100% (3765/3765), done. root@ecs-385f:~/go/src/golang.org/x#

想问一下  华为版 fi 的flink  重点构建的 代码 ,有没有开源GitHub , 有分支开源可以看的代码吗? Flink在当前版本中重点构建如下特性：DataStreamCheckpoint窗口Job Pipeline配置表其他特性继承开源社区，不做增强，具体请参 ：https://ci.apache.org/projects/flink/flink-docs-release-1.12/。

编译在mdc上使用的程序，只要链接了： ascendcl runtime iam easy_comm slog 这几个库，程序就会直接陷入死循环。和程序内容无关。具体程序见压缩包test_hello.zip，直接./build.sh 即可编译出程序。在没有连摄像头的mdc设备上运行改程序会有如下现象，打印了一行EnvManager之后立刻陷入死循环[root@minieye-Latitude-5401 opt]# ./shit EnvManager[ProcName][WARN]: PROC_NAME is set to default name: shit 使用gdb 调试，直接中断，调用栈内容如下：      可以看到是在ascend_hal 这个库里面调用了buff_manage_int函数，最后卡在epoll_wait中。

编译在mdc上使用的程序，只要链接了： ascendcl runtime iam easy_comm slog 这几个库，程序就会直接陷入死循环。和程序内容无关。具体程序见压缩包test_hello.zip，直接./build.sh 即可编译出程序。在没有连摄像头的mdc设备上运行改程序会有如下现象，打印了一行EnvManager之后立刻陷入死循环[root@minieye-Latitude-5401 opt]# ./shitEnvManager[ProcName][WARN]: PROC_NAME is set to default name: shit 使用gdb 调试，直接中断，调用栈内容如下：      可以看到是在ascend_hal 这个库里面调用了buff_manage_int函数，最后卡在epoll_wait中。

产业 GitHub率先消灭了cookies：与烦人的用户条款说再见终于好起来了？GitHub 的「大动作」会引领一种新风向吗？2020/12/24 14:34原文链接理论光学预处理与计算机视觉结合，UCR学者用漩涡实现混合计算机视觉系统这种新方法能够克服深度学习的缺点，并利用光学和电子学的优势。2020/12/24 14:39原文链接AI前线国产开源软件在Github上“刷星”遭热议，这还是开发者的理想乌托邦吗？Github上疯狂“刷星”为哪般？2020-12-24 14:55原文链接快讯高盛牵头收购 Bot 缓解公司 White Ops旨在保护企业和在线平台免受自动攻击的欺诈检测平台 White Ops 近日宣布该机构已被高盛的商业银行部门，ClearSky Security 以及 NightDragon 合作收购。据了解，总部位于纽约的 White Ops 成立于 2012 年，使用威胁情报和机器学习来检测冒充人类行为的恶意机器人。根据 Crunchbase 的数据，White Ops 此前曾筹集了 3100 万美元，该公司表示，在过去一年中，其客户群增长了 40％。高盛公司是其主要所有者之一，因此 White Ops 处于有利的地位，可以在整个企业范围内「开拓新的垂直市场」。（VentureBeat）2020-12-25 07:50原文链接彭博社收购 Second Measure 以"解锁"交易数据洞察彭博社今日宣布，该公司已收购数据分析平台 Second Measure。据了解，这是一家位于圣马特奥的初创公司，利用大数据收集对消费者行为和公司绩效的洞察力。Second Measure 成立于 2015 年，已开发出自助服务分析平台，该平台使用来自「数十亿笔匿名交易」的数据（包括信用卡付款）支持实时和每日指标跟踪。它的机器学习算法可以扫描购买记录以生成洞察力，例如可以通过地理或时间范围进行比较，并将其用于预测分析。多年来，Second Measure 积累了许多知名客户，包括 Instacart，Postmates，Domino』s，Spotify 和 Goldman Sachs。（VentureBeat）2020-12-25 07:49原文链接谷歌被报加强了对「敏感主题」的研究谷歌目前显然因辞退人工智能偏见研究人员 Timnit Gebru 而饱受争议。据路透社报道，该公司的其他工作人员被要求「保持积极态度」，并接受其他审查以抚慰「敏感主题」相关研究人员。路透社援引该公司的研究人员和内部文件的报道称，谷歌去年已经实施了新的控制措施，包括对某些主题的论文进行一轮额外的检查，并且在后期研究阶段似乎增加了对管理人员的干预。2020-12-25 07:48原文链接美国国家电网将机器学习视为未来公用事业背后的大脑如果可以将企业风险投资公司的投资组合作为其母公司战略优先事项的信号，那么美国国家电网就将自动化作为公用事业的未来寄予厚望。作为美国最大的私有公用事业公司之一，美国国家电网拥有约 2000 万人的客户群，对自动化和机器学习的高度重视非常重要。并标志着该行业的发展方向。自成立以来，美国国家网格的风险公司国家网格合作伙伴已投资了 16 家以机器学习为核心的创业公司。近日，该公司还宣布支持 AI Dash。这一机构使用机器学习算法来分析卫星图像并推断国家电网输电线上的植被受到侵害，以避免中断。（TechCrunch）2020-12-25 07:48原文链接人工智能项目发现新的月球陨石坑由人工智能提供支持的新型陨石坑发现工具发现，月球表面比我们想象的还要坚固。在本周发表在《自然通讯》杂志上的一项研究中，来自中国，意大利和冰岛的国际研究人员小组使用利用中国月球轨道器收集的数据来训练的机器学习算法，在月球的低纬度和中纬度地区识别并绘制了 109,000 个新的陨石坑的位置图。新近确定的陨石坑大部分直径为 0.6 到 60 英里（1 到 100 公里）。据了解天文学家以前曾数过大约 5,000 个直径大于 12 英里的陨石坑。（OBSERVER）2020-12-25 07:09原文链接Facebook AI 新博客揭秘图像分类新技术Facebook AI 近日在其博客表示，该团队开发出一种新的方法来训练利用 transformers 的计算机视觉模型，该技术是突破性的最近在 AI 的许多领域都取得了巨大的进步的深度神经网络架构。Transformer 模型在自然语言处理和机器翻译中产生了最先进的结果，Facebook AI 已使用该体系结构为其他任务开辟了新局面，例如语音识别，符号数学和编程语言之间的翻译。但是，人工智能研究界才刚刚开始将「transformer」带入计算机视觉领域，并于今年早些时候发布了诸如 Facebook AI 的 DETR 对象检测架构之类的项目。该款新技术-数据高效的图像 transformer（DeiT）-需要更少的数据和更少的计算资源来生成高性能的图像分类模型。仅用一台 8-GPU 服务器在 3 天内训练 DeiT 模型，该团队在广泛使用的 ImageNet 基准测试中达到了 84.2 top-1 准确性，而无需使用任何外部数据进行训练。该结果与最先进的卷积神经网络的性能具有竞争优势，而卷积神经网络多年来一直是图像分类的主要方法。2020-12-25 07:01原文链接南洋理工大学&商汤科技研究所：生成模型的焦点频率损失近日，来自南洋理工大学以及商汤科技研究所的研究团队发表了一篇名为「生成模型的焦点频率损失」的新研究。以下是该研究的完整摘要分享：尽管生成模型在使用深度神经网络创建逼真的图像方面取得了巨大的成功，但实际图像和生成的图像之间仍然存在差距，尤其是在频域中。在这项研究中，研究人员发现缩小频域间隙可以进一步改善图像合成质量。为此，该团队提出了焦点频率损失这一新的目标函数，它将生成模型的优化引入频域。所提出的损耗使模型可以动态地关注于难以通过降低易用频率的权重来合成的频率分量。这个目标函数是对现有空间损耗的补充，由于神经网络的固有关键性，对重要频率信息的丢失提供了很大的阻抗。该研究证明了聚焦频率损失的多功能性和有效性，可改善感知质量和量化性能方面的各种基准。GitHub 传送门：bit.ly/38wVBOk2020-12-25 07:00原文链接 

【功能模块】【操作步骤&问题现象】1、agg的时候sum(case when里有to_char和to_date，发现性能很差，优化成immtable的函数后性能从6分钟提升到40秒2、pck的列为columnA和columnB，只过滤columnB的情况下pck会提高性能么？我实际试了试试提高了性能的，但是我之前理解应该是只有按照columnA或者columnA+columnB过滤才会有效，请教下为啥【截图信息】【日志信息】（可选，上传日志内容或者附件）

GitOps通过使用成熟的DevOps优秀实践（包括：版本控制、代码审查、以及CI/CD管道等），提供了一整套自动化的管理方法。本文向您介绍GitOps基本原理、组成与优势。如今，许多团队都在各种项目中争相使用着诸如：版本控制、代码审查、以及CI/CD管道等，与DevOps有关的优秀实践。不过，您是否注意到，这些方法主要针对的是软件开发生命周期中的自动化。而在涉及到基础架构的设置和部署时，项目团队仍然主要依赖的是手动的过程。对此，GitOps提供了一套管理基础架构的自动化方法。项目团队可以借助GitOps，并通过使用各种声明文件，将基础架构编写为代码(infrastructure as code，IaC)，进而自动化配置的过程。也就是说，我们可以像存储应用程序的开发代码那样，将基础架构存储放在Git存储库中，以提高整体的交付能力和产品质量。GitOps的工作原理GitOps的概念最初是由Kubernetes管理公司--Weaveworks(请参见https://www.weave.works/)提出的。众所周知，基于容器的应用往往比较复杂，而且难以进行配置和管理。因此，GitOps主要针对的是：在Kubernetes背景下，如何将编排平台转换到运行在容器中的微服务上，并采用DevOps领域的成熟技术，来协助简化该过程。下面我们将深入讨论GitOps的各个主要组成部分：基础架构即代码(IaC)如前所述，IaC可以通过将各种声明性文件存储为代码，进而实现基础架构的配置和管理。据此，通过利用IaC和版本控制，项目团队可以优化当前的各项操作进程。此处提到的声明式(Declarative)，意味着您的配置将不再是一组命令，而是对某种预期状态的声明。例如，在Kubernetes中，您可以在清单文件(manifest)中定义服务所需的Pod数量。系统将通过自行处理，获取所需的容器编号，而无需工程师额外编写命令脚本。在此，任何符合声明性模型的云原生软件，都可以被视为代码。通常，我们会将各种所需的状态声明为代码，并通过系统应用的更改，以自动化的方式实现目标状态。例如：我们可以使用诸如AWS CloudFormation之类的声明性工具，来编写AWS的基础架构。拉取请求(Pull Requests)GitOps概念背后的主要思想是：版本控制系统是唯一的来源。我们既可以将Git用作应用代码的变更管理系统，通过拉取请求来实现各项操作性的变更，又可以将其用于基础架构的代码上，以便将整个声明文件集中于一处。在应用开发的工作流中，我们需要将某个主分支作为发布分支。在此基础上，开发人员会从主分支处创建各个功能性分支，以便开发出特定的功能或故事线。而在功能性分支上，一旦完成了更改，他们会通过创建拉取请求的方式，重新合并回主分支。这样一来，我们就可以在方便实现协作的同时，透明地获悉到谁在何处进行何种更改。而且，由于所有更改都是在Git处被提交的，因此这对于开发团队从根本原因处进行问题的跟踪，也是非常实用的。可见，创建拉取请求的好处在于，我们可以让代码在被集成到代码库的另一个分支之前，事先经历代码的审查过程。而代码审查恰好能够阻止各种不良的代码，进入测试或生产环境。显然，这对于故障的消除，以及基础架构代码而言，都是非常重要的。Git的组成GitOps并不依赖于任何工具或技术。它可以与诸如：GitHub、BitBucket或GitLab等，任何基于Git的系统协同使用。而在部署过程中，GitOps至少需要两个存储库，即：包含了应用源代码、及其部署清单的应用程序存储库;和使用着每个环境的声明性规范描述的，包含了整个系统目标状态的环境配置存储库。您可以在代码存储库中将目标环境定义并描述为开发环境、测试环境、生产环境、或是包含了运行着特定版本的应用和基础架构服务的环境。CI/CD要实现完整的GitOps，您势必需要一个CI/CD管道，以实现Git存储库在每次发生更改时，开发团队都能将对应的基础架构变更交付到指定的环境中。该自动交付管道能够将Git的拉取请求连接到编排系统中，以便通过请求来触发管道，并让编排系统执行指定的任务。一般而言，GitOps有两种可能的部署策略：推送管道和拉取管道。您可以根据当前架构需要部署的实际环境，在两者间做出选择。下面我们来具体看看两种策略的各种特点：推送管道(Push Pipelines)目前，许多流行的CI/CD工具都在使用这种策略。开发人员通常将应用程序的源代码、及其部署清单存储在一个存储库中。当应用代码发生变更时，管道将触发容器映像的构建，并将变更推送到相应的环境中。由于该策略支持任何类型的基础架构，因此它具有较大的灵活性。不过，其缺点是：它会赋予CI/CD工具对于目标环境的写入权限。基于推送的DevOps部署拉取管道(Pull Pipelines)在开发者社区中，人们普遍认为：对于GitOps的拉取管道方法是一种更安全的策略。这种方法引入了操作符(operator)的概念。它是管道和业务流程工具之间的组件。操作符能够不断将环境存储库中的目标状态，与已部署的基础架构的实际状态，进行比较。如果操作符检测到任何修改，那么它就会更改基础架构，以适应环境存储库。同样地，它也可以监视镜像注册表，以识别出需要部署的镜像新版本。基于拉取的DevOps部署可见，在GitOps中，只有在环境存储库中出现修改时，对应的环境才会更新。相反，如果已实施的基础架构在环境存储库中并未定义任何方式的修改，那么系统将会自动还原。在实际项目中，大多数应用程序都会同时涉及到多个环境。对此，GitOps允许您创建多个管道，以同时更改多个环境存储库。当然，您也可以在环境存储库中使用单独的分支，来管理多个环境。我们既可以通过将操作符部署到生产环境中，来对单个分支的修改及时做出反应，又可以通过部署到测试环境中，来响应另一个分支。GitOps的优势由于GitOps专注于Git工作流、IaC、CI/CD管道，不可变服务器(immutable servers)、跟踪、以及可观测性等优秀实践模型，因此它代表了对于Kubernetes云原生应用管理的高级状态。据此，开发团队可以从如下方面受益：简化持续部署顾名思义，持续部署(https://microtica.com/cracking-the-continuous-deployment-code/)意味着更快、更频繁的部署。通过GitOps，部署操作符提供了必要的结构和自动化，而且这一切都在版本控制系统中发生，因此我们无需各种工具，便可管理系统的状态、停机时间、上游/下游依赖关系、以及其他与组织相关的流程。此外，GitOps不但提高了项目团队的生产率，而且加快了他们的平均部署时间(Mean-time-to-deployment，MTTD)。有证据表明，自动化持续部署能够确保团队每天触发30到100次以上的变更，并将生产环境的性能平均提高2到3倍。缩短平均修复时间(Mean-time-to-repair，MTTR)MTTR是衡量DevOps团队绩效的一项关键指标(https://microtica.com/13-devops-metrics-for-increased-productivity/https://microtica.com/13-devops-metrics-for-increased-productivity/)。由于GitOps保留了版本控制系统中的所有修改，并且能够实现自动化的管理，因此，开发团队能够全面了解目标环境中的变化，轻松发现和修复错误，从而显著降低MTTR。简化Kubernetes管理在无需透彻了解Kubernetes的情况下，开发人员可以使用Git等较为熟悉的工具，更加轻松地管理Kubernetes的升级和各项功能。据此，新加入的成员也能够在几天时间快速上手Kubernetes。全面掌握并标准化工作流由于GitOps提供了一站式的应用程序、软件、以及针对Kubernetes修改的框架，因此开发团队可以清晰地洞悉整个项目的端到端工作流，并能通过Git来完全复现日常的业务运营活动。GitOps的实现建立稳定的代码审查与测试过程。通过仔细地检查代码的更改，我们能够及时发现诸如全局变量的添加等操作，并且可以通过提交拉取请求(而非直接提交更改的方式)，来验证代码。而在拉取请求被检查与合并之后，管道才会被触发。此举在避免发布错误的代码的同时，有效地保持了高标准的代码，以及系统后续的稳定性。持续测试。合并到GitOps中，往往意味需要通过高级的自动化机制，对待发布的应用程序进行彻底的测试。有了GitOps，我们不但能够相对轻松地实现回滚，还能够通过良好的测试用例，保障代码的质量和可靠性。专注监控。GitOps允许开发人员重复各项操作流程，改进、发布并回顾各种可追溯的系统状态。而通过专注于监控，我们可以识别并防止任何意外的漂移(drift)、以及系统配置的变更。因此，在开始使用GitOps之前，开发团队有必要检查自己的监控水平，以及处理变更的能力。拥抱文化。作为目前在开发领域的优秀战略，DevOps文化能够促进团队的共同协作，更有效地管理基础架构的稳定性，更快、更流畅地执行应用程序。而GitOps又能够让我们在此基础上，进一步理解开发和运营的协同价值，提供一整套自动化的管理方法。小结作为一种非常好的工作流模式，GitOps不但可以帮助我们有效地处理云基础架构，还能够为工程团队提供：更好的协调性、透明度、稳定性、以及系统耐用性等方面的诸多好处。原文标题：GitOps – DevOps for Infrastructure Automation，作者：Sara Miteva   来源：51CTO.com  陈峻

【功能模块】【操作步骤&问题现象】发表博客被拦截，审核未通过【截图信息】【日志信息】（可选，上传日志内容或者附件）

【功能模块】导入智慧园区自动化测试工程，无法访问git库【操作步骤&问题现象】【截图信息】【日志信息】（可选，上传日志内容或者附件）

实际体验的好处是可以这碰碰，那撞撞，盲人摸象般探测边界在哪儿~昨天看了【操作指南系列】CloudIDE实例中导入Git代码库，今天才try了一下！有了夜读成才的教程，超级顺利~连许久不用的github密码居然一次就蒙对了~23333在github上改了下代码，嗯，没有自动同步到cloudIDE中。再重新import一下，文件夹重名，提示错误。改个文件名，第二次拉取下来。在Cloud IDE修改代码，然后上送git,一直报错鉴权失败，是啊，没有保存github的用户名和密码，这就需要用SSH方式连接github了。密码复制的问题：昨天确实发现代码粘贴不出来，是上面编辑框的代码粘贴不到本地，但是terminal中的文本一直是可以粘贴到剪辑板再到本地的。这里的密码不用使用手册上说的xclip -sel clip < ~/.ssh/id_rsa.pub直接能复制出来就可以了。感觉CloudIDE有点像vmware虚拟机的使用，但VM虚拟机安装了插件后，是可以在虚机和本端自由复制的。

近日，GitHub宣布，自2020年10月1日起，在GitHub平台上创建的所有源代码存储库都将默认命名为 main ，而非原本的 master 。这一变化是什么原因？具体又是怎样的变化呢？接下来为你一一解答。替换 master 等术语，开源项目在行动！今年6月12日，谷歌浏览器开发人员 Una Kravets 的一条 Twitter 火了，内容是建议 GitHub 用 main 之类的中性术语替换 master ，并解释了提出这个建议的原因：main 更短，简洁明了；容易被人记住；会让我的队友们感到舒适；不会让黑人在科技界感到被歧视；GitHub 的 CEO 对此回应到：“提议非常好，我们已经在执行了。”外媒 ZDNet 曾表示：继续使用带有种族色彩的词汇可能会加深种族歧视，这实在令人担忧。一些学者也认为：这些术语不仅反映了种族主义文化，而且还强化、合法化和延续了它。”因为美国 “Black Lives Matter” 运动愈演愈烈，技术界再次掀起了在源码、软件应用开发中删除此类词汇的浪潮。因此 GitHub 于今年6月表示，公司正在努力以 main 之类的中性术语替换 master 一词，以避免不必要的联想到奴隶制。具体的更换有：master 和 slave 将被替换为 main/default/primary 和 secondary，whitelist 和 blacklist 则将被替换为 allow list 和 deny/exclude list 。 除了 GitHub ， Android 移动操作系统、 Go 编程语言， PHPUnit 和 Curl 等都已表示打算用中性词汇替换掉 blacklist/whitelist 。同样，OpenZFS 文件存储管理器也用合适的词语替换了原用于描述存储环境之间关系的 master/slave 术语。与此同时，一些业界知名的开源项目也将其默认 Git 存储库的名称从 master 更改为 main、default、primary、root 等替代名称。不过，值得注意的是，开源项目的名称修改也并非想象中那么简单。在今年6月，React Refresh Webpack Plugin 的开发者迅速将 master 改成 main ，却被一个程序员吐槽：因为在 Git 上下文中，单词 master 的用法与 master/slave 不同，导致所有程序都改变了，最后项目都崩了。由此可见，修改存储库默认分支的名称并非一朝一夕的事，需要循序渐进。这正如同近日 GitHub 官宣的内容：将从10月1日起用 main 代替 master ，但将分阶段进行。GitHub 用 main 取代 master 举措落地，开发者最关心的事情在这里GitHub 以及庞大的 Git 社区都在考虑重命名源代码存储库的默认分支名称，而GitHub 选择用 main 取代 master ，来作为自己存储库的默认分支名称，并将分为几个阶段进行更改，以尽可能减少对现有项目的破坏。GitHub 建议用户：如果您尚未重命名默认分支，可以考虑等到今年年底。我们正在投资开发工具，用来重命名现有存储库的默认分支，从而给维护者和贡献者提供无缝的体验。以下是 GitHub 就此宣布的一些注意事项：已更改部分已更新 GitHub.com ：将包含已删除的分支名称的原版链接重定向到存储库新默认分支中的相应链接；已更新 GitHub Pages ：可以从任何分支构建和部署；注意：发布到特殊的 gh-pages 分支仍可以像以前一样工作，但是现在可以选择存储库中的其他任何分支作为发布源。添加了用户，组织和企业设置：为 GitHub.com 上所有新创建的存储库设置默认分支名称。这些设置涵盖通过 GitHub.com 和 GitHub API 创建的存储库。Git 2.28 添加了类似的设置来控制在命令行上运行 git init 时使用的默认分支。在 Git 2.28 博客文章中可以了解更多有关新的 init.defaultBranch 的设置信息。GitHub Desktop 还将在本月晚些时候为新存储库引入默认分支设置。2020年10月1日：新创建的存储库都将默认为main自2020年10月1日起，新创建的存储库都将使用 main 作为默认分支，而不是原本的 master 。但此更改不会影响任何现有存储库：现有存储库将继续保留与之前相同的默认分支。但此更改可以随时选择退出，通过以下对应网址，可为用户，组织或企业的新存储库设置默认分支：对于用户，请访问 https://github.com/settings/repositories对于组织所有者，请访问 https://github.com/organizations/YOUR-ORGANIZATION/settings/repository-defaults对于企业管理员，请访问 https://github.com/enterprises/YOUR-ENTERPRISE/settings/member_privileges为什么选择用 main 替代？main 是在 GitHub 上看到的最受欢迎的 master 替代词。并且 main 这个词汇很短，可以让用户形成良好的肌肉记忆；在很多种语言中翻译起来也很容易。GitHub 目前正将 main 用于新创建的存储库以及正在迁移的存储库，例如 dependabot-core。今年年底：无缝迁移现有存储库重命名默认分支肯定会对现有存储库带来很多麻烦：打开拉请求需要重新定位到新分支草案发布需要重新定位到新分支分支机构保护策略需要转移到新分支机构今年年底之前，GitHub 将使现有存储库全部无缝重命名其默认分支。当重命名分支机构后，GitHub 会重新定位未完成的PR和草稿版本、移动分支机构的保护政策等等——全部都将自动执行。并且，GitHub 还正在考虑将 git fetch 或 git clone 旧分支名称的用户重定向到新分支名称（带有警告和说明以更新其本地克隆）。对这一举动的思考其实关于计算机术语的政治正确性并不是近几年才出现的话题，GitHub 在公众的督促下换掉 master 也不是首当其冲。早在2004年，master/slave 就曾被全球语言检测机构评为年度最不政治正确的十大词汇之一，只是当时的软件开发和网络发展并没有如今这么发达，所以更换术语这类事就全靠自发。比如，2008年，开源软件 Drupal 宣布将 master/slave 重命名为 client/server ，理由是在有更好的替代方案时，继续使用冒犯性术语很不合时宜。之后一直到2018年，IETF 在草案当中，提出开源软件需要更改 master/slave 和 blacklist/whitelist 两项表述，计算机术语的使用才引起了广泛的关注。因此同年，许多开发者就开始呼吁 Redis、谷歌、Python 这些开源软件厂商修改相关术语。但其实反对的声音也一直很多。其中最重要的两个理由是：计算机源码中的 master、blacklist 等词语，并不包含种族色彩；更改的成本太大。事实上那些倡议者们所追求的，并非完全不能使用“black”这个词，而是呼吁不要把“biack”作为“white”的对立面，传达出“不好”、“需要被限制”等这些负面含义。所以，当 master/slave出现在代码中，表达的又恰好是“主-从”关系，就难免让人想到奴隶制。可是，究其根本，在计算机术语中的master、blacklist等词语，本身并不包含负面和歧视的意思，却因为误解而花费巨大成本修改术语，是否会有些许过犹不及的意味呢？ 参考链接https://baijiahao.baidu.com/s?id=1669620192902455480&wfr=spider&for=pchttps://www.sohu.com/a/405073858_478315https://www.jiangweishan.com/article/hulianwang0234098230948.html转载链接：https://blog.csdn.net/csdnnews/article/details/108765157