This set gives an overview of the following concepts in GitHub.
A repository is similar to a folder, and a GitHub repository becomes a folder that is available online on the cloud for people to download, access, and contribute. This folder contains the code files of the project, which other people can now use.
GitHub was introduced to share the repository with other people who are interested in something that the user is doing or contribute to the repository on which the user himself is interested. GitHub repository helps to connect people. A GitHub repository plays a vital role among the developers to develop something easy and make it available to the whole world.
You can customize access to each repository in your organization with granular permission levels. The levels are read, triage, write, maintain, and admin.
Issues are a great way to keep track of tasks, enhancements, and bugs for your projects. They’re kind of like email - except they can be shared and discussed with the rest of your team. Most software projects have a bug tracker of some kind. GitHub’s tracker is called issues.
The issue has its own section in every repository. GitHub’s issue tracking is special because of our focus on collaboration, references, and excellent text formatting.
Once you’ve collected a lot of issues, you may find it hard to find the ones you care about. Milestones, labels, and assignees are great features to filter and categorize issues.
Contributions to a source code repository that uses a distributed version control system such as git are commonly made by means of a pull request, also known as a merge request. The contributor requests that the project maintainer pull the source code change, hence the name "pull request".
Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.
You can manage your work on GitHub by creating labels to categorize issues, pull requests, and discussions. You can apply labels in the repository the label was created in. Once a label exists, you can use the label on any issue, pull request, or discussion within that repository.
Anyone with read access to a repository can view and search the repository’s labels. Anyone with triage access to a repository can apply/dismiss existing labels. To create, edit, apply, or delete a label, you must have write access to the repository.
Project boards on GitHub help you organize and prioritize your work. You can create project boards for specific feature work, comprehensive roadmaps, or even release checklists. With project boards, you have the flexibility to create customized workflows that suit your needs.
Types of project boards:
You can use milestones to track progress on groups of issues or pull requests in a repository.
Milestones are kind of labels that mark and group work that are expected to be delivered at some point in time. The Milestones page, which you can access from the Issues page, clarifies that you can see the percentage of tickets completed for a particular milestone and the due date. You can also sort milestones by the due date and prioritize works within a particular milestone.
The stress here is on delivery dates and tracking progress.
GitHub Actions helps you automate your software development workflows from within GitHub. You can deploy workflows in the same place where you store code and collaborate on pull requests and issues.
Each workflow is made up of individual actions that run after a specific event (like a pull request) occurs. The individual actions are packaged scripts that automate software development tasks.
With GitHub Actions for Azure, you can create workflows that you can set up in your repository to build, test, package, release, and deploy to Azure. GitHub Actions for Azure supports Azure services, including Azure App Service, Azure Functions, and Azure Key Vault.
Events are used to execute GitHub Action. They are used to trigger a workflow.
GitHub supports various types of events
push
, pull_request
, public
schedule
)workflow_dispatch
event (external systems)Workflows are like pipelines, comparable to a Jenkins or a Travis file. A workflow is a collection of steps and jobs that are run and glue together existing actions in a sequence.
A workflow listens for a particular event and then runs pre-existing actions or shell scripts. The workflow action runs in VMs (Linux, Windows, macOS, or Docker on Linux VM).
Codify useful, customized processes
A runner is a server that has the GitHub Actions runner application installed. A runner listens for available jobs, runs one job at a time, and reports the progress, logs, and results back to GitHub. You can use a runner hosted by GitHub, or you can host your own.