From Creating a Repository to History

1. Create a “Hello, World!” page

mkdir hello 
cd hello 
touch hello.html
Hello, World!

2. Create a repository

git init

3. Add the page to the repository

git add hello.html 
git commit -m "First Commit"

4. Check the status of the repository

git status

The command checks the status and reports that there’s nothing to commit, meaning the repository stores the current state of the working directory, and there are no changes to record.


5. Changing the “Hello, World” page (hello.html)

<h1>Hello, World!</h1>

Repeat step 4.

The first important aspect here is that git knows hello.html file has been changed, but these changes are not yet committed to the repository.

Another aspect is that the status message hints about what to do next. If you want to add these changes to the repository, use git add. To undo the changes use git checkout.


6. Adding changes

git add hello.html

Repeat step 4.

Changes to the hello.html have been staged. This means that git knows about the change, but it is not permanent in the repository. The next commit will include the changes staged.

Should you decide not to commit the change, the status command will remind you that you can use the git reset command to unstage these changes.


7. Staging and committing

A staging step in git allows you to continue making changes to the working directory, and when you decide you wanna interact with version control, it allows you to record changes in small commits.

Suppose you have edited three files (a.html, b.html, and c.html). After that you need to commit all the changes so that the changes to a.html and b.html were a single commit, while the changes to c.html were not logically associated with the first two files and were done in a separate commit.

In theory you can do the following:

git add a.html 
git add b.html 
git commit -m "Changes for a and b"
git add c.html 
git commit -m "Unrelated change to c"

Separating staging and committing, you get the chance to easily customize what goes into a commit.


8. Commiting the changes

When you previously used git commit for committing the first hello.html version to the repository, you included the -m flag that gives a comment on the command line. The commit command allows interactively editing comments for the commit. And now, let’s see how it works.

If you omit the -m flag from the command line, git will pop you into the editor of your choice from the list (in order of priority):

  • GIT_EDITOR environment variable
  • core.editor configuration setting
  • VISUAL environment variable
  • EDITOR environment variable
git commit

On the first line, enter the comment: “Added h1 tag”. Save the file and exit the editor.

git commit 
Waiting for Your_editor... 
[master 412af12] Added h1 tag  
1 files changed, 1 insertions(+), 1 deletions(-)

Repeat step 4.

The working directory is clean, you can continue working.


9. Changes, not files

Most version control systems work with files. You add the file to source control and the system tracks changes from that moment on.

Git concentrates on the changes to a file, not the file itself. A git add file command does not tell git to add the file to the repository, but to note the current state of the file for it to be commited later.

  • First Change: Adding default page tags
<html>
  <body>
    <h1>Hello, World!</h1>
  </body>
</html>
  • Add this change
git add hello.html
  • Second change: Add the HTML headers
<html>
  <head>
  </head>
  <body>
    <h1>Hello, World!</h1>
  </body>
</html>
  • Check the current status
git status

Please note that hello.html is listed in the status twice. The first change (the addition of default tags) is staged and ready for a commit. The second change (adding HTML headers) is unstaged. If you were making a commit right now, headers would not have been saved to the repository.

  • Commit
git commit -m "Added standard HTML page tags" 
git status

The status command suggests that hello.html has unrecorded changes, but is no longer in the buffer zone.

  • Adding the second change
git add . 
git status

Note: The current directory (‘.’) will be our file to add. This is the most convenient way to add all the changes to the files of the current directory and its folders. But since it adds everything, it is a good idea to check the status prior to doing an add ., to make sure you don’t add any file that should not be added.

  • Commit the second change
git commit -m "Added HTML header"

10. History

git log

Details are provided in the git-log instruction.

  • One line history
git log --pretty=oneline
  • Controlling the display of entries
git log --pretty=oneline --max-count=2 
git log --pretty=oneline --since='5 minutes ago' 
git log --pretty=oneline --until='5 minutes ago' 
git log --pretty=oneline --author=<your name> 
git log --pretty=oneline --all
  • Getting fancy
git log --all --pretty=format:"%h %cd %s (%an)" --since='7 days ago'

This is what I use to review the changes made within the last week. I will add --author=petraks if I want to see only the changes made by me.

  • The ultimate format of the log
git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short

where:

  • --pretty="..." defines the output format.
  • %h is the abbreviated hash of the commit
  • %d commit decorations (e.g. branch heads or tags)
  • %ad is the commit date
  • %s is the comment
  • %an is the name of the author
  • --graph tells git to display the commit tree in the form of an ASCII graph layout
  • --date=short keeps the date format short and nice
  • Other tools

Both gitx (for Mac) and gitk (for any platform) can help to explore log history.