3. Look at the status. Compare it to the status output you had after using the Git built-in rm
command. Is anything different? After this, commit the deletion.
4. Use the Git mv command to move or rename a file; for example, rename README to
README.txt. Look at the status. Commit the change.
5. Now do another rename, but this time using the operating system’s command to do so. How
does the status look? Will you get the right outcome if you were to commit at this point?
(Answer: almost certainly not, so don’t. ) Work out how to get the status to show that it
will not lose the file, and then commit. Did Git at any point work out that you had done a
6. Use git help log to find out how to get Git to display just the most recent 3 commits. Try
7. If you don’t remember, look back in the slides to see what the --stat option did on the
diff command. Find out if this also works with the show command. How about the log
8. Imagine you want to see a diff that summarizes all that happened between two commit
identifiers. Use the diff command, specifying two commit identifiers joined by two dots
(that is, something like abc123..def456). Check the output is what you expect.
1. Run the status command. Notice how it tells you what branch you are in.
2. Use the branch command to create a new branch.
3. Use the checkout command to switch to it.
4. Make a couple of commits in the branch – perhaps adding a new file and/or editing existing
5. Use the log command to see the latest commits. The two you just made should be at the
top of the list.
6. Use the checkout command to switch back to the master branch. Run log again. Notice
your commits don’t show up now. Check the files also – they should have their original
7. Use the checkout command to switch back to your branch. Use gitk to take a look at the
commit graph; notice it’s linear.
8. Now checkout the master branch again. Use the merge command to merge your branch in
to it. Look for information about it having been a fast-forward merge. Look at git log, and
see that there is no merge commit. Take a look in gitk and see how the DAG is linear.
9. Switch back to your branch. Make a couple more commits.
10. Switch back to master. Make a commit there, which should edit a different file from the
ones you touched in your branch – to be sure there is no conflict.
11. Now merge your branch again. (Aside: you don’t need to do anything to inform Git that you
only want to merge things added since your previous merge. Due to the way Git works, that
kind of issue simply does not come up, unlike in early versions of Subversion.)