Getting Started with Git and GitHub Part 1: Intro to Git and GitHub

This article is part of articles targeted at getting you, the complete beginner at using the command line and git for version control, from zero to hero.

At the end of this article you'll be able to:

• outline the git principles
• use a GitHub repository
• describe the steps in a standard GitHub workflow
• create branches and merge different branches
• describe how code goes from local development to version control and then to live production

This article is based on Meta's Back-end Developer Certificate Course 3: Version Control. You can find a link to the course here and a link to my article on Meta Back-end developer Course 1: Introduction to Back-end Development here.

Often many beginners get stuck when starting using git and github due to a failure to properly understand git and failing to appreciate the immense power of git and its usefulness to the software collaboration and development cycle.

This article will give a brief but concise introduction to git for beginners to enable them to jump right away and start collaborating and building repositories for their portfolios.

These will the main objectives of this article:

• What are Version Control systems and how are they implemented?
• Learn how to navigate and configure version control systems using the command line.
• Learn how to manage code revisions.
• Create and use a GitHub repository.

Git Principles

In their most basic form, version control systems are borne out of a need to have teams collaborate and work on the same codebase.

We can define version control more formally as the practice of tracking and managing changes to software.

Version control systems enable developers to backtrack to previous versions of code if need be.

This is important given that multiple team members might be working on the same source code and without version control, you cannot tell who made what changes and when.

A more catastrophic result is having no way to backtrack to a previous version of software when a change to the existing code introduces bugs or crashes the code altogether.

Benefits of version control:

1. Long term history of changes
2. Branching and merging
3. Traceability

We'll now go through a basic git workflow that will illustrate most of the basics that will get you started with git and GitHub

0.Install git and create a free GitHub account

Install git according to your operating system here and create your free GitHub account here.

Git is a version control system while GitHub is provides an internet hosting service and a user interface to manage and store our git repositories

1.Create a local git repository

Navigate to the folder you want to initialize your git repository. Run the command git init

2.Creating files

In the same folder where you've initialized git, let's create a file and see how git tracks files. Run the command touch example.txt

You can review how to create files among other simple command line commands from my earlier article here.

3.Adding files to the staging environment

You've created a new file but you need to 'add' it to the staging area for git to start tracking changes made to the file. Run the command git add example.txt

4.Create a commit

With a new file already added, we'll now need to commit it thereby saving any changes we'd made on the file.

Commits are accompanied by a commit message to show what changes have been made and to make it easier to review changes made to a file or project.

Run the command git commit -m 'Initial commit'. Here, "initial commit" is the commit message

5.Create a new branch

When you create a repository on git, the branch you work on by default is the main branch, aptly named 'main' or 'master' (to be deprecated soon).

To work on different features and bugs etc, you create new branches on which you can make changes that can be merged back to the main branch after a pull request. More on pull requests later

First, you can check which branch you are currently on by typing the command git status. Then you can use the command git checkout -b feature. This creates a branch named 'feature' and sets it as the current branch to be worked on

6.Create a new repository on Github

We already covered how to create a Github account earlier. Creating a Github repository is quite easy as seen below

GitHub will ask if you want to create a new repo from scratch or push an existing repo. Since we've already created our repo, we'll choose the latter by typing git remote add origin 'link to repo' Replace 'link to repo' with a link to your repository

7.Push your branch to GitHub

Earlier, we created a local git repository, added and committed a file, created a new branch to work on, created a remote GitHub repository.

Now we would like to push our local branch to GitHub by running git push -u origin feature. Go to GitHub and you'll see the new branch appear as shown below

8.Create a pull request

Navigating to the page shown below, click on the create pull request button. A pull request is a way to notify the code owner (in this case you are the code owner) that you want to make changes in the code. Here, the owner reviews the code and if satisfied, merges the changes to the main branch.

If you are the owner or co-owner of a repository, you may not need to create pull requests to make changes as well as creating branches when working on a feature but its good practice so as to keep a record of changes made.

9.Merge your changes

Click on merge pull request and confirm merge.

Your changes will be merged to the main branch. You can delete the branch that you merged seeing as you no longer need it.

This also helps to make your work neater as too many branches can become messy.

10.Pull the changes to your local computer

If you can recall our workflow so far, we:

• initialized a git repository locally
• added files and committed them
• created a new branch to work on
• created a GitHub repository and added it as a remote connection to our local repository
• pushed the new branch to the remote repository
• created a pull request and merged the pull request.

It's then evident that our local repository is not the same as our remote and therefore to synchronize the changes made, in our terminal we run git pull origin master. We can now git status (to check which branch we are on to make sure we are on the main branch) then git logto see all changes made

In our next article, we will look into more advanced concepts such as going into the details of how git tracks changes to files.

Adios