Sick Gaming
[Tut] GitHub Fork and Pull Workflow - Printable Version

+- Sick Gaming (https://sickgaming.net)
+-- Forum: Programming (https://sickgaming.net/forum-76.html)
+--- Forum: Python (https://sickgaming.net/forum-83.html)
+--- Thread: [Tut] GitHub Fork and Pull Workflow (/thread-100738.html)

[Tut] GitHub Fork and Pull Workflow - xSicKxBot - 02-12-2023

GitHub Fork and Pull Workflow

5/5 – (1 vote)

If you are unfamiliar with
Code:
git
and/or GitHub, it can be overwhelming navigating all the different workflow models you can use to add code to a repository. I know this feeling well, as it took me a while to get used to new workflows after being used to the classic SVN (years ago in University).

This post will focus on the common fork and pull workflow model that is used by many GitHub repositories. It will provide the necessary
Code:
git
commands and a short description for each step of the workflow, specifically for Git beginners who may be hesitant to contribute to GitHub.

[Image: 1f4a1.png] Definition: A repository is a central location that holds data. It’s mostly used to store and manage code, documents, images, videos, and other data types. Repositories can be either public or private and are often used by software developers to store and collaborate on projects.

Fork and Pull Workflow In a Nutshell

[Image: image-167-1024x309.png]

The “Fork & Pull” workflow is a way to contribute changes to an original repository using three easy steps:
  • Step 1: create a personal copy (fork) of the repository,

  • Step 2: edit the fork, and

  • Step 3: submit a request (pull request) to the owner of the original repository to merge your changes.

Step 1: Create a Fork

[Image: 1f4a1.png] Definition: A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project. Forks are commonly used to either propose changes to someone else’s project or to use someone else’s project as a starting point for your own idea.

Creating a fork on GitHub is easy – just click the “Fork” button on the repository page.

Here’s how forking the TensorFlow repository looks like — easy:

[Image: fork_repos.gif]
Step 2: Clone and Edit Fork

Once you have your fork, you can clone it to your local machine and edit it.

Here’s where you actually change or add code files, find and remove bugs, write comments for the code, or refactor everything.

[Image: 1f4a1.png] Definition: If you clone a Git repository, you essentially create an identical copy. You clone to work on your own local copy of the repository and sync changes back to the original repository. This is useful for keeping your local copy up to date with the latest changes and for contributing changes back to the original repository.

Step 3: Push Changes to Fork and Perform Pull Request

When you are done, you push your changes back to the fork on GitHub.

[Image: 1f4a1.png] Definition: A Git push operation is the process of sending changes from a local repository to a remote repository. The changes are applied to the remote repository. And your local repository is synchronized with the remote repository.

Lastly, you submit a pull request to the owner of the original repository.

[Image: image-168-1024x297.png]

[Image: 1f4a1.png] Definition: A pull request is a request to merge a branch into the main branch of a repository. It is used to propose changes and request feedback from other contributors, who can accept or reject the changes based on their review.

If there are no merge conflicts, the owner can simply click the “merge” button to accept your changes.

Six Steps to Pull Request

To create a pull request, you need to:

  1. Fork the repository on GitHub.

  2. Clone your fork to your workspace with the
    Code:
    git clone
    command.

  3. Modify the code and commit the changes to your local clone.

  4. Push your changes to your remote fork on GitHub.

  5. Create a pull request on GitHub and wait for the owner to merge or comment your changes.

  6. If the owner suggests changes, push them to your fork, and the pull request will be updated automatically.

What If Multiple Devs Work In Parallel?

If multiple developers work in parallel on the same repository, it may happen that they work on step 3 in parallel and try to push changes to the remote fork at the same time.

Here’s my drawing of this scenario. [Image: 1f606.png]

[Image: image-166.png]

Add the original repository as a remote repository called “upstream”:

Code:
git remote add upstream https://github.com/OWNER/REPOSITORY.git

Fetch all changes from the upstream repository:

Code:
git fetch upstream

Switch to the master branch of your fork:

Code:
git checkout master

Merge changes from the upstream repository into your fork:

Code:
git merge upstream/master

If you are working on multiple features, you should isolate them from each other. To do this, create a separate branch for each feature.
  • Use the command
    Code:
    git checkout -b BRANCHNAME
    to create and switch to a new branch.

  • Upload the branch to the remote fork with
    Code:
    git push --set-upstream origin BRANCHNAME
    .

  • To switch between branches, use
    Code:
    git checkout BRANCHNAME
    .

  • To create a pull request from a branch, go to the GitHub page of that branch and click the “pull request” button.

To update a feature branch:

  1. Switch to the feature branch:
    Code:
    git checkout my-feature-branch

  2. Commit all changes:
    Code:
    git commit -m MESSAGE

  3. Update the feature branch by rebasing it from the master branch:
    Code:
    git rebase master

Why I Wrote This

[Image: image-170.png]

I wrote this short tutorial to help contributors to our real-world practical project to build a P2P social network for information dissemination that is structured like a big brain. Users are neurons. Connections are synapses. Information Impulses spread through neurons “firing” and travel over synapses in a decentralized way:

[Image: 1f449.png] Recommended: Peer Brain – A Decentralized P2P Social Network App

If you like the tutorial and you want to contribute to this open-source social network app, feel free to try out this workflow yourself on this GitHub repository! [Image: 2934.png]

Summary

The Fork and Pull Workflow is a popular collaboration model used during software development.

In this workflow, a user forks a repository from an original (=upstream) repository, then develops and maintains a separate copy of the codebase on their own fork.

Users can then make changes to their own version of the repository, commit them, and push them up to their own fork. If the user wants to contribute their changes back to the upstream repository, they can then create a pull request. This allows the upstream maintainer to review the changes and determine if they should be merged into the main codebase.

The Fork and Pull Workflow is so popular for collaboration on a common code base because developers can work independently on the code and synchronize on the upstream repos in a well-structured and organized way.

This workflow also benefits upstream maintainers, as they don’t have to manage multiple contributions coming in from multiple sources.

[Image: 1f449.png] Recommended: Peer Brain – A Decentralized P2P Social Network App