undeniablyrob

Say we’re building two features:

1. A checkout process.
2. Support promo codes while checking out.

We’ve finished building our checkout functionality. We wrap up our branch and sent the pull request through our review/testing process. In the meantime, we’re ready to start our second feature.

Since we need the checkout code in order to add promo codes to a checkout process, we can’t create a new branch off of master. But adding to our existing branch will cause headaches for reviewing, testing, and releasing the first feature. We could hold off on sending that first branch out and wait until both features are done. But that’s depriving our customers of the first feature. Git makes this easy for us, although it’s not so obvious how at first.

In Git, we have two options. Both have the same effect, so which one you choose is really a matter of personal preference. We can either:

1. Create a new branch off of our first branch.
   (master) $ git checkout -b my-checkout-branch
(my-checkout-branch) $ git checkout -b my-promo-code-branch
2. Create a new branch off of master, and then pull in the changes from our first branch.
   (master) $ git checkout -b my-promo-code-branch
(my-promo-code-branch) $ git checkout -b my-checkout-branch

ProTip #1: Be sure to sync any changes in your first branch to the second. i.e., if you make a change to the checkout process, pull that into your promo codes branch.

ProTip #2: Don’t start a third branch. Save yourself the headaches. The real value in the Git world is small, iterative branches that are merged quickly.