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!)”

Software Development: Getting Started by Getting Organized

A few weeks ago I wrote up the post on the tech I’ve decided to move forward with for my new project. This post is going to cover the collection of features, domain details (i.e. what is the use case, etc), and related project collateral. Instead of just slinging code like many of us programmers often do, I’m going to layout what I’m trying to build, what features I want, and how I’m going to put those features together before delving into actual code. This way, my hope is I’ll be able to keep track over time better, and if any of this turns into something I’ll then have something to keep working from instead of throwing a code base over the fence to other devs. A crazy action that happens all the time, but is something worth avoiding!

Continue reading “Software Development: Getting Started by Getting Organized”

Using Multiple SSH Keys for Multiple Github Account

FIRST – Setup the Keys

If there is already a key, I can use this one to start with, but if there is no key to start with I’ll need to generate one. I can do this with the following command:

ssh-keygen -t rsa

When generating the keys, best to go with the default location, which is ~/.ssh/id_rsa. This will create two files, id_rsa and id_rsa.pub. The id_rsa file is the private key, and the id_rsa.pub file is the public key. The private key should be kept secret, and the public key can be shared with anyone.

For the next account, which I’ll just call the work account, I’ll generate another new key. This time I’ll hand off the following parameters to the key generation to provide the work account email and the file name:

ssh-keygen -t rsa -C "adron.account@work_mail.com" -f "work_account_one"

I’ve now got two keys, one for my personal account and one for my work account.

~/.ssh/id_rsa

~/.ssh/work_account_one

I’ll need to add these to the ssh-agent and the respect Github (or git whatever servers) so that I can use them.

SECOND – Add the Keys to Github

Adding the keys to Github. We’ll start with the personal account and then add the work account. Copy the public key using pbcopy < ~/.ssh/id_rsa.pub. With that copied log into the Github account that this key should be associated with.

1. Got to *settings*.
2. Select *SSH and GPG keys* from the account user menu.
3. Navigate into `New SSH Key`, give it a title, and paste the key into the key field.
4. Click *Add SSH Key*.

Now log out of that Github account and into the other account, the work account. Repeat the steps above, but this time use the work account email and the work account key.

THIRD

Register the new keys with ssh-agent. Start by checking that the ssh-agent is running with eval "$(ssh-agent -s)". In the past we would add the keys to the agent with ssh-add -K ~/.ssh/id_rsa and ssh-add -K ~/.ssh/work_account_one. Now the keys are registered with the agent with the following.

ssh-add --apple-use-keychain ~/.ssh/id_rsa
ssh-add --apple-use-keychain ~/.ssh/work_account_one

FOURTH

There is one last step, I need to tell the ssh client which key to use for which account. I can do this by adding the following to the ~/.ssh/config file.

# Account 1 - Primary
Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa
  AddKeysToAgent yes
  UseKeychain yes

# Account 2 - Second Account
Host github.com-work_user_account_name
  HostName github.com
  User git
  IdentityFile ~/.ssh/work_account_one
  AddKeysToAgent yes
  UseKeychain yes

Note that work_user_account_name is the name of the work account, not the email address. I can now use the following commands to clone repositories from the respective accounts. This tells ssh-agent to use the id_rsa key for Git URLs starting with github.com and the work_account_one key for Git URLs starting with github-work_user_account_name.

FIFTH

One active SSH key per working session.

This is a good practice to follow. I can use the following command to start the ssh-agent and add the key to it.

eval "$(ssh-agent -s) ssh-add -K ~/.ssh/id_rsa ssh-add ~/.ssh/id_rsa

The same can then be done when the other key needs to be used.

Update 1 – I’ll be teaching the Code Fellows Bootcamp and Unix & Git for Everyone

In the coming month there are three courses I’ll be teaching here in the grand city of Portland, Oregon. Two of the courses are one day Unix & Git for Everyone (Jan 31 and Feb 28)  courses and the big course is the Computer Science & Web Development Bootcamp (Feb 2 – Feb 27). So if you’re interested in ramping up and becoming a software developer sooner than later, check out the courses and more on the Code Fellows Site, follow the PDX Code Fellows Twitter or Code Fellows Twitter, and like the Facebook Page.

I’ll have more information about teach, training, mentoring and other projects I have on the cooker over the course of today.

No excuse not to have your branching strategy taken care of, because: git-flow

First, get it installed. This takes less than a minute, at least on a *nix based machine. I’ve no idea what it takes on Windows, but hey, at least it’s available there too! I did a clean curl and install as shown. It took about 14 seconds solely because I wasn’t typing very fast today.

12:28 $ curl -L -O https://raw.github.com/nvie/gitflow/develop/contrib/gitflow-installer.sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 2145 100 2145 0 0 1732 0 0:00:01 0:00:01 --:--:-- 1732
~
12:28 $ sudo bash gitflow-installer.sh
Password:
### gitflow no-make installer ###
Installing git-flow to /usr/local/bin
Cloning repo from GitHub to gitflow
Cloning into 'gitflow'...
remote: Counting objects: 1407, done.
remote: Total 1407 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1407/1407), 623.29 KiB | 428.00 KiB/s, done.
Resolving deltas: 100% (689/689), done.
Checking connectivity... done.
Updating submodules
Submodule 'shFlags' (git://github.com/nvie/shFlags.git) registered for path 'shFlags'
Cloning into 'shFlags'...
remote: Counting objects: 454, done.
remote: Total 454 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (454/454), 130.91 KiB | 0 bytes/s, done.
Resolving deltas: 100% (337/337), done.
Checking connectivity... done.
Submodule path 'shFlags': checked out '2fb06af13de884e9680f14a00c82e52a67c867f1'
install: gitflow/git-flow -&gt; /usr/local/bin/git-flow
install: gitflow/git-flow-init -&gt; /usr/local/bin/git-flow-init
install: gitflow/git-flow-feature -&gt; /usr/local/bin/git-flow-feature
install: gitflow/git-flow-hotfix -&gt; /usr/local/bin/git-flow-hotfix
install: gitflow/git-flow-release -&gt; /usr/local/bin/git-flow-release
install: gitflow/git-flow-support -&gt; /usr/local/bin/git-flow-support
install: gitflow/git-flow-version -&gt; /usr/local/bin/git-flow-version
install: gitflow/gitflow-common -&gt; /usr/local/bin/gitflow-common
install: gitflow/gitflow-shFlags -&gt; /usr/local/bin/gitflow-shFlags
~

For installation instructions check out the link here: https://github.com/nvie/gitflow/wiki/Installation

Now that everything is setup. Here’s the quick getting started of creating a repo, linking it up to a remote and working in a repository. The first step is to initialize a new repo.

Continue reading “No excuse not to have your branching strategy taken care of, because: git-flow”