In How To Install Git On Linux we learned how to install Git and complete some basic configuration. In this post we'll expand on this knowledge gained and add some further configuration and look at some key required items and significant optional items.
How To Install Git On Linux we already started using some git commands using the terminal window command line. We'll continue using terminal window and the command line to learn Git and all the associated commands. The reason for this is that learning Git command line is the most universally applicable method to use the tool.
The general format of a Git command is as follows:
git <git-options> <command> <command-options> <operands>
|Execute git application|
|global options to specify function to execute|
|command to execute|
|specified command options|
|Items for command operation|
The Pro Git book, Second Edition has a great chapter on explaining the different commands available in Git and the reasoning behind naming convention used in the categorisation. I won't dwell too deeply on this, and recommend reading that chapter and even buying the book as desktop companion as you continue to explore and work with Git.
Git was initially a toolkit for a version control system rather than a full user-friendly VCS, it has a number of subcommands that do low-level work and were designed to be chained together UNIX-style or called from scripts. These commands are generally referred to as Git’s plumbing commands, while the more user-friendly commands are called porcelain commands.
The origin of Porcelain & Plumbing commands comes from Linus Torvalds and the metaphor translates to directly to you toilet. In that everybody knows how to use the toilet, and for 90% of our interactions with the toilet, we will never have to know exactly how it works or what actually happens, for the most part most users don't care. We use the toilet (Porcelain) to do what we need to do, flush and move on. Only very occassionally do we have to deal with and issue, like a blockage, burst pipe or some other issue, and only then do we need some advanced knowledge or do some maintenance task (Plumbing) .
In git the commands are divided up into the two categories:
Porcelain commands aggregate functionality of plumbing commands and certain options and sequences to make things simpler. For most software developers, make use of just Porcelain commands they will accomplish the tasks they need too.
|add file contents to the index|
|Find by binary search the change that introduced a bug|
|List, create or delete branches|
|Switch branches or restore working tree files.|
|Find commits yet to be applied to upstream|
|Apply the changes introduced by some existing commits|
|clone a repository into a new repository|
|Record changes to the repository|
|Get and set repository or global options|
|Show changes between commits, commits and working tree etc.|
|Download objects and refs from another repository|
|Print lines matching a pattern|
|Display help information|
|Show commit logs|
|Join two or more development histories together|
|Move or rename a file, directory or symlink|
|Fetch from, or integrate with another repository or local branch|
|Update remote refs along with associated objects|
|Forward-port local commits to the updated upstream head.|
|Reuse recorded resolution for merged conflicts.|
|Reset current |
|Revert some existing commits|
|Remove files form the working tree and from the index|
|Show various types of objects|
|Show various types of objects|
|Initialise, update or inspect submodules|
|Merge subtrees and split repositories into subtrees|
|Create, list, delete or verify a tagged object|
|Manage multiple working trees|
Git Plumbing commands have names that indicate an action and an object to operate against as opposed to the simpler naming of the porcelain commands.
|Provide content or type and size information for repository objects.|
|Create a new commit object.|
|Count an unpacked number of objects and their disk consumption.|
|Compare a tree to the working tree or index.|
|Output information on each ref.|
|Compute object ID and optionally create a blob from a file.|
|Show information about files in the index and working tree|
|Find as good common ancestors as possible for a merge|
|Read tree information into the index|
|List commit objects in reverse chronological order|
|Pick out and massage parameters.|
|List references in a local repository|
|Read, modify , delete symbolic refs|
|Register file contents int the working tree to the index|
|Update the object name stored in a ref safely|
|Validate packed Git Archive files|
|Create a tree object for the current index|
Git commands can be supplied arguments, to provide additional information and data for the command to act upon. The arguments
can either be full words or abbreviations. It is important to take note that there is a difference in the number of hyphens to be
supplied when using either abbreviations or full words. i.e. when using abbreviations a single hyphen
- is required but when using
full words a double hyphen
-- is required.
# using the delete argument with abbreviation on branch command git branch -D feature/somebranch # using the full word git branch --delete feature/somebranch
Abbreviated arguments may be passed in together, as in -am instead of -a -m. When arguments are combined in this way, the ordering is important. If the first argument requires a value, then the second argument may be taken as the required value instead of an additional argument.
# Using the following two git abbreviations on the with the git commit command # is essentially saying "Git Commit All Changed Files with the following message" git commit -am "Some commit message"
Git has a helpful auto-completion feature that will enable developers to do two things:
Ironically, this feature is enabled by default for Windows users. However, for Most Linux and Mac users it is not enabled by default.
This will be the first part of advanced configuration we should when setting up our Git environment to work with.
Autocompletion in Git enables you to hit TAB and a git command will be autocompleted for you. If there are multiple commands that match what you typed so far, you can hit Tab two times, and Bash displays a list of all possible completions. The same works for variables and filenames, but not for the many commands Git provides.
The contained completion routines provide support for completing:
The first thing we need to do is download the autocomplete file from the Git - Github repository
we'll do this using cURL. We're going to download this file to our $HOME directory and name it
we'll do this all in one lines://s
curl -o .git_autocomplete https://raw.githubusercontent.com/git/git/master/contrib/completion/git-completion.bash
Once the download is complete we need to edit out
.bashrc file, which we can do using any text editor, in my case I'll use
We need to add some additional lines to check if our new file exists load it up so we can use the commands contained in our session.
So somewhere in
.bashrc find a place to add the code below. I usually create a section in my
.bashrc where I have all these file loads
if [ -f ~/.git_autocomplete ]; then . ~/.git_autocomplete fi
Once you save and exit the file, we can just reload our
.bashrc in our current terminal by using
. ~/.bashrc or closing the terminal
and opening a new one.
The autocomplete now enables you to easily explore git commands and their options. For instance when we want to explore
what options we can set when configuring the Global git options, we can enter
git config --global user. and TAB TAB and be presented
with the list of available options we can set.
The autocomplete functionality enables you to explore any commands and available options just by using the TAB TAB combination. Later, it will also enable you to search and list all available branches. Taking the time to configure this functionality pays for itself once you start using git on the command line.
In How to install git on Linux we touched on how to configure global username and email and where git stores these configuration values. Git expects these two values to be set, regardless of which interface or version of Git you use, because Git is a source management system , and its primary purpose is to track changes by users over time, it wants to know who is making those changes so that it can record them.
If you don't specify these values, then Git will interpolate them from the signed-on userid and machine name. Chances are
this is not what you want to have the system ultimately use. If you forget to set these values initially on a new system,
and commits are recorded with the interpolated values, there is a way to go back and correct this information,
commit command with the
These values can be set making use of the
git config command
git config --global user.name "Your Name" git config --global user.email "email@example.com"
The global option is a way of telling Git how broadly this configuration setting should be used—which repositories it should apply to.
The Git model has been designed for many, smaller repositories instead of fewer, monolithic ones. Therefore users may normally be working with multiple repositories, it would be inconvenient and subject to error to have to configure the same settings in each repository. As a result, Git provides options to simplify choosing the scope for configuration values.
There are three levels available for configuration:
Configuration value applies to all repositories on a given system unless it's overridden at a lower level. These settings apply regardless of the particular user.
System-wide configurations Configuration at this level affects every user and every user's repository.
Configuration values apply to all repositories for a particular user, unless overridden at the local level. Unless you need repository-specific settings, this is the most common level for users to work with because it saves the effort of having to set values for each repository.
User-wide configurations configuration at this level affects every user's repository.
Configuration value at the local level apply to the context of a repository. This can be useful in cases where you need to specify unique settings that are particular to one repository. It can also be useful if you need to temporarily override a higher-level setting.
repository only configurations configuration at this level, only the repository.
If you're going to be using Git on the command line and if your typing is as awful and inaccurate as mine, then you'll no doubt benefit from Git's embedded autocorrection but you will have to enable it!
To do this we need to modify the
help.autocorrection property to define how many tenths of a second Git will wait before
running the assumed command.
git config --global help.autocorrect 10
We have outlined the common advanced Git configuration settings that will make your life easier using Git on the command line.
It is important to remember to always be careful editing the Git config files, because if you incorrectly edit any of these files, you just might ruin your entire Linux Git configuration.