Intermediate Github Tutorial

Intro

[0:00 Video timestamp]

Read it, watch it, do it, review it:

There are both a written and accompanying video version of this tutorial. The written version has timestamps under the headings that align with the video version of the topic.

Read it: For each topic heading, first read the topic.
Watch it: Then watch the associated section of the video.
Do it: Then follow the instructions to replicate the steps on your computer.

The CheatSheet has a major category that aligns with this tutorial.

Review it: When you are done with the whole tutorial, do the two GitHub exercises. They repeat the steps from this tutorial without the explanations so you can do them quickly. One exercise uses only Git commands, the other uses the VS Code Source Control sidebar's graphical user interface.
Open the CheatSheet and review the Intermediate GitHub category which includes all the topics from this tutorial. Make sure you understand everything, and can refer back to the CheatSheet when you are working on your own projects in the future.

In the Beginning GitHub tutorial we covered the basics of:

Creating a GitHub account, authenticating it.
Adding a repository to it.
Adding the remote to the local git repository.
Pushing to the remote.
And cloning someone else's remote repository to your computer.

This intermediate GitHub video will focus on using GitHub for collaboration.

Using it as the central repository.

Specifically, we will cover the following topics:

Adding collaborators, protecting branches, releases, licenses, synching the local repo to the remote using fetch or pull.
We will walk through 4 collaboration examples using the shared repository model and the fork and pull model.
And we'll cover creating issues.

We will demonstrate the topics using the git-demo project from the Git and Beginning GitHub tutorials.

The finished code from this whole Git/GitHub series is hosted at github.com/LearnByCheating/git-demo.
To reset it to the finished code from this tutorial enter: git reset --hard v4-intermediate-github
To reset it to the beginning code for this tutorial enter: git reset --hard v3-beginning-github

The VS Code text editor has an integrated Terminal window and Source Control sidebar. We will use both Git commands and the VS Code Source Control sidebar for the actions covered in this tutorial. If you are not using VS Code, just skip over those sections.

Collaborators

[0:59 Video timestamp]

GitHub allows you to add collaborators to a repository and assign permissions.
If the repository is on your personal account, you will be the repository owner.
If the repository is on an organization account, the organization can have one or more owners.
Owners have full administrative access to the repository which includes adding collaborators.
The Visibility setting can be seen to the right of the repo name. Visibility can be public or private.

Public repositories can be seen by anyone.
Private repositories can only be seen by the owner and collaborators.
You can change the visibility in the Settings tab.

To add a collaborator, click the ⚙ Settings tab in the navigation bar > On the left panel select Collaborators and teams

The Who has access section gives an overview of visibility and access.
There is one base role member. And no one with write access except owners, which is you.
You can create a team for the repository. Teams can also be created at the organization level.
To add collaborators click Add people, and enter username or email of collaborators.
Then select their role which determines what access permissions they have.

Everyone has read access to a public repository. For private repos, all members of the organization have read access by default.
Write access allows collaborators to push the the repo, and approve pull requests or request changes be made.
Admins have full access to the repo including adding/removing collaborators and deleting the repository.

Branch Protection

[2:30 Video timestamp]

The default branch is the base branch of the repository, against which all pull requests and commits are made, unless a different branch is specified.
To see or change the default branch, from the left panel in the Settings tab, click Branches. The default branch is listed.
When collaborating on a project you will likely want to protect the default branch from being overwritten by a forced push, or deleted. You can do that by adding branch protection.
Click the Add rule button. Enter the branch name "main".
There are a number of rules you can add.
To require Pull requests, check "Require a pull request before merging".
To require pull requests be reviewed and approved before being merged, check Require approvals.
I will be doing some commits without pull requests so I will uncheck that.
By pressing create, the main branch is now protected from force commits and being deleted.

Releases

[3:30 Video timestamp]

If you publish your project as a software application and you periodically release new versions, you can add tags to your commits with the version number.
Log the commits you have so far in the git-demo project:

git glog

You should have three tagged commits, v1-beginning-git, v2-intermediate-git, and v3-beginning-github.
For software applications, the release name will be the release version number using semantic versioning.
Semantic versioning uses three numbers corresponding to sequential major, minor, or patch changes since the last release. Our tags aren't exactly following that convention. Instead, for convenience we have just have major version followed by the tutorial title.

