Skip to content

git workflow trial environment

git is an unbelievably powerful tool which is unfortunately rather picky in choosing its friends. Documentation is available in copious amounts and this blog article adds to the mountain.

Unfortunately, the documentation out there always assumes the ideal case: A small project, a handful of colleagues who are motivated and doing the right thing, a workflow agreement that matches the work to be done and no mistakes. Reality is different, and so you might find yourself wedged in broken workflows, surrounded by unwilling or incompetent cow-orkers and/or a git repository that has grown historically and still is carrying the burden of misguided work of decades.

In this blog article, I'd like to introduce you to my way of trying things with git. It allows you to easily do things in the right and in the wrong way while immediately seeing the results of your actions. Let me know whether it's of any help for you to grok git (which I have not fully managed yet).

Your new best friend is

git log --graph --oneline --decorate --all

and here is what it does:

  • git log - it shows the git log of your repository
  • --graph - Draws a text-based graphical representation of your history. Much like the nifty graphs in the git man pages and the literature, but top-down instead of left-right
  • --oneline - Shorten the commit IDs and print only the title lines' commits
  • --decorate - adds the names of refs (like tags, branches) to your commits.
  • --all - Show all commits, not only the ones leading up to your current working copy

This is a sample output from a rather simple repository:

Screenshot of a shell showing colored git log output

When you're actively trying things, use this in another window:

watch --color git log --graph --oneline --decorate --all --color=always

This gives you the first page of your git log, refreshed once every two seconds, in color. watch --color allows color codes to get through, --color=always tells git to use colors even if it is not directly talking to a terminal. This is a really nifty help since you'll immediately see the results of your actions.

Now to the core of the trick, the shell script "tgit" for test git.


  echo "\\$ $@"                                                                  
case "$1" in                                                                    
        n) ;;                                                                   
                if ! [ -d .git ]; then                                          
                        cmd git init                                            
                DATE="$(date +%H:%M:%S.%N)"                                     
                echo echo $DATE \\>\\> $FILE                                      
                echo $DATE >> $FILE                                             
                cmd git add $FILE                                               
                cmd git commit -m "$FILE: $DATE"                                
        *) cmd git "$@" ;;                                                      
echo "---"                                                                      
git --no-pager log --graph --oneline --decorate --all                           
exit 0                                                                          

This is what it does:

  • regardless of its parameters, it will output the repository status with git log ... to the console before terminating. This invocation does not use a pager to return you immediately to your prompt so that you still can see the result of your last operation while typing the next one.
  • if invoked with a single parameter "n", it will just output the repository status.
  • if invoked without parameters or with the parameters "f filename", it will append the current timestamp to the given file (or to a new file with the timestamp in the file name), add the file and commit it. If the current directory is not a git repository, it will git init it. This allows you to "do some work" in the repository quickly to be able to see commits. A new file being used every time prevents merge conflicts, while using f with the same filename repeatedly allows you to force merge conflicts.
  • in all other cases, the parameters are taken as parameters to a call to git.

If you alias git to tgit, you can use the script as if it were a git binary so that your finger memory doesn't get confused, with the addition that you can easily create a simple commit and that you see the results. The following two screenshots show a simple session of a new repository, two branches, and a merge.

git screenshot 1
git screenshot 2


No Trackbacks


Display comments as Linear | Threaded

No comments

Add Comment

Markdown format allowed
Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
Form options