GitHub Foundations Course Outline

Lab 1: Introduction to Git and GitHub

Lab 2: Remote Repositories

Lab 3: Branching and GitHub Flow

Lab 4: Git vs. GitHub and Advanced Concepts

Lab 5: README and Markdown Formatting

Lab 6: GitHub Desktop and Collaboration

Lab 7: Repository Settings and Branch Protections

Lab 8: Issues and Discussions

Lab 9: Pull Requests and Code Review

Lab 10: Code Review and Feedback

Lab 11: Repository Templates and Forking

Lab 12: Branch Management

Lab 13: CODEOWNERS and Reviews

Lab 14: Advanced GitHub Features

Lab 15: Using Draft Pull Requests, Gists and Commenting

Lab 1 – Introduction to Git and GitHub
Lab Objective:
Learn the fundamentals of Git and GitHub, including how to initialize a repository, stage
changes, commit files, and understand version control basics.

Lab Purpose:
In this lab, you will create a local Git repository, add files to it, make commits, and explore the
basic workflow of version control using Git. This foundational knowledge is essential for
collaborative development and code management.

Lab Tool:
Git (latest stable version), GitHub account, and a terminal or command-line interface.

Lab Topology:
A local machine with Git installed. Optionally, access to GitHub via a web browser or GitHub
Desktop.

Lab Walkthrough:

Task 1:
Initialize a local Git repository in a new directory. Use the following commands:
mkdir my-first-repo
cd my-first-repo
git init

Question: What does the `git init` command do? What changes occur in your directory after
running it?

Task 2:
Create a new file in your repository and add some content to it. For example:
echo "Hello Git!" > hello.txt

Then, use the following commands to add and commit the file:
git add hello.txt
git commit -m "Initial commit with hello.txt"

Question: What is the difference between `git add` and `git commit`? Why is it important to
stage files before committing?

Notes:
- Initializing a repository with `git init` allows you to begin versioning files locally.
- Commits record snapshots of your file changes and are used for tracking project history.
Lab 2 – Remote Repositories
Lab Objective:
Understand how to connect a local repository to GitHub and explore the GitHub user interface
to navigate repositories, branches, and commits.

Lab Purpose:
In this lab, you will learn how to push a local Git repository to GitHub, create and link a remote,
and use the GitHub UI to view project data such as branches and commit history.

Lab Tool:
Git (CLI), GitHub.com (web interface).

Lab Topology:
A local Git repository and a GitHub account with a new or existing repository.

Lab Walkthrough:

Task 1:
Initialize a local Git repository and push it to GitHub.

Steps:
1. Create a directory and initialize Git:
mkdir my-project && cd my-project
git init
2. Create a file, add and commit:
echo "# My Project" > README.md
git add .
git commit -m "Initial commit"
3. Create a repository on GitHub.
4. Add the remote and push:
git remote add origin https://github.com/your-username/my-project.git
git push -u origin main

Question: What command links your local repository to a GitHub remote? What does the `-u`
option do in `git push`?

Task 2:
Explore the GitHub UI.
Go to your GitHub repository in a browser and explore the following:
- Repository overview (files and README)
- Branch dropdown to view and switch between branches
- Commit history under the "Commits" tab or "Insights" → "Network"

Question: What information can you view about each commit? How does the GitHub UI help
you track branch activity and changes over time?

Notes:
Connecting a local Git repository to a remote GitHub repository enables online collaboration and
version tracking. The GitHub UI is a powerful tool to visualize and manage repositories,
branches, and development progress.

Task 3:
Check the status and log of your repository to view tracked changes and commit history:
git status
git log

Question: What information does `git status` provide? What details can you observe in the `git
log` output?

Task 4:
Create a second file and repeat the process of adding and committing. Then, make a change to
the first file and commit again.
echo "Another file" > second.txt
git add second.txt
git commit -m "Add second file"
echo "Update to hello.txt" >> hello.txt
git add hello.txt
git commit -m "Update hello.txt with more text"

Question: How does Git track changes between commits? How can you view what was changed
using Git?

Task 5:
Explore the .git directory and discuss its contents. Use:
ls -a
cd .git
ls

Question: What kind of data is stored in the `.git` folder? Why should this folder not be modified
manually?
Notes:
Git is a powerful version control system that enables efficient collaboration and code tracking.
Understanding the basic Git workflow—including initializing repositories, committing changes,
and viewing history—is essential for any developer or IT professional. This lab provides hands-on
experience with core Git commands to build a solid foundation for more advanced version
control techniques.