To use these tags to create a release, click "Create a new release"
From the Choose a tag drop-down button select v1-beginning-git.
For the title put the initial semantic version number: 1.0.0
For the release notes, list the changes since the last release.
Click the Publish release button.
The code gets packaged as both a zip and a tar file for download.
Repeat that for the other two tags.
Go back to the main page and you can see there are 3 releases with the latest release as the default.

Add a software license

[5:26 Video timestamp]

Github recommends adding a license to public repositories. And they have license templates you can use.
You can add it directly on Github. Click the Add file button > select Create new file.
For the file name enter LICENSE or LICENSE.md in all caps.
Click the "Choose a license template" link. Select the MIT license which essentially lets anyone use your code however they want and it is available "as is".
Click the Review and submit button.
Click the Commit changes button
Change the commit message to Add MIT license, and select the "Commit directly to the main branch" option, then click Commit changes.

Now you have a license and a new commit that is on the Github remote repository but is not on your local repo.
Go back to your text editor.

Fetch or Pull from the remote repository

[6:20 Video timestamp]

When collaborating on a project, other people's commit's will get merged into the central remote repository.
Our local repo is currently out of sync with the remote, behind by one commit.
Remote tracking branch: We are on the main branch. The corresponding branch in the remote is referred to as the remote-tracking branch.
There are two commands we can use to get us back in sync, fetch or pull.

fetch will check the remote against our local repo to see if the commits are out of sync. If so, it will download the remote commits that are ahead of the local, if any, but doesn't merge them yet.

You can access fetch from the command line or from the Source Control sidebar.

From the command line enter: git fetch
Or from the Source Control sidebar: ⋯ > Fetch

If we are out of sync with the remote, git status will tell tell us how many commits we are behind:

git status

To see the change details, enter the diff command comparing the main branch with the remote's main branch:

git diff main origin/main
It will show the difference is the content of the added License file.

To merge the changes and get back in sync with the remote-tracking branch, you can either:

Merge the remote's commit to the main branch with our local main branch:

git merge origin/main

Or click the Sync Changes button in the Source Control sidebar.

To see all the commits enter: git olog
To see only the commits from this tutorial enter: git olog v3-beginning-github..

v3-beginning-github is the tag name for the last commit from the previous tutorial.

that shows we have one new commit, Add MIT license.

Instead of entering fetch then merge, we can accomplish the same thing with one command... pull

Let's undo that last commit with the reset command and discard the changes by adding the --hard option.

git reset --hard head^

If you run the log command again you can see the license commit is gone:

git olog v3-beginning-github..

The git pull command will combine fetch and merge into one command. Enter it from the command line or with the Source Control menu.

From the command line:

git pull

From the Source Control sidebar. Either:

Click the Sync Changes button.
Or ⋯ > Pull

git olog v3-beginning-github.. confirms the "Add MIT license" commit is back.

Collaborative Development models: (1) Shared Repository, (2) Fork and Pull

[8:52 Video timestamp]

One main reason to use a hosting service like GitHub is to collaborate on projects.
Development models: There are two common development models for collaborating on a project.

The shared repository model.
And the fork and pull model.

Both involve a central remote repository hosted on a platform like Github, with collaborators having cloned copies in their local development environment.
Topic branch: Collaborators can work on different topics offline, like a new feature or a bug fix, by creating a local branch. When done, they push it to the central repository and open a pull request.
Pull request: A pull request is a topic branch that was pushed to the central repository, and is proposed to be merged into the main branch.

Shared Repository Collaboration Model

[9:31 Video timestamp]

The shared repository model is common with small teams and organizations collaborating on private projects.
Collaborators are granted write access to a single shared repository.
When changes need to be made, they create topic branches locally and push them to the remote when done.
Pull requests may or may not be required with this model. But often they are, and may include a code review and general discussion about changes before they are merged into the main branch.
We'll go through two examples. A simple one and a little more involved one.

Shared Repository Model - Example 1

For convenience we will label each step sequentially as steps A through G.

