GitHub简介 (Introduction to GitHub)
GitHub is a website where millions of developers gather every day to collaborate on open source software. It’s also the place that hosts billions of lines of code, and also a place where users of software go to report issues they might have.
GitHub是一个网站,每天都有数百万的开发人员聚集在一起,就开源软件进行协作。 它也是托管数十亿行代码的地方,也是软件用户报告他们可能遇到的问题的地方。
In short, it’s a platform for software developers, and it’s built around Git.
简而言之,它是面向软件开发人员的平台,它是围绕Git构建的。
TIP: If you don’t know about Git yet, checkout the Git guide.
提示:如果您还不了解Git,请查阅Git指南 。
As a developer you can’t avoid using GitHub daily, either to host your code or to make use of other people’s code. This post explains you some key concepts of GitHub, and how to use some of its features that improve your workflow, and how to integrate other applications into your process.
作为开发人员, 您不能避免每天都使用GitHub来托管代码或使用他人的代码。 这篇文章向您介绍了GitHub的一些关键概念,以及如何使用其某些功能来改善工作流程,以及如何将其他应用程序集成到您的流程中。
为什么选择GitHub? (Why GitHub?)
Now that you know what GitHub is, you might ask why you should use it.
现在您知道GitHub 是什么了,您可能会问为什么要使用它。
GitHub after all is managed by a private company, which profits from hosting people’s code. So why should you use that instead of similar platforms such as BitBucket or GitLab, which are very similar?
GitHub毕竟是由一家私人公司管理的,该公司从托管人的代码中获利。 那么,为什么不使用类似的平台(例如BitBucket或GitLab)呢?
Beside personal preferences, and technical reasons, there is one big reason: everyone uses GitHub, so the network effect is huge.
除了个人喜好和技术原因外,还有一个重要原因:每个人都使用GitHub,因此网络影响巨大。
Major codebases migrated over time to Git from other version control systems, because of its convenience, and GitHub was historically well positioned into (and put a lot of effort to “win”) the Open Source community.
随着时间的推移,主要的代码库从其他版本控制系统迁移到了Git,因为它的便利性,并且GitHub在历史上已经很好地定位于Open Source社区(并付出了很多努力来“赢得”)。
So today any time you look up some library, you will 99% of the times find it on GitHub.
因此,今天无论何时您查找某个库,您都会有99%的时间在GitHub上找到它。
Apart from Open Source code, many developers also host private repositories on GitHub because of the convenience of a unique platform.
除了开放源代码,由于独特平台的便利性,许多开发人员还在GitHub上托管私有存储库。
GitHub问题 (GitHub issues)
GitHub issues are one of the most popular bug tracker in the world.
GitHub问题是世界上最受欢迎的错误跟踪器之一。
It provides the owners of a repository the ability to organize, tag and assign to milestones issues.
它为存储库的所有者提供了组织,标记和分配里程碑事件的能力。
If you open an issue on a project managed by someone else, it will stay open until either you close it (for example if you figure out the problem you had) or if the repo owner closes it.
如果您在其他人管理的项目中打开问题,它将一直处于打开状态,直到您关闭它(例如,如果您发现存在的问题)或回购所有者关闭它。
Sometimes you’ll get a definitive answer, other times the issue will be left open and tagged with some information that categorizes it, and the developer could get back to it to fix a problem or improve the codebase with your feedback.
有时,您会得到一个明确的答案,有时,问题将被悬而未决,并带有对问题进行分类的一些信息,开发人员可以根据问题的反馈来解决问题或改善代码库。
Most developers are not paid to support their code released on GitHub, so you can’t expect prompt replies, but other times Open Source repositories are published by companies that either provide services around that code, or have commercial offerings for versions with more features, or a plugin-based architecture, in which case they might be working on the open source software as paid developers.
大多数开发人员无需支付支持他们在GitHub上发布的代码的费用,因此您不会期望得到Swift的答复,但是其他时候,开放源代码存储库是由围绕该代码提供服务或针对具有更多功能的版本提供商业产品的公司发布的,或基于插件的体系结构,在这种情况下,他们可能会以付费开发人员的身份在开源软件上工作。
社会编码 (Social coding)
Some years ago the GitHub logo included the “social coding” tagline.
几年前,GitHub徽标包含“社交编码”标语。
What did this mean, and is that still relevant? It certainly is.
这是什么意思,仍然有意义吗? 必然是。
跟随 (Follow)
With GitHub you can follow developers, by going on their profile and clicking “follow”.
通过GitHub, 您可以关注开发人员 ,方法是进入开发人员的个人资料,然后单击“关注”。
You can also follow a repository, by clicking the “watch” button on a repo.
您还可以通过单击存储库上的“ 监视 ”按钮来跟踪存储库 。
In both cases the activity will show up in your dashboard. You don’t follow like in Twitter, where you see what people say, but you see what people do.
在这两种情况下,活动都会显示在您的仪表板中。 您不会像在Twitter中那样关注,您会看到人们在说什么,但您会看到人们在说什么 。
星星 (Stars)
One big feat of GitHub is the ability to star a repository. This action will include it in your “starred repositories” list, which allows you to find things you found interesting before, and it’s also one of the most important rating mechanisms, as the more stars a repo has, the more important it is, and the more it will show up in search results.
GitHub的一项壮举是能够对存储库加注星标 。 此操作会将其包括在“已加星标的存储库”列表中,使您可以找到以前发现的有趣内容,它也是最重要的评级机制之一,因为回购交易的星标越多,它就越重要,并且它将更多地显示在搜索结果中。
Major projects can have 70.000 and more stars.
大型项目可以拥有70.000个或更多的星星。
GitHub also has a trending page where it features the repositories that get the most stars in a determined period of time, e.g. today or this week or month.
GitHub也有一个趋势页面 ,其中包含在确定的时间内(例如今天,本周或本月)获得最多星星的存储库。
Getting into those trending lists can cause other network effects like being featured on other sites, just because you have more visibility.
进入这些趋势列表可能会导致其他网络效应,例如在其他站点上出现,只是因为您具有更高的可见性。
叉子 (Fork)
The last important network indicator of a project is the number of forks.
项目的最后一个重要网络指标是分叉数。
This is key to how GitHub works, as a fork is the base of a Pull Request (PR), a change proposal. Starting from your repository, a person forks it, makes some changes, then creates a PR to ask you to merge those changes.
这是GitHub工作方式的关键,因为派生是变更请求(Pull Request)的基础。 从您的存储库开始,有人分叉它,进行一些更改,然后创建PR来要求您合并这些更改。
Sometimes the person that forks never asks you to merge anything, just because they liked your code and decided to add something on top of it, or they fixed some bug they were experiencing.
有时,分叉的人从不要求您合并任何东西,仅仅是因为他们喜欢您的代码并决定在其顶部添加一些内容,或者他们修复了所遇到的错误。
A fork clones the files of a GitHub project, but not any of the stars or issues of the original project.
分支会克隆GitHub项目的文件,但不会克隆原始项目的任何星号或问题。
受欢迎=更好 (Popular = better)
All in all, those are all key indicators of the popularity of a project, and generally along with the date of the latest commit and the involvement of the author in the issues tracker, is a useful indication of whether or not you should rely on a library or software.
总而言之,这些都是项目受欢迎程度的关键指标,通常与最近一次提交的日期以及作者在问题跟踪器中的参与一起,对于您是否应依赖项目而言,是一个有用的指示。库或软件。
拉取要求 (Pull requests)
Before I introduced what is a Pull Request (PR)
在介绍什么是拉取请求(PR)之前
Starting from your repository, a person forks it, makes some changes, then creates a PR to ask you to merge those changes.
从您的存储库开始,有人分叉它,进行一些更改,然后创建PR来要求您合并这些更改。
A project might have hundreds of PRs, generally the more popular a project, the more PRs, like the React project:
一个项目可能有数百个PR,通常项目越受欢迎,PR越多,例如React项目:
![React Pull Requests](https://i-blog.csdnimg.cn/blog_migrate/cb8f6f7df74c86b739c4eaaaed584ec8.png)
Once a person submits a PR, an easy process using the GitHub interface, it needs to be reviewed by the core maintainers of the project.
一旦一个人使用GitHub界面提交了PR,这是一个简单的过程,则需要项目的核心维护者对其进行审查。
Depending on the scope of your PR (the number of changes, or the number of things affected by your change, or the complexity of the code touched) the maintainer might need more or less time to make sure your changes are compatible with the project.
根据PR的范围 (更改的数量或受更改影响的事物的数量或所触摸的代码的复杂性),维护人员可能需要更多或更少的时间来确保您的更改与项目兼容。
A project might have a clear timeline of changes they want to introduce. The maintainer might like to keep things simple while you are introducing a complex architecture in a PR.
一个项目可能有一个明确的时间表,他们想要引入更改。 当您在PR中引入复杂的体系结构时,维护人员可能希望使事情简单。
This is to say that not always a PR gets accepted fast, and also there is no guarantee that the PR will even get accepted.
这就是说PR并非总是很快就会被接受 ,也不能保证PR甚至会被接受 。
In the example i posted above, there is a PR in the repo that dates back 1.5 years. And this happens in all the projects.
在我上面发布的示例中,回购中有一个PR可以追溯到1.5年。 这在所有项目中都会发生。
项目管理 (Project management)
Along with issues, which are the place where developers get feedback from users, the GitHub interface offers other features aimed at helping project management.
除了问题(开发人员从用户那里获得反馈的地方)之外,GitHub界面还提供了旨在帮助项目管理的其他功能。
One of those is Projects. It’s very new in the ecosystem and very rarely used, but it’s a kanban board that helps organizing issues and work that needs to be done.
其中之一就是Projects 。 它是生态系统中的一种新事物,很少使用,但它是一个看板板 ,可帮助组织问题和需要完成的工作。
The Wiki is intended to be used as a documentation for users. One of the most impressive usage of the Wiki I saw up to now is the Go Programming Language GitHub Wiki.
Wiki旨在用作用户的文档。 我到目前为止看到的最令人印象深刻的Wiki使用之一是Go编程语言GitHub Wiki 。
Another popular project management aid is milestones. Part of the issues page, you can assign issues to specific milestones, which could be release targets.
另一个流行的项目管理帮助是里程碑 。 在问题页面的一部分中,您可以将问题分配给特定的里程碑,这些里程碑可以作为发布目标。
Speaking of releases, GitHub enhances the Git tag functionality by introducing releases.
说到发行版,GitHub通过引入发行版增强了Git标签功能。
A Git tag is a pointer to a specific commit, and if done consistently, helps you roll back to previous version of your code without referencing specific commits.
Git标记是指向特定提交的指针,如果一致执行,则可以帮助您回滚到以前的代码版本,而无需引用特定的提交。
A GitHub release builds on top of Git tags and represents a complete release of your code, along with zip files, release notes and binary assets that might represent a fully working version of your code end product.
GitHub版本基于Git标签构建,代表了您的代码的完整版本,以及zip文件,发行说明和二进制资产,它们可能代表了代码最终产品的完整版本。
While a Git tag can be created programmatically (e.g. using the Command Line git
program), creating a GitHub release is a manual process that happens through the GitHub UI. You basically tell GitHub to create a new release and tell them which tag you want to apply that release to.
虽然可以通过编程方式(例如,使用命令行git
程序)创建Git标签,但是创建GitHub版本是通过GitHub UI进行的手动过程。 您基本上是告诉GitHub创建一个新版本,并告诉他们要将该版本应用于哪个标签。
比较提交 (Comparing commits)
GitHub offers many tools to work with your code.
GitHub提供了许多工具来处理您的代码。
One of the most important things you might want to do is compare one branch to another one. Or, compare the latest commit with the version you are currently using, to see which changes were made over time.
您可能想做的最重要的事情之一就是将一个分支与另一个分支进行比较。 或者,将最新提交与当前使用的版本进行比较,以了解随着时间的推移进行了哪些更改。
GitHub allows you to do this with the compare view, just add /compare
to the repo name, for example: https://github.com/facebook/react/compare
GitHub允许您使用compare视图执行此操作,只需在仓库名称中添加/compare
即可,例如: https : //github.com/facebook/react/compare
![Compare View](https://flaviocopes.com/github/2.png)
For example here I choose to compare the latest React v15.x to the latest v16.0.0-rc version available at the time of writing, to check what’s changed:
例如,在这里,我选择比较最新的React v15.x和撰写本文时可用的最新v16.0.0-rc版本,以检查更改了什么:
![Compare React Versions](https://flaviocopes.com/github/3.png)
The view shows you the commits made between two releases (or tags or commits references) and the actual diff, if the number of changes is lower than a reasonable amount.
您视图显示两个版本(或标签或提交参考)和实际之间的差异 进行的提交 , 如果变化的数量比一个合理的金额。
Webhooks和服务 (Webhooks and Services)
GitHub offers many features that help the developer workflow. One of them is webhooks, the other one is services.
GitHub提供了许多有助于开发人员工作流程的功能。 其中之一是webhooks,另一个是服务。
网络挂钩 (Webhooks)
Webhooks allow external services to be pinged when certain events happen in the repository, like when code is pushed, a fork is made, a tag was created or deleted.
当存储库中发生某些事件时,例如当推送代码,创建派生,创建或删除标签时,Webhooks允许对外部服务执行ping操作。
When an event happens, GitHub sends a POST request to the URL we told it to use.
当事件发生时,GitHub将POST请求发送到我们告诉它使用的URL。
A common usage of this feature is to ping a remote server to fetch the latest code from GitHub when we push an update from our local computer.
此功能的常见用法是,当我们从本地计算机推送更新时,对远程服务器执行ping操作以从GitHub获取最新代码。
We push to GitHub, GitHub tells the server we pushed, the server pulls from GitHub.
我们推送到GitHub,GitHub告诉我们推送的服务器,服务器从GitHub提取。
服务 (Services)
GitHub services, and the new GitHub apps, are 3rd party integrations that improve the developer experience or provide a service to you.
GitHub服务和新的GitHub应用程序是第三方集成,可改善开发人员体验或为您提供服务。
For example you can setup a test runner to run the tests automatically every time you push some new commits, using TravisCI.
例如,您可以使用TravisCI设置一个测试运行程序,以在每次推送一些新提交时自动运行测试。
You can setup Continuous Integration using CircleCI.
您可以使用CircleCI设置持续集成。
You might create a Codeclimate integration that analyzes the code and provides a report of technical debt and test coverage.
您可以创建一个Codeclimate集成,该集成可以分析代码并提供技术债务和测试范围的报告。
最后的话 (Final words)
GitHub is an amazing tool and service to take advantage of, a real gem in today’s developer toolset. This tutorial will help you start, but the real experience of working on GitHub on open source (or closed source) projects is something not to be missed.
GitHub是一个了不起的工具和服务,可以利用,它是当今开发人员工具集中的真正瑰宝。 本教程将帮助您入门,但是不容错过在GitHub(开放源代码(或封闭源代码)项目)上工作的真实经验。