1. 问题背景    HCS803文档说明裸金属BMS支持smartRaid类的raid卡，DWS的HCS803版本镜像——8.1.0.101(通俗讲为330)并未提供支持。导致使用该版本镜像发放集群时，裸金属实例无法成功初始化，集群发放失败。2. 具体现象   1. 德州公安局点：RdsPingInstanceManagerIpTask失败，进入BMC后如图所示。  2. 甘肃政务局点：RdsPingInstanceManagerIpTask失败，进入BMC后如图所示。3.  解决思路    替换DWS镜像为8.1.1.2版本镜像，并更新软件包，插件包，镜像ID。4.  解决办法    1. 镜像文件替换：        将fcd的/home/pkg目录下的DWS裸机镜像文件进行替换，X86和ARM版本均需要，其名为DWS_ARM_OLAP_BMS以及DWS_X86_OLAP_BMS开头的文件。注意上传完当前需要注册的镜像后，老旧镜像文件需要删除。    2. BMS镜像注册：   使用DWS安装工步进行镜像注册。使用bash /opt/rootscripts/fcdscripts/retry_step.sh run -i 4432 命令重跑注册镜像的工步，其中4432为FCD中DWS的注册BMS镜像工步的子任务ID。如果DWS的安装工程被删除，重新创建一个，并将包校验等安装之前的工步全部走完，（LLD也要上传），最后到安装的步骤，不要启动，直接找到子任务ID，使用上述命令重试。    3. 镜像ID获取：   在serviceOM的镜像资源->管理镜像处找到刚刚注册的裸机镜像ID，记录下来。    4. 上传软件插件包到swift或obs:   将Public_Cloud***Instance包解压，并把所有文件都上传到桶里。使用如下命令：   echo "${obs_ak} ${obs_sk} ${file_name} 1 ${obs_url} ${obs_port} uploadobject ${bucket_name}" | java -jar udstool.jar   其中${obs_ak} 与 ${obs_sk} :op_svc_dws用户的，在rds_obs_info表中有存储，为表中authority为readOnly属性的数据的ak,sk列。${file_name}：需要上传的文件名，单个文件执行，每次上传一个文件。${obs_url}与${obs_port}：CDK参数中的obs.endpoint，包含了域名与端口。${bucket_name}：CDK参数中的instance.obsBucketName,或者rds_obs_info表中readOnly属性的桶的桶名。   这里要严格控制空格数量，按照下图中格式来进行：    5. 导入新版本xml配置：在serviceOM的数据仓库服务中，注册xml信息：  6.录入版本配置信息：   选择新版本软件包信息，录入所有新版本插件信息，并填入第四步记录下来的新注册的BMS镜像ID，x86和arm均需要录入。镜像ID填入后会自动生成镜像类型和OS版本等信息。插件必须全部注册，软件包一样。   录入完成后，在8.1.1.2版本对应的操作后面点击更新状态，将状态改为稳定。  7. 注册完后，可以新发集群尝试。     

我已经按照GitHub上的流程进行了第一项但是当我点击button进行ToIoT类的创建时，有报错报错如下： D/EGL_emulation: eglMakeCurrent: 0xbed704e0: ver 3 1 (tinfo 0xd5d31630)W/System.err: java.lang.NullPointerException: Attempt to invoke virtual method 'android.content.Context android.content.Context.getApplicationContext()' on a null object reference        at android.content.ContextWrapper.getApplicationContext(ContextWrapper.java:118)        at androidx.localbroadcastmanager.content.LocalBroadcastManager.getInstance(LocalBroadcastManager.java:107)W/System.err:     at com.huaweicloud.sdk.iot.device.client.DeviceClient.<init>(DeviceClient.java:185)        at com.huaweicloud.sdk.iot.device.service.AbstractDevice.<init>(AbstractDevice.java:80)        at com.huaweicloud.sdk.iot.device.IoTDevice.<init>(IoTDevice.java:71)W/System.err:     at com.huaweicloud.sdk.iot.device.ToIoT.<init>(ToIoT.java:24)        at com.huaweicloud.sdk.iot.device.MainActivity$1.onClick(MainActivity.java:24)        at android.view.View.performClick(View.java:7125)W/System.err:     at com.google.android.material.button.MaterialButton.performClick(MaterialButton.java:1119)        at android.view.View.performClickInternal(View.java:7102)        at android.view.View.access$3500(View.java:801)        at android.view.View$PerformClick.run(View.java:27336)W/System.err:     at android.os.Handler.handleCallback(Handler.java:883)        at android.os.Handler.dispatchMessage(Handler.java:100)        at android.os.Looper.loop(Looper.java:214)W/System.err:     at android.app.ActivityThread.main(ActivityThread.java:7356)        at java.lang.reflect.Method.invoke(Native Method)        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)我不清楚是什么原因，还是说我我的mContext对象初始化错误了

【功能模块】【操作步骤&问题现象】1、2、【截图信息】【日志信息】（可选，上传日志内容或者附件）

【问题来源】【必填】   星网【问题简要】   安装部署好了DigitalView，如需监控LINUX系统，是否需要安装UniAgent？安装在DV网关服务器还是被监控的服务器？【问题类别】【必填】   DV网管【AICC解决方案版本】【必填】 DigitalView-SW V800R001C20SPC100【期望解决时间】    尽快【问题现象描述】【必填】 安装部署好了DigitalView，如需监控LINUX系统，是否需要安装UniAgent？安装在DV网关服务器还是被监控的服务器？ 【日志或错误截图】【可选】  【附件】【可选】 

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

将IDEA中的项目提交到git远程仓库版本管理，git远程仓库使用华为云进行代码托管。市面上常见的git托管平台有github、华为云、码云、开源中国、Gitlab等。0、下载和安装git：https://git-scm.com/download/一、创建华为云账号：1、从U+实训课程页面，进入到华为华为云首页，U+已与华为云账号打通，华为云和U+共用相同的账号和密码。2、首次进入华为云需要进行实名认证，请自行实名认证二、在IDEA中创建本地仓库1.将idea项目交给版本控制工具，VCS  ——>  Enable Version Control Integration...  2.选择交给git进行管理，点击ok之后，该项目就会交给git进行管理，且在项目所在目录创建本地代码仓库，可以到项目所在目录看到有一个.git的隐藏文件，该目录就是git本地仓库。3.将代码提交到本地仓库（commit）代码提交到本地仓库了。4、为了验证有没有提交成功，可以查看代码的提交历史    右击项目  ——>  Git  ——>  Show History双击某一次提交记录，可以查看该提交的详细内容。三、创建远程仓库以上步骤我们只是将代码提交到了本地仓库，如果实现共享和版本控制，我们要创建远程仓库，远程仓库使用华为云的代码托管。1、华为云首页选择 服务--->代码托管普通新建 输入仓库名，然后确定此处就该仓库的https地址，将项目提交到远程仓库时，根据该地址提交。 mark1三、将本地仓库中的代码提交到远程仓库1、git---》push，提交时push，下载是pull2. 第一次提交需要设置远程仓库地址，其中url是远程仓库的地址（mark1处）3、点击ok  ----》push后需要输入华为云的仓库的账号和密码，仓库账号和密码在如下位置进行查看和修改，默认就是华为云的登陆密码4、 异常处理，第一次提交因为本地项目和远程项目没有关联，所以会提交失败解决办法参考：在项目所在目录下执行git bash，执行命令：（参考：https://www.jianshu.com/p/f8c9fb05681b）git push -u origin master -f或者在idea中使用快捷键  alt+f12  打开命令行Terminal窗口，执行git push -u origin master -f命令，如下图：本地项目和远程仓库进行关联成功，然后在选择idea中vcs--->git---->push   将本地仓库中的代码提交到远程仓库。提交成功后，在网页上可以看到，本地的代码已经提交提交到远程仓库，在网站端可以查看、修改提交的内容。5、（1）如果其他开发人员更新了远程仓库，可以选择通过pull进行下载下来。（2）如果想下载在远程仓库的项目，可以在开发工具中选择check out from version Control，然后输入仓库url（3）总结：每次先本地提交commit，在push