A) Alias remote URL as "origin", and set origin/main as remote-tracking branch:
We already did this step.

Entering git remote will show our remote alias, and git remote -v will show the alias and the URL it represents.
git branch --remotes will show the remote for our current branch, main.

B) In our local repo create a topic branch, code it, then push the topic branch back to the central repository:

This is where the work is done. We'll build our topic branch to add some feature, or fix some bug.
The central repository is now hosted on the remote. Because it is a collaborative project, before working on a topic branch you need to get your local copy is up to date with the central copy. Enter:

git pull

There are not new changes with the central repository so now we can create and checkout a new branch:

git checkout -b feature5

Do our coding:

Add a file called feature5.txt, stage and commit it.

feature5.txt

Some text.

git add feature5.txt
git commit -m 'Add feature5'

Modify app.txt.

app.txt

This is a demo app to learn Git.
Second line modified.
Third line modified in main branch and modified in feature3 branch.
Feature 1.
Feature 2.
Feature 3.
Feature 4.
Feature 5.

Stage and commit it (with one command):

git commit -am 'Modify app.txt'

Now it is ready to push to the remote. Before pushing it, confirm that you still in sync with the remote.
Check out main and do a git pull:

git checkout main
git pull
Nothing changed so are still up to date.

Checkout feature5 again.

git checkout feature5
We have two commits that will get pushed to the central repo git olog -2

Push the whole topic branch to the remote. Specify both the remote, origin, and the branch name, feature5.

git push origin feature5

C) In remote repo, create a pull request from the topic branch:

Go to the Github repository. There will be a notice that a branch was pushed.
Click the Compare & Pull request button.
Modify the commit message to something like: Add feature 5, and give more information in the comment. Then click the Create pull request button.

D & E) Reviewer or reviewers review the pull request then approves it, makes comments to address, or requests changes. If the reviewer requests changes, make changes to the local topic branch, then push the commit:

If you set the main branch protection to require reviewers, this is where they would review our pull request. For this example assume this is a very small team and reviews are not required and you have write access so you can merge your own pull request.

F) Merge the pull request:

There is a button labeled Merge pull request that will merge the topic branch into the main branch.
It gives you three options related to the commits.

We will go with the default Create a merge commit which will use all the commits in the topic branch, plus it will add a separate merge commit. We will discuss the other options in the next example. Click the button.
Then optionally modify the commit message and click Confirm merge.

If you don't plan on adding more commits to this branch, then click the Delete Branch button. It can be restored later if needed.

Go back to the repo main page, and click the commits. You can see that three commits were added from the pull request.

G: After the Pull Request is merged, sync your local repo with it, then delete the branch if you are done with it:

Our local main branch is now out of sync with the remote tracking branch.
In the local repo checkout the main branch and do a git pull, then log the commits.

git checkout main
git pull
git glog

In the commit history the last three commits include the pull request merge commit, then the 2 commits from the feature5 branch.
We are not going to send further commits from the feature5 branch so you can delete it.

git branch -d feature5

Shared Repository Model - Example 2

[13:17 Video timestamp]

Let's do another pull request example, only this time:

The local and remote repos will be out of sync.
There will be a review.
And we will need to make some changes before the commit is merged.

A) Our remote is set up with alias origin.
B) In the local repo create a topic branch, code it, push it to the central repository:

Start by making sure you are still in sync with the remote:

git pull

We are in sync, so create and checkout a new topic branch, feature 6.

git checkout -b feature6

Add your code:

Add file feature6.txt then stage and commit it.

feature6.txt

Some text.
There is a problem on this line.

git add .
git commit -m 'Add feature 6'

Modify app.txt, stage and commit it:

app.txt

This is a demo app to learn Git.
Second line modified.
Third line modified in main branch and modified in feature3 branch.
Feature 1.
Feature 2.
Feature 3.
Feature 4.
Feature 5.
Feature 6.

git commit -am 'Add feature 6 to app.txt'

Let's simulate a change to the central repository by another collaborator.

Go to the central repository on GitHub.
Click the Add File button and select Create New File.
Name the file about.txt
Add file content: About this app
Click the Commit Changes button.
Change the commit message to: Add about page
Make sure the "Commit directly to the main branch" option is selected.
Click the Commit Changes button.
Now there is a new commit in the central repository that is not in the local repo.

