What do you know about Version Control System (VCS)?
What is Version Control System (VCS)? VCS is a system to track changes in file(s) by making a version snapshot changes of that particular file over time.
For the example is, when we want to write a book, we will write a word by word, line by line, or we save it chapter by chapter, we should be able to track the changes of the file, if we save it when we have add the second chapter, we should be able to remove the second chapter, as automatically as we add the second chapter. If we want to know what have we done in the second chapter, we should be able to track what we have we done before it, or even track other chapter changes in file(s).
In the Development phase, says that we want to add new feature such as search functionality to our apps, last thing that we do as developer is we develop it, and right after the feature is done, we save it (commit it) to VCS and take it out as snapshot when that feature have been done.
But the problem is, when the operation team want to release other feature before this search functionality. What should they do if they don’t have that snapshot? do they have to says to developer to delete that feature? off course not, this is when the VCS is playing its role, they can take the snapshot from the VCS and publish the apps as the last snapshot before that search functionality. We should can take out a feature as automatically we add it. So, how much types of version control system?, there are 3 well known types of Version Control System, they are Local, Centralized, Distributed Version Control System:
Local Version Control System
So, what is local version control system? Local VCS is an approach that the user keep it’s own file or saved the file by it’s own self, they manage they own file. But it is hard to maintenance the changes of the file. We can just accidentally replace other file that actually we need. Old programmer made their own database that kept all the changes to file under local version control system.
For example, developers have project named Hello World, they have much feature on it, if they want to add new feature, then, they have to backup their project, so they copy the project to other folder, and change its name like old-hello world. After they have its copy, they add new feature and then, after that feature has done, they want to add another feature, so they copy the folder again, and rename the old project folder like old-hello world-old feature. After that, they add that new feature, then we knew that they have much folder called old-hello world-old feature folder, they can accidentally replace the wrong folder that they actually need it. This is bad for development phase if we need the specific changes, we cannot track it very well.
Centralized Version Control System
Centralized VCS as known as one of its application, subversion (SVN) or maybe other application Concurrent Versions System (CVS). Centralized CVS is a way to track changes on project, but differently with local VCS, this way we save the snapshot of the application on the server, with history changes saved in the server.
For example, when developer want to checkout (take a snapshot from server), then the operation teams want they to add new feature, they can make a new branch (like in a tree, they are new branch for new place for the tree to expand the tree it self), so their old feature have its own branch, and that new feature have its own branch (difference branch between old feature and new feature) than they can track changes within on the old feature and new feature whenever they want to track it. But there is a problem, when you cannot connect to that server, but when you want to commit (save a snapshot of the project), you have to connect to server, for some security reasons, you cannot open that server port, but you close for some address, then you have to use VPN for it, but the VPN that addressed to server is down, so you cannot add that snapshot again to the server. So much problem that you faced here. So there is another VCS, called Distribution VCS.
Distributed Version Control System
Distributed VCS as the inverse of the Centralized VCS, it gives all the management/traceable of the project in the developer/client side, not server side, you can checkout the branch without connecting to server, even you can commit changes, trace changes that you have made even without internet connection. But you can push the changes whenever you have an internet connection (push is a process that you save the snapshot that you have made to the server (in Centralized VCS called commit), so whenever everybody else who want to get it, they can just login and get the project from the server without thinking about that VPN things). For Example Distributed VCS is Git/Mercurial/Bazaar or Darcs. For this time, there is 2 kind of Distributed VCS that used, the first one is Feature Branch Development, and the second one is Trunk Branch Development.
Feature Branch Development:
Feature Branch Development is a way of developing a new feature, using branch / new way in tracker, if you think about tree, you can think that tree have a branch, imagine that branch in tree is a branch in git, it intersection the branch, and you can imagine, new branch in Feature Branch Development is a way to develop a feature using a new line tracker, but it’s still correlated with the main/master/trunk. If you think about book again, you may think that you copy the book, and add a new feature in the copied book, you may to anything to the copied book. We can say that your copied book is isolated from other book (the real book) so that you can make everything in that book. Then there is a term said, Merge Request(MR)/Pull Request(PR), MR/PR is when you are reading that copied book, and see if that changes is able to merge to your real book, then you see it’s able to merge, then you copy that changes to your real book, (if its copied, it’s indicator that your MR/PR is accepted and changes in your code is merged). Generally people delete it branch after merge request/pull request to master is accepted.
Trunk Based Development (Monorepos):
Trunk Based Development is a way of developing a new feature, only using master/trunk, you can imagine that you only use one book for writing a book and you never copy that book, or you only use that book even you have other book that you can copy your book. You make changes, track your changes in master. In Development, you do commit, push, using only master. If you see commit history, you can see that the history is one line, you shouldn’t see branch in visualization of changes if you are using Trunk Based Development.
