Git & Github
Version control and collaboration
Last updated
Version control and collaboration
Last updated
Git is a form of code version control. Simply put, it ensures that multiple developers can work in the same codebase without major problems arising, because you can always go back to a previous version of the code.
It also ensures that if two developers work on the same code at the same time, this is handled properly and that the code of one developer is not simply overwritten by the code of the other developer.
Git ensures that you can work safely in the same codebase with a team of developers and everyone can work on their own features or bug fixes.
Github is one of the largest providers of GIT version control. It is a platform where you can place so-called 'repositories' for free or for a fee and share them with other developers.
Creating an account on Github is easy and free. You can can create an account at:
A Git repository is simply a package or folder containing all the code of a project. We can place this package on Github, for example, and then share it with other developers and collaborate on this codebase.
An application can consist of multiple repositories, often a back-end repository and a front-end repository. This is also the case for Valtimo/GZAC.
Versions are maintained for each repository, so every time a developer adds new code it is considered a new version. Every operation is tracked and can therefore be reversed later.
To ensure that all developers can work on their code in isolation, we use branches. From the main branch, we create a branch in which we can work on our new feature. When we are done with the feature we can merge this branch back into the main branch.
By using branches, features can be kept separate from the main branch until they are fully completed and tested. This significantly reduces the chance of incorrect code in your main branch.
Basically there are 5 operations you can do with branches within your Git repository, these are 'Branching', 'Pulling', 'Committing', 'Pushing' and 'Merging'.
A Git repository always has a main branch. In principle, you never want to work directly on this, so as soon as we want to add new code, we create a new branch from the main branch. When creating the branch we are actually making a copy of the main branch so that we can work on the same code in its own branch.
Suppose we are in our IDE (Integrated Development Environment) on the main branch and we want to create a new branch to work on a new feature. We want to make sure we have the latest version of the main branch before we create a new branch. To do this, we 'pull' the main branch and retrieve the latest version of this branch.
When we are working in our new branch in our IDE, the code is not automatically saved to the GIT repository. For this we have to make a 'commit' to our branch. A 'commit' means that we want to add the code we have modified to the branch we are currently working on. But note, this is local only and not yet saved to the repository on Github.
By 'pushing' our branch we actually send our branch to the repository on Github and our code is safely stored in the cloud. It is wise to do this regularly so that you never lose code in case the machine you are working on is damaged.
Once we're done with our new feature, we want to merge our branch into the main branch so that our new code is added to the main branch. We do this by means of a 'pull request' or 'merge request'.
A 'pull request' (or 'merge request') is a request to 'merge' a branch with another branch, this will often be the main branch but this can also be another branch.
The idea of a 'pull request' is that another developer (the 'reviewer') checks and approves the new code before it ends up in the main branch.
If, according to the other developer, there are errors in the new code or if certain code can be improved, 'comments' can be added to the 'pull request'. These must then first be resolved before the pull request can be merged.
If you create a new 'pull request' on Github, you will receive an overview of all changes in the code. As a 'reviewer' you can see exactly which code has been adjusted, added or removed.
After approving the pull request, the new code can be merged into the main branch.