Go back to your local repo. We need to check if there were any commits to the main branch since we created our feature6 branch.

Check out the main branch and do a git pull. The logs will show that a new commit was added. Run the log to see the details.

git checkout main
git pull We can do a pull to merge it in.
git log -1 will log the new commit.

Go back to the feature6 branch and merge in the main branch again to get our branch up to date.

git checkout feature6
git merge main

The MERGE_MSG file will open.

You can either change the commit message, save the file and close it.
Or just close the file to use the default commit message at the top of the file.

git olog -3 Logging the last three commits shows the two branch commits plus the merge commit that got our branch back in sync with the remote tracking branch.

Now you can push the branch to the remote:

git push origin feature6 [Or click Publish Branch]

C) In remote repo, create a pull request from the topic branch:

Go to the Github repository.
Right at the top it will notify you that you have a new pushed branch called feature6. Click the Compare & Pull request button.
Github has compared the main branch with the feature6 branch and determined that there are no merge conflicts so it can be merged.
Modify the pull request name Add feature 6 and you can add a description as a comment.
Click the Create a pull request button if you are done with the topic branch. If you are not done and only wanted feedback, you would change it to Create draft pull request.
Optionally, you can request specific people to review it by clicking on the Reviewer settings. They have to have write access to the repository. Github will send them an email about the request.

D) Reviewer(s) review the pull request: Approves, makes comments, or requests changes:

Next let's pretend you are someone else and are going to review the pull request.

Go to the main repository page > on the navigation bar click on the Pull Requests tab > click Add feature 6 pull request.

That will take you to the pull request page. It shows the comment and activity history. Click the Files changed tab, it shows the proposed changes for each file.
Let's say you notice there is a problem with the feature6.txt file that needs to be addressed.
Click the Review changes button.
Enter a comment with your feedback: There is a problem in feature6.txt
Then select the type of review. You don't have access to approve or request changes on your own pull request. But you can leave a comment so make sure the Comment option is selected, then click the Submit review button.

E) If the reviewer requests changes, make changes to the local topic branch, then push the commit:

The Pull Request owner will get notified by email that a comment was made.
The next step is for the creator of the pull request to fix any issues and push the changes to the remote.
Go back to your local repository and resolve the issue. Let's say you found the problem and fixed it. Modify feature6.txt to the below:

feature6.txt

Some text.
This problem was corrected.

Stage and commit it:

git commit -am 'Correct problem in feature6.txt'

And push the branch again:

git push origin feature6

Now it's ready to be reviewed again.

F) Merge or reject the pull request:

Go back to the pull request as the reviewer again. Click the Pull Requests tab then the Feature6 pull request.
The Files changed tab will show the changes in the topic branch.
If everything looks good, an actual reviewer would click Review changes and approve it.

Now the pull request can be merged into the main branch by someone with write access.
Click the Conversation tab.
You can see all the comments and events from the Pull Request.

Click the drop-down arrow ▾ on the right side of the Merge pull request button. It will give us some options. The last time we merged a pull request we used the Create a merge commit option, which used the commits from the topic branch and added a merge commit as well.
This time let's use the squash and merge option. That will combine all the branch commits into one, with no merge commit. It is much cleaner, but don't use this option if you are going to make future commits from the topic branch.
Select it then click the button. Then click the Confirm squash and merge button.
Then click the Delete branch button to delete the branch from the remote.

So now you have two closed pull requests. You can see them by clicking the Pull requests tab. Then click Closed.
You can click the closed Pull requests to see the original details if you need them.

G) When the pull request gets merged into the remote main branch, sync the local repo. Delete branch if complete.

The last step is to go back to your local repository and sync up with the merged pull request.

Checkout the main branch and run git pull to update the local repo. Then log the commits.

git checkout main
git pull
git glog v3-beginning-github..

Looking at the log you can see one commit for the feature6 pull request was added to the main branch.
Now you can delete the topic branch:

git branch -d feature6

We walked through two examples of the shared repository model, now let's look at the fork and pull model.

