A Simple Git Branching Strategy for a Small Team (Because We All Know Git Is Fun!)

Git. It’s the tool that makes some of us developers wonder why they didn’t become a carpenter. But let’s face it: Git is here to stay. And for a small team—like, say, 3-4 developers working on the same codebase—getting your branching strategy right can be the difference between smooth sailing and a storm of merge conflicts that will make you question every decision you’ve ever made in life.

So let’s dive into a “simple” strategy for keeping Git under control. No complex workflows, no corporate jargon—just a few solid, time-tested practices to keep you from drowning in source control hell. Because seriously, git is actually super easy and a thousand times better than all the garbage attempts at source control that came before.

The Core Branches (Yes, There Are Only Two You Really Need)

If you’re working on a small team, you don’t need to be fancy. Forget about multiple branches for every single thing under the sun—just stick with main and feature branches. That’s it. Keep it simple. We don’t need a thousand different integration branches or some mythical release branch. Keep it neat.

  • main: This is your production-ready code. The one branch that should always work, always deployable, and always sacred. No exceptions.
  • Feature branches: These are where the magic happens. New features, bug fixes, the stuff that makes your app worth using. Each feature gets its own branch. Think of it like a sandbox—do whatever you want there, but don’t drag your mess into main.

Example 1: The Plain Old Feature Branch (The Easy Way)

Continue reading “A Simple Git Branching Strategy for a Small Team (Because We All Know Git Is Fun!)”

Git Updates

Here’s my latest Git Ignore file for .NET Development.

#Begin .ignore file
#OS junk files
[Tt]humbs.db
*.DS_Store

#Visual Studio files
*.[Oo]bj
*.dat
*.crc
*.exe
*.pdb
*.user
*.aps
*.pch
*.vspscc
*.vssscc
*_i.c
*_p.c
*.ncb
*.suo
*.tlb
*.tlh
*.bak
*.[Cc]ache
*.ilk
*.log
*.lib
*.sbr
*.sdf
ipch/
obj/
[Bb]in
[Dd]ebug*/
[Rr]elease*/
Ankh.NoLoad

#Tooling
_ReSharper*/
*.resharper
[Tt]est[Rr]esult*

#Project files
[Bb]uild/

#Subversion files
.svn

# Office Temp Files
~$*

#End .ignore file

I added a starting Git workflow on my domain here: http://www.adronbhall.com/Home/GitWorkflow

Getting Git

I’ve been stumbling through getting familiar with Git over the last couple of weeks.  It’s the source repository we use at work (thank goodness I’m rid of the damnable TFS nonsense!) and I have officially moved all of my Subversion & even Mercurial Repositories to Git.  I really enjoy using Unfuddle, so have moved back to that after using Repositoryhosting for a while.  The reason boils down to Open ID.  Repositoryhosting didn’t support Open ID and Unfuddle does.  Repositoryhosting supported Mercurial which I’ll admit is awesome.  I really enjoyed that but wanted the combination of Git experience + Open Id that I get with Unfuddle.  In addition, I actually like their management and project tools better.  So back I’ve come to Unfuddle.

Over the next few weeks I’ll probably be posting a few tidbits about Git.  For this entry here’s a tidbit on ignoring certain files that don’t need committed or pushed into the repository.  Based on that this is what my exclude file looks like.

  • Resharper
  • obj
  • bin
  • *.suo
  • *.user
  • *.vs10x

For more information on setting files to ignore, check out the github man page.

UPDATE (1/5/2011):  New post & updated file in this post.