No Git, No Problem: The Absolute Beginner’s Guide to GitHub

Writing code on your own is a good start, but if you want to take your coding skills to a professional level, collaboration is the key. While collaboration and internal teamwork are essential, being able to write software with other developers is the core of success. For this reason, platforms like GitHub exist.

In this article, I will discuss GitHub and repositories, and how to work with them and secure them.

What is GitHub?

GitHub is a cloud-based hosting service for users to upload and track their work. This work is usually code-based, and the tracking is referred to as version control. Cloud-based means that GitHub provides on-demand resources to its users over the internet or the cloud.

For example, it offers storage space so we don’t have to keep large files on our computers. Many platforms offer a similar service, such as GitLab and BitBucket, but GitHub is the most popular.

The primary uses for GitHub are storing and keeping track of projects and files, and collaborating with others. It also acts like a social network, allowing us to connect with other users. There are also several open-source projects that anyone can learn from, practice with, or edit.

Before we go any further, let’s distinguish how GitHub differs from Git. Git is a version control software and can be used independently from GitHub or another hosting platform. GitHub is a platform that enhances Git to make it easier to manage projects and collaborate. It is entirely dependent on Git. We cannot use GitHub without Git!

Now, we’ll dig into how it can make collaboration easier using “version control”. Version control is the concept of tracking a file through its different states and allowing several people to work on the same file.

This workflow can all happen on GitHub rather than using Git on a Command Line Interface. Since GitHub stores a project in the cloud, anyone can access it, making collaboration super easy. GitHub also benefits solo projects or projects we do independently without collaborating with others, as it provides a complete history of every project stage.

A project usually has many files, and when working with Git, there is a .git folder that stores the history the project. Together, these create a repository or repo.

GitHub is built on top of Git, hence the name. The GitHub repo will contain all the files related to a particular project and a record of past versions of the files. Since this GitHub repo is stored on the internet, it is also known as a remote repo. This is because Git defines a local repo as saved on our local computer and a remote repo as saved on the internet, or cloud.

We’ve spoken a lot about Github; let’s now see what it looks like. Here is an example of a profile overview. We can navigate to our Repositories by clicking on the repositories tab.

What are Repositories?

Creating a repo is a straightforward process by simply clicking on “create new” in the top right corner of the repositories page.
Let’s examine some of the parts that exist in each repository:

1. Code: here you can see all the files and the folders that your project has, edit them and fill in the “about” section to tell other engineers about your project.
2. Issues: this section is to track any todos, report bugs and request features from the engineering team.
3. Pull Requests (PRs): they are code suggestions and opening a PR is the way to collaborate with other engineers on a shared repository.
4. GitHub Actions (Actions): it is a workflow automation platform that lives with the same repo and its job is to automate tasks and it is used in CI/CD workflows. For example, you can automate running unit tests whenever someone pushes to the repository. You can automate deployment to AWS Elastic Beanstalk. It is a very flexible automation tool.
5. Wiki: this is where you can create professional documentation of your project. You create pages and write inside them using Markdown language.

How to Create a Personal Repository?

Although creating a repo is a simple process, there is a special repo that I want to highlight, which is the personal repo. When you create a profile on GitHub, you’ll have a unique username.

If you create a repo with the same name as your username, that is a special repository that serves a unique role. Primarily, it is used to enhance your GitHub profile by allowing the addition of a README file that is displayed directly on the profile page.

This README can be a creative space to introduce yourself, showcase your projects, skills, and achievements, or provide updates on what they’re currently working on. You should use this repo to get the attention of employers or clients by showcasing your skills and projects.

How To Write a README file?

Every successful repo on GitHub has a README file that describes the project and document it. Markdown is the language used to write a README file, so let’s learn quickly how to create a professional README file in a repo.

To create it, you create a file called README.md, where the “md” extension stands for Markdown. Writing Markdown inside README is very easy to learn.

If you want to create a heading 1 in Markdown you write “# Heading 1”. If you want Heading 2, you write “## Heading 2”.

And finally, a secret tip to remember is that you can also write HTML with inline styling to take your customization to the next level! For more reference, you can check out my personal README file here.

Modifying a Repo Structure

While you can modify the repo structure directly from GitHub, it is best practice to do that using Git.

1. Step 1:You need to “clone” the repo from GitHub to your local system. You can do that by following this git command: git clone REPO_URL where the REPO_URL is the URL you get from this window down below:
2. Update the repo on your local system. Add files, folders sub-folders, update the README file, delete, rename and do anything else. Remember that a repository is simply a folder where everything else is stored.
3. Add the files and folders you modified in your repo to what is called the “staging area” where git tracks the changes made to the repo. You can add them to the staging area by following this git command:git add . The “.” In the previous command means “add everything” which is what usually used because usually you don’t want to add specific files or folders as it’s tedious work.
4. Push the changes you committed from the staging area to the remote repository on GitHub by following this command git push

Branches

Branches are used for concurrent work on different parts of a project. They can also reduce the risk of conflicting versions of files.

For example, 2 developers can work on a feature of the application in a branch called “feature1”, while 2 other developers work on a second and totally different feature of the application in a different branch called “feature2”. You can visualize this in the diagram below:

You can see that both branches “feature1” and “feature2” originate from the main branch, which is the default branch to any new repository you create. In this case, the main branch is called “branch source” because it is where the other branches originated. But you can start branching from anywhere. I chose to branch from the main because it’s easier to explain.

Once the team finishes working on a specific feature in a branch, they can “merge” into the main branch.

The main branch is the final version of the project. Anything merged or pushed to the main must be secure and tested because if there are real users of the application, all the changes will be reflected in the final version of the application. For this reason, it is best to create branch protection rules when dealing with the main branch.

Let’s add some rules to the main branch:

1. Enforce opening a pull request before merging.
2. Pull requests must be approved before being merged.

Go to the settings tab of the repo:

Click on “Add branch protection rule”:

The “Branch name pattern” is the rule name, and below it, you can select what rules you would like to enforce.

Restrict Access To The Repo

GitHub is a public social network where anyone can login and see any software project as long as it is a public repository. By default, any repo you create is a public repo. But sometimes we want our codebase to be private because it has sensitive information like an AI model trained on huge dataset to suggest marketing campaigns.

In this case, we want to set our repo to be private to restrict access to it from public view.

To set a repo as private, go to the settings page of the repo:

Scroll down to the final part of the page:

Finally, click on the “Change visibility” button and change the repo’s visibility to private.

Congrats! Your codebase now is secure. Now anyone who tries to access your repo by its URL will get a 404 error page:

So far, only you have access to that private repo, but that does not mean you work alone on the project. You can add “collaborators” to the repository to work with you on the same project.

To add collaborators, click on the Collaborators tab in the settings page and add a collaborator by their name or better by email. The added collaborator will receive an email with an invitation to collaborate on your project. Once accepted, they will be added to the list of collaborators.

Conclusion

This is a complete beginner guide to GitHub, We have learned what GitHub is, then we talked about repositories, we explored how to write README files and at last, we discussed how to work with repositories, how to create branches, and protect them. Now you can check some of the best GitHub repositories that a beginner can check to learn more about them.