Two golden practices in collaborating with git are:

1. Keep the master branch functional at all times
2. Keep lines of work (branches) separate from each other

Collaboration with git relies on branches. They allow our "golden practices". Let's explore git branches and we'll come back to review why these golden practices are so helpful.

1. Define what a git branch is
2. Explain branching and committing changes
3. Explain switching branches with git checkout
4. Explain merging branches
5. Preview Merging Remote Branches with git fetch and git pull
6. Explain the motivation of the "golden practices"

A git branch is a means to separate a new set of commits or edits from another branch. Typically we create a new branch off of master. If all developers we collaborate with honor Golden Practice 1, we can trust that master will be a safe starting point.

When we branch, we're creating a separate parallel universe. We can experiment there without any bad effect. It's a contained sandbox where mistakes can be made or ideas can incubate.

It's an idea that a lot of fiction has presented in the last 50 years.

If you understand multiple-timeline fiction, you get the idea of branches.

By doing work in branches, all collaborators can do work without messing with the main line known as master. OK, so how can we actually leverage this reality-shattering idea?

Best practices suggest that any new set of changes related to fixing a bug, creating a feature, or even messing around with experimental code in a "sandbox", should be started on a new branch.

In order to start a new branch, in the terminal type: git branch <branch name> to create the newly defined branch.

This creates a new branch which can be seen in the branch list by typing git branch in the terminal.

In the case of a branch relating to writing a new feature, you could name the branch add-rainbow-background. Thus: git branch add-rainbow-background. This will take the entire commit history of the branch you're on (usually master) and make it the same history as on the add-rainbow-background branch.

At this moment master and add-rainbow-background are the same branches / realities etc. As you add more commits on the feature branch you're changing only the add-rainbow-background reality. The master branch will not be changed. Let's talk about adding those commits.

In order to start making changes on your new branch, you need to "check it out." After checking a branch out, your commits will be added to that branch's history. You move between branches with git checkout <branch name>.

PROTIP: You can create and checkout a new branch in one command using: git checkout -b new-branch-name. That will both create the branch new-branch-name and move into it by checking it out.

If you are currently on add-rainbow-background, you can move back to master with git checkout master. You can also type git checkout - in order to move back to the previous branch.

When you add commits to a branch, you can see the history of the commits by typing git log --graph. The git log command displays the history of commits for the branch you're on. The --graph "flag" tells git to make it pretty, like a timeline. You can use "Space" to page down the history of commits. Use q to exit.

To make sure that you don't lose work, you should make sure all your changes are committed before you switch branches. If you're doing work in add-rainbow-background that updates style.css, because master also has a style.css file, master could overwrite your changes. Make sure all your changes are committed before you switch branches.

ADVANCED: git has a powerful feature called stash which can be used, when you're ready to hold changes-in-progress. When you're very comfortable with git, look into it!

If we then git checkout master, and use git log --graph again, we will see that the master branch only has the code up to the moment you "branched" into the add-rainbow-background timeline, er, branch.

The code from our add-rainbow-background is tucked away in that branch, waiting patiently in isolation from the rest of your code in master until the feature is considered complete.

The final step of completing the add-rainbow-background work is to merge that branch into the master branch.

Now that you have some additions to the code that you'd like to combine back with the master, the goal is to bring the branch of commits that occurred on the add-rainbow-background branch into the master. By merging the branch, master will have all of the commits from the add-rainbow-background branch as though those events occurred on the master branch.

When merging a branch with git merge, it's important to be currently working on your target branch, the branch you want to gain the content of the feature branch. The first step for our add-rainbow-background merge is to checkout master because that is where you want the commits to end up.

When performing git merge -m "merge in feature add rainbow-background" you add a message and complete the commit in one action.

Now the branches have been merged. If you type git log --graph, you'll see the commits from the add-rainbow-background branch on your master branch.

When you're done with a branch that's been merged you can delete it with: git branch -d branch-to-delete.

Your local branches can merge in changes from remote repositories branches just like they can do for local branches!

To update a list of available branches at a remote we use: git fetch remote-name.

As a shorthand to fetch and then automatically merge the same-named branch from the remote we can issue git fetch remote-name branch-name-to-merge-in.

These are complex topics as it brings up the issue of how to reconcile lines of code where you and another developer might have changed the same thing. This is called a "merge conflict." We're not going to cover that topic here. Instead we want you to embrace working in branches, keeping master functional, and doing local merges. To give you a preview of what merging a remote branch workflow looks like:

$ git fetch origin
$ git checkout add-rainbow-background
$ git merge origin/laurens-rainbow-idea

And now our local add-rainbow-background has Lauren's ideas woven into it.

As developers we try to make sure that everyone has a clean place to start from: be that for writing a new feature or fixing a bug. Branching lets us keep master working at all times. If an emergency bug comes up, we know we have a solid foundation to build from. Feature branches also help us look at git log and see what the intention of a feature was.

Git is a complex tool, and these tools are just scratching the surface for collaborating with people. These workflows are just being introduced to you--and it may be challenging for the time being. You'll have lots of time to practice them and get used to what each command does. Don't try to cram it all in at once; instead just start to get an understanding of what is at your disposal.

Do not do as stick man suggests!

View Git Collaboration on Learn.co and start learning to code for free.