You are probably using Git already. If not, you really should. You need to have it installed for working with Bower anyway, so why not use it for your own projects?. Git is a distributed Version Control System (VCS). I cannot imagine working without it, neither in a team nor when working on a project myself. We don't have the space to cover Git for team development here in either case; this topic can easily fill an entire book. However, if you are working in a team that uses Git, you will probably know how to use it already. What we can do in this introductory chapter is go through the basics for a single developer.

First, you need to install Git if you do not have it on your system yet.

# brew install git

# sudo apt-get install git

Let's initialize a fresh repository in the current directory:

git init

Then, we create a hidden file named .gitignore, for now with only the following content:

node_modules

Next, we add all files in the current directory (and in all subdirectories):

git add 

Next, we freeze the file system in its current state:

git commit –m "initial commit"

Now, we can edit any file, try things out, and accidentally break things without having to worry because we can always come back to anything that was committed into the VCS. This adds incredible peace of mind when you are playing around with the code.

When you issue the git status command, you will notice that we are on a branch called master. A project can have multiple branches at the same time; these are really useful when working on a new feature. We should always keep master as the latest stable version; additional features (or bug fixes) should always be worked upon in a separate branch. Let's create a new feature branch called additional-feature:

git branch additional-feature

Once it is created, we need to check out the branch:

git checkout additional-feature

Now, when the new code is ready to be committed, the process is the same as before:

git add .
git commit –m "additional feature added"

We should commit early and often; this habit will make it much easier to undo previous changes when things go wrong. Now, when everything is working in the new branch (all the tests pass), we can go back into the master branch:

git checkout master

Then, we can merge the changes back into the master branch:

git merge additional-feature

Being able to freely change between branches, for example, makes it very easy to go back to the master branch from whatever you are working on and do a quick bug fix (in a specialized branch, ideally) without having to think about what you just broke with the current changes in the new feature branch. Please don't forget to commit before you switch the branch though. You can merge the bug fix in this example back into the master, go back to the feature branch you were working on, and even pull those changes that were just done in the master branch into the branch you are working on. For this, when you are inside the feature branch, merge the changes:

git merge master

If these changes were in different areas of your files, this should run without any difficulties. If they were in the same lines, you will need to manually resolve the conflicts.