Git is an open source, free, distributed, version control system created by Linus Torvalds the creator of Linux.  A version control system tracks changes in the files and folders of your project over time, and allows you to recover back versions.  It can be used on a large variety of projects by software developers and writers, for example.  It was built to be a distributed, and allow developers working around the globe to collaborate, and at the same time work independently of one another.

Git created on Linux in 2005, has since been ported to both Mac and Windows.  This article will focus on installing Git on Windows.  There’s a lot of good documentation on Git out there on the Internet, and several Git books have been published that will walk you through how to use the program after its installed.

To get Git,  go to the download site here.   Select the “Git-1.7.0.2-preview20100309.exe”  full installer for Windows, download it, save it, and click on it to install.  The installer will install a Linux command window, like the Windows command window on your computer.  You will initially use the program in the Linux command window.  Have no fear, there are a couple of GUI’s that will make life easier, if your not a Linux user.

Let’s walk through the installer screens which can be confusing your first time through.  Click the exe file, click run, and you get:

Click Next and you go to the GNU license:

The next screen asks you where you’d like to install the program.  The default is fine.

The Next Screen is the first one that asks you to make some choices.

Additional icons will put an icon you can click on your desktop to open the Git command window.   In the Windows Explorer Integration, click both Git Bash and Git GUI.  Git Bash is the Linux Command Window that, at least initially, you will use to run Git.  Git GUI is a graphical user interface, you can use instead of the command line.  This is a full page Gui that you can use to visually run GIT.   The choice of BASH and GUI eliminates  git cheetah, a windows client interface you could use with Git.  I recommend BASH and GUI.   Next…

If you want to put the Git start-up menus for Git Bash and the Git GUI in a particular folder in your Start Menu in Windows, this is where you can tell the Installer where to put the links.  The default is fine, you can always change it later.   A caution here, if your running Windows 7, 64bit, you should check “Don’t create a Start Menu Folder, then after the program is finished loading, right click on any Start menu folder, and select “Git Bash Here.”  There is a bug with Windows 7, 64 bit, and this is a work around.  Next the path environment screen …

The three choices ask how you want to run the program.  Choice 1 means you’ll open up a Bash Linux command window and work with Git this way.  Choice 2 should only be used if you are running Cygwin’s Git, which we are not, which leaves Choice 3 with the red warning.   Ignore this warning, you want to run the Git tools, like the GUI for example.  Choice 3 it is.  Next…

This screen can be confusing.   In Windows, we run Git in a Linux command window environment as if it were Linux.  Files have different line endings in Linux than in Windows files.  Your development on Windows is done with Windows files.  This screen is asking if you want your files and folders stored in the repository with Windows line endings or Linux line endings.  You would think that choice 3 is a no brainer, don’t convert anything.  Hold on though.  If you ever want to share your work with others or put your work in another repository on a Linux machine, you’ll need to do the conversions.  Git will take care of these conversions automatically, so why not use Choice 1.  When you get files from the repository it will convert to Windows line feeds, when you put them into the repository it will convert to Linux line feeds.   Git is lightning fast, so there’s minimal hit on performance.  Choice 2 can get you in trouble, and is more for a Linux environment.  I recommend Choice 1.  Next…  and your off.

Congratulations, you’ve installed Git.  If you want to get started,  Git comes with a two built in graphical interfaces, which I’ll cover in my next post.

Recently I switched my version control software from Bazaar to Git. I did this for a couple of reasons, one of which was I was using Tortoise Bazaar and every time I had to find a file in my Windows Explorer or Zend Studio file explorer, it took forever for Tortoise to synchronize so you could even see the folder to open a file. In all fairness to Bazaar, I think it was more a Tortoise problem than a Bazaar problem.

We looked around for a version control system that was distributed when we first set up the version control about a year ago. Git, at the time, did not have a Windows port and Mercurial was not really ready yet either. We had a mixed Linux, Windows environment. That left Bazaar, which easily out featured CVS and SVN, which are not distributed. This is not a review of either Bazaar, Git, or Mercurial, I want to reserve judgment until I spend some time with Git.

I resolved when I first started posting to this blog that if any problem took me some time or I couldn’t find a lot of information about it on the web, I would write a post about it. This is one of those.

Git for Windows is available in two distributions, one uses the Linux environment for Windows provided by Cygwin, and the other uses an environment installed with the Git installation using msysgit. All postings seem to recommend the later choice available here
use the Full Installer for official Git.

