I always wonder how the “Avukana statue of Lord Buddha” was built. Sculpting a gigantic statue without any fissures is amazing and requires extraordinary talent and coordination of effort. I believe many people have contribute to this project by engaging in cracking, shaping, polishing various parts of the rock. Each and every hammering should be perfect. If you put little bit of extra pressure than you need, entire months work will be wasted and you’ll have to find a another rock and start it all over again.
But when it comes to building software, mistakes are acceptable. Each and every piece of code you check-in is not perfect and it is known. that’s why you need proper software repository to manage the different versions. Quality of the code is important as the source code control system. Choosing the right software repository is really important in building a sophisticated deployment pipeline. There are wide range of commercial and non commercial software repositories in use today. We have many many options to choose. But what are the key aspects needs to be looked at before selecting a software repository for your project.
Distributed vs Centralized Version control systems like Git offers a much different type of version control in that it’s a distributed version control system. With a distributed version control system, there isn’t one centralized code base to pull the code from. Different branches hold different parts of the code. These systems do not necessarily rely on a central server to store all the versions of a project’s files. Instead, every developer “clones” a copy of a repository and has the full history of the project on their own hard drive. This copy (or “clone”) has all of the metadata of the original. Other version control systems, such as SVN and CVS, use centralized version control, meaning that only one master copy of the software is used.When you’re working with a centralized verison control system, your workflow for adding a new feature or fixing a bug in your project will usually look something like this:
- Pull down any changes other people have made from the central server.
- Make your changes, and make sure they work properly.
- Commit your changes to the central server, so other programmers can see them. Important Terms
- Repository The collection of files that make up your project (with or without version control) plus the database maintained by your VCS
- Working Directory Without version control your working directory is your project folder (and any sub-folders). With distributed version control it’s the same only you have the ability to update your working directory to whatever version of your code you want to work on very quickly and very easily.
- Change set All of the changes that represent the difference between a commit and the prior commit (two versions of your project). Say you make some changes to one of the files in a project and then commit that change, the change set is the difference between the commit you just made and the prior one, i.e. the changes you made to that one file.
- Branch & Tip A branch essentially takes a single version of your code and creates two copies of it. You can then change those two copies independently of each other, changes to one do not affect the other.
- Change Set All of the changes that represent the difference between a commit and the prior commit (two versions of your project). Say you make some changes to one of the files in a project and then commit that change, the change set is the difference between the commit you just made and the prior one, i.e. the changes you made to that one file.
- Merge Most of the source control systems, you can branch your code, so different teams work on it separately. Each team can have its own branch of the code to work on independently. For example above diagram depicts two branches and two merges.
Merging occurs when you want to bring the work back together. Since the work has been done independently on different branches, some code files (and other changes) may have occurred in some of the same files. A merge conflict may occur as it might not be clear how to put together a file from different branches correctly – this normally requires manual intervention and is what most coders refer to when talking about “merge hell”. Few VCS to look at before choosing a VCS