Building an application, any kind of application, requires us to store our code somewhere. The era where code used to only live in a folder inside a local hard drive (and at best, some other hard drive where backups were kept) is long gone, giving its place to versioning systems. Using a versioning system and predominantly Git is not a matter of discussion anymore so let’s see how we can make our lives easier.
Selecting a Git client
There are various flavors of Git clients at the moment: Git Command Line Client, clients provided by repository hosting Services such as GitHub and Bitbucket but also 3rd party git clients and they’re all succinctly summarized in this page in the official Git website. For the purpose of this document, we’ll focus on working with the Git command line client.
Making the Git client work for you
We’re not gonna bother you with installation details, you most probably already have installed or know how to install git client; in case you don’t though, please follow the installation instructions described in the famous Git Book. We’re gonna cover two main features of the git client though: the global gitignore and the aliases
Git Client configuration in general
Git uses a plain text file to store its configuration, which is very easy to read and update, but also specifies individual git config commands that enable us configure each and every option separately. By using the command line (terminal), we can configure Git to use our name, email and a specific editor
$ git config --global user.name "Jane Doe"
$ git config --global user.email [email protected]
$ git config --global core.editor vim
$ git config --global merge.tool vimdiff
What we just did: we set the name and email to be stored in the git commit messages, we chose vim as our editor (Git needs to have an editor in place for commit messages, rebase actions etc) and vimdiff as a merge tool, which is the program that launches whenever we need to resolve conflicts
Global gitignore
By default Git tries to track all the files available under a directory but not all files belong to a Git repository. For example binary files, vendor libraries or files created by the local file system should not be added as they occupy space in the repository that can be freed by either installing libraries or are completely unnecessary. Luckily, Git offers a global gitignore file where you can specify those.
Simply create a file in your home directory called .gitignore_global that contains any file patterns that you need to avoid for example:
# Logs and databases #
######################
*.log
*.sql
*.sqlite
# OS generated files #
######################
.DS_Store
.DS_Store?
._*
.Spotlight-V100
.Trashes
ehthumbs.db
Thumbs.db
# add more patterns here...
In order for the file to take effect, you need to configure the Git client to actually use the file, via the git config option which is thoroughly documented in the Git book as well:
git config --global core.excludesfile ~/.gitignore_global
Aliases (or how to type fewer characters)
Git is going to be part of your workflow, meaning you’re gonna type lots of git commands on a daily basis. Making a command shorter, will save you thousands of keystrokes per year. Let’s take a few basic commands that we’re using on a regular basis:
$ git checkout topic-branch-name
$ git status
$ git branch
$ git diff --word
$ git diff --cached
Now, let’s apply a few aliases that will help us shorten those:
$ git config --global alias.co checkout
$ git config --global alias.st status
$ git config --global alias.br branch
$ git config --global alias.dw "diff --word"
$ git config --global alias.dc "diff --cached"
We now aliased the basic commands that we’re using regularly via the command line, but there’s an alternative, editing the global Git config file (under your home directory) directly as shown in the Git book examples. Here’s how it would look like
# file ~/.gitconfig
[alias]
co = checkout
cob = checkout -b
coo = !git fetch && git checkout
br = branch
st = status
aa = add -A --all
cm = commit -m
po = push origin
gr = grep -Ii
There you have it! You’re now en route to a more productive git flow