Posts /

Git Flow

Photo by Christian Birkholz

Twitter Facebook Google+
21 Jan 2019

Git Flow

Git is an amazingly powerful tool for version control, that not many developers understand.

There are tonnes of resources for this already so I’m going to skip to explaining my git flow, why I do it the way I do and some tools I use to help.

TL;DR:

My git workflow.

Plus git status a million times, just in case.

Alway Work Off Master

git rebase is the best way to ensure your code will be correct before pushing upstream.

The only way to know if your code will work when combined with the latest code, is to work off the latest code. As sometimes this isn’t possible to do up front, using rebase before pushing is the best approach.

Why Rebase and Not Merge

The history becomes hard to follow.

Rebased code is easy to follow.
Merged code is like following a thread in a knitted jumper.

With merge, you end up with wasted commits which add noise to your history. With rebase, every commit has value.

Merge commits are meaningless.

The counter the “but it shows when code was combined” argument, use git tag to label commits, not a commit to label a commit…

With rebase it’s easier to track and create fixes to errors.

Commands like revert are much easier to use on atomic commits. Multiple branches caused by multiple merges are doubly hard to follow.

Git Config

Having a git config that works for you is important to keep your flow.

My git config has a number of shortcuts and typo fixes. You can find my gitconfig here. At the time of writing it looks like this:

[user]
  name = Michael Standen
[pull]
  ff = only
[alias]
  st = status
  f = fetch
  fe = fetch
  ef = fetch
  cm = commit -m
  graph = log --graph --all --oneline --decorate
  gprah = graph
  gr = graph
  sh = stash
  stasth = stash
  amend = commit --amend --no-edit
  pu = push
  pus = push
  pusg = push
  pushinboots = push
  ff = merge --ff-only
[core]
  autocrlf = true
[push]
  default = simple
  followTags = true

Some of the default git configurations are dangerous. Running git pull is a quick way to come into trouble, as the command performs a merge. This creates difficulty for new users and makes the history really hard to follow. Setting pull to use -ff-only prevents automatic merges that aren’t fast forwards.

Shortening common commands like status to st may not feel like much but any reduction in characters not only reduces the typing time, it also reduces the potential for typos.

Aliasing commands with flags such as the graph also saves time and helps with memory. This command is a great visual aid. See screenshot:

git graph is a great visual aid.

Extra Tools

A tool I’m quite fond of is The Fuck. The Fuck is a quick way to fix typos and soothing the soul.

When you make a typo, you can follow up with the command fuck which will correct your typo and re-run the command. It also fixes your bash history as an added bonus.

It also adds defaults to fix things like pushing a new branch that doesn’t yet have an origin.

$ git pu
fatal: The current branch new-feature has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin new-feature

$ fuck
git push --set-upstream origin new-feature

...

Take Away

Write clean code, and base your code correctly.

Knitting doesn’t belong in source control.



Thanks for reading

If you enjoyed the content please consider leaving a comment, sharing or hiring me.

Cheers,
Michael



comments powered by Disqus