DevOps Bootcamp · Lesson

Forking Workflows on GitHub

Understand how to use the 'fork and pull request' model for contributing to projects where you don't have direct write access.

Forking Workflows on GitHub is a free DevOps Bootcamp lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the DevOps Bootcamp learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

What is a GitHub Fork?

Imagine you want to contribute to an open-source project, but you don't have permission to directly change its code. That's where forking comes in!

A fork is simply a personal copy of someone else's GitHub repository. It lives under your own GitHub account, giving you full control to experiment and make changes without affecting the original project.

Why We Use Forking

The main reason to fork a repository is to propose changes to a project when you don't have direct write access to its original codebase.

Safe Experimentation: Work on your copy without fear of breaking the original.
Contribution Path: It's the standard way to suggest features or fixes to public projects.
Personal Projects: Use a fork as a starting point for your own related project.

How to Fork on GitHub

Forking a repository on GitHub is very straightforward:

Navigate to the original repository you want to fork.
Look for the 'Fork' button, usually in the top-right corner.
Click the 'Fork' button. GitHub will then create a copy of that repository under your account.

You'll now have github.com/YOUR_USERNAME/ORIGINAL_REPO_NAME.

Clone Your Fork Locally

Once you've forked the repository on GitHub, you'll want to bring that copy down to your local machine to start working on it.

Use the git clone command, but make sure to clone your fork's URL, not the original repository's URL.

git clone https://github.com/YOUR_USERNAME/your-forked-repo.git

Make & Commit Changes

Now that you have your fork cloned locally, you can make changes just like any other Git project. It's a good practice to create a new branch for your feature or fix.

git checkout -b my-new-feature
# Edit files, add new code...
git add .
git commit -m "feat: added my new feature"

Push Changes to Your Fork

After committing your changes locally, you need to push them up to your remote fork on GitHub. This updates your personal copy of the repository.

The origin remote typically points to your fork.

git push origin my-new-feature

Sync Your Fork with Upstream

While you're working on your fork, the original repository (often called 'upstream') might receive new updates. To keep your fork current, you need to sync it.

First, add the original repo as a new remote named upstream. Then, fetch and merge its changes.

git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPO.git
git fetch upstream
git checkout main
git merge upstream/main

Create a Pull Request

Once your changes are complete and pushed to your fork, you're ready to propose them back to the original project. This is done via a Pull Request (PR).

On GitHub, navigate to your fork. You'll often see a banner suggesting you create a PR from your new branch. Follow the prompts to compare your branch with the original repository's main branch and submit your proposal.

The Forking Workflow Loop

To summarize the typical forking workflow:

Fork: Create your personal copy on GitHub.
Clone: Bring your fork to your local machine.
Develop: Make changes on a new branch.
Push: Send your changes to your remote fork.
Sync: Keep your fork updated with the original project.
Pull Request: Propose your changes to the original project.

Quick Check: Forking Reasons

Understanding why and how to use a forking workflow is essential for open-source collaboration.

Recap: Forking Power

In this lesson, you learned about the GitHub forking workflow. You now understand that forking creates a personal copy of a repository, allowing you to contribute to projects even without direct write access.

We covered how to fork, clone, make changes, push to your fork, sync with the upstream repository, and finally, how to create a Pull Request to propose your contributions. This workflow is a cornerstone of collaborative development on GitHub!

Frequently asked questions

Is the “Forking Workflows on GitHub” lesson free?

Yes — the full text of “Forking Workflows on GitHub” is free to read here on the web, and the DevOps Bootcamp course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the DevOps Bootcamp course, upgrade to CoddyKit PRO.

What will I learn in “Forking Workflows on GitHub”?

Understand how to use the 'fork and pull request' model for contributing to projects where you don't have direct write access. You practise DevOps Bootcamp with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start DevOps Bootcamp?

No prior experience is required. DevOps Bootcamp on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Forking Workflows on GitHub” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this DevOps Bootcamp lesson?

Yes. Every DevOps Bootcamp lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

← Back to DevOps Bootcamp