November 2016

Wednesday, November 9, 2016

Be the Change

Donald Trump will be the next president of the United States. #

There will be a lot of negativity in the coming days. A lot of finger pointing, name calling, blaming and possibly violence. Please don’t participate in the negativity. #

When people succeed they tend to party but when they fail they tend to ponder. #

Tony Robbins #

This is an opportunity to listen to each other. A large part of our country spoke last night. They are tired of being ignored, they are in pain. They want what all of us want. To be loved and to provide for themselves and their families. #

They feel that Donald Trump is the best chance they have to change a system that they feel is hurting them. A system that is hurting their families and communities. #

As a nation, we now have the opportunity to listen to each other. To understand each other and do the best we can to move forward and make this country great for all of us. #

If you’re like me and are scared about what this election means for our families and communities. If you’re scared of what it means for people of color, for women, for LGBTQ people, for Muslims and Jews. Take comfort in all the good in the world. #

I think that many Trump supporters are kind, caring, thoughtful people. They are not the racist, misogynistic monsters portrayed by the news. #

Don’t ask why is this happening to us. But what opportunities does this present for us all to be the change we want in the world? #

When I was a boy and I would see scary things in the news, my mother would say to me, “Look for the helpers. You will always find people who are helping.” #

Fred Rogers #

Do not shut out your friends, family or neighbors who voted differently than you yesterday. Listen. Don’t lecture or try to convince. Just listen. We are more common than different. #

Friday, November 4, 2016

What is the best git branching strategy for small teams?

In my development, I use Git all the time. It was a little tricky to figure out at first but, I feel like I have a good understanding of how to use it. #

When I’ve worked with other developers I see them struggling with a few concepts that I use regularly and thought it might be helpful to document my workflow. #

On our team, we use feature branches and pull requests. I don’t have a strong preference of whether the feature branch is in our main repo or in a developers fork of our repo. For this post, I’ll assume feature branches are in the main repo. #

Let’s start with the following master branch. #

master A-B-C

I’m going to work on a new feature so I create a new branch off of master and start committing my changes. #

master  A-B-C
feature      \_F1-F2

During that time, other developers merged in features. #

master  A-B-C-D-E
feature      \_F1-F2

I’m ready to submit my PR, but first I need to rebase off of master, potentially resolving conflicts that emerge. #

master  A-B-C-D-E
feature          \_F1-F2

I need to make changes based on a code review, so I commit those to my repo. Meanwhile, other features are merged into master. #

master  A-B-C-D-E-F-G
feature          \_F1-F2-F3

Before I have my new changes reviewed I once again need to rebase off of master. #

master  A-B-C-D-E-F-G
feature              \_F1-F2-F3

To push up to the main repo I need to do a force push because I’m overwriting what was previously there. #

git push -f origin feature

My PR is accepted, so it’s squashed and merged into master as H (via GitHub), the feature branch is deleted. #

master  A-B-C-D-E-F-G-H

Once something is merged into master it’s locked. Other than specific edge cases, you shouldn’t ever have to force push to master, only to feature branches. #

With our main SaaS applications I also use Git to deploy to staging and production. I wouldn’t use this for library development or any applications that have multiple deployments. #

I have special branches staging and production which our continuous integration platform watch. When I push changes into those branches they are tested (as with all pushes) and if tests pass, they are deployed to that environment. #

So if we wanted to deploy my latest feature, I’d merge it into staging and have our team review it to determine if there are any issues that need to be resolved before deploying to production. #

git checkout staging
git merge master
git push origin staging

If there are changes we create a new feature branch and start at the top of this workflow. #

If there are no changes to be made then we merge into production, it’s tested and deployed. #

git checkout production
git merge staging
git push origin production

That’s it! Developers I’ve worked with tend to get hung up on rebasing. I know some workflows never rebase and always merge, but I strongly prefer keeping things clean with rebasing. #

I know that there are a million ways to use Git and different teams have different workflows. What do you think of my process? Anything you’d change? #

Published by Andrew Shell on and last updated .