Starting Out With Git
At the end of this lab you will be able to:
Install git on windows
Create a git repository
Perform basic git functions on the repository
Part 1 - Install Git
First, we're going to install “Git For Windows”. For the lab, we have
provided the download file for you. For your real installations, you can
retrieve the download from “http://git-scm.com/download/win”. It is free
software, licensed under the GPL.
Using Windows Explorer, navigate to C:\Software.
Locate the file Git-1.9.5-preview20150319.exe, and double-click on the file to run it.
Windows may show a security warning that says the publisher cannot be verified. Click Run to allow the installer to run.
Windows may show the User Account Control dialog. Click Yes to allow the installer to proceed.
The installer will show the first Git Setup dialog. Click Next.
The installer shows the licensing dialog. Click Next.
Accept the default for the installation location by clicking Next.
The installer shows the Select Components dialog. Leave all the defaults as-is, and then click Next.
The installer will display the Select Start Menu Folder dialog. Leave the default as-is and then click Next.
The installer will display the Adjusting your PATH environment dialog. Click the radio button for Use Git from the Windows Command Prompt, and then click Next.
The installer displays the Configuring the line ending conversion dialog. Leave the default as-is, and then click Next.
The installer will run for a few seconds installing Git.
The installer will display the Git Setup dialog. Un-check the checkbox for View ReleaseNotes.rtf, and then click Finish
That's it! We've installed Git for Windows
Part 2 - Set Windows Explorer View Options
By default, Windows Explorer hides the extensions of files when there is
an application associated with that file. We're going to shut that off
so that we can see the entire file name in Windows Explorer.
Open Windows Explorer by clicking on the icon in the task bar.
Note. The following steps are for Windows 8 and may vary on other OS.
In the main menu, select View → Options.
Explorer will display the Folder Options dialog. Click the View tab to select it.
Find the entry for “Hide extensions for known file types”. Make sure it is un-checked, and then click OK.
Leave the Windows Explorer window open – we'll be using it in the next part of the lab.
Part 3 - Create a Workspace Folder with a Repository
Use Windows Explorer to create a folder in the C: drive called C:\workspace
Double-click on the new folder to enter it.
Create a new folder called BasicOperations
Open a Windows Command Prompt by going to the start menu () and then typing 'com'. The search box will appear, and one of the entries in it should be the "Command Prompt". Click the command prompt to open it.
At the command prompt, enter
At the command prompt, enter
You should see git create the repository, as shown:
Go back to the Window Explorer. Double-click on the BasicOperations folder to enter it.
There probably appears to be nothing in this folder, but there is
actually a hidden folder that contains the git repository. Let's change
the view options so we can see it.
In the Explorer main menu, click on View menu. Find the Show/Hide panel and ensure that the Hidden items checkbox is selected.
Now we can see that there is a folder called '.git' inside the BasicOperations folder. This folder is the git repository. The name comes from the Unix convention where the shell's 'ls' command considers a file 'hidden' if it starts with a '.' character.
Part 4 - Tell Git Who You Are
One interesting aspect of Git is that it separates user identity in the
repository from any sort of authentication or authorization. Because a
distributed repository will generally be maintained by many separate
individuals or systems, the identity of the committer must be contained
in the repository – it can't just be supplied as a user id when we do
the commit. So, even if we're not connected to any central repository,
we need to tell Git who we are. The identity that we supply will be
recorded whenever we commit to a repository.
For the purposes of this lab, we're going to use an imaginary user named
“Alice Smith”, who has an email address “
firstname.lastname@example.org (alice at smith dot com#_blank)
Ensure that the Command Prompt is showing the BasicOperations folder from the last part of the lab.
Enter the following two lines in the Command Prompt:
git config --global user.name "Alice Smith"
git config --global user.email email@example.com
Ensure that there were no error messages. The output should be similar to:
Part 5 - Create Files and Commit Them to the Repository
Now we'll create a file or two and do our first commit. For the sake of
simple tools, we're going to just use Notepad here, since it's
already installed with Windows, but feel free to install and use a
different editor if you prefer.
Ensure that Windows Explorer is showing the BasicOperations folder from the last part of the lab.
Right-click in an empty area of the main panel, and select New → Text Document.
Windows will create the new file, and should leave the file name selected for you to edit. Change the file name to Sample.txt
Double-click on Sample.txt to open it in Notepad. Change the contents to read “First Version.” and hit enter.
Save the file by clicking File → Save, and then close the file by clicking the close button.
At this point, the file is there, but Git isn't tracking it yet (even
though Git certainly knows it's there, after all it's in the file
system). Let's add the file into Git's staging area.
In the command prompt, enter:
Git will tell us about the files it sees in the folder:
As we can see, git is aware of the new file, but it is "untracked".
Let's change that.
At the command prompt, enter:
git add .
The '.' says to add the contents of the current directory. If you
preferred, you could have called out the name of the file itself.
At the command prompt, enter
Git should now report that the file is "staged" as a file to be committed.
Before we do the commit, let's talk about the default editor. A Commit
needs to be accompanied by a 'commit message' that goes into the
repository's log to explain the commit. We could provide a commit
message with the '-m' option to git's command line, however, that tends
to lead to short, one-line commit messages. Normally, we'd like to be a
little more descriptive with the commit message. As a result, if we
don't specify a commit message, git will open up an editor with a
default message from a template.
By default, the editor is a Windows version of 'vim' that was installed
with the git package. If you're familiar with 'vim' then go ahead and
use it (it's an excellent programmer-oriented editor), but if you're not
already a 'vim' user, it's a little complicated to explain here. So,
we'll change the default editor to Wordpad in the next step.
At the command prompt, enter (all this should be on one line):
git config --global core.editor
Note the single quotes and double-quotes in the above line. They need to
be typed exactly as shown, because the path to the wordpad executable
At the command prompt, enter:
An instance of Wordpad should open, with the default commit message in it.
Enter a message at the top of the file. For instance, “First commit in the new repo.”
Save the file by selecting File --> Save, and then exit Wordpad by clicking the close button.
The command prompt should reflect the completed commit:
Open the 'Sample.txt' file with Notepad again, and then change the contents to read 'Second Version'. Save and close the file.
Once again, go to the command prompt and enter:
Git should tell us that 'Sample.txt' was modified, but is not currently
staged for commit.
If we were to commit now, we would actually be committing without any
changes. In fact git will tell us that there are no changes staged, and
we need to add files before committing.
At the command prompt, enter:
Git will show us what' changed in the folder.
Having reviewed the 'diff', we can decide to go ahead and commit all the changes. At the command prompt, add all the updated files into the staging area by entering:
git add .
At the command line, enter:
Git opens up Wordpad with the proposed commit message. Note that the file now appears under 'Changes to be committed'.
The commit message is intended for us to give a description of the commit that will be useful when we review the logs. Enter 'We're on the second version.', and then save the file and close Wordpad.
Part 6 - Review the Change History
At this point, we've now committed two different versions of the file
'Sample.txt'. Let's see if we can find any evidence of this history.
Just to be different, let's try out Git's command shell.
Ensure that the Windows Explorer window is still open and displaying the C:\workspace\BasicOperations folder.
Right-click in an empty area of the window, and then click on 'Git Bash'.
Git will display a new terminal window with a '\$' prompt. If you've
used Unix or Linux, you may recognize this as the Bourne shell or 'bash'
prompt. In fact, Git for Windows includes a variant of the 'bash' shell
derived from the 'Cygwin' system. Cygwin is a software package that
provides a traditional Unix-style shell and the full set of Unix-style
utilities in a Windows environment. Git for Windows includes a subset of
The git commands are available at a command prompt, or through the 'Git
Bash' facility, or also in Windows PowerShell. The commands and
arguments are identical in all three access modes, so choosing one is a
matter of individual taste.
Type 'git log' and press return.
Git displays a list of all the commits that we have done, in reverse
Leave the Git Bash window open for the next part of the lab.
Part 7 - Delete a File and Recover It
In this section, we'll demonstrate that files are actually stored in the
repository, even if we delete the file in our folder.
Using Windows Explorer, delete the file 'Sample.txt'. Right-click on the file and select Delete.
git In the Git Bash window, type 'git status' and press return.
Notice that git sees the removal as a change that has not been staged or
committed. If we really wanted the change to stick, we could say 'git rm
Sample.txt' to stage the removal, and then we could commit the change.
Instead, we'll recover the file from the repository.
Type 'git checkout -- Sample.txt' and then press return.
Note that 'Sample.txt' has re-appeared in Windows Explorer.
Note: The command 'git checkout -- Sample.txt' looks a little funny –
what's the double-dash for? The answer will make more sense after we've
talked about branches. Basically, it's possible to pull a file in from a
different branch than the one that we're currently on, so the 'git
checkout' command actually allows you to specify the branch name and the
file path we want to recover. '--' separates the parameters from the
list of files, and basically indicates the current branch.
Part 8 - Use a '.gitignore' File
It's common to have files in a working directory that we don't really
want to put into the repository. For example, a compiler might take
“hello.c” and generate “hello.o”. Since “hello.o” is a generated file,
and will be regenerated every time we execute the build, it makes no
sense to put it into version control. We can create a file called
'.gitignore' that specifies a set of patterns to specify files that
should be excluded from the repository.
Ensure that our Windows Explorer is still displaying the 'C:\workspace\BasicOperations' folder.
Right-click in an empty area of the Explorer window, and then select New → Text Document.
Explorer will show the new file, with the base part of the name (excluding '.txt') selected. Type 'gitignore'. Right now we are calling the file 'gitignore.txt'.
Note: We really want the file to be called '.gitignore', but Windows
Explorer doesn't like that style of name. We're going to edit the file
in a format that Explorer likes, and then rename it in the bash prompt
Alternately, if you are familiar with the 'vi' editor, the git bash
utility includes a version of 'vim' that you can open from the bash
prompt, with command 'vi .gitignore'.
Double-click on 'gitignore.txt' to open it in Notepad.
Add the following three lines to 'gitignore.txt':
Save and close the file.
In the git bash window, enter:
mv gitignore.txt .gitignore
and then press return.
In the git bash window, enter 'git status' and press return.
Notice that git is telling us that we have unstaged changes – the
'.gitignore' file that we just created. This time we'll use the command
line to add and commit them.
In the git bash window, enter 'git add .' (note the 'dot' at the end) and then press return.
In the git bash window, enter the following line, and then press return:
git commit -m "We now have an ignore file."
In this example, we've used a shortcut "-m" option to specify the commit
message. If you leave out that option on the command line, git will open
up an editor (in this case 'vi') to let you edit the commit message.
Enter the following line and then press return, to create a file called 'hello.o':
echo 'Hi there' > hello.o
Enter 'git status' and press return.
Notice that git reports nothing to commit. Because the file name
'hello.o' matches the pattern in the line '*.o' in our '.gitignore'
file, git ignores it. It would also ignore a file called
'local.properties' and a folder called 'temp'.
In this lab, we started off by installing Git for Windows, and then
created a repository and executed a few simple operations on it.
One concept to note is the idea of the separate areas of a project that
we're managing under git: the working directory, the staging area, and
the repository. The working directory is the area that is currently in
the operating system's file system. We make changes to files in the file
system, and then tell git which changes we want to record by copying the
changes to the staging area (or 'staging' them) using 'git add'. Then we
put the changed snapshot into the repository by 'comitting' them. Once a
file is in the repository, it is there forever, even if we remove it
from the working directory. We can recover any version of the file that
we've previously committed.