In this installment in my series describing a Git workflow for open source collaboration
we'll look at the workflow for developing code to be contributed back to the project (e.g., bug fixes, new features, etc.).
Add a Feature
After reading parts I and II your local repo is all set up and ready to go.
Let's say you want to add a feature to the project. The first step is to create a topic branch for your changes.
A topic branch is not a special type of branch from a technical perspective, it's just a regular Git branch, but I'm going to use that term to refer to a branch that you create
for one specific purpose. It might be to fix a bug or to add a feature. This brings us to our first rule:
Rule #1 - All Changes Should Be Made in a Topic Branch
That's right. Never make changes directly in the develop branch, and never, ever, touch the master branch.
If you want to add a feature you need to create a new topic branch for your feature. Let's call it newFeature and create it
by issuing the command from within the develop branch:
You'll recall from the previous post that the -b option tells Git to create a new branch.
Make some code changes and commit often. Don't worry about creating too many commits as you're going to squash them down before merging them back into the develop branch.
One thing you want to keep on top of, though, is keeping your code up to date with the code in the main repo. If changes happen to code in the main repo you want to get those changes into your topic branch
as soon as possible, to minimize the chances of merge conflicts later. This brings us to the second rule: