Fork: A fast and friendly Git client for Mac and Windows

I use a Git GUI, not because it's more efficient or because it enables better workflows, but it's more comfortable for me.

- When I'm browsing the history, I can scroll up and down the list of commits and see the diff of each one by clicking on it.

- When I'm cherry-picking a commit, I can just drag the commit onto the branch.

- When I'm modifying a branch or a remote, I can right-click on it and go to Delete or Rename.

- When I'm resetting to an old commit, I can right-click on it and go to Reset.

Basically, I like to refer to things by pointing to them, and interacting by clicking or dragging. All of those things I just mentioned are trivial using the command-line — with the exception of modifying a branch or remote, you just have to write the git subcommand and its arguments. But having a Git resource as a tangible "thing" on the end of my mouse cursor makes me feel more calm using Git. I want to reset to that commit. I want to delete this branch. I want to cherry-pick this commit onto that branch. I want to see the diff for this commit. I can't really describe it but I feel more "connected" interacting with a repository like this, than on the command-line where I have to run commands and use the output of previous commands in new commands.

Not for products targeting software engineers, the distributions of systems looks very different from the general public and Linux is very common.

Jurisdiction is right there on the bottom:

Governing Law

This agreement shall be governed by the laws of Czeck Republic. If any portion of this Agreement is deemed unenforceable by a court of competent jurisdiction, it shall not affect the forcibility of the other portions of this Agreement.

It is clear that those clauses are ONLY trying to protect them, the authors, from liability for the actions of others using their software. Perfectly reasonable.

It is clearly not written by a lawyer (IANAL), it may not be legally bullet proof, but this is freeware by a couple of people in their spare time. FOR FREE.

We've found that our repos get bad branches and bad merges far less often with them. For a long time, we had issues where a repo would have to be completely rebuilt (or replaced with all history lost) after a dev who thought he knew the Git CLI did a merge incorrectly or force pushed something. Detached HEAD branches locally and remotely, incompatible remote branches, inability to merge without conflict, etc. It was always strange issues that usually required we branch off a commit on develop from a few weeks earlier, merge a few weeks of changes in a single commit, drop every single remote branch, and push and merge back into develop. Was a mighty pain.

We noticed that this only ever happened with devs who (incorrectly) believed they knew the Git CLI and as a result, we instituted a GUI-only policy and preinstalled SourceTree on all computers. In the 2 or 3 years since we started the policy, we haven't had this issue even once. We occasionally have a complaint from a new hire, but after a week or so, they usually tell us that they prefer using a GUI after all. I wish we didn't have the policy, but it became necessary, unfortunately.

(for reference, we are a small-ish shop. Never had more than 15 devs at once. That makes such a policy more easily enforced and worked around. We're currently reevaluating using SourceTree as the default recommendation and Fork is one of the options we are considering)

DISCLAIMER: Obviously some git tasks are just the wrong fit for a GUI, and some git tasks are just not possible.

I've not used Fork but I find SourceTree (which looks very similar) MUCH quicker to search for, and build commits from, hunks. I mean perhaps if I really invested in the git tool I could get my speed up, but I don't see the point - I have what I need already in SourceTree.

More generally the tree-structure of the git filesystem often lends itself to persistent visualisations e.g. split view graph + branches. Especially when fetching, and the graph automatically re-renders and shows you an unexpected structure.

If we are talking about vanilla git - GUIs can be a nice drop in to speed up commit work flows like "checkout that commit I was working approx a dozen commits ago". Being able visually-grep, and then double-click is a bit faster than `git log --pretty=oneline; git checkout SHA"`

And finally, and they are a great on-boarding wrapper for users who are new to git. I've had good success unblocking users with very little git experience who are only using a git CLI, by introducing a git GUI. This really flattens out the learning curve, which frees up both devs to concentrate on the _actual_ task at hand.