2022年,继续做开源的朋友

举报
zhushy 发表于 2022/02/07 19:38:07 2022/02/07
【摘要】 利用开源软件,和利用并回馈开源社区,档次和境界是不一样的。哈佛商学院教授 Frank Nagle 的一项新研究发现, 回馈开源软件能给自家企业带来更多的竞争优势。通过贡献代码,程序员能更深入的理解系统结构和功能,这能带来巨大的竞争优势,还有助于改善公司形象,有利于招募优秀人才,能增加公司研发效率。当然回馈开源软件对低技术公司意义不大。本文就说说参与社区贡献的几点注意事项。大家,2022年就可...

利用开源软件,和利用并
回馈开源社区,档次和境界是不一样的。哈佛商学院教授 Frank Nagle 的一项新研究发现, 回馈开源软件能给自家
企业带来更多的竞争优势。通过贡献代码,程序员能更深入的理解系统结构和功能,这能带来巨大的竞争优
势,还有助于改善公司形象,有利于招募优秀人才,能增加公司研发效率。当然回馈开源软件对低技术公司意义不大。

本文就说说参与社区贡献的几点注意事项。大家,2022年就可以多参与社区的贡献,我们一起做开源的朋友!

1、 熟悉已有的详细资料

OpenHarmony Docs文档仓、Gitee帮助站点都提供了丰富的资料,介绍如何把开源代码仓Fork到本人的仓库下,如何提交Pull Request来贡献代码。可以通过下述链接了解更多信息:

2、Fork个人仓里创建分支

把开源仓代码fork到个人仓后,就可以把代码下载到本地工作机器上进行开发了。通常建议,创建不同的分支来解决不同的issue或特性开发。如果没有创建分支,直接在master分支上进行开发,并提交Pull Request后,由于Committer代码审核者需要时间来审核代码,在这个期间,我们是无法提交PR代码解决其他问题的。如果有不同的分支,则可以使用不同的分支来提交PR同时解决不同的问题。界面上创建分支如下图所示:

现在Gitee已经支持了可以多次fork代码仓到本人仓,如下图所示。但是使用不同的分支,依旧是效率更优的工作方式。

3、更新Fork个人仓代码

当其他开发者提交的PR被Committer合入后,我们之前Fork到本人仓的代码就与最新代码不同步了。可以界面上操作,如下图所示。但是,如果存在未合入的PR,这种界面上刷新是不允许的。

另外,界面上的操作没有办法刷新创建的其他分支的代码,可以使用git命令行来更新代码。如下所示,⑴处的命令行查看远程分支,⑵处增加远程分支,然后可以执行⑶来拉取远程分支代码,远程master分支的代码合并到本地当前分支。其中-r选择等于–rebase,属于变基操作,可以自行搜索rebase查询更多的信息。这些命令的输出,如下图所示。

⑴    git remote -v
⑵    git remote add remote_origin --mirror=fetch https://gitee.com/openharmony/kernel_liteos_m.git
⑶    git pull -r remote_origin master

4、学会解决冲突

我们提交PR的时候,代码是最新的,随着其他开发者提交的PR的合入,可能存在冲突,导致我们的PR存在冲突,如下图所示。这一般是因为自己的本地做的提交和服务器上的提交有差异,并且这些差异中的文件改动,Git不能自动合并,那么就需要用户手动进行合并。

怎么来解决冲突?需要参考上面的小节来更新Fork个人仓代码,由于存在冲突,更新会失败,更新后解决冲突,重新提交即可。下面介绍下步骤。当执行⑴处变基rebase更新代码因冲突失败时,会提示哪些文件存在冲突。⑵处查看本地更改,然后根据本地代码和最新代码的冲突的实际情况,修复冲突。如⑶的例子,BUILD.gn文件存在冲突,编辑解决冲突。然后使用git add 添加到更改。解决完毕冲突后,执行⑷继续应用补丁。最后重新推送代码即可,注意需要使用-f表示强制推送。

   git remote -v
   git remote add remote_origin --mirror=fetch https://gitee.com/openharmony/kernel_liteos_m.git
⑴  git pull -r remote_origin master
⑵  git status
⑶  vi testsuits/sample/kernel/mem/BUILD.gn
   git add testsuits/sample/kernel/mem/BUILD.gn
⑷  git rebase --continue

⑸  git push origin XXX:XXX -f

关于如何处理代码冲突,也可以参考Gitee帮助站点如何处理代码冲突了解更多信息。

5、追加amend提交

通常一个PR只能用于解决一个单一的问题,只需要提交一个git commit。如果需要解决多个问题,需要提交多个PR。经常由于提交的代码由于需要再次修改,导致一个PR包含多个git commit,如下图所示。这样不规范的提交会导致git log提交日志信息非常多,后续查看提交修改时,非常不方便。

解决这个问题的方式就是提交代码时,使用amend追加方法。本地再次修改后,执行⑴git commit提交时,注意需要添加–amend选项,此时会弹出窗口让修改git message信息。⑵处提交追加的代码,注意需要添加-f选项强制提交。

⑴  git commit --amend
⑵  git push origin XXX:XXX -f

关于如何追加提交,也可以参考Gitee帮助站点修改最后一次提交了解更多信息。

6、cherry-pick提交

当合入一个PullRequest之后,有时我们想要把这个PullRequest上一个或者多个提交重新拿出来提交为一个新的PullRequest,然后合并到新的目标分支。这时就可以使用Cherry Pick 功能。关于cherry-pick提交,可以参考Gitee帮助站点cherry-pick提交了解更多信息。

7、Git message规范

需要注意git message规范,可以参考Git Commit message 编写指南

小结

因为时间的关系,以后逐渐补充吧,有啥问题随时留言给我。谢谢。

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。