During the install check that you want the GUI and the BASH and check the bottom box with the red warning and you’ll know what I mean when you get to it. There is some good documentation on Git install for Windows except not many of them tell you which boxes to check on the Windows install. I installed twice before I got it correct.  See my article on “Installing Git on Windows” for a complete walk-through.

Git will install an icon on your desktop. When you click the icon, it will bring up a command window, that command window is a Linux environment. Change to the directory where you’d like to start a repository, type git init, and it will set up a repository for your files. If you’d like all your files in the repository, type “git add .” including the period. but not the quotes followed by “git commit -m “first commit”.  You’ve done your first commit.

You will want to know more, and Git has great documentation, but none better that the book written by Scott Chacon available on Amazon here, and online for free here.  Please buy the book, and read it online, while your waiting for your book to come.

What I wanted to write about when I started this post is a small irritating problem that I experienced. When you open the Git Bash Window, it opens in the same start directory that Windows opens when you open a cmd window in Windows. That’s a small problem, because your repository is located in another directory and in the Linux Git Bash window you have to do the “cd ..” and “pwd” and “ls” until you arrive at your repository directory. To me that is a minor pain since usually the repository is far and many levels from your starting directory. Every time I use the Git Bash window you have to go through this.  There has to be shortcut.

I searched for a quick solution to this on the Internet and it’s not well documented. I thought about setting an environmental variable, or writing a short Linux script to run, when actually there’s is a quick way to go back and forth from your start directory to your repository using the tilde ~.

For example, if Windows sets your start directory at “C:\Document and Settings\Dale”,  and if you want your working repository to be located at “C:\wamp\www\Joanna”   you can designate the later as your HOME directory in Windows.   This is done in Windows by right clicking on Start>My Computer>properties>Advanced>Environmental Variables.  Under system variables, click on HOME and the Edit to the directory where ever your currently working.  In git bash this sets your ~ character to that directory.

Click the Git Bash icon to open the Linux command window and …

// Your current directory is your start directory
$ pwd
// the output
$ /c/Document and Settings/Dale

// To go to the repository directory
$ cd ~
// or
$ cd $HOME

//Check the directory
$ pwd
// the output
$ /c/wamp/www/joanna

// to go back
$ cd ~-
// check the directory
$ pwd
$ /c/Document and Settings/Dale
// and your back to your start directory

This makes switching directories a lot easier, however it creates a couple of problems, which I’ll talk about in part 2 here.

It seems like my first posting on changing directories inside of Git Bash on Windows has some problems.  I’d like to explore this a little more by going through some other choices.

If you change your Windows Home directory as recommended in my first post so that cd ~ will go to  your current working directory, everything will work fine, except this does leave you with a couple of hangovers. First, every time you switch to another project you end up having to switch your Windows Home directory, it would be better to have something like a Windows .bat file to change the directory with a different .bat file for each project.  Nice thought, but Bash is a Linux environment and .bat files are Windows script files. So no dice there.

The second reason that you probably shouldn’t change your Windows Home directory is that git stores its config file ~/.gitconfig file in your Home directory.  If your switching home directories back and forth, git could loose track of where your .gitconfig file is, or you will have to duplicate the .gitconfig multiple times for each project.  This is a poor solution as you have to change every .gitconfig file if you change one of them so git will perform the same in every repository.  True, git will run without the .gitconfig file, but you want your mergetool, for example, when you need it.

Those Windows .bat files seem nice, and Linux has what is called shell scripts that are very much like .bat files with one exception, when you run a shell script it runs in its own shell space.  If you say change directory inside this shell, you will change directories inside that shell, but when you exit, you go back to the originating shell, and lo and behold you’re right back where you started.  Linux shell scripts will not work in this case.

How about symlinks, or symbolic links?  Symbolic links allow you to assign a name as a reference to another file or directory.  Symlinks are mainly used to manipulate files, not change directories.

Well, what about using an alias. Something like this:  “alias cbc=”cd /c/wamp/www/cbc”    Now when you type cbc at the command prompt, you’ll go to /c/wamp/www/cbc.   Well, this works fine, and is what we want, except for one problem.  It lives only for your current session of git Bash.  When you exit the window, it blows the alias away.  Aliases need to be loaded every time you open the git Bash window.