Fork and Pull Model

[18:11 Video timestamp]

A fork is where you copy of another Github user's repository to your own account.
Use forks to

Propose changes to someone else's project that you don't have write access to.
Or to copy someone else's project to use as a starting point for your own ideas.

Github has a simple tutorial and practice repo called spoon-knife that you can fork: github.com/octocat/Spoon-Knife

But we will do our own fork and pull with our git-demo project.
The fork and pull collaboration model lets potential collaborators propose changes without having write access to the original repository.

It is popular with open source projects.
Anyone can fork an existing repository and push changes to their personal fork, then open a pull request on the original repo.
The changes can be reviewed and pulled into the source repository by the project maintainer.

We will simulate someone else forking your repo, creating a topic branch, and making a pull request.
Each step will be labeled as:

Fork: Actions take by the person forking your repo. Remote Fork are actions take on the remote forked repo. Local Fork are actions take on the local forked repo.
Or Source: Actions taken by the owner of the original repository.

Step A (Fork): Fork and clone an existing repo, then configure your remote:

Step A1 (Remote fork) Fork the repo:

Go to your GitHub git-demo repo.
Click the fork button on the upper right side of your repository.
For clarity, add "fork" to the forked repo name git-demo-fork, then click the Create fork button.

Step A2 (Local fork): The next step is to clone the forked repo:

Copy the repo URL:

Click the Code button > The copy the repo's URL. It will be something like:

https://github.com/your-username/git-demo-fork.git

Then clone it to your computer. You can either:

Open your Terminal application and enter the git clone command using your own username:

git clone https://github.com/your-username/git-demo-fork.git
Then open the project in your text editor.

Or in VS Code open a new window: File menu > New Window.

Click the Clone Git Repository... link > paste in the URL and press enter > select a directory to place it.

Step A3 (Local fork): Alias original remote URL as "upstream":

When you clone the repo, git automatically adds origin as a remote pointing to your forked repo.
Add a second remote pointing to the original source repository. By convention the source repo is aliased as upstream. Change the username to your GitHub account username from the command line or using the VS Code Source Control sidebar:

git remote add upstream https://github.com/orig-username/git-demo.git
Or ⋯ > Remote > Add Remote > enter the URL > enter a name: "upstream"

git remote -v shows our remotes.
You will be pushing your proposed changes to the forked repo, but pulling the latest updates from the original upstream repo.

Step B (Local fork): Create a local topic branch, code it, and push it to forked repo:

Now add your code. Check out a new topic branch called feature7.

git checkout -b feature7

Add a file called feature7.txt with the below code (note it has a bug in it), then stage and commit it.

feature7.txt

Some text.
This is a bug.

git add feature7.txt
git commit -m 'Add feature7.txt'

Modify the app file, stage and commit it.

app.txt

...
Feature 7.

git commit -am 'Add feature 7 to app.txt'

git olog -2 Log the two commits

Before pushing them, make sure the main branch is still in sync with the original repo.
Checkout the main branch and do a git pull specifying the original upstream remote on the main branch.

git checkout main
git pull upstream main
or ⋯ > Pull, Push > Pull from... > select remote: upstream > select branch to pull from: upstream/main

It should be up to date. Switch back to the feature7 branch, and push it to the forked repo. Specify the remote and the branch.

git checkout feature7
git push origin feature7
or:

click Publish Branch button > select remote: origin

Step C (Remote fork): Go to the remote forked repo to create a pull request on the source repo.

Go back to your git-demo-forked repo. It lets you know that the feature7 branch had recent pushes. Click the Compare & pull request button.
It takes you to the source repo to open a pull request on it.
You can modify the Pull request title Add feature 7

And add a comment to give information on what the proposed changes are: Adds functionality x, y, z.

The Create pull request button has a drop-down menu that lets you either create a pull request or a draft pull request. Click the default: Create pull request
This will take you to the source git-demo repository, to the pull request page that you just created.

Step D (Remote source): Source repo reviewer reviews the pull request, then approves, comments, or request changes:

At this point there would be a review of the pull request by one or more people with write access. They would go to the Files changed tab to review the changes then approve it or request changes.

