The Blog of Tom Webster

Chronic Ranter, Reviewer, and Developer. I speak only for myself, opinions are my own.

Git Training and Reference Links

  2015-08-26 15:00:00 PDT

Updated: 2015-12-04

Git Training

Here’s a collection of links about Git that I’ve found useful. I’ve been pretty involved in teaching people about version control recently and have used these resources to teach myself. If you want to see another link added, leave a comment or issue a merge request. I’ll make sure you’re credited on this post.

Try GitHub

A fantastic first-run introduction to git. Covers just the basics. Completely interactive and all training takes place inside the browser.

Codecademy: Learn Git

I really love Codecademy, they have tons of free courses ranging from programming languages, to frameworks, to APIs, and now onto version control. A highly-interactive tutorial, just like Try GitHub, just a bit more in-depth. Highly recommended.

Git Immersion

A great VERY in-depth tutorial for git. Covers lots of subjects, but is quite text-heavy. Relies on local git and having Ruby installed.

Linux Academy

If you have a Linux Academy subscription, I highly recommend this git course. It walks you through Git, GitLab, and GitHub. From basic usage to management.

Git SCM Book

Another VERY in-depth book about git. Always up-to-date, but a bit dry. It isn’t written in a tutorial-style, it’s more of a tech book. Good for some people, bad for others. I use this site as a reference all the time.

Udemy Git Tutorial

If you learn from reading textbook examples and diagrams, Udemy has a course available for Git training as well. It’s a bit wordy, but the content is solid.

Your Real-World Git Cheat Sheet

A super-light cheat sheet for everyday git operations. If you want a simple walkthrough of the most basic git commands, or just forget when to use git revert, check this page out.


An absolutely wonderful single-page reference. The information isn’t too dense, and will be very helpful to those new to git who just need to remember a few commands or remember the syntax of something. Totally bookmark-toolbar-worthy.

Git SCM Site

Not a single-page reference by any stretch of the imagination. This site has everything you could ever need. Combine your favorite search engine and site: for some truly stellar search results.

Commit Messages

Why good commit messages matter

A lesson on why commit messages are the most important thing to get right when using git. Commit messages are your messages to the universe, important, meaningful, they stand on their own. Commit messages as art.

Utter Disregard for Git Commit History

Who cares about commit messages? Seriously, no one cares. Put anything you want into them, the pull/merge request is what matters! Have the discussion, collect +1s and -1s, gather in-line code comments, and hash it out there. Anyway, the view is better from the merge request.


You should probably read both links above and make your decision. Software development and version control especially is not one-size-fits-all. Some shops will focus on the commit itself, others value the pull/merge request and attached discussion. Some shops are literally one guy and his side project that no one will ever look at so who the hell cares anyway? Do the research, try things out, pick the best method for you and your team.

Branching Models


Dubbed “Git Flow”, this model is one of the biggest original git management workflows. I’ve used it for countless projects and it works pretty well. The only real downside is that it can be overbearing for smaller projects or teams.

GitHub Flow

A very simple Git Flow model, without the baggage. Companies without proper testing or CI integration should not use GitHub Flow. It really is suited for internet-based services and projects.

There’s one rule: master is always production-ready and deployable.

The flow works like this:

  1. Create a branch
  2. Make your commits
  3. Open a pull/merge request
  4. Everyone discusses the proposed change on GitHub/GitLab
    • You make changes as necessary, adding commits to the pull/merge request
  5. Deploy your changes, make sure nothing breaks (either manually or through continuous integration)
  6. Merge your code into master

And from there the process starts over.

GitLab Flow

GitLab flow is a teeny tiny bit more complex than GitHub flow, but is still quite simple compared to Git Flow. The only difference is that instead of a single master branch, you have different environment branches (with master being deployed to your staging or pre-production environment with every commit), while all development happens on master via pull/merge requests.

Here’s how the flow breaks down:

  1. Create a branch
  2. Make your commits
  3. Open a pull/merge request
  4. Everyone discusses the proposed change on GitHub/GitLab
    • You make changes as necessary, adding commits to the pull/merge request
  5. Deploy your changes, make sure nothing breaks (either manually or through continuous integration)
  6. Merge your code into master
  7. Do your testing in staging
  8. If staging looks good, merge staging to pre-production
  9. If pre-production looks good, merge pre-production to production