前言版本控制系统是指对软件开发过程中程序代码、配置文件、文档等发生的变更进行管理的系统，它可以帮助团队更好的沟通协作，从而更好的进行交付，常见的版本控制系统分为集中式版本控制系统（如SVN）和分布式版本控制系统（如Git）。之前拜访一家企业，企业内的开发团队使用Git管理日常开发工作，在开发过程中遇到一个问题：分支策略使用很混乱——最初开发团队从主干分支拉出一条特性分支，但新功能完成后，该特性分支没有合入主干分支，而是作为下次开发的主干分支，重新拉出一条新的特性分支，导致主干分支一直形同虚设，团队没有一条稳定的代码分支。这个问题很大程度上源于团队对分支策略的不了解，本文就简单聊一聊Git中的工作流——分支策略。常见的分支策略上文中提到的团队使用分支策略很混乱，这种分支策略也并不是主流的，使用主流的分支策略则会避免以上问题。常见的分支策略有以下三种：GitFlow、GitHubFlow以及GitLabFlow。Git FlowGitFlow是这三种分支策略中最早出现的。GitFlow通常包含五种类型的分支：Master分支、Develop分支、Feature分支、Release分支以及Hotfix分支。Master分支：主干分支，也是正式发布版本的分支，其包含可以部署到生产环境中的代码，通常情况下只允许其他分支将代码合入，不允许向Master分支直接提交代码（对应生产环境）。Develop分支：开发分支，用来集成测试最新合入的开发成果，包含要发布到下一个Release的代码（对应开发环境）。Feature分支：特性分支，通常从Develop分支拉出，每个新特性的开发对应一个特性分支，用于开发人员提交代码并进行自测。自测完成后，会将Feature分支的代码合并至Develop分支，进入下一个Release。Release分支：发布分支，发布新版本时，基于Develop分支创建，发布完成后，合并到Master和Develop分支（对应集成测试环境）。Hot fix分支：热修复分支，生产环境发现新Bug时创建的临时分支，问题验证通过后，合并到Master和Develop分支。通常开发过程中新特性的开发过程如下：从Develop分支拉取一条Feature分支，开发团队在Feature分支上进行新功能开发；开发完成后，将Feature分支合入到Develop分支，并进行开发环境的验证；开发环境验证完成，从Develop分支拉取一条Release分支，到测试环境进行SIT/UAT测试；测试无问题后，可将Develop分支合入Master分支，待发版时，直接将Master分支代码部署到生产环境。可参考下图：GitFlow的优点是每个分支都有明确的定义，严格按照GitFlow管理项目代码的话，很难出现代码混乱；其缺点是：如果特性分支过多的话很容易造成代码冲突，从而提高了合入的成本；由于每次提交都涉及多个分支，所以GitFlow也太不适合提交频率较高的项目。使用华为云 DevCloud 实现 Git Flow1.创建分支华为云DevCloud的代码托管功能支持端到端的GitFlow，我们在代码仓库中可新建分支，如图，目前已有主要分支：Master分支和Develop分支，和两个特性分支：Feature-Bill和Feature-Score分支。2.为分支创建流水线流水线功能需要在华为云DevCloud的流水线功能中进行配置，基于“Feature-Bill”分支新建一条流水线。在流水线中配置构建、部署任务，以便于对Feature-Bill分支代码的构建、部署进行验证（构建、部署等任务需要提前在对应模块下创建）。3.Feature提交代码并验证Feature-Bill分支开发完成后，提交代码即可触发流水线进行验证。4.代码合入 Develop 分支进行验证同理还需要为Develop分支创建一条流水线，当Feature-Bill分支通过merge命令合入到Develop分支之后，由于Develop分支的代码发生了变化，也会触发流水线进行验证。Develop分支验证没问题后，团队可以拉取Release分支，创建并启动Release分支的流水线进行测试环境验证。若发现缺陷，可直接在Release分支进行修改、验证。当测试环境验证通过后，将代码合入Master分支，创建并启动Master流水线进行生产环境升级与验证。GitHubFlowGitHubFlow看名字也知道和GitHub有关，它来源于GitHub团队的工作实践。当代码托管在GitHub上时，则需要使用GitHubFlow。相比GitFlow而言，GitHubFlow没有那么多分支。GitHubFlow通常只有一个Master分支是固定的，而且GitHubFlow中的Master分支通常是受保护的，只有特定权限的人才可以向Master分支合入代码。在GitHubFlow中，新功能开发或修复Bug需要从Master分支拉取一个新分支，在这个新分支上进行代码提交；功能开发完成，开发者创建Pull Request（简称PR），通知源仓库开发者进行代码修改review，确认无误后，将由源仓库开发人员将代码合入Master分支。很多人可能会问，提交代码通常是commit或者push，拉取代码才是pull，为什么GitHubFlow中提交代码提出的是“Pull Request”。因为在GitHubFlow中，PR是通知其他人员到你的代码库去拉取代码至本地，然后由他们进行最终的提交，所以用“pull”而非“push”。GitHubFlow优点是相对于GitFlow来说比较简单，其缺点是因为只有一条Master分支，万一代码合入后，由于某些因素Master分支不能立刻发布，就会导致最终发布的版本和计划不同。GitLabFlowGitLabFlow出现的最晚，GitLabFlow是开源工具GitLab推荐的做法。GitLabFlow支持GitFlow的分支策略，也支持GitHubFlow的“Pull Request”（在GitLabFlow中被称为“Merge Request”）。相比于GitHubFlow，GitLabFlow增加了对预生产环境和生产环境的管理，即Master分支对应为开发环境的分支，预生产和生产环境由其他分支（如Pre-Production、Production）进行管理。在这种情况下，Master分支是Pre-Production分支的上游，Pre-Production是Production分支的上游；GitLabFlow规定代码必须从上游向下游发展，即新功能或修复Bug时，特性分支的代码测试无误后，必须先合入Master分支，然后才能由Master分支向Pre-Production环境合入，最后由Pre-Production合入到Production。GitLabFlow中的Merge Request是将一个分支合入到另一个分支的请求，通过Merge Request可以对比合入分支和被合入分支的差异，也可以做代码的Review。华为云DevCloud也支持GitLabFlow的合并请求，以保护主干分支不收干扰。1.设置保护分支仓库管理员在代码托管的“设置”中，选择“保护分支管理”，然后将Master（或Develop）分支设定为保护分支，普通开发者不可向Master分支提交代码、也不允许合入代码，只有仓库管理员才可以向Master分支提交代码或合入代码。2.创建合并请求在代码仓库的“合并请求”中，创建一条合并请求，请求将Feature-Bill分支合入develop分支。并指定评审人员和执行合入操作的人员。3.Review代码并通过合并请求相关人员收到合并请求后，可以通过“文件变更”，比对文件前后的变化，确认无误后，可执行合入操作，如果有冲突可线上或线下解决冲突。除了执行合并操作，还可以对代码进行评论打分，为Feature-Bill分支的合入提供建议。总结分支策略不同，研发效率也不同，没有最好的分支策略，只有最适合团队的分支策略，各分支策略的优缺点在上面已经列出，大家可以根据团队情况，选择合适的分支策略进行开发。

【功能模块】AppCube平台开发模块【操作步骤&问题现象】1、想要将代码上git备份，出现未授权，白名单现象，如何解决【截图信息】【日志信息】（可选，上传日志内容或者附件）

