This is the second quick guide I wrote for the devs at work. Here, I cover the simple stuff about branching with Git. The idea of a branch is to provide separation between experimentation and production code. You’ve already seen that the main branch Git uses is called the
Your workflow should look something like this:
- Write code and commit to a feature branch. While it is possible to push those branches to a remote SCM host (like Bitbucket), it's not a good idea. The remote should only have production-ready code.
- When you have tested your code and the feature is complete, you would then merge your branch with master and push it.
- It might be that you are working on several branches at once, but the procedure is the same. Only merge on to the master branch when you have tested your code and are happy it is production-ready.
To create a new branch from the command line:
git branch my-new-feature
Git will not switch you to the new branch. You have to do that yourself with:
git checkout my-new-feature
It is possible to create a new branch and check it out all in one go:
git checkout -b my-new-feature
If you want a branch to be tracked by the remote SCM (as I said, generally we won’t but you never know… ):
git branch –track my-new-feature
You can see what branches you have like this:
That’ll show you all your local branches. If you add
-r you’ll be shown only the remote branches. Adding
-a will show you all the branches.
A useful trick is to be able to see which branches have been merged into your current branch. You do this:
git branch --merged
And for completeness, here’s how you see branches that have not been merged:
git branch --no-merged
That’s the basics of branching with Git. In the next post, I’ll cover some of the more advanced functionality.