My Attempt At Demystifying Git

What in the Git are you talking about?

When I was first exposed to Git, everyone introduced it as the best thing to happen since sliced bread. And while I eventually figured out why over 80% of developers utilize Git daily, I have to admit it initially threw me for a loop. In theory, it sounded easy enough, but navigating the software can quickly get confusing. I had to backtrack, get my thoughts or ducks in a row🦆🦆🦆 and systematically break down each phase of the process. I aim to demystify Git using simple terms and an interactive demonstration. Strap in and prepare to arm ⚔️yourself with the knowledge needed to tackle this beast one step at a time.

Back Story

Development environments have evolved at an alarming rate over the years and teams today need tools that allow them to work faster and smarter to meet demands. Version control, also known as source control, manages modifications to the source code over time. Git is the most popular version control system out there, and it’s not just because it was written by the living legend Linus Torvald.

One of Git’s greatest strengths is its ability to record a project’s history chronologically. Version control software keeps track of every change to the source code. If a mistake is made, developers can turn back the clock and compare earlier versions of the code to help fix the error without affecting live projects or other team members working on the same project.

There’s Git & Then There GitHub: What the difference?

Think of Git as keeping a list of changes to files locally. You can use Git on its own, but that is not how it was meant to be utilized. GitHub is a hosting platform for Git repositories. GitHub allows you to share your code and collaborate with others on a global level. Git can record changes to a single or set of files via the command git commit. But before performing a commit, you must rungit add, which adds the files to a staging area. Git will only record the historical changes for files you decide to stage and commit locally. Once satisfied with your changes, you push them to GitHub, a cloud-based hosting service that enables you to manage multiple Git repositories. If you have open-source projects that use Git, then GitHub is designed to help you better manage them and the contributors you have working with you.

There are other cloud-based repositories like Bitbucket and GitLab, but GitHub is the world's largest host of source code. In this tutorial, we will be focusing on using Git with GitHub. Even though the names are similar, I hope my brief explanation clarifies the difference between the functions of Git and GitHub.

Prerequisites to following along:

• Create a free GitHub Account
  https://github.com/
• Ubuntu: System with root-level access

Git can be installed on Windows, Linux, or macOS I’m just using Linux

Getting Started

A high-level look at what we’re about to cover:

• Create GitHub.com Account Setup
• Local Git Installation & Initial Configuration
• Initializing a new Git repo
• Add, Stage, & Commit a modified version of a file to the repo
  - The most common Git version control commands
• Configuring GitHub and Git for remote collaboration
• Fork & Cloning an existing repo

1.1 GitHub Account

Let’s get started by navigating to GitHub.com to create a free account. The signup is straightforward name, email, and password. After you confirm everything and you’re all set up, we’ll move right into our shell to install and configure git.

1.2 Git Installation

Regardless of your operating system, go ahead and open your terminal. From your shell, install Git using apt-get. If you haven’t updated you’re system in a while, this step can take some time.

$ sudo apt-get update
$ sudo apt-get install git

You can verify that it was installed successfully by running the git — version.

$ git --version
git version 2.25.1

1.2a Configure Your Environment

One of the key features is looking up the name and email address of any person that executes a commit. For this to work, you must let Git know who you are by configuring your email and user name with the following commands.

$ git config --global user.name "John Doe" 
$ git config --global user.email "jdoe123@gmail.com"

Note: Use gloal to set the username and e-mail for every repository on your computer. If you only want to set that information on the current repo you can remove the global option.

You can verify the effects of this command by running git config --list

$ git config --list
user.name=John Doe
user.email=jdoe123@gmail.com

1.3 It’s time to Initiate Git!

By initiate, I mean initialize our local repo. To do this, we’ll need to navigate to the directory where our project is contained or create a new one. We’re going to create a new directory from scratch.

$ mkdir firstproj
$ cd firstproj
~/firstproject$ git init
Initialized empty Git repository in ~/jdoe123_user/firstproj/.git/

Running git init will create a new .git file in your current working directory. Essentially you’re letting Git know it needs to track the changes of files within this directory, aka project. Now that we’ve created our first repo, let’s add some files.

