GIT is a versioning system that allows us to manage and track code evolution over time. We can clearly see all the changes made, we can go back in the code and mark new versions. Another reason why GIT is used is the ability to easily share a project with others and the systematic collaboration of a team of developers on the same project.
Another great advantage is that thanks to the online GIT repository, we have our project securely backed up and we do not have to worry about losing it due to technical problems with our machine.
GIT repository services online
We can easily create our own GIT repository on our local machine. However, we lose a lot of benefits, especially the possibility of cooperation on the project with other developers. For this reason, it is necessary to have a repository located online. We can either use our own server or reach for the services that hosting GIT repositories online offers for free.
The most common services you will come across in practice are Github and Bitbucket. Both are good to know, both are suitable for something else.
Github repository for open source projects
The github.com website offers the opportunity to host its public GIT repositories for free. Thanks to this, it is mainly used for open source projects that are easily accessible to everyone.
Bitbucket for private GIT repository
If you want to host private GIT repositories that you only share with your team for free, you’re sure to come across bitbucket.org. You can freely set permissions for individual projects, so the code is always safe.
GIT installation
To use GIT in your local development environment, you must first install it. The installation depends on your operating system, so I recommend following the official GIT installation instructions.
You can also install GIT within the Sourcetree software, which I definitely recommend all beginners to try, we will talk more about it below.
Basic elements of the GIT system
Commit
Commit is the cornerstone of the GIT versioning system. Thanks to the commit, we can save and name the changes made to the code. Along with the changes made, information about the time of storage is saved, on which the GIT builds further.
Branch
If we work alone on a simple project, we will probably be able to make do with the main branch, which is most often called the master. We make all the changes in this branch, simply put, we store our commits. However, if we work in a team or develop several application functions at the same time, we will have to learn to work with branches.
I write about working with branches in even more detail below in the article.
Push
An important action when working with GIT is the so-called push. We will send our commits, ie the changes made, to the remote GIT repository, where everyone can see them from now on and can continue working with the modifications.
Pull
Pull is the opposite of push. If you make a call, we update our local project compared to the remote repository. It is important to perform a pull before making any adjustments so that we always work on the current project.
Both push and pull actions are always performed with respect to the current branch in which we are located. So if we work in our own “dev” branch and do a push, we will only send commits within the “dev” branch. Conversely, if we pull in the “dev” branch, only this branch is updated, not other branches, such as master, etc.
How to use the GIT versioning system
GIT can be used in several ways. Of course, hardcore users can use it directly from the command line, for which GIT is mainly intended, but this article is intended for beginners, so we will show you how to use GIT visually within GUI applications.
Sourcetree application
As I mentioned, I would recommend Sourcetree to all beginners to get used to GIT. This is a GUI application, so you will see the history of your project nicely graphically and you can better imagine how GIT works and how we can use it.
We can easily link the Sourcetree application to our Github or Bitbucket accounts. We can easily commit the changes made and graphically see the history of the project, including all active branches, between which we can easily switch.
GIT integrated in the IDE
For more advanced users, I recommend learning to work with VCS (Version Control System) integrated directly into their IDE (development environment), which they are used to. Most modern IDEs already have this functionality as part of a basic installation, or GIT can be installed using plugins. If your IDE does not, change the IDE. 🙂
Thanks to the integrated GIT directly in the IDE, you get new possibilities of writing code that you never even dreamed of. Not only do you have everything available within one application and you don’t have to switch between multiple windows, but especially when writing code you see all the changes made directly in the code editor, you can easily view the history of each line, undo changes and much more.
Each IDE has a work with VCS / GIT solved a little differently, so it’s not worth describing something in detail here. However, I personally use VCS integrated in PHP Storm and working with GIT is very intuitive and simple here and I can no longer imagine working on a project where I do not have GIT.
Working with GIT branches
The hardest thing for most beginners is learning to work with branches. For simple projects that we work on ourselves, we can make do with one main branch, usually called a master.
For many years, Github.com referred to the main branch as the master. In 2020, the main branch changed to main. But technically nothing changes, it’s just a name.
For more complex projects and especially when working in a team, we will have to learn to work with branches.
In the diagram above, you can see roughly how branching in GIT works. Each line is its own branch, the wheels are commits. Thanks to branches, we can simultaneously develop several functions and then combine them into one branch using the so-called merge. It does not happen to us that we somehow influence or rewrite the code with each other. We always create a branch from an existing commit and as soon as we are done on the given part of the application, we perform a merge back to the main branch.
Conflicts can occur when performing a merge, such as when there are changes in both branches on the same line of a file. However, thanks to GIT, they can be easily solved and many problems can be avoided.
I recommend naming the branches systematically so that it is clear what they are used for and what is being worked on. Some name branches by their first / last name, which is quite useless when a second developer comes to the project and does not know what you are working on in that branch.
Leave a Reply