This is a practical workshop consisting of common GitHub-related actions.
It is based on the unikraft/catalog-core
repository, giving us a concrete Git repository to screw up ... hmmmm ... to do wonderful amazing great things to.
First of all, clone the repository:
git clone https://github.com/rosedu/workshop-github
cd workshop-github/
And let's get going! 🚀
Take a look at the following repositories:
Do a tour of as much information as possible about them:
- See statistics about the programming languages used.
- See information about contributors.
- See number of stars and number of forks.
- Take a quick look at the issues and pull requests.
Take a look at the GitHub projects for the unikraft
organization.
Browse the projects.
Look at the Release - Next
GitHub project.
Browse the items in the list.
Browse different views (tabs) in the projects.
Take a look at pull requests in the unikraft
repository.
Select 3 pull requests and check them out.
Look at the discussions, changes, checks for each pull request.
Identify a pull request that is connected to an issue.
Select pull requests that have been authored by michpappas
.
Select pull requests that are to be reviewed by michpappas
.
Select pull requests that use the area/plat
label.
Let's set up GitHub for proper use.
If you haven't already, add your public SSH key to your GitHub account. Follow the instructions here.
Create a personal access token to use as an authentication mechanism for GitHub. Follow the instructions here. Add all permissions to the personal access token.
Follow the instruction here and install GitHub CLI.
Authenticate to GitHub:
gh auth login
Use the username and the personal access token above to authenticate.
Then clone the three repositories above:
git clone https://github.com/unikraft/unikraft
git clone https://github.com/microsoft/openvmm
git clone https://github.com/nodejs/node
For each repository, use the GitHub CLI tool to:
- List repository issues with
gh issue list
. - List repository pull requests with
gh pr list
. - List repository pull requests whose state is
closed
withgh pr list -s closed
. - View details about a pull request with
gh pr view <PR_ID>
.
Let's first create a work GitHub repository based on the current repository. We will use it for toying around, messing it up and fixing it.
First, make sure you are in the local directory clone of this repository (workshop-github
).
Then, create a repository on GitHub from the command line (using GitHub CLI - gh
):
./gh-create-repo.sh
Check your repository on GitHub using a web browser.
Your repository is now available as the upstream
remote.
Check your remotes:
git remote show
git remote show origin
git remote show upstream
Let's now create pull requests on our GitHub repository. A pull request is created from a series of commits in a branch.
We do the steps:
-
Create a branch for the new pull request:
git checkout -b add-c-bye
-
Create the contents of the
c-bye
program:unzip support/c-bye.zip
-
Create commit:
git add c-bye/ git commit -s -m 'Introduce c-bye program'
-
Push commit to the
upstream
remote:git push upstream add-c-bye
-
Create a pull request by clicking on the URL that was printed by the command above. You will end up having a pull request created in the repository. The pull request is requesting for a merge to happen from the
add-c-bye
tomain
.
-
Repeat the above steps at least 2 more times. Reset before each step:
./gh-reset-repo.sh
-
Do the same steps as above for the
cpp-bye
andpython3-bye
programs in thesupport/
directory. You should end up with three pull requests.
The pull requests should be reviewed and merged. For that, in the GitHub web interface for the pull request follow the steps:
-
Go to the
Files changed
tab. -
Click the
Review changes
button. -
Aim to approve your pull request. You cannot approve your pull request, if you're the author.
-
Now, get back to the
Conversation
tab. Go below to theMerge pull request
button.Below clicking the button, see the options from the little drop-down option on the right. See what are the options, choose one and do it.
-
Do the steps above for all 3 pull requests.
-
Now reset the repository:
./gh-reset-repo.sh
and redo the pull requests, and merge them again.
-
Create your own commits and pull requests. Be creative.
Create at least one pull request with two commits. Use the
Squash and merge
merge strategy.
In order to approve a pull request, you need to have another user able to approve your pull requests.
Before everything, reset the repository:
./gh-reset-repo.sh
And create the pull request, as above.
To add someone to be able to approve your pull requests, they need to have Triage
permissions.
For this, do the following:
-
Go to the
Settings
tab in the GitHub web view of your repository. -
Go to the
Collaborators
entry in the left menu. You'll have to provide your GitHub password, or use some other authentication method. -
Ask someone around you for their GitHub username. Add them to the repository as collaborator.
-
Ask them to confirm the invite via e-mail or by accessing the invitation URL:
https://github.com/<your-github-username>/workshop-github/invitations
-
Ask them to approve your pull request.
-
Now merge the pull request.
We want to enforce an approval for our pull requests.
Before everything, reset the repository:
./gh-reset-repo.sh
And create the pull request, as above.
Now add a ruleset to add a required approval condition. For this, do the following:
-
Go to the
Settings
tab in the GitHub web view of your repository. -
Go to the
Branches
entry in the left menu. -
Click
Add branch ruleset
. -
Check
Require a pull request before merging
. -
Add
1
toRequired approvals
. -
Now ask for an approval for your pull request, as above.
-
Merge the pull request with the approval now done.
We want to configure Rebase and merge
as the only merge strategy.
For that, do the steps:
-
Go in the
Settings
tab in web view of your GitHub repository. -
Go to the
Pull Requests
session. -
Uncheck
Allow merge
commits andAllow squash merging
.
Now create a new pull request and see that the only option for merging is Rebase and merge
.
GitHub shines for collaborative / team work. For this, work in pairs of two.
Before this, do a reset of your repository:
./gh-reset-repo.sh
Each of view should now:
-
Create of fork of the other's repository. Be sure to give it a different name, not to clash with your own
workshop-github
repository name. -
Clone the fork locally:
git clone <fork_url> cd <clone_directory>
-
Create a branch and commit(s) from
c-bye
. -
Push the branch to the
origin
remote (belonging to your fork). -
Create a pull request to the other's repository (from fork to the initial repository).
-
The other person should approve and merge your pull request.
Do this multiple times, be creative, use your own ideas.
Now, let's get really creative.
Continue working in pairs of two.
Each of you should create their own repository, with whatever content they want.
Create it from scratch, be creative, do whatever you want.
Configure the repository to use the Rebase and merge
strategy.
Ask the other to fork your repository and then ask the other to create a pull request. Toy around.
Before asking for a pull request, create an issue on your repository, and ask the other to "solve" the issue by creating a corresponding pull request. Link the pull request to the issue once it is created, by following instructions here.