Lab 3 – Branching and GitHub Flow

Lab Objective:
Learn how to create and switch branches using Git CLI and demonstrate the GitHub Flow model
including branching, pull requests (PR), and merging.

Lab Purpose:
In this lab, you will use Git on the command line to create and manage branches, simulate
collaborative development using GitHub Flow, and understand how pull requests facilitate code
review and merging in a team environment.

Lab Tool:
Git (latest stable version), GitHub account, web browser, and a terminal or command-line
interface.

Lab Topology:
A local Git repository linked to a remote GitHub repository.

Lab Walkthrough:

Task 1:
Ensure your local repository is connected to GitHub. Check the current branch:

git branch
Question: What is your current branch? What does the asterisk (*) indicate?

Task 2:
Create and switch to a new branch for a feature:

git checkout -b feature-xyz

Make changes and commit:

echo "New feature line" > feature.txt

git add feature.txt
git commit -m "Add new feature line"
Question: Why do we use a separate branch for new features or bug fixes?

Task 3:
Push your branch to GitHub:

git push -u origin feature-xyz

Navigate to GitHub and open a Pull Request (PR) for your `feature-xyz` branch.

Question: What is a Pull Request? How does it help in team collaboration?

Task 4:
Review and merge the PR on GitHub. Once merged, pull the updated main branch:

git checkout main

git pull origin main
Question: What happens when you merge a PR on GitHub? How does your local repository get
updated with the merge?

Task 5:
Clean up the feature branch locally and remotely:

git branch -d feature-xyz

git push origin --delete feature-xyz
Question: Why is it important to delete old branches after merging?

Notes:
The GitHub Flow is a lightweight, branch-based workflow that supports collaboration and code
review. It encourages the use of short-lived branches and pull requests for structured
development. Mastering this flow is essential for modern software teams and continuous
integration practices.

Lab 4 – Git vs. GitHub and Advanced Concepts

Lab Objective:
Understand the difference between Git and GitHub, and explore advanced Git concepts such as
stashing, rebasing, tagging, and gitignore.

Lab Purpose:
This lab will help you distinguish between Git as a local version control system and GitHub as a
remote repository hosting platform. You will also explore several advanced Git features that
improve your workflow and project management.
Lab Tool:
Git (latest stable version), GitHub account, and a terminal or command-line interface.

Lab Topology:
A local Git repository connected to a GitHub remote repository.

Lab Walkthrough:

Task 1:
Compare Git and GitHub. Research and write down the differences between the two.

Question: How does Git manage your code locally? What does GitHub add to the development
process that Git alone cannot provide?

Task 2:
Use git stash to temporarily save changes:
echo "Temporary change" >> temp.txt
git add temp.txt
git stash

List and apply your stashed changes:

git stash list
git stash apply

Question: When would using `git stash` be helpful in your workflow?

Task 3:
Rebase your feature branch onto the main branch:
git checkout feature-branch
git rebase main

Question: How does rebasing differ from merging? What are the benefits and risks of using
rebase?

Task 4:
Create a tag for a release version:
git tag -a v1.0 -m "Release version 1.0"
git push origin v1.0

Question: What is the purpose of tagging in Git? How can it be useful in software versioning?

Task 5:
Create and use a .gitignore file to exclude specific files or directories:
echo "*.log" > .gitignore
echo "node_modules/" >> .gitignore
git add .gitignore
git commit -m "Add .gitignore file"

Question: Why is it important to use a .gitignore file in your projects?

Notes:
Git is a powerful local version control tool, while GitHub offers remote repository management
and collaboration features. Understanding the distinction and mastering advanced Git
functionalities will significantly improve your productivity and code management. These skills
are essential for real-world software development workflows.

Lab 5 – README and Markdown Formatting

Lab Objective:
Learn how to create and format a README file using Markdown to effectively document your
GitHub repository.

Lab Purpose:
In this lab, you will add a README file to your repository and use Markdown syntax to format
text, insert links, create lists, and embed images. This helps communicate your project purpose,
usage, and setup instructions clearly to others.

Lab Tool:
Text editor (VS Code, nano, or any Markdown editor), Git, GitHub.

Lab Topology:
A local Git repository with a GitHub remote.

Lab Walkthrough:

Task 1:
Create a new file called README.md in your repository root:
touch README.md

Question: What is the purpose of a README file in a GitHub repository?

