I use a git UI, and so should you… here’s why.

I’ve been working as a professional developer for quite some time now, and I have almost always, used git, for every single project I do. Small or big, it doesn’t matter git is great for any size. The only difference, is how I use it.

For small projects I generally just do it single branch style, no fuss, just for the history and have the ability to branch out, in the literal sense.

In larger projects I always use “git flow” which was made popular by Vincent Driessen. Which allows for easy parallel development, having a developbranch, where feature branches are spun out from, and then merged back in. Once stable, develop is then merged into master . Gitflow in particular, is A LOT easier using a UI for the work, as it eases the burden of the workflow, not having to remember to merge into hotfixes into both develop and masterand just being able to drag 2 things together instead of typing git checkout master ->git merge -X theirs develop.

Looking is easier than thinking.

Having a UI to look at, to see changes in git, is just 100.000.000 times better than doing git diff, if you changed more than a few lines of code. git logalso has a way of getting out of control really fast.

Solving merge conflicts can be hard.

It doesn’t have to be though. Usually you would have a separate tool for that, which was made specifically to sort out this sort of thing, but some git UIs has this ability built in.


Release the kraken.

History lesson

There are multiple git UIs out there, you can see some of them here. Of those, I have tried quite a few, but none have come close to GitKraken.

I’ve used GitKraken extensively over the past couple of years, and it has moved quite a bit since its launch.
At its launch there were basically only a single really good client on the market, namely Sourcetree. GitKraken blew it out of the water for me, GitKraken was beautiful, fast and the UI was intuitive.

Git Flow

It is super easy to create new git flow branches and finish them through the UI.

Merge Conflicts

In gitkraken, merge conflicts are seamlessly fixed, in the UI — see the short video below.

Git Diff

Super easy to to use diff views WITH inline editing!

My list of small, but really useful features

  • Right click revert .
  • Drag’n drop merge.
  • Stashing made super easy.
  • Right click git reset <option>
  • Dark theme!
  • Fuzzy finder.
  • Cross platform.

A lot of the time, I just find using a UI simpler, and much easier to get an overview of.

Want to try GitKraken? Please the link below to sign-up.

https://www.gitkraken.com/invite/u5NxELFP

Disclaimer: I am a GitKraken Ambassador, not a paid employee of GitKraken by
Axosoft.

When the network is your problem (Developer Edition).

I’ve seen many junior and even senior developers struggling with figuring where an issue is located in their network topology. Developers need to know how to troubleshoot networking related issues, not necessarily fix them, but most definitely help figure out where they are.

This post will cover the basic tooling and how to use them to figure out what and where a problem is.

The topology

This post assumes some knowledge on how the internet connects, a good primer can be found here

I am going to base all of the examples on the following very generic topology, which should resemble most setups, to some degree at least.

A very generic network topology.

The problem

You try to go to the website you are working on, and you are hit with

Site can’t be reached (chrome edition)

S#!%… Okay, relax… breathe…

First thing to note is, we are not getting back a response of any kind from the server.

A response of any kind, means that the network is working, and the problem is either the webserver (IIS, Apache etc.), in code or filesystem related.

Or

You try to connect to an RPC service on a server, but it does not respond.
Either way, the problem could be the same.


Ping

Ping is a utility that sends ICMP echo requests to a given IP address and returns with the time it took to reach that destination. ICMP is its own protocol and does not have a concept of a port. Thus, you are only testing if the server responds to ICMPs.

Usage

ping {IP}
ping 8.8.8.8

Pros

  • Tests the entire chain, from client to server.
  • Can be set to ping until stopped (which is nice for checking when a servers goes back up, from a reboot)

Cons

  • Can be blocked in production firewalls.
  • If it fails, we generally have no idea why or where. It could be failing from the client and outward.
  • Does not test DNS.

Test Chain — Success

On a successful ping, we know that the client can reach the server over ICMP.
Problem could be Ports or DNS

Test Chain — Failure

If it fails, we really have no idea where or how. This is where you either start pinging from the client out / or server in — Or go try tracert.


Tracert (traceroute)

The natural next step from Ping. Traceroute also utilizes ICMP requests, but returns per hop response times, meaning this utility can show you the route your packets go through to reach the destination.

This helps in figuring out any bottlenecks in routing, and also which endpoint the communication stops at.

Example; the server’s local firewall is blocking all connections. When using tracert we can see that everything, but the server responds. troubleshooting can now continue on the server, as we know the network is fine.

Usage

tracert {IP}
tracert 8.8.8.8

Pros

  • Tests the full chain, from client to server.
  • Can see individual hit endpoints on the way to the destination.

Cons

  • Still uses ICMP, which may be blocked by production firewalls/servers.
  • Does not test DNS.
  • We as developers can’t do much about routing issues, other than report them where appropriate.

Test Chain — Success

If output looks fine, and there are the “expected” amount of hops, we know that the client can reach the server over ICMP.
Problem could be Port or DNS

Test Chain — Failure

If it times out after a certain point, we know that we can at least reach that point. — Investigations should continue from the point of failure and everything before can generally be ruled out (unless other problems also occur)


Telnet

Telnet is used to establish TCP/IP connections. In troubleshooting scenarios we can use it to test if a given port is open and accessible on a remote server.

When you connect to a website, your browser establishes a TCP/IP connection on port 80/443 on that server.

There is a similar powershell command you can run, which does the same thing and a ping if connection fails.

Usage Telnet

telnet {IP/FQDN} {PORT}

If you get a blank screen or any output — Connection has been established.

Usage Test-NetConnection

Test-NetConnection {IP/FQDN} -Port {PORT}
Test-NetConnection google.com -Port 443

Pros

  • Can directly tell us, whether or port is open or not — Any port.

Cons

  • Not installed by default in later version of windows (security)(can be installed as a feature) (or just use Test-NetConnection)
  • Does not test DNS

Test Chain — Success

If a connection is established, we know that the network is in good shape and that the server responds on the correct port. — The error then being on the actual server in question. or possibly loadbalancer issues (again, something to tell the appropriate team)

Test Chain — Failure

If we already know that we can ping or DNS is correct, but we cannot connect on the port in question, we now know that the port is either closed on the server or blocked by a firewall.


Nslookup (dig)

Nslookup or dig on linux, is used to check DNS records. Generally, the problem with DNS is the propagation times and TTL on records.

The general problem is either;

  1. Wrong IP/Hostname in DNS entry
  2. Stale records on client

Usage

nslookup {FQDN}
nslookup google.com response

Pros

  • Checks the DNS side of things, if the name matches what you expect for the address, then everything is in order (perhaps)
    DNS takes a while to propagate, so DNS might be working in some parts of the internet, where others might not. Generally, up to 24 hours (usually within an hour or so)

Cons

  • Only checks DNS

Getting committed lines of code count, through git

TL;DR

git diff --stat 4b825dc642cb6eb9a060e54bf8d69288fbee4904

Explanation

Git has a “secret” hardcoded SHA1 for an empty tree, referenced in the source code as EMPTY_TREE_SHA1 which is technically the /dev/null tree.
You can find the hash by doing git hash-object -t tree /dev/null
So with git diff --state 4b825dc642cb6eb9a060e54bf8d69288fbee4904 you get the difference between your current tree and an empty tree, which will return the lines of code committed

Note: That package.json and package-lock.json can become pretty big 🙂