Tips from the experts on getting more from Git

Git Tricks

Article from Issue 223/2019

The Git distributed version control system is a popular tool for managing open source development projects. If you know the basics of Git but are looking to learn the ways of the experts, read on for some useful Git tips and tricks.

"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:

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.

Listing 1

git add -i


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.

Listing 2

Vim Plugin for git blame gui


Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Tree View

    Complex Git projects sometimes require a better view of the dependencies and branches. Several tools offer GUI options for Git. We take a look at gitk, gitg, git-gui, and GitAhead.

  • Remote Git Repositories

    Software projects often comprise several code branches, some of which exist in parallel. Git supports community code development through remote repositories and code branching.

  • Etckeeper

    Etckeeper keeps order in global configuration files and prevents problems with accidentally deleted files.

  • Version Control with Git

    The Git version control system is a powerful tool for managing large and small software development projects. We'll show you how to get started.

  • Git Ready

    If you develop open source software, you need to know how to use Git. Information on Git fills books, but this basic overview will get you started with a vital open source development tool.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More