- [Instructor] Welcome back. In this lecture, we'll review version control and why it underpins and supports other DevOps related practices. 

A version control system is used to manage source code and the changes that occur within source code over the course of time. Version control software maintains a history of change and modification for every tracked file in a specialized database. A version control system is a fundamental component of a functioning DevOps build pipeline. In fact, it is the first service you should have in place. Without a modern version control system in place, software development in enterprise teams will be problematic, to say the very least. To ensure that everybody within the development team can code independently and in a manner where each and everyone's code is predicted and manageable, than a version control system has to be used. As we will see in the coming slides, a version control system provides features to manage conflicts on the same file. That is, to be able to detect and merge coding changes that have occurred in the same file by different team units. This is a key point regarding version control systems. That anyone on the team can edit and change the same file at the same time and then later on leverage the version control system to manage and merge the changes. 

A version control system is absolutely mandatory. Git and git-based tools are, without doubt, the most popular for version control as per market share reports. The fact that git, by it's very nature is a distributed version control system, promotes collaboration amongst the development team. Two other decisions should be considered. The first being where to store your repositories. On prime, this is online. And secondly, what workflow to adopt. Consult the wider team to ensure the right choices are made. 

The benefits of using a version control system are numerous. Let's cover off a few of them. Productivity and collaboration. Different developers can work on the same file at the same time, later merging their changes within the version control system. This ensures that no one file becomes a bottleneck in the overall development project. Auditability. Co-changes can be tracked and traced back to developers to understand who made what change and when. Additionally, changes within the version control system can be cross-referenced and connected in to other project management tools, and or issue tracking applications. Versioning. Every file that has been checked into the version control system has a complete long-term history of change, regardless of which developer made the change. Versioning tracks not just the code changes, but includes creation and deletion of files, and tracks metadata about the change, such as the date when the change was committed back to the version control system. Differencing. Different versions of the same source code file can be examined to determine and observe what differences exist. Branching and merging allows you to maintain independent streams of development effort for all files within a given repository. This is useful for when developers build new features independently. They touch many and multiple same files. Backups. By virtue of using a distributed version control system such as git, you have the same source code distributed amongst each team member, which in a way provides you with a method to recover all source code, should either the central repository become broken, or any individual's local copy of the same repository become broken. 

Although, in most cases the argument and associated benefits for adopting a version control system are to be accepted, there are a few challenges that sometimes exist and are worth mentioning. Complexity. If you're adopting a distributed version control system, such as Git, it can be difficult for first-time users to understand the concepts and how the code is pushed and pulled between distributed copies of the same repository. Performance. Performance tends to drop as the project size increases over time. Binary files. Support for binary files can sometimes be problematic. Version control systems are generally not great at dealing with binary assets true in nature to the relative size of a binary file when compared to a typical source code file. 

Considering that the overwhelming majority of software projects are managed and maintained using git, the following git-based version control products are available. GitLab is a web-based git repository manager with wiki and issue tracking features, using an open source license developed and provided by GitLab. GitHub, also a web-based hosting service for version control using git. Recently acquired by Microsoft. Bitbucket, again another web-based version control repository hosting service. Owned and provided by Atlassian. Note Bitbucket also supports Mercurial. 

Other nongit-based version control to consider are Subversion, a software versioning and revision control system, distributed as open source under the Apache license. Team Foundation Server or TFS is a Microsoft product that provides source code management and also supports git. Helix VCS by Perforce is a versioning control engine for large scale development environments. And Mercurial is a free distributed source control management tool. 

When it comes to working with a version control system, many of its features should be used to manage and maintain source code in a collaborative manner. For example, branching and merging. Knowing when to branch and how often to branch and then again when to merge is really down to the characteristics of both the team and the software project being worked on. However, one thing is for sure. The bigger the team and or project, the harder it becomes to manage all assets, as the concurrency of the development increases. Problems with code conflicts become more frequent, resulting in time lapses for project completion. In this section, we'll examine several workflows that are commonly used when working with a git-based version control system. We'll give you a basic introduction for each style of workflow. Remember, no one workflow is correct. Each has its advantages and disadvantages, and regardless of the workflows we describe here, you can always come up with your own, with it based on a variation or entirely new. 

The basic workflow, as the name suggests, is the simplest workflow to understand, but provides very limited options. This workflow is particularly popular with developers who are new to git. It is a good starting point to gain familiarity with the system. A central repository is created, from which each developer then clones from. Developers edit local versions of the code base, and commence the changes back to the local repository. Finally, all local changes are pushed back to the central repository, from which other team members can later pull and upload into their cloned version of the same repository. 

The next logical evolution from the basic workflow is the feature branch workflow. The challenges I showed you with the basic workflow approach is that it's simple to track changes that are being made on mutually exclusive sets of files. This is not often the case in the real world of software development. Often, projects require different developers to work on different features for the same project. Each independent feature may touch many common files. Features also tend to want to have their own independent timelines. For example, feature one may have been completed and be ready to be released into production. Feature one shouldn't be impacted by the readiness of feature two. To address this problem, the feature branch workflow, as the name suggests, utilizes branching. Branching allows you to run independent streams of the code base. In this case, one per feature. That is, each new feature gets allocated its own feature branch. The developer or developers assigned to work on a particular feature work within the allocated branch. Once the feature is completed and tested, the feature branch is merged back into the master branch for release into production. Finally, the feature branch in question can be deleted. 

Gitflow is a workflow created and documented by Vincent Driessen in 2010. Gitflow is great for large software projects. Using a branching strategy that accommodates releases, features, and hotfixes. At its core, the workflow utilizes two parallel and long-running branches, master and develop. The master branch is considered the main branch. With a source of hid always reflects a production ready state. The develop branch is where the feature branches are merged into and where integration tests are performed. After all integration tests pass, the develop branch is then merged into the master. Supporting the main branches, master and develop are additional branches for features, releases and hotfixes. These additional branches are employed to support the following requirements. Concurrent development within a team, support tracking of features, prepare for production releases, and quickly fixing live production problems. Each supporting branch has a specific purpose within the overall workflow, and are governed by rules as to where they are branched from, and to where they are merged back into. 

The forking workflow is based on the process of forking an entire repository. This type of workflow is most commonly used with open source projects, such as those hosted on GitHub. The main driver behind forking is that when a developer wants to contribute a new feature, or change an existing piece of functionality, they do so within their own fork of the repository, meaning they don't need to miss of the official repository. When a developer completes the changes within their own copy, they raise a pull request and submit to the owner of the official repository, who in turn can either accept or deny the pull request. Forking is similar in essence to feature branching. Where forking maps to branching, and a pull request maps to a merge. Assuming git is the version control system of choice, as it probably should be, spend time evaluating and choosing the best git workflow that will support the way you build and maintain your software applications. 

Okay, that completes this lecture on version control. Go ahead and close this lecture, and we'll see you shortly in the next one.