Task 2:
Add a project title and description using Markdown headers and text formatting. Example
content:
# Project Title
This is a sample project to demonstrate how to use Markdown in a README file.
Question: How do Markdown headers work (e.g., #, ##, ###)? What are the differences in size
and hierarchy?

Task 3:
Create a usage section with bullet points and code blocks. Example:

# Usage
- Clone the repository
- Navigate to the directory
- Run the application

```
git clone https://github.com/your-username/your-repo.git
cd your-repo
npm start
```

Question: Why are code blocks useful in a README?

Task 4:
Add links and images using Markdown. Example:
# Resources
[GitHub Docs](https://docs.github.com)

Question: How do you format a link vs. an image in Markdown?

Task 5:
Commit and push your README.md file:
git add README.md
git commit -m "Add README with Markdown formatting"
git push origin main

Question: How does having a well-structured README improve collaboration and project
adoption?

Notes:
README files are often the first thing users see when they visit your repository. Markdown
makes it easy to structure content, add visuals, and improve readability. A professional README
reflects the quality and usability of your project.
Lab 6 – GitHub Desktop and Collaboration
Lab Objective:
Learn how to use GitHub Desktop to clone repositories, commit changes, push updates, and
manage collaborators with appropriate permissions.

Lab Purpose:
This lab introduces GitHub Desktop as a visual tool for working with GitHub repositories. You will
learn how to perform essential Git operations and manage collaborators on a GitHub repository
to facilitate teamwork and secure project access.

Lab Tool:
GitHub Desktop, GitHub account, web browser.

Lab Topology:
A remote GitHub repository cloned, edited, and managed using GitHub Desktop.

Lab Walkthrough:

Task 1:
Install GitHub Desktop from https://desktop.github.com and log in using your GitHub
credentials.

Question: What are the benefits of using GitHub Desktop over the Git command line for
beginners?

Task 2:
Clone an existing GitHub repository using GitHub Desktop:

- Open GitHub Desktop

- Go to File > Clone repository
- Select the desired repository and location
- Click "Clone"

Question: Where is the local copy stored, and how can you confirm it’s cloned correctly?

Task 3:
Make a small change in the local repo (e.g., add text to a README file). Save the file and commit
the changes using GitHub Desktop.
- View the file change in GitHub Desktop
- Enter a commit message
- Click "Commit to main"
- Click "Push origin" to upload changes

Question: What does committing and pushing achieve? Where can the changes be seen online?

Task 4:
Add a collaborator to your repository:

- Visit your repository on GitHub

- Go to Settings > Collaborators
- Add a GitHub username
- Assign the appropriate permissions (Read, Write, Admin)

Question: Why is it important to manage collaborator permissions correctly? What are the risks
of giving admin access unnecessarily?

Task 5:
Have your collaborator clone the repo via GitHub Desktop, make a change, and push it. Observe
the collaboration process.

Question: What challenges might arise in collaboration, and how does GitHub help resolve them
(e.g., file history, PRs, merge conflict resolution)?

Notes:
GitHub Desktop is a beginner-friendly tool for managing Git repositories. It simplifies the process
of cloning, committing, and pushing code. Adding collaborators and controlling permissions is
essential for teamwork, ensuring security and effective collaboration.

Lab 7 – Repository Settings and Branch Protections

Lab Objective:
Learn how to customize GitHub repository settings and apply basic branch protection rules to
improve project organization and maintain code quality.

Lab Purpose:
This lab guides you through updating repository metadata (like description and topics) and
configuring basic branch protection rules such as requiring pull request reviews. These practices
help teams collaborate more effectively and protect critical branches from unintended changes.
Lab Tool:
Web browser, GitHub account.

Lab Topology:
A GitHub-hosted repository with branch protection settings enabled via the web interface.

Lab Walkthrough:

Task 1:
Navigate to your repository on GitHub. In the top section of your repo page, click the "Settings"
tab.

Update the following metadata:

- Description (e.g., "This project demonstrates basic GitHub configuration")

- Topics (e.g., "git", "github", "collaboration")

Question: How do topics help with repository discoverability? What kind of description is most
useful for potential contributors?

Task 2:
Scroll down in Settings to "Features" and ensure features like Issues, Discussions, and Wiki are
enabled or disabled according to your team’s needs.

Question: Why might you disable certain features like the Wiki or Discussions?

Task 3:
Click on "Branches" in the left sidebar. Under "Branch protection rules", click "Add rule".
Configure the following:

- Branch name pattern: `main`

- Require a pull request before merging
- Require approvals (at least 1 reviewer)
- Require status checks to pass before merging (if CI is set up)
- Optional: Restrict who can push to matching branches

Question: How does enabling branch protection help maintain code quality? What are the
trade-offs of making rules too strict?

Task 4:
Create a test branch and attempt to push changes directly to `main`. Observe what happens if
branch protections are enabled.

Question: What message or restriction do you encounter? How does this reinforce collaborative
workflows like pull requests?
Notes:
Repository settings are crucial for discoverability, security, and team workflows. Branch
protections reduce errors and enforce quality standards by ensuring changes go through peer
review or testing. These features promote consistency and collaboration across teams.

Lab 8 – Issues and Discussions

Lab Objective:
Learn how to create, manage, and convert GitHub issues and discussions to facilitate
communication, task tracking, and team collaboration.

Lab Purpose:
This lab introduces GitHub Issues and Discussions as tools for project planning and community
engagement. You will learn how to use labels, assignees, and pinning to organize issues, and
how to convert between issues and discussions to support different types of collaboration.

Lab Tool:
Web browser, GitHub account.

Lab Topology:
A GitHub-hosted repository with Issues and Discussions features enabled.

Lab Walkthrough:

Task 1:
Navigate to your GitHub repository and go to the "Issues" tab.

Click "New Issue" and create an issue with a meaningful title and description. Assign the issue to
yourself and apply relevant labels (e.g., bug, enhancement, question).

Question: How do labels help organize issues in a busy repository? What types of issues are best
suited for label use?

Task 2:
After creating your issue, click the three dots (•••) at the top-right and select "Pin issue".

Question: When might you want to pin an issue? How does pinning impact visibility for team
members or contributors?
Task 3:
Click the "Convert to Discussion" option on your issue. Choose the appropriate category (e.g.,
Q&A, ideas).

Question: What is the main difference between an issue and a discussion? Why might you prefer
one over the other?

Task 4:
Go to the Discussions tab, find your newly converted discussion, and interact with it (e.g., reply,
react, or close it). Then click "Convert back to Issue".

Question: What happens to the content and structure when converting back to an issue? Are
any changes lost or preserved?

Notes:
Issues and Discussions support collaborative project management in different ways. Issues are
best for task tracking and bugs, while Discussions are better for brainstorming and community
input. GitHub’s conversion features let you switch formats as needs evolve.

Lab 9 – Pull Requests and Code Review

Lab Objective:
Learn how to link pull requests to issues, conduct code reviews, and understand draft pull
requests and pull request statuses.

Lab Purpose:
This lab guides you through the GitHub workflow of creating a pull request (PR) linked to an
issue, requesting a review, and navigating draft PRs and status indicators. This process is
essential for collaborative development and ensuring code quality.

Lab Tool:
Web browser, GitHub account.

Lab Topology:
A GitHub-hosted repository with at least one open issue and a newly created branch to submit
pull requests from.
Lab Walkthrough:

Task 1:
Ensure there is an open issue in your repository. Create a new branch locally or on GitHub, make
a small change (e.g., update a file), and push the branch.

Open a pull request and link it to the issue by including "Closes #<issue-number>" in the
description.

Question: What happens to the issue when the PR is merged? Why is it useful to link PRs to
issues?

Task 2:
Request a review from a collaborator. The reviewer should leave comments, approve the PR, or
request changes.

Respond to the comments and, if necessary, make further commits to the branch.

Question: How does the code review process contribute to code quality and team learning?

Task 3:
Create a new pull request but select "Create draft pull request".

Observe the "Draft" label and how it limits merging until marked as "Ready for review".

Question: When is it appropriate to use a draft PR? What are the benefits of starting with a draft
rather than a regular PR?

Task 4:
Explore PR status checks (e.g., "All checks have passed", "Waiting for review"). Enable or
simulate a CI check if applicable.

Question: How do status checks affect the ability to merge a PR? Why are automated checks
important in collaborative projects?

Notes:
Pull requests are central to GitHub collaboration, allowing developers to propose changes,
request feedback, and merge contributions safely. Linking PRs to issues ensures traceability, and
using draft PRs and review workflows maintains quality across teams.
Lab 10 – Code Review and Feedback
Lab Objective:
Learn how to conduct detailed code reviews by commenting on specific lines of code within a
pull request on GitHub.

Lab Purpose:
This lab teaches how to provide constructive feedback by reviewing individual lines of code in a
pull request. Reviewing code at this granular level improves quality and facilitates team
communication during development.

Lab Tool:
Web browser, GitHub account.

Lab Topology:
A GitHub-hosted repository with an open pull request containing code changes to review.

Lab Walkthrough:

Task 1:
Open an existing pull request in your repository. Navigate to the "Files changed" tab to view the
modified files.

Click the "+" icon next to a line of code to add an in-line comment. Provide feedback or ask a
question.

Question: How does commenting on specific lines differ from general PR comments? Why might
this be more helpful to developers?

Task 2:
Add multiple comments across different lines in the pull request, then click "Submit review" and
select either "Comment", "Approve", or "Request changes".

Question: When would you choose each review option? How does each one affect the PR and
the contributor?

Task 3:
Respond to a review comment from another collaborator. Discuss how this feedback cycle leads
to better code and understanding.
Question: How should developers handle feedback they disagree with? What’s the best
approach to maintaining positive team communication during reviews?

Notes:
In-line code comments provide targeted feedback that helps developers understand exactly
what needs improvement. GitHub’s code review tools support professional collaboration,
encourage discussion, and ensure higher code quality through collective input.

Lab 11 – Repository Templates and Forking

Lab Objective:
Learn how to use repository templates to start new projects and explore GitHub Gist and forking
for sharing and reusing code.

Lab Purpose:
This lab introduces repository templates and gist as tools to promote re-usability and quick
project setup. You’ll create a new project from a template and explore how forking gist enables
collaboration and modification of shared code snippets.

Lab Tool:
Web browser, GitHub account.

Lab Topology:
A GitHub-hosted repository marked as a template, and the GitHub Gist platform.

Lab Walkthrough:

Task 1:
Navigate to a repository marked as a template on GitHub (or mark one of your own repos as a
template).

Click the "Use this template" button to create a new repository based on it. Customize the repo
name and settings during creation.

Question: What are the benefits of using a repository template over starting from scratch? How
might this be useful for on-boarding team members?

Task 2:
Visit https://gist.github.com/ and create a new public or secret gist with at least one file. Add a
brief description and meaningful content.
Question: What types of code or content are best suited for gist versus full repositories?

Task 3:
Search for another user’s public gist and click "Fork" to create your own copy. Modify the
content in your forked version and save it.

Question: How does forking a gist support collaboration or experimentation? How is it different
from forking a full repository?

Notes:
Repository templates provide consistent project structures and are ideal for reusable codebases
or starter kits. Gist offer lightweight sharing for code snippets or single files, with forking
enabling easy modification. Both tools enhance development efficiency and sharing.

Lab 12 – Branch Management

Lab Objective:
Learn how to manage branches by creating a new branch, switching contexts, and adding files in
GitHub or via the Git CLI.

Lab Purpose:
This lab focuses on branch management as a key part of working with Git. By creating a new
branch and adding files to it, developers can safely test and build features in isolation from the
main code-base.

Lab Tool:
GitHub.com, GitHub Desktop, or Git CLI.

Lab Topology:
A GitHub repository with write access for performing branch operations.

Lab Walkthrough:

Task 1:
Navigate to your GitHub repository or open it in GitHub Desktop/CLI. Create a new branch called
"feature/new-content".

Using the CLI:

git checkout -b feature/new-content

Using GitHub.com: Navigate to the branch dropdown and type a new branch name.
Question: Why is it important to use branches for new features or updates instead of working
directly on the main branch?

Task 2:
Add a new file (e.g., README-update.md or test.txt) to the new branch. Commit and push the
changes to GitHub.

Using the CLI:

echo "Test content" > test.txt
git add test.txt
git commit -m "Added test file to new branch"
git push origin feature/new-content

Question: How does Git track changes per branch, and what happens when you switch between
branches with different files?

Notes:
Branching allows multiple streams of development to occur without interfering with each other.
This enables safer experimentation and easier code reviews before merging into production
branches.

Lab 13 – CODEOWNERS and Reviews

Lab Objective:
Understand how to enforce code reviews by configuring a CODEOWNERS file in a GitHub
repository.

Lab Purpose:
This lab introduces the CODEOWNERS file, which designates users or teams responsible for
reviewing code in specific parts of a repository. It automates review requests and enforces
collaborative workflows.

Lab Tool:
GitHub.com or GitHub CLI, text editor.

Lab Topology:
A GitHub repository with at least two collaborators or teams, and branch protection rules
enabled.
Lab Walkthrough:

Task 1:
Create a `.github` directory in the root of your repository if it doesn’t exist already.

Inside this directory, create a file named `CODEOWNERS`.

Add the following content as an example:

# This assigns ownership of all files to the user or team

* @your-username
# Specific directory or file owners
/docs/ @docs-team
*.js @frontend-team
Commit and push the file to the default branch.

Question: How does GitHub use the CODEOWNERS file to automatically request reviews? What
happens if a PR modifies files owned by different users or teams?

Task 2:
Enable branch protection on the default branch and require code reviews.

Go to Settings → Branches → Add/Edit a branch protection rule.

Check "Require pull request reviews before merging" and optionally enable "Require review
from Code Owners".

Question: How does requiring CODEOWNERS reviews enforce quality control and prevent
unauthorized changes?

Notes:
The CODEOWNERS file is a powerful GitHub feature for automating reviews and managing
contributions across large or multi-team projects. When paired with branch protection rules, it
ensures accountability and helps maintain high-quality code standards.

Lab 14 – Advanced GitHub Features

Lab Objective:
Explore advanced GitHub features that help manage and track project progress effectively.
Lab Purpose:
This lab focuses on using GitHub’s advanced project management tools such as Projects,
Milestones, Labels, and Insights to plan, track, and measure development progress.

Lab Tool:
GitHub.com (web interface).

Lab Topology:
An active GitHub repository with Issues and Pull Requests.

Lab Walkthrough:

Task 1:
Create a new GitHub Project board.

Navigate to the "Projects" tab in your repository and click "New Project". Choose either a
Kanban or Table layout.

Add at least three columns (e.g., To Do, In Progress, Done) and move existing issues or PRs to
appropriate columns.

Question: How does organizing work in a project board help improve development visibility and
team collaboration?

Task 2:
Create a Milestone and assign it to issues or pull requests.

Navigate to the "Milestones" section under "Issues", create a new milestone, and add a due
date and description.

Assign the milestone to existing issues or PRs.

Question: How do milestones help in tracking progress toward specific project goals or release
versions?

Task 3:
Use Labels to categorize issues and pull requests.

Apply built-in labels (e.g., bug, enhancement) or create custom labels.

Filter issues/PRs using labels to understand the nature and status of your project’s tasks.

Question: How can label systems be customized to suit different teams and workflows?

Task 4:
Explore GitHub Insights.
Go to the "Insights" tab and review metrics such as contributors, commit history, code
frequency, and issue tracking.

Question: What insights were most helpful in understanding project activity and team
contributions?

Notes:
Advanced GitHub features support agile planning, progress tracking, and productivity
measurement. Teams that use Projects, Milestones, and Insights efficiently can coordinate
development better and meet project deadlines more reliably.

Lab 15 – Using Draft Pull Requests, Gists, and

Commenting
Lab Objective:
Understand the use of draft pull requests and their statuses, create and fork gists, and provide
code-specific comments during code reviews.

Lab Purpose:
This lab combines key GitHub collaboration tools to enhance the development workflow. You’ll
learn how to initiate work with draft pull requests, share and collaborate using gists, and
conduct detailed code reviews by commenting on specific lines.

Lab Tool:
GitHub.com (web interface), GitHub CLI (optional).

Lab Topology:
An active GitHub repository and access to GitHub Gists.

Lab Walkthrough:

Task 1:
Create a draft pull request.

On GitHub, go to your repository, push a new branch, and click "Compare & pull request". Select
"Create draft pull request".

Review the pull request page to observe the "Draft" label and limited merge actions.

Question: What is the benefit of using a draft PR instead of a regular one at the start of
development?
Task 2:
Understand and track pull request statuses.

Observe the change from "Draft" to "Ready for review" when you mark a draft PR as ready.

Note CI checks, review statuses, and merge conflicts under the PR status box.

Question: How do pull request statuses improve visibility and communication in a development
team?

Task 3:
Create and fork a gist.

Visit https://gist.github.com/ and create a new gist with some code content.

Find another user’s gist and click "Fork" to create your copy.

Question: In what scenarios would gists be preferred over full repositories?

Task 4:
Comment on specific lines of code in a pull request.

Open an active pull request and click on the "Files changed" tab. Hover over a line and click the
blue "+" icon to comment.

Leave one or more comments with constructive feedback.

Question: How do inline comments in PRs improve the code review process compared to
general comments?

Notes:
Using draft PRs allows early collaboration while clearly indicating incomplete work. Gists simplify
sharing small code snippets, and inline PR comments make code reviews precise and actionable,
fostering better communication and code quality.