ProgFu

Git Coding Guidelines

This article is less of an article and more of a list of guidelines for proper git workflow. Let’s dive right in.

• master branch is ALWAYS ALWAYS ALWAYS deployable, never work directly on master
• Development code should be on dev branch and then merged into master once fully tested, that way master awlays stays deployable
• Every time you start a new task, create a branch from dev and then rebase or merge back

Why all of this nonsense? A simple example:

• You’re working on a feature A
• Feature B request comes in with a higher priority (before A is finished)
• Huge security issue comes up and needs immediate fix

If you’re doing this correctly, then:

• Feature A is started on a separate branch, not directly on dev
• Since A isn’t finished, you can easily branch B from dev
• Now fix the security issue on dev? Maybe, but why not just branch and rebase once you’ve fixed it? It doesn’t cost anything and makes things easier in the long run.

This is how it would look

 git checkout -b A
 .. cool shit on A

 .. request for B comes in
 git checkout dev
 git checkout -b B
 .. cool shit on B

 .. security thingy comes up
 git checkout dev
 git checkout -b security-fix
 .. fix the problem

 git checkout dev
 git rebase security-fix

 .. now continue with A
 git checkout A
 .. finish the feature A
 git checkout dev
 git rebase A

 .. now continue with B
 git checkout B
 .. finish the feature B
 git checkout dev
 git rebase B
 .. everything is now on dev and the history is clean

Branches are the reason why git is so awesome. There is absolutely no reason to be afraid of using them.

Aliases for git come in handy. Since you’re going to be branching a lot, you might want something like

alias gco='git checkout'
alias grb='git rebase'
alias gr='git reset'
alias grh='git reset --hard'

and so on.