Starting your project or maybe helping your friends with their code? Either way, Internet Archive says that there is a 73% chance that you will use git for version control. If you don’t belong to that 27%, I suggest you go step by step and read this blog for a better understanding of what git is, how it works, and how to use it properly.

What is Git?

In general, keeping track of the changes to a file or project over time would probably be impossible without some sort of version control system. As mentioned in the introduction, with around 73% of worldwide usage for version control, git is a free, open-source, and the most popular VC (version control) system in the programming world. Even though it’s not an acronym, “Get it together” describes git very nicely. Git stands for “Global Information Tracker,” and it’s used for tracking, storing, and (like a time machine) accessing any code version you need at any time. Git is also a collaboration tool for people to work and maintain the same project simultaneously and efficiently.

In this article, we will cover the following steps (respectively):

STEP 1: Install git on our computer

First, what you have to do is install git onto your local machine. There are various ways to install git, but we will go through 1 or 2 of the easiest ones.

For macOS users: You can run the command git using Xcode Command Line Tools.

git

This is probably the easiest way. Another way to do it is by using the Homebrew package management system and simply running the command.

brew install git.

For Windows OS users: 

For Windows users, it is a bit different. The easiest way is to go to the official git website https://git-scm.com/download/win and follow all the straightforward installation steps.

For further information and a more detailed view, you can visit https://git-scm.com/book/en/v2/Getting-Started-Installing-Git and learn much more about how to start a Git project.

STEP 2: Creating a Github account

There are several repository hosting managers like Bitbucket, GitLab, or the most popular one, GitHub (which we will use in these examples).

So, after we did the initial step, the next step is either to create a git repository or join an existing one.

mkdir theProject

If you are starting your own project, you need to create your repository on GitHub. With a terminal command mkdir you will create your project folder at the current location your terminal points to.

cd theProject

With cd <projectName> you will navigate to it.

git init

There you will initialize your new repository with the command init. What it does is it actually creates a hidden folder called .git which contains all the needed folders and files for Git to reference a certain directory.

git clone https://github.com/Bruno2Kozina/Demo-projekt.git

If someone invites you to their project, you will have to clone the specific repository with the command git clone <repourl> into your new folder that you created and initialized, just like in the first example.

Actually, what you just did there is that you duplicated the remote repository and created your local environment where you will track the changes between what you will do locally and the current version of the code on the remote level. After you make some changes to the code, you will probably want to upload it to Github and connect it to the remote repository. In the next step, we will cover how to do that.

STEP 3: Git commands to integrate changes

https://i.ytimg.com/vi/ew732TEA1TU/maxresdefault.jpg There are three states which lead us to three main sections of projects changes integration:

A basic workflow goes like this:

Make changes to the code: After saving the file, changes are automatically read by git and shown in the Modified state.

git status 

Usually, to be sure, the next step is to use thegit status command to check in which state is each of your changed files.

git add
git reset

With the command git add <file_path>, you migrate a specific file from modified to staged state, or with git add . you can migrate them all at once. If you want to revert it, instead of git add, you use git reset.

git commit <commit message>
git push 

To migrate changes to the Committed state, you use the command git commit -m ‘some commit message’ from which you will push it to your local branch with the command git push and then to the public repository with git push origin <branch name>.

git reset --soft HEAD~
git reset --hard HEAD~ 

If you want to revert your commit before pushing, you will use the Git reset –soft HEAD~ command, which will return your files from Committed to Staged state. Git reset –hard HEAD~ (dangerous method) will completely delete your changes.

There you go. You just made the changes to the current public branch you are on. Speaking of branches, if you are working on a larger project with more people, things can get a little bit trickier, and it is not that simple to keep track of who made the changes and when. In that case, we use the worktree (multiple branches), which helps us structure our project's workflow to maintain the project and review its changes.

STEP 4: Understand how branching works

Branching is a compelling concept for organizing and structuring the code version flow. 

Here at Cinnamon Agency, we have a Git policy, which is defined by the size of the project. Every project, large or small, has one main branch, which is called master or main by default. In the previous examples, we already interacted with that branch by changing it. But what are the differences between large, medium and small projects? How and when to create new branches? How to interact with them? How to merge one to the other? We will cover all these questions and more with the next workflow example:

Someone invites you to the project and gives you a specific task. You clone the repository, initialize it, and you are ready to make some changes. Since other people are working on the same project at the same time, you don’t want to make changes directly to the main branch, instead, you will create your own and later merge it with the others:

git checkout -b 'some branch name' 

This is the short version of creating a branch and checking out on it. A more extended version would be git branch ‘some branch name’ to create a new branch and git checkout ‘some branch name’ to switch to that branch. The important thing to know is that by creating a branch you actually duplicated the branch that you were previously checked on (in this case, the main branch), and gave it the name ‘some branch name’.

After you made some changes, committed them, and pushed them, you will probably want to publish your branch to the remote repository. Before that, keep in mind that you will have to make some other steps to prevent the possible issues.

git pull origin main 

While you were making changes, some of your colleagues could integrate their branches into the main branch. That’s why, before pushing the changes, you always need the current version of the main branch, and you will do so by pulling it to your local machine. This will make sure that you are on track with the current version, and you can safely push and merge your branch to the main. 

Conflicts - Conflicts are common in the development process. They often occur when someone is making changes on the same file as you while starting the merge process or during the one. For more information on how to solve them, check https://www.simplilearn.com/tutorials/git-tutorial/merge-conflicts-in-git 

git merge some branch name git checkout 

After you have done all steps above, it’s time to implement your changes to the main branch, and you will do so by switching to main branch with git checkout main, merge it with ‘some branch name’ with git merge some branch name and push the changes with git push. 

Also, keep in mind that there are git branching naming conventions for better quality and faster understanding of what you or someone did. This concept is highly recommended and mandatory used by most companies. Check it out on ​​https://codingsight.com/git-branching-naming-convention-best-practices/

Voila, there you have it. Your changes are implemented to the actual state of the project's main branch. But, if you are a junior developer, there will probably be someone who will check if your code works and if the changes are correctly done before it is merged with the main or some other branch. Instead of merging it directly, you will have to make a pull request.

STEP 5 (optional): Make a pull request

As we said earlier, pull requests are used for reviewing someone else's code. If you are a Junior developer or you’re just joining the ongoing project, there is a high chance that pull requests will be your go-to.

The process is pretty straightforward. After you make the changes and push them to your origin branch, GitHub will automatically offer you the option “Compare & pull request”.

After you press it, you will add some Title and description, and choose which branches you want to merge and who you want to review the changes. A person reviewing your request will either approve it, reject it, or leave a comment on what you potentially need to fix.

To keep things in order, it is a good practice to always delete the branch that has been merged. Don’t worry, your commits will still be available and visible.

CONCLUSION: 

Git is a potent tool for organizing and structuring your project workflow. In this article, we covered only the basics of using git in your work environment. Git has a lot more to offer, and there are plenty more exciting and useful features. I highly recommend you understand Git as much as possible. It will make your life a lot easier as a programmer, and you will be able to focus more on coding rather than fixing potential frustrating issues with code versions.