Preface

GitHub is a platform used by developers to post, save and access different versions of source code folders (known as repositories) for collaborative projects. Git is the tool that communicates with GitHub on managing the different versions of the source codes for our projects, which is popularly used in the terminal.

Although some of the FAANG companies use their own in-house platforms for maintaining different versions of their source codes, many engineers and developers globally enjoy collaborating on projects that generate real-world value through GitHub (whether that's in, but not limited to, a corporate, social or personal capacity), and the popularity in the dev communities only appears to be growing with the platform attracting approximately 83 million users according to Wikipedia as of June 2022.

Key terms (TLDR)

• Git - an open-source tool used for pushing, pulling and tracking changes made to GitHub repositories.

• repository (repo) - a folder for storing source code and the history containing every change made to the source code

• local repository - the directory on a local machine that stores changes made to the project folder. This is located in the .git folder in the working directory's root folder, and only stores changes made to the working directory's files and the repo's commit history.

• remote repository - the directory on a remote server (i.e. GitHub) that stores changes made to the project folder.

• push request - posting the changes made on your local repository to your remote repository.

• pull request - a request to combine an existing branch with the branch that contains the proposed changes.

• commit - a log that registers every change applied to a repository at a specific period in time.

• branches - an independent version of the main repository.

• working directory/tree - the local copy created after a repository is cloned from a remote repository.

• staging area - a temporary location for file changes to land before commits occur.

• merge - the act of combining an existing branch with another branch that contains changes that are proposed by another developer. A merge can occur once a review of the codebase has been conducted and other collaborators are happy with the code proposal, otherwise more revision may be required before that state is reached.

• fork - creating a replica of a remote repository to your own account. This means the copy is yours because it now sits on your remote server (i.e. your GitHub account) which means any changes you make can be pushed to your fork.

• clone - downloading a replica of a remote repository to your local machine (i.e. creating a local copy). This doesn't imply you own the repository. You need permission to push changes applied to the clone into the remote repository (granted by the authorised owners of the remote repo) via a pull request.

Repositories

1. Local repositories

The local repository is the directory on a local machine that stores changes made to the project folder. This is located in the .git folder in the working directory's root folder, and only stores changes made to the working directory's files and the repo's commit history.

The working tree (or directory) is a copy of your project folder downloaded once a repository is cloned from a remote repo. You can specify any location on your machine for this copy to reside in.

To create a local repository via the terminal, use the following:

cd C://[working-directory-path]
git init

The first line directs your terminal session to the working tree of your choice.

The second line will create an empty local repository in the working directory ready to track and save changes made to the files in your project folder.

2. Remote repositories

This is simply the repository located on a remote server. In the context of Git this is usually a repository found in a GitHub account.

Staging Area

Think of the staging room as a waiting room for all file changes to enter before they are pushed to the appropriate remote repository via commits.

The staging area gives developers an opportunity to select and confirm which files are included in the next commit, leaving you with the option of only including relevant changes to the commit instead of all changes.

View changes in the local repository

To simply view the changes you've made in your local repository, use:

git status

This will show you your working directory's current state by listing out all the tracked files in your local repository that are modified, added, deleted as well as whether they are staged or not.

View variances between the staging area & last commit

To dig deeper by highlighting the main differences between the files in the staging area and the latest commit, you can use:

git diff --staged

Because this reports what makes the staging area different from the latest commit, this does not report the changes made to your files at a local repository level.

It's usually best to use " git diff --staged" after you've added a file to the staging area via "git add [file-name]"

Commits

A commit is a record that takes a snapshot of all changes made to the files of a local repository at a specific time.

By creating a commit, you store all changes uploaded to the staging area at that specific period. Note: These changes are only saved to your local repository UNTIL you explicitly make a push request to a remote repository.

Here is how you create a commit via the terminal:

git commit -m "add your description here"

Because each commit includes all the changes made up to a specific point in time, you can roll back and forth between different commits in a repository's history via the git log command (time travel), which will contain details around a git's hash, commit message, author, date and more.

You can also compare two different versions of the same repository by using the "git diff" command in the terminal. If you want to switch to a specific version of a repo, you can use the git checkout command and specify the branch name or commit hash like so:

git checkout [test-branch]

Push requests

A push request is a special request that directs the proposed changes made from the local repository to the remote repo.

Here is the command for making push requests:

git push origin [branch-name]

It's important to note that changes sent to the remote repository (via commits) are not merged with the main code base, they are simply added to the repo's history. So no merges occur at this level.

Pull requests

A pull request is another special request which is sent to the owners of a remote repository to merge an existing branch with the branch that contains the proposed changes sent from a commit.

This is an opportunity for other collaborators to perform code reviews and run discussions regarding your code to determine whether it is suitable for merging to the shared branch or whether further revisions on the proposed changes are required.

Branches

A branch is an isolated version of the main repository used for development and debugging purposes.

It's usually a good practice to create branches isolated from the main/production version so we can add, edit, test or remove features and changes without impacting the main branch. This is good because contributors can be confident that only stress-tested changes will be merged into the main branch, development can easily be monitored through separate branches based on the different responsibilities adopted by each team member and therefore good, quality code is shipped to the main branch in the process.

To create a new branch, you can use:

git checkout -b [branch-name]

Typical Workflow

Assuming you want to create a local repository after you've specified the desired directory for your working tree, you can apply the following steps:

• create and switch to a new branch separate from your main branch

git checkout -b [branch-name]

• create a new local repository

git init

• check the repo's current status

git status

• add the files you want to be included in the next commit to the staging area

git add [file-name]

• review changes to the repository before commit

git diff --staged

• commit changes to the local repository

git commit -m "add commit message here"

• connect the local repository to the remote repository

git remote add origin [remote-repo-url.git]

• push changes to the remote repository

git push origin [branch-name]

Once you follow these steps you can create a pull request via GitHub (select the branch to push to, add a summarised description of the changes you're proposing, including any ticket/reference number etc)

Other useful commands

• troubleshoot your push requests

git push --verbose

• remove a folder from the staging area - (particularly useful for dropping folders and files once changes are made after bumping into a push request error )

git rm -r --cached [folder-name]

• delete all commits that haven't been pushed into the remote repository

git reset --hard [commit-hash]

• list the commit history of the local repository

git log

• create a new branch separate from your main branch

git branch [branch-name]

• switch to the new branch created

git checkout [branch-name]

• set up an upstream branch

git push --set-upstream origin [branch-name]

• search for a commit that contains a word or phrase:

git log --grep "enter search term or phase here"

• clone a git branch

git clone -b [branch-name] [remote-repo-url]

• the easier way to "clone" a git branch than the above

git checkout -b [branch-name]

Summary

This isn't an in-depth article on Git but should contain the basics you need to get the most useful activities on GitHub via Git done.

I will set out time to go over some extensive depths where necessary when I get some downtime.

In the meantime don't hesitate to let me know if you need me to shed more light on any areas that may have been unclear to you and I'll be happy to respond to your requests.

Also, feel free to connect via my handles: LinkedIn| Email | Twitter