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 og 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 point. 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.cQuite 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.
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 6b8653a1Or you can also switch to that commit with the command
git checkout 6b8653a1The difference between reset and checkout is quite complicated to explain. You can read about that from: https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified
When you create a repository 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. If your active branch is the main and you execute command git checkout -b hotfix1, git will create a new branch named hotfix1 and the content is the same as the content of main. Then you can edit your code in hotfix1, but main will stay in the original state. Later you can merge the hotfix to main or you can also decide that you will forget the changes you have made in hotfix1. So the idea is that if you fail with your new features, you can switch back to main branch. But if you are satisfied to your new feature, you can merge that branch to the main. And you should avoid working directly inside the main branch.
Here is a diagram from one repository. The "dots" describe commits. And qt_frontend, restapi, UI, restapidd, main are branches.
git checkout -b hotfix1Git will create a new branch named hotfix1 and switch to it. And now the content of hotfix1 is identical with main. Now you can edit your code and make commits. If you have not committed your last changes, you can not switch to another branch. If your active branch is still hotfix1 and you will execute command
git checkout -b hotfix2Git will create a new branch named hotfix2 and switch to it. And now the content of hotfix2 is identical with hotfix1.
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 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:
password.txt
*.exe
*.docx
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.