Up until now, we have worked in a branch named master, which is the default branch when creating a new repository. But what are branches, exactly? One of the strengths of Git is that you can branch from your code to develop features, fix bugs, and so on. Since your initial branch is master, the next new branch will be based off of it. This is usually the development branch, also referred to as dev:

# New branch
git branch develop
git checkout develop

# Develop new stuff
New-Item NewFile2.ps1 -Value 'Restart-Computer'
git add NewFile2.ps1
git commit -m 'Implemented new awesome feature'

This setup enables us to have only productive code in the master and to develop new features in development. We will revisit this model when we talk about the release pipeline, which uses these branches heavily.

There are many opinions on proper branching. Some advocate for Git Flow, and some advocate using only the master branch, and developing features, hotfixes, and releases in separate branches. It is the author's personal preference to use master and develop, to make it easier to release, by merging development into master when enough changes have been done to mandate a release. We base new features off of the development branch while working on them, and later, we merge them back.

When working with Git repositories, we recommend forking the repository that you want to work on. This will entirely recreate the repository for you, and will have a connection to the original repository, called upstream. You can develop new features at your leisure, and later on, you can add them back to the upstream code by filing a pull request.