You reach a point in your software development where the next step is kind of experimental. It is a major addition or change to what you have, but you are not necessarily clear on what path to take. At the same time the change is big enough to make it hard to undo if your work shows that it has to be done differently.

Another scenario would be that you have developed your software and released it to the users. You need to be able to maintain it, but at the same time you are already planning the next version with some changes and additions.

In both scenarios you need to have two different versions of your software live simultanously. The gift from Git in both situations: branches.

Branches are powerful in Git. Direct Git to one branch, make major changes to some file, save it. Then go back to the previous branch, look at the file, and it looks as if the code never changed. If you look at your filesystem, there is only one file. Now, how does that come about?

When you create a branch in Git, you create, in your repo, a new manifestation of the master you already have. With a Git command you direct the file systems attention to one of them, and to the file system this appears to be the only version. If you open a file from the current branch in your editor, the file has some code in it. Then you close the editor, make Git switch to the other, or another, branch. Reopen the editor seemingly with the same file, but the content is totally different. This is the magic of Git. Very powerful magic. Now we shall see the mechanics of that.

My tutorial is on http://wetware.work, at this link: http://wetware.work/prez/introducinggit/ as you might recall. Today skip to slide 43, we will work from there through the end of the slide series.