Graphical User interfaces (GUIs) for the Git version control system let users visualize branches and different version levels. Developers thus have a better overview of their projects' status. In addition, GUIs make Git easier to use, because programmers do not need to remember any of the cryptic Git commands.

Thanks to the great popularity of Git, numerous GUIs are now vying for the attention of users, including some commercial offerings. Many users are not aware that Git already has two GUIs, gitk [1] and git-gui [2]. Although both are part of Git's official scope of supply, many distributions outsource them into separate packages. In Ubuntu 18.10, users have to install the git-gui or gitk packages. The code for the two GUIs has also been adopted by external projects. The Git developers always add the latest stable version to their branches.

The following comparison with the free competitors GitAhead [3] and gitg [4] is intended to reveal how the two GUIs perform compared to the rest of the field.

gitk

Gitk [1] is based on the Tcl scripting language and the Tk toolkit. This dependence on Tcl/Tk is reflected by the old-fashioned appearance of the main window. The software was last updated two years ago. Gitk only visualizes the Git history (Figure 1); users can call it up directly in the project directory. The tool cannot manage and compare several projects. In the top-left corner of the main window, you will see the view of all branches, where merges and commits also appear.

Figure 1: Gitk confronts users with information overkill, although you can only really use it to visualize branches and commits.

A click on a commit shows the changelog in the lower-left corner together with the changes made. The changed files appear bottom-right, and the names of the persons responsible at the top-right.

Two search functions help you find information. One of the search functions digs through the open changelog and the changes; the other digs through the commits. Only the second search function evaluates regular expressions. Both highlight the search results in color when you enter a search term.

Users can create views to restrict the display to certain criteria. For example, you can create a view that displays only commits by Tim Schürmann. However, gitk does not open these views in separate windows; instead, users have to switch to them via a menu, which is inconvenient.

git-gui

Git-gui, which comes with the Git package, is also based on Tcl and Tk. As with gitk, you call the tool directly in the project directory using the Git git gui command. In contrast to gitk, git-gui [2] simplifies the actual work with the Git commands. Graphical representation of the branches is left to the counterpart gitk utility, which has a menu item for this purpose.

In the main window, git-gui displays the changed files on the left and the changes in the selected file on the top-right (Figure 2). In the lower area, developers can add comments and quickly create a commit using the options provided.

Figure 2: The git-gui main window.

If the Aspell dictionaries available under Linux are installed, git-gui even performs a spell check. After a developer has changed a source code file (Figure 3), they have to refresh the view in git-gui – the tool does not recognize changes on its own.

Figure 3: Git-gui can display individual files in this File Viewer, which also provides an interactive Blame view.

Users can create, rename, delete, or locally merge new branches via the menu. In addition, git-gui can fetch and push from and to external repositories. Last but not least, the tool integrates external tools if required, although git-gui can only start one command-line command given by the user at a time.

GitAhead

GitAhead [3] is not as well integrated into Git, and it is essentially the work of developer Jason Haslam. The software is available under the MIT license. We were able to install the current version 2.5.3 on Ubuntu 18.04 in our lab without any trouble. If you are interested in the product, you won't find it in your package manager's lists, but it is available on GitHub [5]. The package with the .sh extension is a script, which you need to make executable by typing chmod u+x GitAhead-2.5.3.sh and then launch by typing./GitAhead-2.5.3.sh. The command unpacks the software contained in an archive into a subfolder. You then launch the software via the gitahead file.

GitAhead cooperates with a number of popular Git vendors, including GitHub, GitLab, Beanstalk, and Bitbucket (Figure 4). For our test, we added a source code archive on GitHub via Add GitHub account.

Figure 4: GitAhead can integrate four external services.

The documentation for the software is fairly sparse. If you have any questions, you are supposed to tag them as [gitahead] on Stack Overflow [6], which apparently nobody has done yet. Most Git users probably intuitively understand how the application works anyway, so they don't need a helping hand. The fact that people actually use GitAhead is shown by the open issues on GitHub.

In the left pane, the software presents the remote, open, and recently used repositories. Local changes can be moved to the remote repository using the Remote | Push menu item. If you want to create a new repository, click File | Initialize New Repository and then assign a local location for the repository.

File | New File lets you create new files in a simple editor; you save them with File | Save in the newly created repository. They are not checked in yet. A click on the new repository shows Uncommitted Changes. In the upper-right area, developers then create a commit message and select Stage All and Commit to check in all changes locally.

To the left of center, the branches and commits appear one on top of the other in two smaller windows. The upper window lists the branches (often the only branch is master); below them you see the commits they contain. On the right side of the window, the commits appear in detail. A click on the pen icon next to an entry opens the entry in the built-in editor, where you can then modify it.

The interface also supports branches and merging. To work on a branch other than master, developers need to select a commit to branch and then select Branch | New Branch. If you then want to work in the new branch, select it in the Branches area and double-click on it. On the right you can now click on the pen, work on the code, and save your changes by pressing Ctrl+S or selecting File | Save. Check the code in again via Stage All and Commit.

Once all changes have been made to the branch, Branch | Merge puts the two branches back together again. If merge conflicts occur, GitAhead displays a diff in the details window and asks which changes the developer wants to apply – because third parties might have made changes to a file in the meantime.

The individual commits to the branches appear below the branches. As the number of branches increases, this is visualized by branching lines shown in different colors (Figure 5). The lines connect the commits and quickly show the developer which parts of the code are temporary spin-offs. You can see who is currently working on a branch in the top right-hand corner of each commit.

Figure 5: GitAhead traces the often confusing ramifications of the code with colored lines.

At the bottom of the window, a history of commits to a project also appears. There are also error messages if the master cannot be checked out due to unresolved conflicts or if Git Large File Storage (LFS) is not installed, but the developer wants to use it.

To push the local repository to GitHub, the developer first logs in, then creates a new repository via the browser, and copies the link, for example:

https://github.com/username/Repository-Name.git

Now, in GitAhead, first select the desired local branch and then Repository | Configure Repository. A small window opens. In the Remotes tab, there should not be a remote source directory for a local-only source directory. However, this can be added by pressing the plus sign.

First type a name, such as origin/Repository-Name. In the line below, you need the link to GitHub; the whole thing is sealed by a click on Add Remote and then Ok. Afterwards, move your local repository to GitHub via the Remote | Push to menu item. For the other Git providers, the procedure should work in the same way. Further commits can then be automatically moved to the remote server using the settings.

GitAhead has more capabilities that we have not yet talked about. Tags let you assign version numbers to software. In addition to a merge, a rebase is also possible, which, for example, transplants a feature branch to the top of the master branch. Code contributions can also be undone in the commit overview. Just right-click on the commit entry and select Revert from the context menu.

If time is of the essence, but you do not want to let your unpolished changes loose on the repository yet, you can use the Stash menu item. Stash lets you push your changes into a virtual icebox for the time being, and Pop Stash lets you continue to work on them. Last but not least, cherry picking is possible if you wish to select only certain commits from the history and transfer them to another branch.

Tools | Options makes it possible to adjust a few settings, such as character encoding, themes, fonts, and updates. You can also enter an external editor if it is located in $PATH. To call the editor, right-click on the bar above a commit in the detail view and choose Edit in External Editor.

If you usually work in a different editor, the files created with it are simply stored in the local Git repository. They then appear as unsubmitted changes in GitAhead.