It turns out that when git Bash opens,  it looks  for, and loads the .bash_profile file located in your home directory, another reason not to move your home directory around.  When you first install git, you will not find a .bash_profile file.  You have to create it.  Let’s do that.

You can not use a Windows editor because of the different line feeds in Linux files versus Windows files.  We’ll use the vi editor that comes with git Bash.  Open git Bash.  You should be in your home directory.  It should have the .gitconfig file in it.  Which you can look for with a “ls -al” command.

I’m not sure of the level of reader reading this, so bear with me, and  I’ll slow down a touch.  Open the vi editor at the command prompt by typing vi .bash_profile.  When the edited file is saved this will create the .bash_profile file in your home directory.

The vi window opens in command mode, you need to move into insert mode.  Type i and you will enter the editors insert mode.  Now type your alias.  “alias cat=”cd /c/wamp/www/cat/rel_0.1.2″   is the syntax for the alias command.  Note the forward slash /, and the c drive is just c not c:  You start with the /.  You can put as many aliases you want, one per line.  If you have a couple of projects, I would make an alias for each project.

When your done typing, you’re still in insert mode in the vi editor.  To go back to the command mode to write the file, hit the escape key, and then type :wq that will save the file and quit the editor.  If you make a mistake and want to leave the editor without saving, type :q!, and try again.

There’s one gottcha here.  The .bash_profile loads when the git bash command window opens.   After you first complete your .bash_profile file in the vi editor, it’s still not loaded.  You have to close down and restart the git bash window before the alias will work.

If you ever forget what your aliases are, just type “alias” at the command prompt, and all your alias will print out.  Try it.

Try your alias out.  If it doesn’t take you to the correct directory, go back and edit the .bash_profile file until it does what you want.  To go back to your home directory, type “cd ~”.  Type your alias again and go back to your working directory.  Minor problem solved, and more important, your back to one .gitconfig file for your globals.

Your writing a book and you expect to spend about a year on the project.  To set up your folders, you make a directory called “mybook” and subfolders called “research” and “thebook.” In “thebook” folder you intend to have a file for each chapter of the book, “chapter1.doc” for example.

The way you write from draft to finished chapter, you tend to change a chapter a lot, sometimes cutting out whole paragraphs, or moving sentences to different spots in the chapter.  In the past, you’ve deleted entire sections, and some times have regretted it, because you would have liked to reuse the section some where else in the text, and other times you like the way you worded a sentence, but lost it when you made changes.

With Git version control, you can keep all your history of changes through out your project, and not worry about losing anything.  You can also make a duplicate copy of your book on another computer, and keep your book history up to date while your working.  This is the beauty and benefit of version control.

We’ve installed Git version control on Windows in the last post.  Let’s at least get you started on using Git in this post.

Let’s start tracking.  You should have Git Bash icon on your desktop. Click it and up pops a linux command window.  Don’t panic. This is like the Windows command window, only it runs Linux. There is a neat little GUI that will make the command window go away. Type “git gui” to open it.

Git Gui will ask if you want to create a new repository. “Click Create New Repository,” a new window will open. Browse to the folder where you want to track all your changes, i.e. “mybook,” select it and click “Ok” and “Create.”  Your Git Gui will open.  There is nothing shown in the gui, because you have blank folders.

Open your favorite editor, type in some text and save it as, chapter1. txt or doc in the sub folder “thebook.”  Click “Rescan” in your gui, and wahlah!, git has said you added a chapter1 file in “thebook.” Click on the file, and you’ll see the text you just typed. Go back to your editor, add some more text, save it, click “Rescan” in your Git gui and your changed text will show up. Git tracks every change you make to your files and folders.

The file is not yet saved in your git repository though, let’s do that.  Git has a two stage process to make sure you commit your changes to the git history.  First you have to stage the file, and then commit it. In the upper menu, click “Commit->Stage to Commit” and the file will move to the green staged area in the gui ready for committing.  If you click on the file some additional information has been added to get ready to commit.

Before you can commit the changed file to the repository for tracking, you need to put a message in the “Commit Message” window, as a hint to what was saved on this commit to the repository so when you view the history later you’ll know what changes are stored in that particular commit.

Good, click, “Commit.”  Everything disappeared, what happen? You saved everything in the repository. There are no new changes in the entire file system, so your gui is “clean.”