首先拉镜像root@ecs-385f:~/gitlab# docker pull beginor/gitlab-ce:11.0.1-ce.011.0.1-ce.0: Pulling from beginor/gitlab-ceb234f539f7a1: Pull complete 55172d420b43: Pull complete 5ba5bbeb6b91: Pull complete 43ae2841ad7a: Pull complete f6c9c6de4190: Pull complete e6597e975df6: Pull complete 73dc92c66025: Pull complete 5282194f87d6: Pull complete df88dfe59bb1: Pull complete dffab5bd4f6d: Pull complete 945907026b4f: Downloading [==================================>                ]  304.8MB/443.6MBc2fd3f9dce0a: Download complete dcd61611748b: Download complete 18b2c0be8c67: Download complete 1e1d10273471: Download complete 58c783f2b859: Download complete 2ac94cbcc08d: Download complete 6c10cd924130: Download complete 1df14ac85b55: Download complete 同时另开一个终端，准备好一会儿要用的目录和命令：Last login: Tue Jun 29 15:57:02 2021 from 61.139.x.xroot@ecs-385f:~# mkdir -p /mnt/gitlab/etcroot@ecs-385f:~# mkdir -p /mnt/gitlab/logroot@ecs-385f:~# mkdir -p /mnt/gitlab/dataroot@ecs-385f:~# docker run \>     --detach \>     --publish 8443:443 \>     --publish 8090:80 \>     --name gitlab \>     --restart unless-stopped \>     -v /mnt/gitlab/etc:/etc/gitlab \>     -v /mnt/gitlab/log:/var/log/gitlab \>     -v /mnt/gitlab/data:/var/opt/gitlab \>     beginor/gitlab-ce:11.0.1-ce.0等待镜像拉取完毕，在第二个终端敲回车。修改vim /mnt/gitlab/etc/gitlab.rb文件写入external_url 'x.x.x.x'修改vim /mnt/gitlab/data/gitlab-rails/etc/gitlab.yml ## Web server settings (note: host is the FQDN, do not include http://)    host: x.x.x.x    port: 8090    https: false浏览器访问 http://x.x.x.x:8090

1. 创建本地项目2. 码云创建项目（复制SSH地址）3.     touch README.md  touch .gitignore #忽略推送到git仓库文件*.class#package file *.war *.ear #kdiff3 ignore *.orig #maven ignore target/ #eclipse ignore .settings/ .project/ *.ipr *.iml *.iws #temp file *.log *.cache *.diff *.path *.classpath #idea .idea/ /idea/ *.ipr git init #初始化项目git status #查看哪些项目发生变化git add .#添加所有文件git commit  -am '注释'#提交文件 -am  后面直接添加注释git  remote add origin xxx#远程仓库git push -u origin master#推送项目git push -u -f origin master #强制推送git branch -r#查看远程分支git checkout -b dev origin/master#创建dev分支git branch#查看分支git push origin HEAD -u#推送远程分支

root@ecs-b769:~# git clone https://gitee.com/beeworkshop/openair-cn-new.gitCloning into 'openair-cn-new'...fatal: unable to access 'https://gitee.com/beeworkshop/openair-cn-new.git/': Failed to connect to 127.0.0.1 port 1080: Connection refused这是什么原因呢？搜了下资料，是因为git config里面有代理的配置，将其重置就可以了。root@ecs-b769:~# git config --global --unset http.proxyroot@ecs-b769:~# git clone https://gitee.com/beeworkshop/openair-cn-new.gitCloning into 'openair-cn-new'...remote: Enumerating objects: 7920, done.remote: Counting objects: 100% (7920/7920), done.remote: Compressing objects: 100% (1753/1753), done.remote: Total 7920 (delta 6036), reused 7920 (delta 6036), pack-reused 0Receiving objects: 100% (7920/7920), 12.55 MiB | 1.69 MiB/s, done.Resolving deltas: 100% (6036/6036), done.root@ecs-b769:~# lsopenair-cn.git  openair-cn-newroot@ecs-b769:~# 

参考https://blog.csdn.net/qq_42030961/article/details/82695682 搭建EPC的模拟环境，要用到欧洲的网站gitlab的git资源。发现这个网站的资源必须要提供用户名和密码才能下拽资源。gitlab网站虽然可以访问但是注册用户名却需要google的验证码，当然没有，怎么办？网上说可以用github的用户名密码登录，绕过这一限制，但是现在gitlab已经没有这个登录选项了。oai 搭建EPC，应该已经流行一段时间了，那么就会有很多人已经走完了这个坎，换个地方找找资源。。。nice！

