Version control is a tool that helps you recall the previous versions of your source code to check them and work with them; it is agnostic of the language or technology used and it is possible to use a version control in all softwares developed in plain text.
We can categorize the versioning control tools into the following categories:
- Centralized version: Control system needs a centralized server to work and all developers need to be connected to it so that they synchronize and download the changes from it.
- Distributed version: Control system is not centralized; in other words, each developer has the entire management version control system on their own machine, so it is possible to work locally and then synchronize it with a common server or with each developer. Distributed Version Control Systems (DVCS) are faster because they need less changes on the centralized or shared server.
Subversion (SVN) is a centralized version control system and, for this reason, some developers think that it is the best way to work respecting the entire project, so the developer just needs to write and read the access controllers in one place.
The entire code is hosted in one place, so it is possible to think that this way, it is easier to understand SVN better than Git. The truth is that the SVN command line is easier and there are more GUIs available for SVN. The reason is clear: SVN has existed since the year 2000, and Git came 5 years later.
Another advantage of SVN is that the system to number the versions is clearer; it uses a sequential number system (1,2,3,4...) and Git uses SHA-1 codes, which are more difficult to read and understand.
Finally, with SVN, it is possible to get a subdirectory to work with it without the need of having the entire project. This is not a problem for small projects, but it can be difficult when you have a large project.
In this book, we will use Git for our version control. We made this decision because Git is definitely faster and more lightweight (it takes up 30 times less disk space than SVN). Also, Git became the standard version control on web development version control and our goal is to create an application based on microservices using PHP, so Git is a great solution for the project.
The advantages of Git are as follows:
- The branches are more lightweight than SVN
- Git is a lot of faster than SVN
- Git is a DVCS from the start, so the developer has total control of its local
- Git provides better auditory in branching and merging
In the subsequent chapters, we will use Git commands on our project, explaining each one and giving examples, but until then, let's take a look at the basic ones:
How to create a new repository: Create a new folder, open it, and execute Git in it to create a new Git repository.
How to checkout an existing repository: Create a local copy from the repository executing Git clone /path/to/repository. If you are using a remote server (hosting centralized servers will be explained in the following lines), execute Git clone username@host:/path/to/repository .
To understand the Git workflow, it is necessary to know that there are three different trees:
- WORKING DIRECTORY: This contains the files of your project
- INDEX: This works as the intermediate area; files will be here until they are committed
- HEAD: This points to the last commit done
Adding files to the INDEX and committing them are easy tasks. After working with files on your project and changing them, you have to add them to the index:
- How to add files to the INDEX: Checking the files before adding them to the INDEX is recommended. You can do this by executing
git diff <file>. It will show you the added and deleted lines, and some more interesting information about the file you modified. Once you are happy with the changes made, you can executegit add <filename>to add a specific file or add Git to all the files you have modified. - How to add files to the HEAD: Once you have included all the necessary files in the INDEX, you have to commit them. You can do this by executing
git commit -m "Commit message". Now the files are included in the HEAD in your local copy, but they are still not in the remote repository. - How to send changes to the remote repository:To send the changes included in your HEAD local copy to the remote repository, execute
git push origin <branch name>;you can choose the branch where you want to include the changes, for example, master. If you did not clone an existing repository and you want to connect your local repository to a remote one, executegit remote add origin <server>.
The branches are used to develop isolated functions and can be merged with the main branch in the future. The default branch when a new repository is created is called master. The workflow overview will be something like this:
- How to create a new branch:Once you are in the branch from where you want to create a new one, execute
git checkout -b new_feature - How to change the branch:You can navigate through the branches by executing
git checkout <branch name> - How to delete a branch: You can delete a branch by executing
git branch -d new_feature - How to make your branch available to everyone: A branch will not be available to the rest of developers until you upload your branch to the remote repository by executing
git push origin <branch>
If you want to update your local copy with the changes made on the remote repository, you can execute git fetch to check if there are any new updates and then git pull to get that update.
To merge your active branch with a different branch, execute git merge <branch> and Git will attempt to fuse both branches but, sometimes, if two or more developers changed the same file, there could be conflicts and you will need to solve those conflicts manually before the merge and then put the modified files into the INDEX again.
If you fail, maybe you want to trash your local changes and get the ones from the repository again. You can do this by executing git checkout -- <filename> . In case you want to trash all your local changes and commits, execute git fetch origin and git reset --hard origin/master.
When we are working in a team, maybe we want to have a common repository with a centralized server. Remember that Git is a DVCS and it is not necessary to use a place to have the code centralized, but in case you want to use it for different reasons, we will look at the two famous ones.
The hostings provide you with a better way to manage your repository using a web interface.
GitHub is the place to host the code chosen by a majority of developers. It is based on Git, and companies, such as Twitter and Facebook, use this service to put their open source projects. GitHub became the most famous source host in just a few years and currently, many companies ask for a candidate's GitHub repository before their technical interview.
This hosting is free for all developers; they can create unlimited projects with unlimited collaborators and only one condition; the project needs to be open source and public. If you want to have a private project, you will have to pay.
Having your project as public on GitHub is a good opportunity to show your project to the world and take advantage of the big GitHub community. It is possible to ask for help because there are many registered and active developers.
You can visit the official website at https://github.com/.
BitBucket is an alternative place to host your project. It uses Git, but you can use Mercurial too. The interface is pretty similar to GitHub. A great advantage of BitBucket is the company that makes it possible--Atlassian. It has many functionalities for developers included in their hosting, for example, the possibility of integrating other Atlassian tools or a small continuous delivery tool which allows you to build, test, and deploy your application.
This one is free regardless of the project you want: public or private. The only limitation is that it only allows five collaborators for each project; if you need more people working on your project you will have to pay.
Official website: https://bitbucket.org/.
When you are developing an application, it is important to keep your code nice and clean, but it is even more important when you work with other developers. In this section, we will give you a small introduction to the most known version control strategies you can use in your project.
This strategy is the most common for developers who were previously using SVN (old school) or similar version controls. Like Subversion, the project is hosted in a central repository with a unique point of entry. This strategy does not need more branches except master (trunk in SVN).
Developers clone the entire project on their local machines, work on the project, and then they commit the changes. When they want to publish the changes, they execute push.
This is the next step from centralized work. It works with a centralized repository also, but developers create a local feature branch in their copy and this one is published on the centralized repository too, so all the developers have the chance to participate in that feature. The branches will have descriptive names or number of issues.
In this strategy, the master never contains errors, so this is a great improvement for continuous integration. Also, having specific branches for each feature is a good encapsulation to not disturb the main code base.
Gitflow workflow does not add more new concepts than feature branch workflow. It just assigns different roles for each branch. Gitflow workflow works with a centralized repository too, and developers create branches on it, such as feature branch workflow. However, the branches have a specific function, for example, development, release, or feature. So, the feature branches will be merged with a specific release and then with master. This way, it is possible to have different releases for the same project.
This strategy is used for large projects or projects that need releases.
The last strategy is quite different to others that we have looked at in this chapter. Instead of cloning a copy from the centralized server and working on it, this one gives a fork of that to every developer. This means that every developer has two copies of the project: a private one and the server-side.
Once the developer makes the changes they want, they are sent to the project maintainer to be reviewed and checked so that they do not break the project and then they are merged with the main repository.
This strategy is used in open source projects, so the developers cannot break the current project.
It is really important to have a versioning system in our microservice or API. This allows the consumers and yourself to have a coherent system of versioning so that everyone can know the importance of a release or feature.
Set the version number as MAJOR.MINOR.PATCH:
MAJORwill be incremented when incompatible API changes are made, so developers need to trash the current API version and use the new one.MINORwill be incremented when a new feature is added and it is compatible with the current code. The developer, therefore, does not need to change the entire API just to update the current one.PATCHwill be incremented when a new bug fix for the current version is done.
This is a summary of semantic versioning, but you can find more information at http://semver.org/.