Git and GitHub Guide for the Beginners
Last Updated on March 4, 2024
Modern-day software development wouldn’t be possible without version control systems. The whole environment depends on the cooperation of teams working on different features at the same time, and version control allows you to make it easy to work. Therefore there is a need to understand how git works – the most popular version control system right now.
In this article, we will go through the basics of the git version control system, how to use git in general and create a git repository, how to merge, how to do a pull request (merge pull request too), and how to use GitHub – all on the beginner-friendly level. Let’s get started.
What is git
But first, let’s answer the question of what exactly a git version control system is.
Git is an open source distributed version control system developed by the same person that created Linux. It works on every major operating system – Linux, Windows, and Mac OS, so no matter which you use, git will work there.
Git as a version control system makes it easy for a team like yours to keep track of every change made to projects, during the development process. All developers share the code, stored in the repository, work on it independently, and the code is merged back together to push the project forward.
With git, there is no need to be connected all the time, because your projects are saved locally and remotely on a server. This also means that the changes you create will not affect the project unless you decide to merge your code with the existing one in the repository. This is a great way to ensure your code’s safety.
Another great advantage of git is the fact that you can easily check or revert to previous versions of your code – hence the name version control system.
Working area, staging area, and repository
Let’s take a closer look into the three areas in Git where code resides.
The first is the working area also called the working tree. In brief, it is a space where reside files that are not in the staging area. In the same way that you keep files in a local directory.
The second is the staging area, which stores files that are going to be a part of your next commit. That’s exactly how Git knows what is going to change between the current commit and the next one.
The last one, the repository contains all of the commits. What is the commit? It is a snapshot of what the working and staging area looked like during the time of the commit.
In short, we add files from the working area to the staging area, and then we commit from the staging area to the repository.
Git vocabulary
Now that we know what git is before we will install it, you should know some of the basic vocabulary, as at first, it might be quite intimidating, but is necessary to understand what is happening.
Repository
You can say that the repository is the container that has all the things involved with your project that git tracking. It includes the files and directories related to your project, the history of changes, and other related information. In more common situations it is referred to as a “repo”.
Local and Remote Repository
Now that we know what repositories are, we need to know how to distinguish between the types of them – there are two: local repository and remote repository.
A local repository is located on the machine you work on, as a hidden “.git” folder inside your project’s one. You as a user of that machine are the only person able to access and make changes to that repository.
A remote repository is usually created on a remote server on the internet or your local network. It has no working directory but it is entirely the “.git” repository folder. Everybody on the project can contribute their changes to that repository. They are used to share and exchange data among your team.
Ready to create repository?
Commit
A commit is a name for all the changes that you created, and want to save to put into your repository. You can understand it as saving your work done on a project.
Each commit creates a new version of your project, marking a point in time for your project. With the commit comes all the information about the project from the point of adding changes, therefore it can be used to restore a project to a certain stage. You can add a short comment to it so that you and your team know what was the purpose of that commit, and what it changed.
How secure are your repos and metadata? Don’t push luck – secure your code with the first professional GitHub backup.
Push
A Push is directly related to the commit. Because as you save your progress with commits, you need to have a way to share your work with your team, and here comes a Push. It syncs your local work with the remote repository of your project. You can easily push many commits at once, for example when you don’t have an internet connection, you can still work on your project, create many commits, and when you are back online, you push them all, for your team to see.
Clone
A clone is what the name suggests, literally a clone of your repository, it includes all information stored within the repo, all files, and the history of changes. It takes the remote repository and creates an exact copy of it on your local machine.
If you are into clone commands, there is a detailed article describing how to clone a Git repository, and what the pros and cons of such a solution are.
Branch
You can think of a branch as a safe place for you to work on your code, separately from the main project. This allows your team for safe work on the project because individual bugs and mistakes will only affect the branch you work on and won’t affect the main software stored on the Master Branch. We’ll take a closer look into how to commit changes to another branch later.
Head
While working with git, and using branches you need to know which branch you are working on currently, and that branch is called the “HEAD” branch and is sometimes referred to as an active or current branch.
Merge
When you think you finished work on your branch, added a new feature, and tested it you would like to include it into the main codebase – the Master branch, or into the branch that is higher in the hierarchy. You basically merge them together. From now on, the new code will be a part of the branch you merged to.
Fork
A Fork is something similar to the cloned repository. But there is a big difference, instead of cloning the repository on your local machine, a new repository with the same code is created and assigned to you – a fork. This feature is used usually when developers decide to try and go the other direction with the software that already exists, with different ideas to test them in a safe environment, so that the changes don’t influence the main code. You can also merge the changes to the master branch. To learn more, check this post – Git forking workflow.
Pull Request
A pull request is when you want to pull (merge) branches or forks with all of the changes made within them into the master branch. If the pull request is approved, all the changes made in the branches are now a part of the main software. There is also a possibility that the pull request will not be approved, then the person responsible for merging branches is able to give feedback on why it wasn’t possible, so you can improve and fix the code.
Git usage
Now you have somewhat of the idea of what vocabulary is used when operating git, and you will hopefully not consider them magic spells anymore!
But what is theory without any practice, let’s work on the git itself!
How to install git
The first thing there is to do is to install the git software. Installing it is easy, and you shouldn’t have any problems with it whether you work on Windows, Mac, or Linux.
Just choose which operating system you work on, and follow the instructions on the site.
- Installers: Linux | Windows
- For Mac OS, you need to open the Terminal, and type in “git”. If you don’t have it installed, it will prompt you to do it.
You can find all of the downloads of git on this site.
Basic Git commands
Git has some complicated commands, but that should not discourage you from using it, and understanding it at the command line level. Even though there are few amazing services, like GitHub, GitLab, or BitBucket, that help you manage your git repositories without the need to know the commands, knowing them, and what they do, will help you a lot with version control of your project.
How to create a new repository
You can either create a completely new repository by using the command (don’t forget to add some clear repository name):
$ git init
Or you can clone already existing repository:
$ git clone ssh://[email protected]/repo.git
Commits
To add all the changes to the next commit use:
$ git add
If you want to add a specific file instead of the dot, insert the name of the file.
If you want to see what files are included in the next commit, and which ones are not, and also what has changed since the last commit use:
$ git status
To commit all the local changes use:
$ git commit -a
Commits History
To show all commits history starting from the newest commit use:
$ git log
Branches
To see a list of all the branches in your repository use:
$ git branch -av
When you want to change active branch use:
$ git checkout <branch>
To create a new branch based on your current HEAD use:
$ git branch <new-branch>
To delete a local branch use:
$ git branch -d <branch>
Merge and Pull request
To merge a branch to your current HEAD use:
$ git merge <branch>
Learn about differences – Merge vs Rebase
To do a pull request on the branch and directly merge into the HEAD use:
$ git pull <remote> <branch>
Git workflow
Now we know the most necessary commands used within git. To have a better view of how the git workflow function works check out this article – Git Workflow.
Ready to command git like a King?
Using git: why you would use GitHub
Let’s start by explaining what GitHub (and other git hosting services in general) is. GitHub is currently the most popular git repository hosting service with over 56 million users worldwide.
For more information about what are the best git hosting services check out our GitHub vs. BitBucket comparisons.
To answer the question of why you should use GitHub, the first reason is that you can host as many public (a good solution for an open source project) and private repositories (start with a simple repository with a readme, as a semi test-drive) as you wish with a free plan. Another benefit of using GitHub instead of using git yourself is that it simplifies your work significantly because you don’t need to process your repositories with git commands, instead, it allows you to work with a graphical interface directly from the GitHub website.
Getting started with GitHub
To start using GitHub, you need to create your GitHub account on their website (or you can log into one if you have it) Then you can create your first repository directly from the website panel or you can upload one from your computer. For a beginner, the first solution is way simpler.
Disclaimer: In this tutorial, we will only use the git service itself, not any third-party git management tool, we will be working on the commands, so you can understand better what is happening inside git.
You can choose to add a .gitignore file, license, and a README file. “.gitignore” allows you to choose which parts of your project you don’t want to involve in your repository. README file is an elegant solution if you want to create some sort of a wiki and basic documentation for your code.
Make sure to transfer your repository from GitHub to your local machine next. You can do that by clicking on the “Code” button.
We are cloning the repository so we don’t have to worry about too many things. We just need to remember the Cloning with HTTPS part. You won’t need to configure a thing, you will just have to input username and password when you do the push.
If you know where you want your repository to be stored, in git, use “cd [your directory name]” to switch to that location, use “git clone [link from the GitHub site]” then use “cd [name of your repo]” and now you are working on the repository locally.
If you are using Visual Studio from Microsoft, integrating GitHub repositories into your local repositories is even easier. All you need to do is follow instructions provided directly from the Visual Studio.
Check this out: Visual Studio Code GitHub integration. Learn more about the best way to connect the two of the most loved by software developers tools.
Commits and pushing to remote repositories
So now you have done some work on the project, and you want to push your changes into the remote repository in GitHub, what do you need to do?
Well, from a git perspective, you will just need to use a few commands, we listed previously.
The first one is “git add .” – this command will add changes to your repository, the dot means that you want to add all the files into a commit. If you want to add specific files, just enter their name where the dot is.
Then you would normally check if your changes were added to commit, for that you would use “git status”.
The next command you would use is “git commit -m “message you want to tell” – this command will commit your changes to the repository, with a message. It is a good practice to add information about what changed with this commit, so your colleagues or you from the future know what the purpose of it was.
How to write a commit message?
A commit message can adequately communicate why a change was made. A well-crafted one is the best way to communicate context about a change to other developers in your team and definitely makes collaboration much more efficient.
How to write a good commit message then? First, specify the type of commit. Is it an update, some new feature that you are adding to the application, or maybe a bug fix? Have in mind to separate the subject from the body with a blank line and check the message for any whitespace errors, unnecessary punctuation marks. Start each subject line and each paragraph with a capital letter, and don’t end the subject line with a period. Those are the most basic rules.
Remember, never assume that your code is self-explanatory.
Pushing to remote repositories
Now that all work on the local part is done, you need to push your commit into the remote repository on GitHub.
Before you push to the remote repository, it is a good practice to check beforehand how things are looking in the commit, what you are pushing, and if you are on the branch you want to push to – to do that use “git status”.
Then use “git push” – which is self-explanatory. Then enter your GitHub credentials, be aware that when you type in the password field, it will remain empty, it is normal, just type your password and then hit enter.
After all that you can go to your GitHub page, and check if everything went right, you should see there not only the files you committed but also the message you typed in.
Branching and merging
Creating branches and working on them is one of the key ingredients of a well-done project. It allows you to work with your code without affecting the main branch where the whole project rests. Once you are sure that the changes you made are well-tested and won’t ruin the project you can merge branches back together and improve on the project.
First, we need to create a new branch in our repository.
From what we have already told in this tutorial you would be able to create a new branch in your repo, but this time we will go a little different route. To add a new branch, we will use the checkout command but with a parameter.
Use “git checkout -b “[name of your new branch]”” – This command will create a new branch with a name that you provide, but it will set it as a current HEAD. The thing that allows us to do that is the “-b” parameter, which is a representation of the “git branch” command.
Then when you would do a “git status” you would see that in fact, you are on the newly created branch. And normally you would just start working on that branch, but for tutorial purposes we will use a filler command, to artificially add a new file to that branch.
“git touch [filename with extension]” will add a new file to that branch, you can check if it was added with the “git status” command.
Then if you can do “git add .” or “git add [filename with extension]” to your next commit. To check if it was added as usually use “git status”.
If during the push operation something unexpected happens, you will receive a message saying that you need to set the repository’s origin. An origin is what your computer considers as a remote repository.
To deal with that problem you need to set up the origin. You can do that with a command: “git push –set -upstream origin [name of the branch]”.
Now when you are done with that branch, you would like to merge it to master. To do that your HEAD needs to be master, so we use “git checkout master”. Then just for safety “git status” to check if everything is okay.
Then to merge use “git merge [name of the branch]”. If everything is okay with that branch it will merge the branches. Before we push it to the remote repository as always use “git status”. If everything is fine, use “git push” as previously, and all your changes should appear on GitHub.
If you would check out GitHub’s repository page you would see that indeed all the actions we made are successfully uploaded to GitHub. With all the commits, branches, and files.
You may find this topic interesting: git clone with SSH key. For many security experts, SSH is a golden standard, hence it’s worth to implement it into your git operations. Using SSH keys you can limit the risk of data interception by unauthorized persons. Another benefit is…
GitProtect.io, security by design
Your code is your intellectual property and is the most valuable asset in your company. You know exactly what it took to create your code, and how important it is not to lose a single line of code. That is why we tend to use version control systems to keep track of our data, and you would say that git itself is some sort of backup tool, and you would be mistaken.
What will you do if one of your team members accidentally delete the branch? In almost most cases you should use a backup to keep your repositories safe at all times. To learn more about why git backup is better than git itself to keep your data safe, check out this article: Git backup or git clone?
If you want to have a reliable backup of your git repositories you can try GitProtect.io. It is an easy-to-use, and very powerful tool to keep your repositories safe in case something bad happens to them. But you can check that yourself with a 14 days free trial, all you need to do is click here!
