Version Control

Today, version control is essential in application development. It makes teamwork smoother because the code from different developers can be combined in a controlled way.


Git is a version control system (VCS) for tracking changes in computer files and coordinating work on those files among multiple people.

As with most other distributed version control systems, and unlike most client - server systems, every Git directory on every computer is a full-fledged repository with complete history and full version tracking abilities, independent of network access or a central server.


Basicly the word repository refers to a central place where data is stored and maintained. So you have a project where your code is. And then if you are using Git, you will create a repository and put your code there. The repository can be a local repository (in your computer) or a remote repository (in Github, Bitbucket etc). Quite often you have both of them: you will update your local repository very often and every now and then you will also update the remote repository. Using the remote repository will also help teams to collaborate.


Commit is like a restore points. So, after you have been working for a while and you want to attach the current state of your work: you will commit it. Commit has two steps: staging and committing.


You can think that staging means that you will add the file to the repository. Example you have added a file named cat.c or you have edited that file, then you can stage it with the command

git add cat.c
Quite often you will just use command git add ., which means that you will stage all files inside the current folder, except those which are mentioned in the file named .gitignore.

After you staged the files, you can commit your repository with the command
git commit -m "some description which I have made"
When you commit your repository, you will have a state where you can later reset your repository. We can describe the developing process like this:
start -----writing code ---COMMIT_1-----writing code ---COMMIT_2-----writing code ---COMMIT_3 ......
So, later you can reset your code to the state of any of those commits.

With the command git log, you can check which commits you have made. The result might look something like this:

So, every commit has an unique id and you can use that id to reset your repo to that state. Example with below command you will reset the repository to the state of the commit which id starts like 6b8653a1

git reset 6b8653a1
Or you can also switch to that commit with the command
git checkout 6b8653a1
You can read about the difference of reset and checkout from


When you create a repository (git init or git clone), you will also create a main branch (previously master). You can create several branches inside one repository. And you can change from current branch to another using the git checkout-command. The idea of using branches, is that you should not work inside the main branch. When you start to make a new feature to your application, you will create a new branch for it. If you succes with the feature, you will merge the branch to the main.

You can switch between branches using the checkout command. You can switch example from your current branch to branch named hotfix1 with the command

git checkout hotfix1
above command works if you have staged your current branch and hotfix1 already exists. If the hotfix1 doesn't exist yet, you can execute command
git checkout -b hotfix1
so now Git will create a new branch named hotfix1, which is identical with the branch where you execute the command.

Here is a diagram from one repository.
  • the "dots" describe commits
  • qt_frontend, restapi, UI, restapidll, main are branches


With the merge-command you can integrate changes from another branch to your active branch. Example, if you are satisfied with the changes, you have made in hotfix2, you can merge them to main with these commands

git checkout main 
git merge hotfix2
You can use the parameter -b in the checkout command, if you want to create a new branch and switch to it. If you want to switch to existing branch, you won't use the -b.

You can check which branches you have with the command git branch. The result might be something like

In above the active branch is master.


There might be certain files that you don't want to add to the Repository. In that case the best solution is to create a file named .gitignore (the name really starts with dot). And then you add those file names in the .gitignore file.
Example if the content of the .gitignore file is like this:

Then the password.txt and all the exe-files and docx-files will not be added to the repository, even if you use command git add .

So what files you should put to .gitignore? Normally you don't add exe-files to the Repository, because they are big and you can allways create them again with the compiler. And also if you are using public remote Repository (like GitHub), you should not add any files which contains passwords to the Repository.

Main / Master

In October 2020 GitHub changed the terminology so that master is named main.

If you wish that Gitbash will also create a branch named main, when you init a repo, you can execute below command
git config --global init.defaultBranch main

Git clone

With the command git clone remote-repo, you will download the remote repository to your local computer.

Git fork

You can fork also repositories which are not your own repositories. When you fork a repository you will have your own copy of a repository inside your own remote server. So, you can fork the repository in the remote server and then clone the forked repository to your local computer. The original repo and the forked repo are independent of each others.

Toggle Menu