Posted over 3 years ago. Visible to the public. Repeats.

Recommended git workflow for feature branches

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.

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

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'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 - git branch -d <your branch name> git push origin :<your branch name> git push

The merge should always be a "fast forward", otherwise you did not rebase properly.

Does your version of Ruby on Rails still receive security updates?
Rails LTS provides security patches for old versions of Ruby on Rails (3.2 and 2.3).

Owner of this card:

Tobias Kraze
Last edit:
almost 2 years ago
by Emanuel De
About this deck:
We are makandra and do test-driven, agile Ruby on Rails software development.
License for source code
Posted by Tobias Kraze to makandra dev
This website uses cookies to improve usability and analyze traffic.
Accept or learn more