Step E (Local fork): If the reviewer(s) leave comments to address, or request changes, then make them in the fork and push them again. For this example we will assume no change requests.

Step F (Remote source): If approved, the source repo administrator can Merge or Reject the Pull Request.

On the git-demo Add feature 7 Pull Request page there is a button that gives you three options for merging the Pull Request: Create a merge commit, Squash and merge, Rebase and merge.

This time select Rebase and merge and click it. That will add the two commits from the topic branch to the main branch, without adding a separate merge commit.
Click the Confirm rebase and merge button
Click the Delete branch button.
If you click the Code tab on the navigation bar to go back to the main page, then click the commits link at the top right of the file list, you will see Rebase and merge added the two commits from feature7 branch, but didn't add a separate merge commit.

Step G (Local fork): If reviewer merges your PR in original repo, sync local repo, push to fork:

If you continue contributing to the origin repo, then you need to keep your local forked copy in sync with the upstream original.

Go back to your local forked repo and checkout the main branch:

git checkout main

Then do a git pull from the original repo upstream from the main branch:

git pull upstream main

Your local repo main branch is now back in sync with the remote.
But your remote git-demo-fork repo is still out of sync with the source git-demo, so do a push to the "origin" remote:

git push origin main

If you are done with the feature7 branch you can delete it:

git branch -d feature7

The Github git-demo-fork is no longer in sync with the source repo.

Go to the forked repo. Refresh it if necessary. It will tell you if you are behind the source repo by 2 commits. Click the Sync fork button.

Issues

[22:53 Video timestamp]

Github has an issues feature.
Issues are mainly used to identify and fix bugs, but they can also be used to:

Track the progress of a release.
Track progress on a large initiative or project, which is then linked to the smaller issues.
Request a new feature.

Anyone with read access can open an issue, and close their own issue.

If you are a maintainer on the git-demo project and discover there is some kind of bug in feature 7. Clicking the feature7.txt file show the code. On a project with multiple collaborators, there will be a button labeled "Blame". Clicking it will show the commit and who made it.

To open an issue for this, click the Issues tab on the navigation bar > then the New issue button.
Add a title: Feature 7 contains a bug
In the message field, provide details:

Put more details here. 
Mention @someUsername and they will be notified.

Tasklist
- [ ] Task1
- [ ] Task2

There is a toolbar above the field with formatting options. You can use Markdown syntax on GitHub if you are familiar with it.
You can mention users or teams with the @ symbol followed by the username, and they will get notified.
You can add a task list with the format: - [ ] Task name

Then click the Submit new issue button.

The issue is now open. There will be a number after the issue name (e.g., #4). Issues are numbered automatically. Take note of the issue number.

If you have Triage access or higher you can assign the issue to someone by clicking the Assignees ⚙ setting and they will be notified. Assign yourself to the issue.
You can also add a label to the issue by clicking the Labels ⚙ setting. Select the bug label.

You or other collaborators can add comments to open issues:

The problem seems to be coming from feature7.txt on line 2:
`This is a bug.`

Click the Comment button.

Fix the issue:

Let's fix this from the fork repo, using the fork and pull model.
Following the same steps as before, step A is already done. We have a fork and cloned it to our computer.

Step B) In our local repo create a topic branch, code it, push the topic branch:

In your local git-demo-fork repo in the main branch, first confirm you are still in sync with the remote:

git pull upstream main

Create and checkout a branch to fix the issue:

git checkout -b patch-feature7

Then fix the issue in your code. Change line 2 and save the file.

feature7.txt

Some text.
This bug has been patched.

Stage and commit the change with an extended message. Extended messages include a blank line between the short message and the extended message that includes the issue number. Change #4 to your issue number if it is not 4. We'll come back to the extended message later.

git commit -am 'Fix bug in feature7
 
fixes #4 issue'

Switch to the main branch, and make sure it is still in sync.

git checkout main
git pull upstream main

It is still in sync so go back to the topic branch.

git checkout patch-feature7

Then push the branch to the forked repo.

git push origin patch-feature7
Or in VS Code, you can go to the Source Control sidebar and click the Publish branch button and select origin as the remote.

