Forking and Pushing Changes to a Remote Repository using Git and GitHub

First Things First: What is Git?

“Git” is a version control tool, to make a slightly less than one-to-one comparison, it’s like a Google Docs for code. It allows you to record the history of changes that have been made to a codebase, and tracks who made those changes as well as when. It makes it easy to revert back to a previously working state in case a change goes wrong and overall makes collaborating on code projects easier for everyone involved.

When using Git, the code you use is stored in what’s called a “Repository”. Repositories can either be stored remotely or locally, and the typical workflow when collaborating using Git consists of modifying code within your local repository and then “pushing” those changes to the remote repository where the most up-to-date code for the project will be stored. The benefits of using a remote repository are High Availability and the elimination of a Single Point of Failure. No single person holds the most up-to-date code, and the code can be accessed at anytime and anywhere.

Okay, so then what is GitHub?

You can think of GitHub as a GUI (Graphical User Interface) extension of Git, they are different things. You can use Git without ever using GitHub, but you can’t use GitHub without using Git. In addition to adding a GUI for Git, GitHub has integration with different DevOps tools, as well as other extensions to make collaborating on different projects easier. Overall, GitHub is a catalyst for open-source projects and social coding.

Now that you know a little about Git and GitHub, let's jump into Forking!

Scenario:

To set the scene for this specific practice scenario: You are working for a Tech Startup called “Level Up in Tech”, your team has tasked you with editing and changing code from your Level Up In Tech team repository. After making changes, the team would like to manually check the code before putting it into production.

Tasks (In order):

1: Fork the Level Up In Tech repo

2: Clone the forked repo to your local server environment

3: Using Vim, create a change in the file that is in the repo directory

4: Save the file and add to your local repo, then commit the file

5: Push the file back to your own GitHub repo

6: Send a pull request to merge with Level Up In Tech production repo

(In addition to these tasks they also sent you a “Good Luck!” message for positive reinforcement)

Prerequisites:

~A machine with Git installed
~Vim or an IDE
~A GitHub Account
~Beginner Understanding of Bash

Quick Aside- Branches and Forks:

If you’re at all familiar with Git, you will know that there are what’s called ‘branches’ and they are very similar to forks. Throughout the course of this exercise we will be creating both, so it’s probably best to explain them before creating them.

Branch: Within Git the “Master Branch” is reserved for code that is ready for production, it is free of bugs and clean, however, you can have more than one branch aside from the Master. You can create other Git Branches to essentially function as disposable test environments separate from the Master Branch. If you end up liking a feature made on a branch, it can be ‘merged’ into the main branch or discarded entirely. These other branches are where you would push untested features that are not yet cleared for production. Additionally, when you “push” the changes you made locally to the remote repository, it is best practice to push them to a branch and not the master.

Fork: A fork is different from a branch in that it is its own independent repository. It can become its own independent project separate from what it was forked from. People often create forks as a means to start an entirely new project using the original code as a starting point. Forking is also necessary for open-source development.

If you don’t own a project, or you aren’t made a contributor of a project by the owner, forking would be the only way to contribute to it. You would fork the project, make changes, and then create a pull request, essentially proposing the changes you’ve made to the project owner. If they like the changes you’ve made, they can ‘merge’ them into the main project.

Step 1: Fork the Level Up In Tech repo

Navigate to the repository that you would like to fork on GitHub. The name of the repository owner should be on the left, and that should be followed by the repository name, the format should be [Repo Owner / Repo Name]. In the top right should be the ‘Fork’ button, simply press that button and you’re all forked and ready to go.

Step 2: Clone the forked repo to your local server environment

For this step, you will want to stay on the page with the forked repository you’ve just created, go to the green “code” drop down, and find the SSH url.

Then make a directory for the cloned repository to live, move into that directory, then use the “git clone” command on your local device using that url:

The syntax for the url will generally be [git@github:RepoOwnerUsername/FilePath], and according to the GitHub Knowledge Base, you will always be using the “git” username for the SSH access.

Step 3 and Step 4: Using Vim, create a change in the file that is in the repo directory, save the changes, then commit the file

When within the terminal, there are multiple ways to edit a file, in this instance we will be using ‘vim filename.sh’ but you can also use ‘code filename.txt’.

The ‘code’ command will automatically open the specified file within your default code editor environment, VSCode, Atom, Sublime, etc. Conversely, by specifying ‘vim’, it opens the file within Vim.

Within the above image:

1. I created a new branch to do the edits on, which gives me the option to merge them later using “git merge”. You can also create a branch using “git branch”, but by using “git checkout” with the “-b” option I was able to create the branch and switch to it at same time.
2. I modified the file in Vim, and then added it to the “Staging Area” using “git add”. The Staging Area exists as a way for you to evaluate a file (or multiple files) that you plan on pushing before doing so.
3. I checked which files were being added to the staging area using “git status”. (if you wanted you could see the exact changes made to the file using the “git diff” command)
4. Lastly, I committed the file with the “-m” option. It is best practice to use the “-m” option and add a comment explaining what was changed within the commit for proper documentation of the project’s history. It’s a way of communicating what changes you’ve made to all of your collaborators. You can think of the commit as the final landing before the “git push”.

Step 5: Push the file back to your own GitHub repo

Finally we are pushing the file to the remote repository. When you’re working with Git you may actually have many remote repositories, so in order to confirm which upstream remote repository your local repository is pointing to, use the “git remote” command (the “-v” is just the “verbose” option):

As you can see my local repository and branch are pointing to the remote forked repository I created earlier, so that is where the changes I’ve made locally will go once I push them:

The usual syntax for this would be [git push -u origin <LocalBranchName>], but since the branch I created locally does not yet exist remotely, the [ — set-upstream] prefix creates the remote branch and pushes my changes to that branch at the same time.

Step 6: Send a pull request to merge with Level Up In Tech production repo

Finally, you’ve done the work, accepted the luck, and forked with the best of them, time to send a “pull request” to the main production repository. Just like it sounds, this is a request to “pull” the changes you have “pushed” into the main repository, and this will be done on GitHub itself.

Just click the green “new pull request” button:

If you have successfully pushed your code, you should see a notification that looks like this on your forked repo.

Then click the “View Pull Request” button and you will get this:

This is how you can then view the changes that you made along with the commit messages you have added to those changes. It’s ultimately up to the administrator of the project to decide whether or not your changes are accepted, but you have now successfully pushed changes to a remote repository!