Make some changes to the chapter1 file, and let’s add a “chap1research” file to the research sub directory.  Click “Rescan.”  Notice in the Git Gui  the “chapter1 file has more text, and there is another file added located in the research sub directory.

Click “Commit->Stage to Commit” and the two files move to “Staged Changes” ready for saving.  Put a commit message in the message window, and click “Commit.” Everything goes away, you have a clean working directory.

Now, let’s go back in history and take a look at “Chapter1″ before the last change.  Go to the upper menu in the Git Gui and click,  “Repository->Visualize Masters History.” This opens gitk.

Gitk tracks the entire history of your project.  Click on your first commit message in the upper left window.   Now move to the lower right window, and you’ll see “thebook/” the book directory. Click on it and you’ll see the file “chapter1.txt”  Click on the “chapter1 file and you’ll see the text in the lower left window that existed before the second commit change to the file.

Let’s see the second commit.  In the upper left window, click on the “master” and in the lower right window, the research directory will now appear.  Click on “thebook” directory again and the “chapter1″ file and you’ll see your chapter1 changes on the second commit.

Git is loaded with functionality.  I’ll leave you to explore some of the other menu choices in these Gui’s.  Git is used by any one that builds projects, like software developers and writers, to keep track of changes in their files.  There are currently three very good books on Git if you’d like to get really proficient.

Sometimes you want to not include files in a repository, files like help files, object files, and temporary files, for example. It’s good to ignore non-source files, because it reduces the number of files you track, and even though Git is the fastest version control software, it still speeds up how fast Git will run. The less files the faster Git is, although I have to admit, it’s not much of an issue with Git.

As an introduction to ignoring these files let’s first define how Git classifies files.

Git groups your repository files into three categories:

Tracked files. Tracked files are any files in your repository or any files you have staged and are getting ready to added to your repository. Tracked files are part of your current “index” of files.

Untracked Files. Untracked files are new files you may have added, since the last commit, and files you have changed, but have not yet staged to be committed, that is files you haven’t run “git add” on yet. Untracked files show up when you run “git status.”

Ignored files. Ignored files are files, or directories, that you designate to be ignored in the repository. Files that will be invisible to Git, even if they are modified in some way.

In order to ignore files in Git, you have to explicitly tell Git what files, or directories, you would like to ignore. This is done in one of two files.

The “.git/info/exclude” file ignores files located in any directories and sub directories in your current Git repository. The exclude file is created when you init your repository, and is located in your hidden Git directory under “info.” Any files listed in the “exclude” file will be ignored by Git.

The “.gitignore” file, which is not created, when you first set up your repository by running “git init.” You will have to explicitly create a .gitignore file where you want it. A .gitignore file can be placed in any sub directories under the top directory. Files declared in “.gitignore” will be ignored in the current directory and any sub directories below. Most folks just place the .gitignore file in the top directory and they’re set.

What is the difference between “.git/info/exclude” and “.gitignore” ? The exclude file is not passed on to other users with a clone command while the “.gitignore” file actually, becomes a tracked file in your repository, and travels with the repository every time the repository is cloned.  This means that a group of developers could have a ghost file that changed, but is ignored floating around, but in reality the fact that a file does not show up in a git status that a developer just modified is a clue for the developer to change the file name, or check the .gitignore file.

Both of these files are text files that are edited with a Linux text editor, like vi. The rules and syntax for ignoring files are:

• One file or directory per line.
• Blank lines are ignored.
• Lines with a # are used for comments.
• A simple file name will match any file with that name in every directory applicable to .gitignore.
• Directory names are indicated with a trailing / which includes any sub directories.
• You can use * as a wild card, but can only match files in the designated directory, like so: “dev/test/*.o” will match all files in test/ ending with “.o”.
• You can have “not” files that are never ignored by starting the listing with a “!”.

The contents of a two .gitignore files with ignored files, and a .git/info/exclude file with no files added.

There is one gotcha. If you commit files and then add them to the .gitignore file, “git status” will show these ignored files in your untracked files ready for a commit.

In order to get around this, you have to remove the files from the git index with “git rm -cached ” This will take it out of the “git status” command. Warning if you just run “git rm ,” it will delete the file, which may not be what you want to do. The “cached” is important.

There is an alternative way to do this, if the rm command makes you uncomfortable, that is, using the “git-update-index –remove ” command to modify the current working index and directory cache. Both of these methods will clear previously committed, but now ignored files, out of your git status, and have them ignored in your repository.