These commands will identify who you are to Git. They will store this information in the current repository which may be fine. If you don’t want to have to keep entering this information for each repository however you can run the commands with the global flag:

Now Git will remember these settings for all repositories for you. This is probably how you want to edit most of the config settings (globally) in most circumstances. While we are editing the configuration we should tell Git what editor we want to use with Git. This command looks like this:

git config --system core.editor C:\Windows\notepad.exe

Note in this case we have updated the system configuration which will apply to anyone using Git on this machine. Git looks for the first place to find a configuration setting. It looks first in the repository config (no command line switch), then your user config (—global) and finally in the system config (—system) file. There are a couple more settings you should tend to. Git does not have a tool for showing file differences. You can use any tool that you like.

git config --global merge.tool vimdiff

Finally, you may want to set how Git handles end of line (EOL), characters. Anytime you are sharing text files across multiple computers there is the question of how lines are ended. If you do not know there are differences to the characters that mark the end of a line on different computers. The trick is that you don’t want Git telling you that all the lines in the file are different because someone on a different system edited the file and their editor replaced all the end of line markers. Git can handle this situation for you. The autocrlf feature will convert Windows line ending to Unix line ending when the files are put back into the repository.

git config --system --core.autocrlf true

Now that Git is setup, let’s add some files.

git init

To start working we need a repository. Git creates the repository when you run the git init command. Git will create a folder called .git. There is nothing in this folder you need to look at. It is important that this folder is being backed up somehow as all of the change history that is being tracked is in this folder.

So now that we have run git init we have a repository but there are no files in it. Not very interesting.

git add

Not surprisingly the command to add files in git is git add. This adds the files to a staging area. Since Git was designed around a command line interface (CLI) there needed to be a way to select the files you want to act on. This staging area is that list. People will often use git add . orgit add -A. The first command git add . will add files that are new or that have been modified to the staging area. Git add -A will add new files, modified files and note any files that have been removed. For this tutorial we will use a shared directory for our examples. This directory will have a line for each person with their name, phone number and file name of their picture. Let’s say Fred Foyle is starting this directory, so he creates a file with his information and his picture.

Now that our list of files has been staged we can “look” at the list using the git status command.

A couple of things to note. The [master 7576855] tells you that the commit was added to the master branch (more on branches later) and the commit has an ID of 7576855. The ID will become important when we start SharingWithOthers. Note that the commit records all the changes, in this case both files. Also note that though Git allows for adding binary files (like ffoyle.jpg) it will not track differences in binary files.

Now that we have a start our man Fred decides to add his son to the directory. After adding his son’s name to the directory Fred copies a picture also. Then if you run git status you will see something like this:

So git add . will add all the files and git add MichealF.jpg adds that one file. If you have several files to add it may become tedious to add them one at a time, so git allows you to add them interactively.

git add -i

Then follow the prompts.

With Git, you can commit changes frequently. Because these changes are committed locally to the repository on your machine, no one else will see them until you are ready to share them.

Note that you do not have to checkout files you wish to modify. You just make changes and Git notices which files you’ve changed.