We have worked on various aspects of network automation with Python, Ansible, and many other tools. If you have been following along with the examples, in the first nine chapters of the book, we have used over 150 files containing over 5,300 lines of code. That's pretty good for network engineers who may have been working primarily with the command-line interface! With our new set of scripts and tools, we are now ready to go out and conquer our network tasks, right? Well, not so fast, my fellow network ninjas. 

The first task we face with the code files is how to keep them in a location where they can be retrieved and used by us and others. Ideally, this location would be the only place where the latest version of the file is kept. After the initial release, we might add features and fix bugs in the future, so we would like a way to track these changes and keep the latest ones available for download. If the new changes do not work, we would like to rollback the changes and reflect the differences in the history of the file. This would give us a good idea of the evolution of the code files. 

The second question is the collaboration process between our team members. If we work with other network engineers, we will need to work collectively on the files. The files can be the Python scripts, Ansible Playbook, Jinja2 templates, INI-style configuration files, and many others. The point is any kind of text-based files should be tracked with multiple input that everybody in the team should be able to see. 

The third question is accountability. Once we have a system that allows for multiple inputs and changes, we need to mark these changes with an appropriate track record to reflect the owner of the change. The track record should also include a brief reason for the change so the person reviewing the history can get an understanding of why the change was made. 

These are some of the main challenges a version-control (or source-control) system tries to solve. To be fair, version control can exist in forms other than a dedicated system. For example, if I open up my Microsoft Word program, the file constantly saves itself, and I can go back in time to revisit the changes or rollback to a previous version. The version-control system we are focused on here is standalone software tools with the primary purpose of tracking software changes. 

There is no shortage of different source-control tools in software engineering, both proprietary and open source. Some of the more popular open source version-control systems are CVS, SVN, Mercurial, and Git. In this chapter, we will focus on the source-control system Git, the tool that we have been downloading in many of the .software packages we have used in this book. We will be taking a more in-depth look at the tool. Git is the de facto version-control system for many large, open source projects, including Python and the Linux kernel. 

Before we dive into the working examples of Git, let's take a look at the history and advantages of the Git system.