Have you ever updated a large number of topics based on a planned new feature, only to later have your product team defer the feature to a later release? Ever performed a global change across a project that didn't produce the desired result (such as forgetting to select Match case in a replacement across hundreds of topics, which now include some lower-case replacements at the beginning of sentences)? Ever worked with a team of writers and discovered that a large portion of content is inexplicably missing, without knowing who removed it or why? These are all situations in which version control can make it easy to resolve otherwise laborious and time-consuming operations within minutes, rather than hours. Some primary benefits of version control are:
- Storing draft changes in separate branches, which you merge for publishing only after they are fully reviewed.
- Easily comparing differences between previous drafts of topic content, and recovering an earlier version when needed.
- Visibility into the full history of a file (to see who made changes, when they were made, and the reasons why).
- Sharing the latest content updates among all members of a team.
- Distributing work across multiple client computers, as well as a remote server, so that no computer is a single point of failure for losing committed content.
Now that you understand the importance of version control, let's take a look at the architecture of the Git version control system, and its configuration options.