Starting Out With Git

At the end of this lab you will be able to:

1. Install git on windows
2. Create a git repository
3. 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 “https://git-scm.com/download/win”. It is free software, licensed under the GPL.

1. Using Windows Explorer, navigate to C:Software.
2. Locate the file Git-1.9.5-preview20150319.exe, and double-click on the file to run it.
3. Windows may show a security warning that says the publisher cannot be verified. Click Run to allow the installer to run.
   
4. Windows may show the User Account Control dialog. Click Yes to allow the installer to proceed.
   
5. The installer will show the first Git Setup dialog. Click Next.
   
6. The installer shows the licensing dialog. Click Next.
   
7. Accept the default for the installation location by clicking Next.
   
8. The installer shows the Select Components dialog. Leave all the defaults as-is, and then click Next
   
9. The installer will display the Select Start Menu Folder dialog. Leave the default as-is and then click Next.
   
10. 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.
    
11. The installer displays the Configuring the line ending conversion dialog. Leave the default as-is, and then click Next.
    
12. The installer will run for a few seconds installing Git.
13. 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.

1. 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.
2. In the main menu, select View → Options
   
3. Explorer will display the Folder Options dialog. Click the View tab to select it.
   
4. Find the entry for “Hide extensions for known file types”. Make sure it is un-checked, and then click OK.
5. 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

1. Use Windows Explorer to create a folder in the C: drive called C:workspace
2. Double-click on the new folder to enter it.
3. Create a new folder called BasicOperations
   
4. 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.
5. At the command prompt, entercd workspaceBasicOperations
6. At the command prompt, entergit init
7. You should see git create the repository, as shown:
   
8. 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.

1. In the Explorer main menu, click on View menu. Find the Show/Hide panel and ensure that the Hidden items checkbox is selected.
   
2. 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 “

alice@smith.com (alice at smith dot com#_blank)

1. Ensure that the Command Prompt is showing the BasicOperations folder from the last part of the lab.
2. Enter the following two lines in the Command Prompt:git config –global user.name “Alice Smith”git config –global user.email alice@smith.com
3. 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.

1. Ensure that Windows Explorer is showing the BasicOperations folder from the last part of the lab.
2. Right-click in an empty area of the main panel, and select New → Text Document.
3. Windows will create the new file, and should leave the file name selected for you to edit. Change the file name to Sample.txt
4. Double-click on Sample.txt to open it in Notepad. Change the contents to read “First Version.” and hit enter.
5. 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.
6. In the command prompt, enter:git status
7. 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.
8. 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.
9. At the command prompt, entergit status
10. 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.
11. At the command prompt, enter (all this should be on one line):git config –global core.editor
    “‘C:Program FilesWindows NTAccessorieswordpad.exe'”
    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 contains spaces.
12. At the command prompt, enter:git commit
13. An instance of Wordpad should open, with the default commit message in it.
14. Enter a message at the top of the file. For instance, “First commit in the new repo.”
15. Save the file by selecting File –> Save, and then exit Wordpad by clicking the close button.
16. The command prompt should reflect the completed commit:
17. Open the ‘Sample.txt‘ file with Notepad again, and then change the contents to read ‘Second Version’. Save and close the file.
18. Once again, go to the command prompt and enter:git statusGit 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.
19. At the command prompt, enter:git diffGit will show us what’ changed in the folder.

1. 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 .
2. At the command line, enter:git commit
3. Git opens up Wordpad with the proposed commit message. Note that the file now appears under ‘Changes to be committed‘.
4. 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.

1. Ensure that the Windows Explorer window is still open and displaying the C:workspaceBasicOperations folder.
2. 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 these utilities.The git commands are available at a command prompt, or through the ‘Git Bash’ facility, or also in Windows PowerShell. The commands an arguments are identical in all three access modes, so choosing one is a matter of individual taste.
3. Type ‘git log’ and press return.Git displays a list of all the commits that we have done, in reverse chronological order.
4. 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.

1. Using Windows Explorer, delete the file ‘Sample.txt‘. Right-click on the file and select Delete.
2. 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.
3. 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.

1. Ensure that our Windows Explorer is still displaying the ‘C:workspaceBasicOperations‘ folder.
2. Right-click in an empty area of the Explorer window, and then select New → Text Document.
3. 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 window.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’.
4. Double-click on ‘gitignore.txt‘ to open it in Notepad.
5. Add the following three lines to ‘gitignore.txt‘:*.olocal.propertiestemp/**
6. Save and close the file.
7. In the git bash window, enter:mv gitignore.txt .gitignoreand then press return.
   
8. 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.
9. In the git bash window, enter ‘git add .‘ (note the ‘dot’ at the end) and then press return.
   
10. 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.
    
11. Enter the following line and then press return, to create a file called ‘hello.o’:echo ‘Hi there’ > hello.o
12. 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’.

Review

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.