These words, probably, are appearing on your screen somewhere in your favorite web browser. If you’re reading this on your phone you probably clicked on an icon to open your web browser to get here; if you’re on a laptop or a desktop you probably clicked on an icon too, though you also could’ve gotten here with a few keyboard commands.
Long ago, keyboard commands were all that anyone could use to get computers to do what they wanted them to do; with the advent of Graphical User Interfaces (GUIs), pioneered by Xerox and popularized by Apple, users were able to to interact with their computers visually and see more information at once. The GUI has proven so popular that it’s become almost ubiquitous, saturating the way most people interact with computers, carving out innumerable paths including the one you presumably took to get to this page.
Not everybody’s been happy about this, though – many people strongly prefer to stick to the command line interface(CLI) as much as possible, typing in commands no matter what buttons are on hand to be clicked on. These people are usually, but not always, researchers and developers, people who see computer competence not as a means to an end but as an end in itself.
Of course, computers aren’t just used for crunching numbers or for controlling various things; they’re also used to help people communicate and collaborate, forming connections and working together on projects no matter what amount of space and time might separate them.
If you’ve been involved in computer development you’ve very likely encountered the version control system known as Git, the popular architecture used to help coordinate work on a software project across multiple people. You were probably introduced to Git via its command line interface, learning the basics by typing things in. From there you might have gone on to use a GUI for Git, or you may have stuck with using the command line for all tasks that come your way.
Sticking to a command line is not without its merits – the CLI is a ‘lingua franca’, capable of being applied to help develop projects across all platforms; CLI is amenable to automation, enabling an advanced user to have a robot push updates at all hours of the day and night at inhumanly precise intervals; CLI lets you know exactly what you do exactly when you do it, rather than relying upon some abstraction layer that you didn’t enact; if you jump on Stack Overflow for help you’ll probably find CLI recommendations first rather than help for given particular GUI client.
These are all important points, all supporting the option of having a CLI ready to go at any time. But these points don’t detract from the merits of GUIs, either.
GUIs help take care of a lot of work that can be repetitive and obscure, accomplishing with a drag-and-drop or the push of a button what might take untold typed lines to accomplish. Relatedly, with fewer typed lines come fewer typos, and with fewer typos come fewer time-consuming errors.
These features serve to lower the barrier of entry for new developers, helping get more people involved faster and ultimately making more get done. The challenge and the reward of mastering difficult development tasks is all well and good, but it shouldn’t be maximised for its own sake – the point of development is to deliver something, not for the developer to achieve some private enlightenment. Unless you’re a research scientist, the value you bring to a given project is not your own ability to reinvent the computer from scratch.
GUIs for git are also very well-suited for facilitating collaboration among team members, which serves the basic stated purpose of git itself. Branches, changes to branches, teammate activity, and other such information is best conveyed visually. It’s easier to see it when all of the information is present to the user at once, rather than being funneled through a command line one line at a time.
Ultimately, both GUI and CLI have their place – beside one another. GUIs make important things easier and CLIs have more power, and the best approach is to swap between the two as the needs of your project require. Through this approach the full capabilities of git can be deployed, helping us all build bigger and better things, together.