为了让大家能够非常清晰直观地了解协作开发的流程，大家在看的时候可以打开 Learn Git Branching 的沙箱运行环境来实践（可以直接输入提供的代码）。在左边的终端中输入命令，就会在右边看到相应的动画。其中左边的实线圆圈代表本地仓库，右边的虚线圆圈代表远程仓库，* 号指向的是当前分支，o/master 就是远程分支（ o 就相当于 origin ）。由于 Learn Git Branching 为了演示和学习的方便对部分命令做了简化，我将指出在实际操作中应当输入的命令。基本流程接下来将重点讲述以下两个流程：贡献代码更新本地仓库贡献代码接下来的流程描述了在接到开发任务后，如何为中心仓库贡献代码。将仓库 clone 到本地$ git clone实际命令应当提供 URI 参数，例如：$ git clone https://github.com/dhucst/cooperation.git开启新分支$ git checkout -b B1为了便于演示，我们将新分支命名为 B1。在实际开发中，新分支的命名应当遵循以下原则：使用 kebab-case，例如 new-branch ，而不是 new_branch 或 newBranch尽量能概括这个分支所要完成的任务如果是为了解决某个 Issue，在最后加上 Issue 的编号，例如 fix-75编写代码并提交$ git commit实际命令应当要先执行 git add 来将修改的文件添加到暂存区，例如：$ git add . $ git commitCommit Message (Log) 的书写是有比较严格的规范的，会在后文的 提交信息书写规范 中详细阐述。推送分支$ git push实际命令在第一次 push 任何分支时，应当指定 remote 和分支名称：$ git push origin B1有时候我们的分支会在一夜之间“过时”。什么是过时的分支，我们该怎样处理？不要方，后面会讲到。提交 Pull Request这一步骤无需在 Learn Git Branching 中操作。将分支提交到远程仓库后，打开仓库的 GitHub 页面，应该会看到下面这样黄色的提示框：image-20200429091859922然后点击 Compare & pull request 按钮，即可进入到提交 Pull Request 页面。填写 Pull Request 标题所遵循的原则与 Commit message 大致相似。在填写 Pull Request 的详细内容时，如果是为了解决某个或多个 Issue 时，可以使用 Close(s), Fix(es) 或 Resolve(s) 关键词来关闭某个 Issue，例如 Fix #75 。点击 Create pull request 按钮后，即可完成本次 PR。如果经讨论后发现需要修改，则在本地仓库修改后直接 git push 继续提交即可。如果代码通过了评审，则会由项目管理者将此分支并入 master 中，本次贡献代码流程结束。更新本地仓库接下来的流程介绍了当团队其他成员贡献代码后，如何将远程仓库的更新同步到本地。如果你在使用 Learn Git Branching 边看边练，请输入以下命令：$ reset $ git clone其他成员贡献代码$ git fakeTeamwork 2实际没有这条 Git 命令 ????，是 Learn Git Branching 提供用于练习协作的。这时候你会发现远程的仓库有了本地没有的提交 C2 和 C3 。拉取远程代码我们先来看第一种比较简单的情况：这时候一眼就可以看出，只需把远程的 C2 和 C3 直接拉取过来接在本地的 C1 后面就可以了：$ git pull接着我们来看另一种比较棘手的情况：需要输入的命令如下：$ reset $ git clone $ git checkout -b B2 $ git commit $ git fakeTeamwork 2对着图看，我们在 B2 分支上在开发某个新功能，这时候远程仓库已经更新到了 C4，很显然我们本地的 master 分支和 B2 分支都不是最新的了。这种情况很常见：几个小伙伴从同一个起点（在这里就是 C1 ）各自开发新功能时，其他人先于我们提交。大多数情况下，请遵循这一条原则：只更新 master 分支。这一原则对于并行开发并不适用，我们会在本知识库后续文档中讲解。$ git checkout master $ git pull这时候，我们就会认为 B2 分支已经过时（outdated），因为它没有最新的 C3 和 C4 。但过时的分支并不意味着没有价值了，我们可以像前面所讲解的那样 push 到远程仓库：$ git checkout B2 $ git push然后一样可以发起 Pull Request。GitHub 会提示你这条分支已经过时，你可以点击 Update Branch 按钮来更新这一条分支（通常由项目管理者来执行这一操作）。小结团队协作开发的模型只涉及两个核心流程：贡献代码和更新本地仓库。贡献代码的流程：$ git clone <REPO_URI> $ git checkout -b new-branch $ git add . $ git commit $ git push origin new-branch更新代码库的流程：$ git checkout master $ git pull并行开发一个项目的开发往往由多个开发任务组成，每个人都会负责承担一个或多个开发任务。最简单、最理想的情况当然是：同学 A 开始贡献代码，成功合并后所有人更新本地代码库；接着同学 B 开始贡献代码，合并后所有人更新本地代码库；然后是同学 C、D、E……不会有任何冲突，只需用到前面 基本流程 所介绍到的命令，多么轻松愉快！唯一的问题就是：这样的开发显然进度很慢，而且大家的时间安排也不够自由。这种串行开发的方式过于同步化，对于一个追求效率的团队来说是不能接受的。我们需要高度并行、完全异步的协作开发模式。接下来我们将描述三个典型的并行开发场景，其中的主角是大唐同学和煨鸽同学。互不依赖且没有修改同一文件例如有个着陆页开发的任务，大唐负责做“关于我们”页面，叫 about-us.html，煨鸽负责做“联系我们”页面，叫 contact.html，这两个文件相互独立的。这里我们假定大唐同学率先完成了任务并且已经合并到 origin/master 。这时候根据前一章 更新本地仓库 一节的说法，煨鸽正在工作的分支已经“过时”。这时候他只需要继续完成他的 contact.html 页面，然后提交就可以了。这是最简单的，也是最常见的情况（合理的任务划分应当如此）：相互独立的分支只需依次 push，不管是否过时。存在依赖关系且没有修改同一文件现在我们又假设大唐在开发着陆页的首页 index.html，煨鸽负责写着陆页的样式 index.css，很明显大唐的开发任务依赖煨鸽。经过一天的开发，大唐写完了主体部分 C2，煨鸽也写好了样式 C3 并且已经提交到远程仓库，现在他需要把煨鸽的样式表加进来，才能完成自己的开发任务。在 Learn Git Branching中输入以下代码：$ git clone $ git checkout -b html $ git commit $ git fakeTeamwork然后大唐使用 fetch 命令将远程的 C3 抓取下来（其实更严格的说法是将本地的 o/master 分支与远程的 master 同步）：$ git fetch可以看到，html 文件的提交和 css 文件的提交在不同的分支上。html 是我们工作的分支（也是当前所在的分支），因此要把 C3 所在的 o/master 合并过来：$ git merge o/master这个形状看上去有点吓人！实际上，你只要真正理解分支的本质就会觉得非常好理解。分支不能简单地理解为一串 commit（虽然说在大多数情况下这种理解非常直观），而应该理解为指向某个 commit 的指针，而该 commit 的所有父节点都是该分支上的节点（commit）。因此在执行合并后，我们可以说 C2 和 C3 都已经在 html 分支上了。合并之后，我们再修改点东西，提交为 C5 ，然后推送到远程仓库：$ git commit $ git push再次提醒真正的 push 命令在第一次推送某一分支时要加上远程仓库名称和分支名称，例如 git push origin html 。接下来就是提交 Pull Request、等待合并就可以了。修改同一文件首先声明这种情况非常少见，合理的任务划分会尽量避免这种情况出现。但是我们还是会讲解一下这种比较棘手的情况。由于 Learn Git Branching 没有提供冲突（conflict）的演示，所以我们需要自己在本地开仓库进行演示。为什么在本地开仓库练习就可以了，而不需要搭一个远程仓库吗？因为本小节的操作流程和命令跟上一节相比，除了增加了一个处理冲突的步骤，其余完全相同，因此我们关注的重点是怎么处理冲突。$ mkdir conflict-demo && cd conflict-demo $ git init $ touch index.js $ git add . $ git commit -m "Add index.js"然后我们开启一个新分支 add-func :$ git checkout -b add-func在 index.js 中增添一个 add 函数：function add(x, y) { return x + y; }保存并提交：$ git add . $ git commit -m "Implement add function"然后我们切回主分支，并开启一个叫 origin-master 的分支（听这名字也知道，它模拟了远程的主分支）：$ git checkout master $ git checkout -b origin-master接着再在 index.js 中添加一个叫 multiply 的函数：function multiply(x, y) { return x * y; }好了，现在本地的 add-func 工作分支和“远程”的 origin-master 分支修改了同一文件 index.js，冲突一触即发！让我们来点燃这根导火索！其实你可以不停地把分支切来切去（轮流输入 git checkout add-func 和 git checkout origin-master ），你会看到 index.js 的内容会随之变来变去，版本控制系统的魅力可见一斑。$ git checkout add-func $ git merge origin-master我们会发现 Git 会输出你从未见过的信息：Auto-merging index.js CONFLICT (content): Merge conflict in index.js Automatic merge failed; fix conflicts and then commit the result.划重点：index.js 在合并时发生冲突，请处理冲突然后提交。我们查看 index.js 的内容，发现了很神奇的东西（在命令行中用 cat 查看）：<<<<<<< HEAD function add(x, y) { return x + y; ======= function multiply(x, y) { return x * y; >>>>>>> origin-master }如果我们用 VSCode 打开，会看到更炫酷的结果：这就一目了然了！绿色部分是我们当前分支 add-func 的内容，蓝色部分是 origin-master 的内容。由于我们两者都要，所以点击 Accept Both Changes。然后略经修正，将 index.js 改为如下：function add(x, y) { return x + y; } function multiply(x, y) { return x * y; }提交我们用于处理冲突的 commit：$ git add . $ git commit -m "Merge conflict of index.js"冲突处理完成，我们提交此分支，任务完成。小结并行开发是 Git 团队协作中比较高级却又非常重要的部分。平时大多数情况下，我们遇到的都是第一种情况。如果“不幸”遇到了后面两种情况，不熟悉时可以回来看一看这篇文档。PS：对于后面两种情况，有一点需要补充：如果想要撤销 merge，使用下面这条命令：$ git merge --abort提交信息书写规范提交信息，又称为 commit messages 或者 commit logs，是每一步提交所必需的信息。我们可以看一下 React 仓库的提交记录：由此我们可以对项目每一步做了什么有了比较好的了解。格式每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。<header> // 空一行 <body> // 空一行 <footer>其中，Header 是必需的，Body 和 Footer 可以省略。HeaderHeader部分只有一行，是对 commit 的简短概述，是一个包括动宾结构和修改对象（可选）的祈使句（不要加句号！）。我们来看几个例子。Remove 'warning' module from the JS scheduler这里的动宾结构是 Remove 'warning' module，修改对象是 JS scheduler。Add @flow directive to findDOMNode shim这里的动宾结构是 Add @flow directive，修改对象是 findDOMNode shim。Update www warning shim这里动宾结构是 Update www warning shim，由于修改对象已经很明确（在动宾结构中），所以无需再写。BodyBody 部分是对本次 commit 的详细描述，可以分成多行。下面是一个范例。More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. Further paragraphs come after blank lines. - Bullet points are okay, too - Use a hanging indent有两个注意点。使用第一人称现在时，比如使用 change 而不是 changed 或 changes。应该说明代码变动的动机，以及与以前行为的对比。FooterFooter 部分只用于两种情况。（1）不兼容变动如果当前代码与上一个版本不兼容，则 Footer 部分以 BREAKING CHANGE 开头，后面是对变动的描述、以及变动理由和迁移方法。（2）关闭 Issue如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue。Closes #234也可以一次关闭多个 issue 。Closes #123, #245, #992我们团队建议在 Pull Request 中关闭 Issue，如前面基本流程所描述的那样。Revert还有一种特殊情况，如果当前 commit 用于撤销以前的 commit，则必须以 revert: 开头，后面跟着被撤销 Commit 的 Header。revert: feat(pencil): add 'graphiteWidth' option This reverts commit 667ecc1654a317a13331b17617d973392f415f02.Body 部分的格式是固定的，必须写成 This reverts commit <hash>.，其中的 hash 是被撤销 commit 的 SHA 标识符。如何修改一开始写 Commit Message 的时候难免会出现写得不好的情况，一般情况下会有人建议你如何写得更好，或者你自己想到了更合适的写法。这时候该如何修改呢？修改最近一次提交如果你要修改的就是最近一次提交，那就非常简单了。Git 有专门的命令用于轻松修改刚才的提交：$ git commit --amend然后就会进入 vi 界面重新编辑你的提交信息。当然也可以直接用 -m 选项指定提交信息：$ git commit --amend -m "Updated commit message"想要在 Learn Git Branching看看怎么回事？输入下面的命令体验一下吧：$ git commit $ git commit --amend修改倒数第 n 次的提交下面要介绍的 rebase 命令威力可以说是非常巨大，但是要掌握却实属不易。没事，我们先来看看如何用 rebase 修改倒数第 3 次提交：$ git rebase -i HEAD~3-i 的意思是 --interactive ，输入后 Git 就会打开一个 vi 编辑器，并出现下面的内容：pick 0f78800 倒数第4次提交 pick 459014c 倒数第3次提交 pick 38009c7 倒数第2次提交 pick dff7f7d 最新的提交 # Rebase 500d110..dff7f7d onto 500d110 (4 commands) # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # d, drop = remove commit # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # # Note that empty commits are commented out其实如果你认真看一下下面的注释，基本上知道怎么做了：把倒数第三次提交前面的 pick 命令改为 reword 。保存后，Git 就会把你带到倒数第 3 次提交的 vi 编辑页面，这时候重新写提交信息就可以了。你也可以在 Learn Git Branching中体验一下 rebase 命令：$ reset $ git commit $ git commit $ git rebase -i HEAD~3Learn Git Branching 提供的是图形化界面，和 Git 的 vi 界面略有区别。强制推送修改有时候可能你已经把分支 push 到远程仓库、甚至已经提交了 Pull Request 了。如果直接 push ，Git 会因为远程和本地的分支冲突而拒绝推送。这时候只需要加上 -f 选项，强制用本地的分支覆盖远程的分支即可：$ git push -f参考阮一峰《Commit message 和 Change log 编写指南代码评审代码评审，又称代码审查，是软件开发流程中必不可少的一环。代码审查是计算机源代码的系统性检验（有时被称为同行评审）。其目的在于找到开发初期所忽略的错误，从而提高软件的整体质量。——Wikipedia为什么要代码评审代码评审并不意味着被评审者的能力不足。有下面这些原因表明代码评审的重要性。降低风险写出存在 bug 的代码再正常不过了。每个人贡献的代码先要经过持续集成（CI，Continuous Integration）的一系列构建测试，然后是人工代码审查，因此代码审查可以说是最后一道防线。显著提高代码质量代码评审不仅仅是单纯地查找 bug 或是修正格式问题，还包括使代码更高效。在一个团队里，每个人都有自己的背景和特长，因此总有人可能提出更聪明的解决方案，更合适的设计模式，或者能降低复杂性或提高性能的方法。有助于熟悉项目当一个团队在做一个项目时，想要每个开发人员致力于应用的每个部分，这是极不可能的。有时候，会出现这种情况：在某一段时间，一个开发人员正为项目的大部分模块辛苦地工作，而另一个人则完全在做别的东西。知识共享通过合作，每个人都可以相互学习并取得进步。提交代码者很有可能从该工作中得到反馈，并意识到可能存在的问题和需要改进的部分；而审查者也可以通过阅读他人代码学到新的东西，并找出适用于他们自己的工作方案。如何进行代码评审发起代码评审代码评审发生在 Pull Request 阶段，代码提交者可以请求其他成员的 Review，如下图所示。然后被请求进行评审的成员打开这条 Pull Request 页面时会出现一个提示框：我们点击 Add your review 按钮，即进入到 Review 页面（或者也可以点击 Files changed 这个 Tab）。Review 页面展示了本次 Pull Request 所有发生改动的文件，评审的过程也就是审查这些发生改动的代码。在 GitHub 上评审直接在 GitHub 的 Pull Request 页面评审是最基本的方法。对于改动比较小的分支，这种方法完全足够。有时候我们发现了他人代码的问题。千万不要保留你的意见！要把自己的想法有条理地写下来。我们可以选择特定一行来发表评论，只需把鼠标移到行首，就会显示一个加号，如下图。点击加号，就可以对这一行进行评论了：拉取到本地评审有时候某些分支的改动非常大，大到需要你在本地亲自运行一下，看看是否真的达到了预期的目标。$ git fetch origin lots-of-changes $ git checkout logs-of-changes然后你的本地仓库就完成切换到待评审分支的状态了！你可以试着运行，做各种尝试，还可以在自己熟悉的编辑器里面更加舒适地阅读代码，美滋滋。提交评审结果无论是直接在 GitHub 还是在本地审查，最后都要提交评审结果。评审结果包括你在代码行中的所有评论、Review summary 和最终意见。Review summary 主要是一些总结性的话语。如果代码提交者确实做得非常优秀，当然是要夸奖一下喔；如果有些地方做得不足，则要给出改进的方向和一些鼓励。最终意见有以下三种：Comment：只是做一些客观评价，对此分支是否可以合并不给出明确意见Approve：同意此分支合并进主分支Request changes：不同意此分支合并，需要进一步修改接着代码提交者根据其他人的评审进行修改后提交，然后再继续评审，如此迭代，直到分支可以合并。最佳实践对于代码提交者任务最小化每个开发任务都应当只做一件事情，因此所需评审的代码应可能地少。事实表明，超过 200 行的代码评审的有效性显著降低，超过 400 行时代码评审几乎没有意义。提供足够的上下文在编写代码时应有意识地添加足够的注释或文档，因为你的代码会被很多人阅读。良好的注释能够让团队其他成员评审你的代码时更加轻松，也更容易发现问题所在。另外，在填写 Pull Request 说明信息时，也应该将所解决的问题、发生的相应改变说明清楚。对于评审者评审最重要的事情不要纠结于代码风格或是格式问题，这些事情会有专门的工具代劳。你应当关注的是下面这些问题：代码是否具备良好的可读性？能否实现得更简洁、更地道？代码是否遵循了良好的设计原则？代码的空间效率和时间效率怎么样？保持积极开放的心态不必过于挑剔，乐于赞扬他人的劳动，学会欣赏他人的代码。