Step C) In the remote forked repo, create a pull request from the topic branch:

The git-demo-fork repo will have a notification of the latest push. Click the Compare & pull request button.

This automatically takes you to the source repo, git-demo.
Github determines there was no merge conflict so you can open the pull request.

The pull request default title is the branch's last commit message.
Notice that the extended message from the commit is put in the pull request description automatically, although you could type it in manually as well.
This links the pull request with open issue #4.

If Github sees one of the following keywords in the pull request description:

close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved.

Followed by the pound sign and issue number (e.g., fixes #4).
Then they will be linked. And when you close the pull request, the issue will automatically be closed as well.

Check or uncheck the Allow edits by maintainers box.
Then click the Create pull request button.

Now the pull request is ready for someone to review and approve it.

Steps D & E) Review and follow up if requested.

Simulate the reviewer by opening the source git-demo repo on the main page.

It should show there is one open pull request. Click it. Then select the open pull request title.

The reviewer can review and approve, comment, or request changes.
Assume you are reviewed it, everything is okay, and you want to merge it.

Step F) Merge the pull request:

Select the type of merge you want to do. We'll use squash and merge so it will just be one commit. Then click the button > and click the Confirm squash and merge button.
Click the Delete branch button.

Because we linked the pull request to issue #4, when the pull request is merged the issue will automatically be closed.
If you click the Issues tab you can see there is 1 closed issue.
Clicking on the issue shows its history.

There is a button labeled Reopen issue to reopen the closed issue.
Or cancel the issue by selecting Close as not planned,

Step G) If the reviewer merges the Pull Request in the remote, sync the fork repos:

If you are keeping the fork active, you now need to sync your fork with the git-demo source remote:
In the local git-demo-fork repo, switch to the main branch:

git checkout main

Pull from the upstream remote to get your local fork repo back in sync with the source repo:

git pull upstream main

But your remote git-demo-fork repo is still out of sync, so do a push to the "origin" remote:

git push origin main

If you don't need the patch-feature7 branch anymore, you can delete it:

git branch -d patch-feature7

Conclusion (Add a Release)

[28:08 Video timestamp]

To wrap up go back to the original git-demo project.
Go to the main branch if you are not already there then log your commits from this tutorial:

git checkout main
git glog v3-beginning-github..

Check if you are in sync with the git-demo remote. Either:

Open the VS Code Source Control sidebar. If you are out of sync it will tell you how many commits you are behind.
Or you can enter git fetch then git status:

git fetch
git status

To get back in sync you can either:

enter: git pull
Or click the Source Control sidebar's Sync Changes button

Add a tag to the last commit:

git tag v4-intermediate-github
Or ⋯ > Tags > Create Tag > Name: v4-intermediate-github > Intermediate GitHub

Log your commits to view the tag on the last one:

git glog v3-beginning-github..

Push the tag to the remote repo:

git push origin v4-intermediate-github

Add the latest tag as a release on GitHub.
Open the GitHub repository > click Releases > click the Draft a new release button > click the Choose a tag button > select v4-intermediate-github tag
This will be a new major release set the title to 4.0.0
Add a description. It uses markdown which you can format using the toolbars above the field.

**Intermediate Github demo app.**

- Add software releases.
- Add collaborators and assign roles (permissions).
- Protect branches.
- Add a license.
- Sync with the remote using fetch and pull.
- Fork a repository.
- Make pull requests.
- Manage Issues.

Click the Publish release button.

That completes this tutorial on Intermediate Github / remotes.
The final tutorial in this series on Git and Github covers the MarkDown language used to make Readmes.

Intermediate Github Tutorial (Video Tutorial)

Intermediate Github Tutorial

Intro

Collaborators

Branch Protection

Releases

Add a software license

Fetch or Pull from the remote repository

Collaborative Development models: (1) Shared Repository, (2) Fork and Pull

Shared Repository Collaboration Model

Shared Repository Model - Example 1

feature5.txt

app.txt

Shared Repository Model - Example 2

feature6.txt

app.txt

feature6.txt

Fork and Pull Model

feature7.txt

app.txt

Issues

Fix the issue:

feature7.txt

Conclusion (Add a Release)