This process ensures that all features are stage-gated through each environment, cutting down on potential problems or downtime.

GitLab Flow also has the concept of release branches, but those are only useful if you’re releasing versioned software to the outside world. Check out the link to learn more.

Additional Thoughts:

If you have an interest in this kind of work, you’d better check out Semantic Versioning. It’s a great way to version software and keep outside developers happy. Many open source projects are now using this system. It’s way better than the old odd-numbered-dev-versions system.

GitHub Evacuation (Hello GitLab)

  2015-08-17 17:00:00 PDT

I’m leaving GitHub for GitLab. All project references on this site have been changed to reflect their new home. All GitHub-hosted code gists have been replaced with locally-highlighted code snippets.

The reasons for this are three-fold:

  1. I love open source software, I should support it by using an open platform.
  2. I run my own GitLab instance for personal projects that aren’t yet ready to be open sourced. I’m really digging the interface.
  3. I don’t want or need politics mixed my with code.

New Site Design

  2015-04-12 14:09:53 PDT

I’ve been working for a while on re-doing my site. I’ve decided to move from Octopress to Jekyll for a variety of reasons. Octopress v2 had some well documented shortcomings, but it honestly was a fantastic intoduction to Jekyll and flat-file sites. I really love what Octopress is and how it introduced me to generating flat file sites, but I’ve outgrown it. I’ve moved fully to Jekyll, and as always you can grab all the source code here.

If you find any errors, bugs, or want to make something better, I do accept merge requests, so have at it.

Wifi Grenade

  2015-04-09 02:39:49 PDT

You can find the talk materials and slides right here.

My latest mini-project involves deauth attacks of a portable nature. I give you, the Wifi Grenade. Just be warned, this talk is juvenile, script-kiddieish, and probably irresponsible. In this post, I’ll show you how to build it.


To cover myself, I have to warn you of some things:

  1. I’m standing on the shoulders of giants: The hard work here has been done by other people.
  2. Only use this on a network you are legally allowed to attack. This shouldn’t cause permanent damage, but I’m not bailing you out if you get busted.
  3. This isn’t technical, it’s not impressive, at best it’s a way to see what deauth packets do, at worst this is juvenile stupidity. Either way, don’t take it too seriously and have some fun.


First, go shopping, you’ll need some things (Amazon referral links below).

[$50] Raspberry Pi 2 Model B with case

[$6] 8GB Micro SD Card

[$40] Alfa Wireless Card (G/N 2W)

[$40] Anker 16000mah Battery

When you have all of your gear, let’s get the OS installed:

I’m using Arch Linux ARM for my Pi, follow the instructions here to get the base OS installed, then run your updates with pacman -Syyu.

Next run pacman -S scapy iw wireless_tools git to pull the required tools and libraries.

Next, clone Dan McInerney’s fantastic Wifi Jammer script from GitHub. This will put the code into a directory called “wifijammer”.

git clone

Next, we have to set an auto-login. Create /etc/systemd/system/getty@tty1.service.d/override.conf with the following contents:

ExecStart=-/sbin/agetty --autologin root --noclear %I 38400 linux

Next, we have to set the jammer to run on boot. The simplest way to do this is with .bashrc, modify the contents with the following:

exec /usr/bin/python2 /root/wifijammer/ -a 11:22:33:44:55:66

Now your system will boot directly into the root user and start the wifi jammer. By default, the jammer is set to only jam 11:22:33:44:55:66. Modify this script to specify which network you would like to jam. Without -a, will jam any and all networks it comes across, be careful and only attack networks you are legally allowed to.

How to stop this attack from working

NSA Documents Archive

  2015-02-17 14:10:00 PST

I’ve put up a document archive for all of the EFFs NSA documents. You can download the entire zip file in one click, no BS. I’ve signed it with my public key so you can verify it’s legit. Head over this way for the details and mirroring instructions.

Page: 8 of 32