- News -1.赫特福德郡大学遭受网络攻击 致其整个IT系统瘫痪https://www.cnbeta.com/articles/tech/1116243.htm2.Celsius Network披露数据泄露事件https://www.bleepingcomputer.com/news/security/celsius-email-system-breach-leads-to-phishing-attack-on-customers/3.安全人员披露NAME：WRECK漏洞影响近亿设备https://www.bleepingcomputer.com/news/security/name-wreck-dns-vulnerabilities-affect-over-100-million-devices/- Research -1.Chromium V8 JavaScript引擎远程代码执行漏洞分析讨论http://noahblog.360.cn/chromium_v8_remote_code_execution_vulnerability_analysis/2.从git原理角度浅谈.git泄露利用原理https://www.anquanke.com/post/id/236487

【GitOps 3天强化实战营】基于Kubernetes的GitOps实战直播简介：以Kubernetes为基础环境，构建基于Jenkins、Gitlab和Nexus3的全自动化CICD流水线。实战案例：采用spring boot框架建构一个微服务应用，在开发人员将代码变更推送至指定仓库后，可实现自动化构建、打镜像、推送镜像，以及滚动更新线上应用的版本。直播讲师：马哥，马哥教育创始人，云原生技术课程讲师，《Kubernetes进阶实战》作者直播日期直播时间直播主题及链接点击报名4月15日 16:00-18:30GitOps模型及基础环境准备解析点击报名4月16日 16:00-18:30 Jenkins及Pipeline实战点击报名4月17日 16:00-18:30GitOps实战点击报名直播福利：华为云微认证《云容器快速搭建网站》原价48元，直播期间限时0元！在电商、游戏、互联网等众多行业，应用容器化已经成为了必然趋势，微认证结合云容器引擎CCE快速实现网站搭建，助力企业实现网站快速开发上线。报名现已开启>>>>>>>当然我们一定不会只有学习课程这么简单我们准备了“带着好友一起学习，一起进步，一起“赢好礼”的超大惊喜01. 活动详情 邀好友，学课程，赢大礼，添码力！邀请好友一起报名学习GitOps 3天强化实战营，就有机会得到好礼！一起学习，共享进步！-邀请活动时间：即日起-2021.4.18课程结束-邀好友，赢奖励：邀请1名好友“报名课程”即可免费赢价值58元微认证《轻松玩转Kubernetes》点击查看领取成功名单公示-参与步骤：1.点击上方“立即报名”按钮参与活动，邀请好友报名课程2.报名成功后进入课程《人人学云容器》点击“报名课程”，3.获得原价58元的微认证《轻松玩转Kubernetes》0元领取资格（报名成功后次日可进入该链接0元购买），点击进入0元购买。注意事项：自己和好友皆完成上述步骤，“活动报名+报名课程”成功，才可领取“0元微认证”，权益在“报名课程”次日发放。01. 活动详情 -tips：如何邀请好友？步骤一：邀请人成功报名后（点击去报名），点击图示中的“分享有礼”按钮 步骤二：通过生成的专属链接/邀请二维码，即可邀请好友报名活动