Git Workflow for Small Teams

A huge shift happens when your team grows from 2 to 3 people.

The way you communicate will be destroyed because of a very simple reason: communication about a project will no longer be able to take place in the natural human format of a conversation. All of the status, the thinking, all the communication surrounding the actual in-the-trenches work of development will have to move somewhere else.

One of the more interesting areas that took us a while to figure out was how to set up our projects on GitHub. We’ve finally settled into a process that I’m having a hard time poking holes in, so that means its time to share it.

However, there’s a caveat. I think this workflow is only good for when you have 3-10 active developers on a private repo. This is because leads and managers are necessary way to scale responsibility and communication inside an organization, and after you get above 10 people you hit the next communication breakpoint: teams.

I haven’t done that yet, so I have no idea what a good way to do that would be or if this would work.

Git Workflow for our Rails Projects

So a basic git workflow that’s working really really well for us as a team is this:

Basic branch setup

‘master’ is production.

‘staging’ is the safety net between dev and master.

‘dev’ is the branch where everything gets resolved.

That’s pretty standard for a git workflow, and we use it because there is no need to get creative here.

‘dev’ as default branch on Github

We set our ‘dev’ branch to be the default branch in Github, rather than ‘master’. This reduces the need to switch branches in Github – there is rarely a need to look at ‘staging’ or ‘master’ when all the action is going on in ‘dev’ and feature branches. If you’re doing a hotfix and you need to merge it directly into staging, then you have to override the default selection of ‘dev’. While both mistakes are reversible, accidentally merging a hotfix into ‘dev’ will be less painful than accidentally merging a feature branch into ‘master’, especially if you are working with continuous integration tools.

Feature branch naming convention

Finally, we’re partial to naming branches like 001_first_feature, which has some benefits:

  1. The feature branches always appear up top and all next to each other so when you click on the ‘branches’ dropdown you can immediately get a sense of whats being worked on.
  2. Being able to refer to a specific number is actually quite nice because its very explicit and easy to look for ‘007’ as opposed to alphabetically-sorted branch names.
  3. As the numbers go up, you also get a quick sense of how old a feature branch is and how likely there are to be conflicts or problems when you are ready to merge. For example, you’re working on ‘095’ and one of the other developers is doing a PR for a branch prefixed with ‘062’.
  4. Doing stuff this way kind of naturally guides you to doing cohesive, Single responsibility-style pull requests.

So you create an 00x_feature_name branch, work on it, push it up, then pull request. After merging, delete the branch. Need to reopen up a similar vein of functionality and work on it later? Well, time for a new feature branch with a new number.

You’ve been ‘rolled.

Future enhancements?

I’ve also been thinking about a naming convention like feature/001_description, just because it looks nicer. Then you could do all kinds of prefixes like hotfix/001_thing or wild_goose_chase/001_cacaw. There could be some advantage there depending on the nature of a given project.

But we’re leaving that out for now because it is an extra layer of thinking to engage in when you’re doing git co -b 032_wat_branch. It also means several extra moments of processing when you click on the ‘branch’ dropdown. And for what? A bit more nuance about the state of the project that we just haven’t needed yet.

That’s it. Happy hacking! 🙂

Get access to our expertise or simply chat us by tapping on this green thing »