Skip to content
markdown guide

I took a page out of Drew Barontiti's playbook and set up a repo for Documenting code snippets. Anytime I come across something handy, I'll toss it into my Documents repo for later use. It's a much more organizational way of keep track of useful pieces of code.

Original Article -


That's general advice but I think the "default" Git(Hub) workflow should be this:

Issue > Fork > Branch > (Work) > Rebase (if needed) > PR > (Discussion & more work if need be) > Merge

IMHO that's the easiest (for you and for the original dev) way of contributing to a project using Git(Hub).

Other random things from experience:

  • Use a shitload of aliases for Git commands, but only when you are familiar with the "real" commands
  • Start small, don't get into the branching/rebasing/cherry-picking madness before mastering the Git basis
  • That's maybe outside the scope of the question but keep track of your issues and PRs with tools like Trello or GitHub's projects

Here is my fav github tip:

Use oh my zsh with github enabled plugin, It provides info on which branch you are and if there is diff etc..

Github + zsh

  1. If you are following git workflow then I would suggest to make develop as default branch.

  2. When you are looking at the source code just press t to search(fuzzy) any file by name

  3. I also recommend to use oh my zsh as suggested by

    joehobot image
    . It has many aliases to make you more productive. Also you will see current branch with it's status on the console all the time. So no need to go and check git branch
Classic DEV Post from Nov 21 '19

What are your favourite Alfred workflows?

Alfred is such a great tool if you use a Mac....

Joe Hobot profile image
DevOps Guy who loves to work on CI/CD and recently full on Kubernetes.