Learning
Since the early 2000 I’ve been using JEDI VCS (formally Free VCS) and its served me well as a version control system but since its change to JEDI VCS and the release of the 2.5 beta there has not been any updates or fixes. The only change I’ve made is to move the back end to MS SQL Server so I can backup and restore the database if needed. Often, it has taken months for as release for the latest IDE plug-in so I’ve been looking for an alternate version control system for a while and I written an application to migrate one or more JEDI VCS projects to Git which seems to work well for the projects I’ve migrated so far but that’s another post.
Not long after I got back into coding when I became an MVP someone suggested I load my plug-in examples on to GitHub, so I went and had a look. I downloaded the command line tools and scratched my head and then downloaded the desktop application. The desktop application worked for my needs at the time and I uploaded numerous projects to GitHub.
I read a blog post by 19 Tips For Everyday Git Use by Jeroen Wiert Pluimers and at the bottom of the post was a link to Git Pro, a free book on Git. I started reading the book on the way home from work and all the way until midnight and I started to understand the power of Git. I then spent some time understanding some of the commands and using them on some of my not so important projects. I had used the IDEs integrated Git functionality but the font in the form is a little too smaller for my old eyes (QP raised) so I opened Take Command (my go-to command line) and started using the command-line version and started to like the way it works. So over a period of time I kept going back into the book and learning more about Git.
So this blog is about what I’ve learned as I think it might be useful to those that are either learning Git or want to understand Git a little more.
Steamlining
I’ve broken the following down into different parts that can be used to configure Git the way you want it.
Configuration
My command-line in Take Command doesn’t use a black background (a black screen makes my think the computer’s crashing) but instead uses a a blue background. As such, some of the default colours in the difference and grep views were not as clear as I would like, however its easy to change them. If you type git help config you will be presented with a HTML page of configurations options. Git configurations have three levels: local (to the project), global (to your user profile) and system. Ideally you want to put all your custom settings in the global configuration file which is called .gitconfig in the root of your user profile however you don’t need to edit it to change the colours, instead you can use the git config command-line (I also suggest to back this file up as well).
I changed by colours as follows ()from the .gitconfig file:
[color "diff"] new = green bold old = red bold plain = white dim meta = red white func = blue bold commit = yellow bold whitespace = red [color "grep"] context = white dim filename = green bold linenumber = red dim function = blue bold match = red bold matchcontent = white dim separator = red dim
To change these colour you can write the following command:
git config --global color.section.name "colour style"
The section in this case is either diff or grep, the name is the name of the meta-data, colour is the colour name and the style changes the colour (the help page details all these names). So for instance the diff new colour can be set as follows:
git config --global color.diff.new "green bold"
You will probably have to play around with the colours to get something that works for you. You can edit this file using git config --global -e but by default it will be in VIM the default editor (more on that later).
There are a few other config settings that you might want to change. I made Git use WinMerge as both my diff and merge tools as follows:
git config --global diff.tool winmerge git config --global merge.tool winmerge
Obviously you need WinMerge installed.
The last thing I changed is to ensure that grep shows line number by default:
git config --global grep.linenumber true
Aliases
So unfortunately Git doesn’t provide config options for all command-line options for all commands however it does support aliases to make things easier. They allow you to type git aliasname and have Git run a more complex command for you. The first one I did was for the log as follows:
git config --global alias.lg "log --graph --oneline --all"
This means I can get a log report for all the repository as a one-line per commit listing with a graph of the layout of the commit tree down the left hand side (note that commands needs to be in quotes).
The other aliases I’ve defined as follow (the other graph options were found on Stackoverflow):
sh = show lg = log --graph --oneline --all lg1 = log --graph --abbrev-commit --decorate --format=format:'%C(bold yellow)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all lg2 = log --graph --abbrev-commit --decorate --format=format:'%C(bold yellow)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' --all lg3 = !"git lg1" dev = checkout Development mas = checkout master tg = tag -v st = status com = commit br = branch cfg = config --list --show-origin cfgp = log --graph --all --pretty=format:%C(bold yellow)%h %Creset%cr %C(bold red)%d %Creset%s bl = blame --date relative
Graph Colours
So due to my blue screen I also needed to change the colour of the graph lines in the log report (you need an up to date version of git for this and this also affects GITK). I wanted bright colours so I configured by as follows:
git config --global log.graphColors = "bold green,bold magenta,bold yellow,bold red,bold cyan,bold blue"
Commit Template
Another thing I’ve done is create a template for the commits to remind me of what to write (title followed by a blank line and then the description). You can configure this as follows:
git global --global commit.template "D:\Path\CommitTemplate.txt"
Environment Variables
Now to my only grumble about Git – the VIM editor. I had to change this almost immediately as I just simple got stuck in it with no real idea how to get out. This I’m sure could put people off immediate. So this made me create a small lightweight editor for editing files (you could use Notepad) and then I used an environment variable to tell Git what to use for an editor as below:
SET GIT_EDITOR=GitEditor.EXE
You can configure this with git config --global core.editor GitEditor.exe as well.
Command-line Aliases
The last of the streamlining process is specific to Take Command but can be achieved using BAT files on the path (I’m sure other command interpreters have similar capabilities). Take Command allows you to create aliases for complex command so I’ve created shorter versions of the common Git commands. The %$ at the end of the aliases passes all the command line parameters to Git, you may need to do %1 %2 %3 etc. in BAT files.
ALIAS G = `GIT %$`
ALIAS GA = `GIT add -v %$`
ALIAS GC = `GIT commit %$`
ALIAS GD = `GIT checkout Development %$`
ALIAS GH = `GIT help %$`
ALIAS GL = `GIT lg %$`
ALIAS GK = `GITK –all`
ALIAS GM = `GIT checkout master %$`
ALIAS GS = `GIT st %$`
ALIAS GT = `GIT tag -a %$`
ALIAS GTL = `GIT tag –list %$`
Git Flow
All of the above lets you work with Git more easily however one of the strongest aspects of Git is its branching and what that opens up to you in terms of development work flow. The Git documentation has a number of suggestions however I would highly recommend you read about Git Flow (Gitflow Workflow). At the moment I’m using the workflow suggested but implementing it manually using the built in Git command. Once I’m happy with how it all works I might start using the GitFlow commands but it opens up a world of possibilities for bug fixing and release cycles that were simply not possible before.
I hope to helps those of you who are either starting with Git or want to learn more.
D.