The importance of a versioning repository
No matter what type of versioning repository you use, its importance is a priority when working in a development environment separate from the approval and production environment.
When we work with languages like Visual Basic, ASP Classic, and even ASP.Net, we don't care so much about versioning because the code only runs in one place, the production environment, and the adjustments can be applied at run time, instantly .
However, when we work with languages like C ++ or Java, we depend on versioning repositories and we need them to be completely intact and that they actually represent the scenario in real production.
In CVS, a basic versioning system, there is a repository where the current project files are saved, and any new file is included using only the graphical interface, in a very intuitive way, you retrieve a repository from somewhere, perform the checkout to overwrite local changes from the server, or save to send your code change to the CVS server, which can be connected with a specific protocol or via SSH.
After CVS, we have several other types of code versioning, but the most popular today is Git, due to the popularity of the GitHub site, which emerges with a web interface to control its repository, and adds branches that are separate lines of development , which can be merged (merge) into a main line.
The main line and the branches lines may change according to the development model, according to the technical structure, but if there are 3 separate scenarios, there must be 3 separate development lines, and for each test that goes up, the merge request for changes.
Git is very good at this, finding conflicts and pieces of code that can impact other parts, although it was not developed with a specific language in mind, it is practically essential in the development of Java projects, as it reflects all the necessary security as creating users that can have write access to a particular branch, users who can accept "merge request" requests, and then everyone can have access to the code, but it can only be actually included in the "QA" or "master", depending on the user level.
Who is in the development area, can not move up the line of approval or production, except if they are bugs, where the process can be the reverse, as applying the merge request in production, and going for approval and development. This is also possible, but it depends on the user's access level, and mainly on the productivity line development model.
Learn more about Tortoise CVS:
http://www.tortoisecvs.org/See a tutorial of a type of productivity line, Git Flow:
No comments