When I work on code, I prefer working from a branch, especially if it’s on a project that I’m working on with a team.

If your team does all programming as a pair, you might be developing right on master. Since there are two of you working together, you’ve got peer-review happening as you write the code. You’ve already got the opinions of two people worked into the code that’s written.

But if you’re working on your stories as individuals, branching can be really important. My teams use GitHub as our repository host, which provides us with a lot of fantastic tools. Here’s the process I go through for each story I pick up.

In PivotalTracker, I “start” my story. A story is a feature, bug, or chore that needs to be done in order to continue moving the project forward.

Then in my command line, I open up my repository and make sure I have all of the newest changes on master.

git checkout master
git pull

Once I’ve made sure I have the newest changes that are in production, I create my new branch from master. Some teams will name the branch based on what type of story it is (“ft-StoryName” for a feature or “bg-StoryName” for a bug) and other teams might include the developer’s initials (“amm-StoryName” for a story that I’m working on).

git checkout -b ft-NewNavigationIcons

This creates my new branch and switches me to it so that I’m now working on it.

From here I can do all the development I need to do, and push up my changes to our repository host as I go. I try to make sure I push up all of my most recent completed changes when I log off for the day, or if I’m going to be away from my machine for a few hours. This way I don’t have any confusing changes to reacquaint myself with when I get back, my code is available for me no matter what machine I sit down in front of to code on, and if someone else from my team needs to pick up where I left off, it’s available.

Don’t push up code that’s in the middle of being changed unless you have to; it’ll just be confusing for your teammates.

The first time I push up to a new branch:

git push -u origin ft-NewNavigationIcons

Every time after that, all it takes is:

git push

When my changes are all done and I’ve run all my tests and pushed up all of my commits, I can create a pull request. GitHub makes this really easy. In my pull request description, I’ll link back to the story in PivotalTracker for a reference for the acceptance criteria, describe what I’ve done, and include screenshots that help explain what the change was.

I’ll also tag or assign a team member on the pull request, so that it can get reviewed, approved, and merged.

GitHub makes it really easy to compare the diffs so teammates can see exactly what was changed and easily comment on commits or lines of code. While a pull request is usually intended for when a story is completed and ready to merge in, it can be a helpful place to have a conversation about code that might have you stumped or that you’d like some feedback on before you proceed.

Once at least person has reviewed and approved the code (and your tests that you’ve integrated into GitHub have all passed), all that’s left is clicking “merge” and deleting the merged branch.

From there, our code will run through our pipeline, which runs all builds and tests and pushes the updated application into production. Because we use branching and a rigorous pipeline with tests, we have a lot of safeguards against any problems being pushed into our production environment.