1.4 Add files

Fig.1

A few things are happening in Fig.1 for starters, I created a new file called helloworld.html. Immediately afterward, I ran git status. The output shows us that Git is aware of the existence of the helloworld.html file, but it is not being tracked for changes. Hence being in the untracked section. Any new file added to git is always in this state until git addis run.

Note: Tracked — files that Git knows about and are added to the repository
Untracked — files that are in your working directory but not added to the repository

1.4a Initial Commit on the Local Repository
While working on your project, you’ll eventually complete the change, hit a milestone, or come to a stopping point. You should add your modified files to the staging area when this happens. You do this by running the below command. You will not see the output after this but can confirm the change by running git status again. Git Status provides key information like which branch you’re on and the overall state of the working directory and staging area.

$ git add <your_file_name_here>
$ git status
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
         new file:   helloworld.html

Git add doesn’t affect the repository in any noteworthy way. The changes are not recorded until you run the following

$ git commit -m "My first commit for the hello-world oroject"

Fig.2

The -m option adds a message describing the change you made. When you commit, you should always include a message. The software will force you if you don't- try running it without it if you doubt me. Now Git will view your commit as a change point or “save point.” As mentioned, each commit is associated with the name and email address you set up with the git config global earlier. You can verify this by running git log(see below).

$ git log
commit be4cd56b661a56837328f3eb0f21425c37db97fb (HEAD -> master)
Author: Raymond Sylverne <raysylverne@gmail.com>
Date:   Sun Nov 6 00:38:02 2022 +0000
     
       My first commit for the hello-world oroject

1.5 Configuring GitHub & Git For Remote Collaboration

1.5a Creating a New GitHub Repository
Navigate back to GitHub.com/new. Fill out the relevant information on the web form. I will write a separate article going over the different options but for now, make sure to name your repo and choose Public. Choosing the public option does not mean anyone can collaborate it simply makes your repo visible. Once complete, select create repository option at the bottom of the page.

Fig.3

On the following page, you will be presented with the following options with instructions. Choose the one that best suits your scenario.

Fig.4

1.5b git remote add
Since we already created our local repo with the git init command, we’ll use the second option. The git remote add origin <URL/SSH> specifies that you are adding a remote repository with the specified, <SSH URL>, as an origin to your local Git repo.

After adding a remote, you’ll be able to use ＜name＞ as a convenient shortcut for ＜SSH URL＞ in subsequent Git commands.

The git push command will push our local Git repository code to the remote GitHub repository. When you run the git push command, you will be asked to enter your GitHub username and password to log in to your GitHub account from the terminal. Next, we will push our master branch to the origin URL and set it as the default remote branch.

Fig.5 git remote add origin | git config — list

What happening behind the scenes is your modifying the repos /.git/config file. We mentioned this earlier when we manually added our name and email. The result of the following commands can also be achieved by directly editing the ./.git/config file with a text editor.

1.5c Setup SSH Keys
Before we can run git push, we’ll need to generate a new SSH key and add it to the ssh-agent. For those on a ubuntu system, the following commands will yield the desired outcome.

If on a different OS, the documentation for how to perform this can be found at docs.github.com.

$ cd ~/.ssh
$ ssh-keygen -o -t rsa -C "your_GitHubemail.com"

Your output should resemble Fig.6.

Fig.6

Next, you’ll run $ cat id_rsa.pub you will want to copy the output of that file to your device's clipboard and navigate to github.com/settings/keys to associate your newly generated key with your account. Now you can run git push to publish and upload local changes to a central repository to share modifications with remote team members. When you run the git push command, you will be prompted to enter your GitHub username and password to log in to your GitHub account from the terminal.

$ git push -u origin master

The “-u” when entering the command “git push -u origin master” sets origin as the remote (upstream) target so any pushes after that can be called with “git push” instead of typing it all out.

After the repository is pushed, you can navigate to your GitHub account page or the repository link and refresh. You should now see the HTML file we created locally in the remote repo.

Fig.7

Any subsequent changes we make won’t automatically affect the remote GitHub repository until we repeat the cycle of add (staging), commit (saving), and push those changes again to update the remote repo.

1.6 Fork & Clone an Existing Repo
Conceptually you should fork before cloning, although that is not always the case. On the surface, these seem to have identical functions -make a copy of a repo- but there's is a specific use case for each. When you fork a repository, you create a copy of the original upstream repository, but the new repository remains on your GitHub account. When you clone a repository, the repository is copied (downloaded) onto your local machine with the help of Git. Forking is useful when you want to contribute to someone else’s project or start your own project based on theirs. A fork is not a command in Git, but something that GitHub offers. Forking was created since Git does not allow you to add code to someone else repo without access rights. However, that is where cloning comes in handy.

git clone is a Git command used to target an existing repository and create a clone or copy of the target repository? The workflow for git clone is usually a 3-step process :

1. You start by identifying and cloning the upstream repository on GitHub that you want to work on locally.
2. Now that you have an exact copy locally, you can begin to make your desired changes to the file. You can apply single or multiple commits to the repository in this step. But the bottom line is everything happens on your local system.
3. Once the changes are done, the modifications can be pushed to the upstream repository.

The workflow in Fig.8 below ⬇ does a great job of showcasing how forking and cloning overlap but are not one and the same.

Fig.8

1.6b Practical Application
There is a sample repository called Spoon-Knife hosted by GitHub, which they created for testing purposes: https://github.com/octocat/Spoon-Knife We will be using this repository to test the Fork feature of GitHub. Go to the repository page by following the link above and click the ‘Fork’ button, as shown in the screenshot below:

Fig.9

Fig.9_1

When the process is completed, you will be taken to your copy of the Spoon-Knife project repository. This forked repository will be tied to your GitHub account and won’t affect the original repository. To clone the forked repository, visit its page from your GitHub profile and select the green ‘Clone’ menu button, then click on the icon shown in the Fig.10 to copy the repository SSH that we will need for the next step.

Fig.10

After copying the SSH URL, head back to your terminal and input the following syntax

$ git clone https://github.com/<your-username>/Spoon-Knife.git

That will create a new Spoon-Knife folder and download all the project files and repository data. You can change directories (cd) into that folder and start working on the project. After making changes or implementing new things to the forked project, you can normally add and commit those changes as you would for any other repository. Also, you can push the changes that you made to the forked (remote) repository tied to your GitHub account.

The first time I ran git clone, I noticed this was a lot like git init in the sense that it creates a new local repo on your system. But in truth
git clone is a combination of a few different commands. Here’s what happens when you clone a repo.

1. git init (create the local repository)
2. git remote add (add the URL to that repository)
3. git fetch (fetch all branches from that URL to your local repository)
4. git checkout (create all the files of the main branch in your working tree)

After making a small change to the index.html file, I changed things up by running git status —-short giving the output in the short format. The “M” next to the index.html file represents a modified file. I also skipped the staging environment by providing the add and commit options on one line.
git commit -am

Go to GitHub, and observe our fork repository has a new commit ahead of the main.

If you select that hyperlink, you’ll be led to the new pull request page where you can add information about your changes.

It’s crucial to give a thorough account of everything you’ve done when trying to contribute to a developer’s third-party project whom you don’t know. The original project owner can choose whether to incorporate your changes into their project based on that and the code changes.

You can, at last, send the original project owner a fresh pull request after adding details about your improvements.

Wow! That was a lot to digest. Let's do a quick recap of what has been done.

• GitHub.com Account Setup
• Git Installation and initial Configuration
• Initializing a new Git repo
• Add, Stage, & Commit a modified version of a file to the repo
  - The most common Git version control commands
• Configuring GitHub and Git for remote collaboration
• Fork & Cloning an existing repo
• Create a Pull Request

We didn’t even get into git branches, git fetch, git pull, and many more. The goal was not to expose you to all things Git. I simply meant to arm you with the tools needed to get started. I will use Git and GitHub to document all my projects. Let's connect and collaborate the way Git was meant to be used.

Raymond Sylverne