Read more

Recommended Git workflow for feature branches

Tobias Kraze
September 29, 2015Software engineer at makandra GmbH

This is a guide on how to effectively use Git when working on a feature branch. It is designed to get out of your way as much as possible while you work, and ensure you end up with clean commits in the end.

Illustration web development

Do you need DevOps-experts?

Your development team has a full backlog? No time for infrastructure architecture? Our DevOps team is ready to support you!

  • We build reliable cloud solutions with Infrastructure as code
  • We are experts in security, Linux and databases
  • We support your dev team to perform
Read more Show archive.org snapshot

We assume you are the only person working on this branch. We also assume the branch has never been "partially" merged into master.

You want to start a feature branch

git checkout master
git checkout -b my-feature-branch
git push -u origin my-feature-branch

You've added code that works independently of your other changes

Turn this code into its own commit by reviewing changes one by one.

You've added code that will be part of something bigger

You should still commit this once in a while, if only to have a backup and some kind of history.

Simply turn your code into a WIP ("work in progress") commit.

git add -A
git commit -m 'WIP'

Do this and push at least once a day, using git push.

Master has changed

Bring your code up to date with the current master:

git fetch origin master:master
git rebase master
git push -f

If there are conflicts, fix them and continue using git rebase --continue. Note that conflicts are "reversed" compared to merging, i.e. master is the base, and your commits are the changes.

Never use merge.

You've found some code that belongs to an earlier commit in your feature branch

If you already have a "final" (i.e. non-WIP) commit in your branch, and you later realize you've forgot to add some code to it:

Turn the missing code into its own commit, using

git add -p
git commit -m 'fixup'

Review changes as above. WIP-commit (or stash) all other changes.

Do a

git rebase -i master

Move the fixup directly below the commit it belongs to. Change the "pick" in front of the fixup commit to "f". Don't touch any other lines. Save.

You can also use git fixup.

You're done and want to merge to master

First follow the "master has changed" steps above.

However, if you have a mixture of WIP and final commits, don't do a simple rebase, instead do

git rebase -i master

Now reorder your commits by moving all final commits to the top. Save the file. If you get conflicts, you can fix them. Usually this is an indicator, that your commits perhaps should not be separate commits in the first place.

Now use the git add -p method and review your changes as above. If you have changes that work independently of one another, you may turn them into separate commits. Don't force this, turning everything into a bigger commit is usually fine.

Now do

git checkout master
git merge - # - refers to the previous branch, which is $feature-branch
git branch -d $feature-branch
git push origin -d $feature-branch
git push

The merge should always be a "fast forward", otherwise you have not rebased properly.

You can also configure a Git hook that will interactively delete the feature branch.

Your feature branch depends on another feature branch which has been squashed since

Git: rebase dependent feature branch after squash

Tobias Kraze
September 29, 2015Software engineer at makandra GmbH
Posted by Tobias Kraze to makandra dev (2015-09-29 17:31)