Feb 162015

I’ve been using Git as my main source control system for a few years now. I’ve finally gotten around to documenting a set of commands that support a github-flow style workflow. A google search for github flow will turn up a wealth of links pro and con for github-flow vs git-flow. I like the simplicity of github-flow and how it better supports continuous delivery and agile methodologies compared to git-flow.

Here are a couple of introductory links to github-flow:


Below are the raw commands I use to support a github-flow workflow. These could be wrapped in aliases or scripts to lessen the typing and insure consistent use across a team.

Git Process description

  • master branch is always buildable and deployable
  • Create local branches off of origin/master
  • Use descriptive names for feature branches
  • Include tracking number at the beginning of the feature branch
  • Push feature branches to remote often
  • Open a pull request at any time
  • Merge from origin/master often
  • Create a pull request before checking into master
  • Rebase feature branch off of origin/master after pull request is OK’ed
  • Merge –squash feature branch onto master
  • Push to origin/master
  • Alternative is rebase -i off of origin/master and push directly to origin HEAD:master
  • Delete old local feature branch
  • Delete old remote feature branch

Goal is to have master branch buildable and deployable at all time. Anything checked into master must be at least reviewed and pass automated testing.

Never create new features directly in master.
Create a feature branch for creating new assets.

Refresh the source branch, usually master, before branching

  • git checkout master
  • git fetch --prune
  • git merge origin/master


  • git checkout master
  • git pull -p

Create a new feature branch to work the issue. Add the feature or issue tracking number to the start of the feature branch name.

  • git checkout master
  • git pull -p
  • git checkout -b TR-0001-new-feature


  • git fetch -p

The following command creates a new feature branch off of origin/master

  • git checkout -b TR-0001-new-feature origin/master

See http://www.lornajane.net/posts/2014/understanding-tracking-branches-in-git for comments on tracking branches. Setting the tracking branch sets the default push/pull tracking branch. We want to use origin/TR-0001-new-feature instead of origin/master as the remote tracking branch.

Investigation indicates the default push schema pushes to the same named remote branch instead of the origin/master. That is if you create a branch off of origin/master

  • git checkout -b TR-0001-new-feature origin/master

and then push that new feature branch to the remote

  • git push origin TR-0001-new-feature

then the default push git push pushes to the same named remote branch.

Looking at http://git-scm.com/docs/git-config the default config for push is simple.

  • git config --global push.default simple

  • git config --global push.default current

The result is that it seems to be ok to branch off of origin/master and then push the new branch to the remote. The result is simple pushes will go to the similarly named remote branch.

Immediately push the feature to github so it is visible to other developers.

  • git push origin TR-0001-new-feature

Create new feature while on feature branch.

  • write code here
  • git add [.][filename]
  • git commit -a -m"commit message here"
  • git commit -m"commit message here" [.][filename]

Merge feature off of master on a regular basis.

  • git fetch --prune
  • git merge origin/master

Push the feature branch to github early and often.

  • git push origin TR-0001-new-feature


  • git push

Build and run automated tests regularly

When you think you are done issue a pull request on github against your pushed feature branch.

When the feature has passed review then squash and commit to master:

First update local master

  • git checkout master

Fetch remote to update origin/master

  • git fetch -p
  • git merge origin/master


  • git pull

Rebase feature branch off of origin/master

  • git checkout TR-0001-new-feature
  • git rebase origin/master

Merge feature onto master

  • git checkout master
  • git merge --squash TR-0001-new-feature

  • git commit -a -m"TR-0001-new-feature

  • git push origin master

As an alternative you can checkout the feature branch, do an interactive rebase off of master to squash all commits and give a single commit message, then push directly to origin/master.

  • git checkout TR-0001-new-feature
  • git fetch --prune to update origin/master
  • git rebase -i origin/master

Pick and Squash as appropriate
Edit commit message as appropriate

  • git push origin HEAD:master

Delete unused branches

  • git branch -D TR-0001-new-feature
  • git push origin --delete TR-0001-new-feature
Feb 032014

I built my 3D printer from a kit a couple years ago. It is a MendelMax style and it came with a modified version of Marlin as the firmware and printrun as the host app.

One of the first things I did after putting everything together was update the firmware to the latest version of Marlin and printrun. That was a couple years ago. New versions of both the printer firmware and host software have come and gone and I’ve largely ignored them. My printer has been working fine and no need to mess with what works.

I’m in the process of building a polar plotter and I’m using my 3D printer more heavily to create many of the parts. After using the printer to print a couple parts, and remembering many of the little irritations that always bothered me, I decided to look around and see what new firmware and host apps are available.

I tried a couple different firmwares but eventually settled back on Marlin. I forked and cloned the latest from ErikZalm, created a branch for my printer mods, updated the Configuration.h, pushed my branch back to my fork, and pushed the changes to my fork. The changes for my printer are pretty minimal but pushing them to github gives me a place to stash them off box and makes them available if anyone else finds them interesting.

I added ErikZalm’s original github repo as an upstream repo so I can continue to fetch and merge his latest changes.

Fork ErikZalm’s Marlin repo into my github – do this on github.

Clone my fork onto my desktop.
git clone https://github.com/bhunting/Marlin.git

Add ErikZalm’s repo as an upstream remote.
git remote add upstream https://github.com/ErikZalm/Marlin.git

Create and checkout a branch for my feature work (support for my MendelMax)
git checkout -b bhunting_MendelMax

Fetch and merge upstream (ErikZalm’s repo), not really needed right now since I just forked and cloned it.
git fetch upstream
git merge upstream/Marlin_v1

Push my feature branch to my repo
git push origin bhunting_MendelMax

Modify the code as needed…..

Add, commit, and push
git add Configuration.h
git commit -m"configuration changes for MendelMax 3D printer - BAH"
git push

After the mods I built the firmware using Arduino 1.5.2 and flashed it to my printer.

First off I like that the annoying beep when using the rotary encoder has been toned down. Much more palatable now. I like the new menu system. Not a lot has changed but it does look cleaner and I like the wording better. But how does it print?

I upgraded to the latest version of printrun but at the same time I wanted to try Repetier Host. Printrun seems to work fine with the latest Marlin but Repetier has a more full featured interface. Repetier provides both host side software and printer side firmware. I was unsure if Repetier Host would talk to Marlin firmware but it turns out Repetier Host is more than happy to drive the Marlin firmware. In fact the two get along just dandy.

I’ve only done one print using Repetier Host and Marlin firmware but one thing I did notice, other than the improved user interface on both the printer and host side, is my print started and completed in one pass, no hiccups or restarts. It might be an anomaly but at least it didn’t crash and burn right out of the gate. So far I’m happy and looking forward to trying more prints with this combination.