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.