"You must know a few Git experts," an editor at Linux Magazine said to me. As the leader of the SUSE documentation team, I spend large portions of my day around veteran Linux developers. When I agreed to ask the team for some tips for using the Git version control system [1], I did not expect that I would trigger a thread that lasted several days (Figure 1).

Figure 1: The thread with Git tips on the internal SUSE mailing list quickly grew.

The number and quality of the tips shows just how important Git is to SUSE developers. This article rounds up some of my favorite tips. If the tricks mentioned here are not enough for you, you will find many more online – aimed at beginners and connoisseurs alike. Check out the DZone site for a summary of useful Git commands [2]. The Fedora team has also assembled their own list of "pro tips" for Git developers [3]. And don't forget the Git cheat sheet for an at-a-glance view of some important Git commands [4].

At SUSE, the developers aren't the only ones who depend on Git. The documentation team uses Git every day, including the gitflow workflow feature, which we use for managing documentation projects [5]. The Trello board shown in Figure 2 is used for tracking internal documentation of version-management tips and tricks. Over the years, countless short how-tos have accumulated, ranging from entry level to highly sophisticated solutions. The first five tips in this article – submitted by technical editor Thomas Schraitle – come from this pool.

Figure 2: The SUSE documentation team uses Trello's Kanban boards for almost all tasks. The documentation specialists collect the best Git tips for new SUSE employees.

Tip 1: Getting Pretty

The Git Pretty flowchart from developer and blogger Justin Hileman [6] (shown in Figure 3) is extremely helpful for cleaning up after working on a project. The simple decision chains can help you decide how to respond to a mess, which is when you might need the help the most. At the end of each chain, you will mostly find simple Git commands. See the Git SCM site [7] for more on cleaning up in Git.

Figure 3: Git Pretty gives users a decision-making tree for cleaning up Git repositories. © Justin Hileman: http://justinhileman.info/article/git-pretty/

Tip 2: Interactive, Please!

It happens time and time again: Users want to interactively decide what kind of code they will be adding and supplementing in their projects. If a git add is not enough for your needs, two options for working with Git in an interactive mode are git add -i (-i for interactive) or git gui. The git gui command opens a Tcl/Tk user interface, through which developers can create new commits or change existing settings. git gui also creates new branches, manages stages, and offers other useful features (see also the article on Git GUIs elsewhere in this issue).

git add -i is a little leaner. Listing 1 shows three changes in a file named README.adoc that are not yet ready for a commit; the output looks a bit like git status. The +3/-1 in line 2 means that programmers have added three lines and removed one. Typing a P and Enter starts patching; Git then expects the file number to be selected (here 1) and shows the changes immediately.

Typing ? displays the help. You will usually go through one change at a time and confirm it with a Y or reject it by typing N. If you press D followed by the number of the file you wish to edit, a diff appears. Q quits the viewer and takes you back to the shell, where you can complete the code in the usual way. Look online for more information on Git's interactive options [8].

Tip 3: Who Committed What?

The git blame command annotates a file with line-by-line revision information showing who made previous changes to each line. Thomas points out that many users don't realize the -L option accepts a start and an end value, which means you don't have to generate output for a whole file but can focus on a specific section of the code. GitHub also supports this function. The Blame button visualizes the output on the web and shows author, commit message, SHA sum, and the changed lines. If you like Emacs, you will be able to access the blame function via M-x git blame-mode if you install the git-mode extension.

SUSE developer Benjamin Poirier has set up a Vim command to show him the history of the code in the Git Gui – git gui blame (Listing 2). If you like this option, add the code from Listing 2 to your own .vimrc file and enter :GGBlame (or GG and Tab) in a Git session in Vim.