当前位置: 首页 > 科技观察

你可能不知道的15个有用的Github功能

时间:2023-03-13 20:23:30 科技观察

15个你可能不知道的实用Github函数。其实github里面有很多好玩或者有趣的地方。当然,这些技巧也能大大提高你的工作效率。整理了一些平时用的比较多的功能/技巧,希望能给大家的工作带来一些帮助!Gist可能很多人没有听说过Gist。它在github主页的一个子目录中:这是github提供的一个非常有用的特性。Gist是一个粘贴数据的工具,就像Pastie网站一样,你可以很方便的在Gist网站中粘贴数据,在其他网页中引用Gist中粘贴的数据。Gist作为GitHub的子站点,自然是使用Git仓库来维护粘贴的数据,非常方便。进入Gist网站首页,会看到一个大数据粘贴对话框。只需提供简单的描述、文件名并粘贴文件内容即可创建新的粘贴。每个新粘贴都称为Gist,并有一个单独的URL。创建粘贴时,会显示新创建的Gist页面,点击嵌入按钮,会显示一段嵌入其他网页的JavaScript代码。将上述JavaScript代码嵌入到网页中,然后将Gist中的数据嵌入到相应的网页中,并保持语法高亮等功能。通过web界面创建文件在某些??情况下,我们可能不想在本地创建文件,然后通过git推送到远程创建文件。有没有简单有效的方法?很简单,github提供的web界面创建方法(createnewfile)就可以创建:filesearch有时候,我们想在一个庞大的git仓库中找到某个文件。如果我们一个一个的看,可能需要一段时间(以前总觉得在github仓库找文件真的很麻烦)。其实github提供了一种快速搜索的方法:按键盘上的'T'键激活文件查找器,按??和??上下选择文件,当然你也可以输入你要查找的文件名,并快速找到它。githubcli(commandline)我们将本地代码提交到GitHub后,可以在GitHub网站上查看各种交互信息,比如其他开发者提出的Issue,或者提交的代码合并请求等。但是如果我们可以直接在命令行上查看和操作此信息。让我带你从0到1开始使用GitHubCLI!安装安装GitHubCLI非常简单。macOS下,可以使用Homebrew工具安装:$brewinstallgithub/gh/gh#如果需要更新,执行如下命令$brewupdate&&brewupgradeghWindows下,可以使用如下命令行安装:scoopbucketaddgithub-ghhttps://github.com/cli/scoop-gh.gitscoopinstallgh安装完成后,直接在命令行执行gh命令。如果看到下图所示的信息,则表示安装成功:其他平台安装,参考官方文档:https://cli.github使用.com/manual/installation时,我们需要授权一次:在命令行中输入回车键在浏览器中打开授权页面,点击Authorize:授权成功返回命令行,我们发现通过ghissuelist命令已经获取到issue列表:我会在这里列出几个常用的操作。要创建一个问题,我们通过CLI交互式地提交一个问题,并且需要通过nano编辑问题的主体。过滤问题问题列表中的项目通常太多。通过指定条件过滤问题是一个很常见的需求:如上图所示,它会过滤掉所有标签为动态规划的问题。如果想查看issue的具体信息,可以使用如下命令在浏览器中快速打开issue的详细信息页面:接下来,您可以选择打开网页,预览并提交。当然我们也可以选择直接在命令行提交。这里我简单介绍几个与issue相关的常用命令。更多使用方法请参考官方文档了解更多:https://cli.github.com/manual/examples。GitHubActionsGitHubActions是GitHub的持续集成服务。通常持续集成是由很多操作组成的,比如抓取代码、执行脚本、登录远程服务器、发布到第三方服务等等。GitHub将这些操作称为动作。如果需要action,不用自己写复杂的脚本,直接引用别人写的action即可。整个持续集成过程变成了动作的组合。GitHub创建了一个官方市场,可以在这里搜索其他人提交的Action:下面从基本概念和发布流程来详细介绍GitHubActions。基本概念工作流(process):持续集成运行一次的过程就是一个工作流。job(任务):一个工作流由一个或多个作业组成,是指可以完成多个任务的持续集成操作。step(步骤):每个作业由多个步骤组成,一步步完成。动作(action):每一步可以依次执行一个或多个命令(action)。示例:将React项目发布到GitHubPages这里,通过GitHubActions构建一个React项目并发布到GitHubPages。最终代码在这个仓库中,发布的URL为https://jack-cool.github.io/github-actions-demo/。生成密钥由于示例需要将构建发布到GitHub存储库,因此需要GitHub密钥。按照官方文档,生成一个key。然后,将这个key存放在当前仓库的Settings/Secrets中。我这里的环境变量的名字是ACCESS_TOKEN。创建一个React项目使用create-react-app初始化一个React应用:$npxcreate-react-appgithub-actions-demo$cdgithub-actions-demo在项目的package.json中,添加一个homepage字段(代表应用的根目录)发布后目录)"homepage":"https://jack-cool.github.io/github-actions-demo"创建工作流文件在项目的.github/workflows目录下,创建工作流文件,这里是ci.yml。上面说了,GitHub有一个官方市场。这里直接使用JamesIves/github-pages-deploy-action:name:GitHubActionsBuildandDeployDemoon:push:branches:-masterjobs:build-and-deploy:runs-on:ubuntu-lateststeps:#Pullcode-name:Checkoutuses:actions/checkout@v2#Ifyou'rereusingactions/checkout@v2youmustsetpersist-credentialstofalse在大多数情况下为了部署正确地工作。with:persist-credentials:false#Installdependencies,packaging-name:InstallandBuildrun:|npminstalldnpmrun#deployment-scriptbuildGotoGitHubPages-name:Deployuses:Jame??sIves/github-pages-deploy-action@releases/v3with:ACCESS_TOKEN:${{secrets.ACCESS_TOKEN}}BRANCH:gh-pagesFOLDER:build这里整理下配置文件做了什么:1、拉取代码。这里使用官方的GitHubaction:actions/checkout@v22,安装依赖,打包3,部署到GitHubPages。第三方作者的动作使用:JamesIves/github-pages-deploy-action@releases/v3。这里详细介绍一下这个动作:使用with参数给环境传入三个环境变量:readThebranchtotake)FOLDER:仓库中要部署的文件的路径,也就是我们使用npmrunbuild生成的打包目录这里需要注意一点:我使用的是v3版本,需要使用with参数传入环境变量,需要自己搭建;网上常见的教程使用的是v2版本,env参数用于传入环境变量。不需要自己构建,可以使用BUILD_SCRIPT环境变量传入构建脚本。至此,配置工作完成。以后每次有代码推送到master分支,GitHub都会自动开始构建。分享具体代码通常我们可能有一行非常好的代码想分享给其他同事,那么我们可以在url后面加上#L行号,例如:https://github.com/Jack-cool/rest_node_api/blob/master/app/models/users.js#L17,效果如下:如果要分享几行,可以在url后面加#L开始行号-L结束行号,比如https://github.com/Jack-cool/rest_node_api/blob/master/app/models/users.js#L17-L31,效果如下图:IssuesareautomaticallyclosedbysubmittingmsgLet's先看关闭issue的关键字:closeclosesclosedfixfixesfixedresolveresolved关闭同仓库issue如果想关闭同仓库issue,可以使用上面列表中的关键字,加上reference它后面的问题编号。例如,如果一个commit包含fixes#26,一旦这个commit被合并到default分支,仓库中的issue26将自动关闭。如果commit不在default分支,issue不会关闭,但下方会有提示信息。此消息将告诉您有人添加了提及此问题的提交,如果您将其合并到默认分支,该提交将被关闭。关闭不同存储库中的问题如果你想关闭另一个存储库中的问题,你可以使用类似用户名/存储库/#issue_number的语法。例如,如果提交消息包含closesJack-cool/fe_interview/issues/113,它将关闭fe_interview中的问题113。关闭其他仓库issue的前提是你已经将代码推送到对应的仓库,查看项目的访问数据。在你自己的项目下,点击Insights,然后点击Traffic,里面有Referringsites和Popularcontent的详细数据和排名。其中,Referringsites表示每个人都从哪个网站访问您的项目,而Popularcontent表示人们经常查看您项目的哪些文件。任务列表有时我们需要标记一些任务列表来记录我们下一步要做什么。您可以在任务列表议题和拉取请求中添加复选框。语法如下(注意空格):-[]Step1-[]Step2-[]Step2.2-[]Step2.3-[]Step3效果如下:一个只读的任务列表可以是在普通markdown文件中创建,比如在README.md中添加TODO列表:###Nextthingtodo🦀-[x]数据结构和算法-[]react源码-[]docker效果如下:对任务排序您可以单击任务左侧的复选框并将其拖放到新位置,以在单个评论中重新排序任务列表。问题模板和拉取请求模板这是一个问题模板示例。pr模板类似于这个问题模板。我在给elementui提issue的时候发现:在GitHub中,如果代码库维护者提供定制的issues模板和pullrequest模板,可以让人们针对某类问题提供有针对性的准确信息,从而进行有效的对话和交流。可以在后续维护中进行改进,而不是乱七八糟的信息。创建问题模板在代码库根目录新建.github目录在.github目录下添加ISSUE_TEMPLATE.md文件作为问题的默认模板。创建问题时,系统会自动引用该模板。比如我在项目根目录下新建了一个.github/ISSUE_TEMPLATE.md:##Overviewbugoverview##Reproducestep1.aaa2.bbb3.ccc##BugBehaviorBugBehavior##ExpectedBehaviorSoftwareCorrectBehavior##附上图片或日志,请使用日志的格式:>```>日志内容>```在本仓库新建issue时,会出现上面预设的issue模板:GitHubWiki,大家常用的项目,一般都是用Markdown来写项目文档和README.md等。Markdown一般可以满足我们的文档编写需求,如果使用得当,效果也很好。但是当项目文档比较长的时候,阅读体验可能就不是那么理想了。这种情况我想大家应该都遇到过。每个GitHub项目都有一个单独的、完整的Wiki页面,我们可以利用它来实现项目信息管理,为项目提供更全面的文档。我们可以将Wiki作为项目文档的重要组成部分,将冗长、具体的文档整理成Wiki,将精简和概述的内容放在项目或README.md中。关于wiki的使用,这里就不多说了。具体可以参考官方文档查看提交记录热力图。查看文件时,可以按b键查看提交记录和热图显示每行的最新修改。它会告诉您每一行代码的提交者,并提供可点击的链接以查看完整的提交。中间有一个橙色的垂直条。颜色越鲜艳,越接近变化。Git子模块与Git子树为什么使用子模块或子树?团队通常有公共代码库。子模块和子树让我们可以在不同的项目中使用这些公共代码,避免因为抄袭导致代码重复,甚至导致同一代码的差异修改产生多个版本。区分subtree和submodule的目的是为了git分库管理。两者的主要区别在于subtree属于copy子仓库,而submodule属于reference子仓库。关于实践,官方文档说的很清楚,我就直接放链接了:.io/post/2020/04/git-subtree-usage.htmlGitHubpluginsGitHub推荐的插件有很多。这是我常用的三个插件。Octotree我们有时候需要在github上找文件,但是如果文件结构嵌套很深,找起来就很麻烦。这时候使用Octotree可以在仓库左侧显示当前项目的目录结构,让你在github上使用就像使用WebIDE一样方便。isometric-contributions这是一个比较酷的3D立体渲染github贡献。增强型GitHub插件支持显示存储库大小、每个文件的大小以及存储库中每个文件的下载链接。GitHubmascotOctocat哈哈这个比较有意思。刚知道GitHub也有自己的吉祥物。把网址贴在这里,顺便选几个觉得可爱的,也可以去上面选几个做自己的头像什么的。