Git has been around for a long time, and is a well-established source control tool with astonishing popularity. Take the current survey by Stack Overflow, a popular portal for professional and amateur developers, as an example (image source: https://insights.stackoverflow.com/survey/2018):

With nearly 90% of all developers out of roughly 75,000 participants choosing Git as their version control system, it is safe to assume that Git is a great tool. To further decrease the amount of people answering I don't use version control, we would like to demonstrate what Git can do for you.

We already saw the basics of working with Git in Chapter 4, Advanced Coding Techniques, and if you have followed the examples so far, you already have Git installed. In a CI/CD pipeline, Git is an essential component. Your code commits will, depending on the branch you are on, lead to publishing your modules or DSC configurations to the QA or production environment.

Many, if not all, of the CI tools that are available can hook into Git repositories, whether in the cloud or on-premises, and base their actions on code commits.

In order to fully benefit from Git, your team and your contributors will need to agree on some kind of workflow. This is a collaborative effort—the workflow you agree on should enable you to produce code faster, more securely, and for different environments, without unnecessary overhead.

The following criteria can be used to determine the usefulness of a workflow:

• Is it easy to recover from errors with it?
• Can it scale as your team grows, or will it become a hindrance?
• Will it add unnecessary overhead?
• Is it easy to apply and learn?

There are two main approaches that you can take here—a centralized workflow with one central repository that uses only the master branch, later extended with feature branches, or a forking workflow with decentralized repositories.