ETC5513: Collaborative and Reproducible Practices

Tutorial 11

Author

Michael Lydeamore

Published

21 May 2024

🎯 Objectives

  • Recap moving through git repositories
  • Practice undoing and resetting commits

Moving back in time: finding our way in a Git repo

  1. How can we explore old commits?
  1. How are the commits identified?

  1. Fork the following repo: https://github.com/github/explore. Clone the repo locally.

  2. Using your terminal look at the commits. How can you go up and down over the commits? How can you get out of the list?

  1. List the commits that have been done in the repo since 14 May 2024 only.

  1. Open the local project in RStudio and have a look at the tree history and the commit messages. Specially have a look at longer commits that contain not only one line but also some more text.

  2. Where is the repo HEAD?

  3. Using the command line interface or terminal move the HEAD of the repository to two commits back from the most recent

  1. What is the first line of the commit message of this commit?
  1. Which files have been modified in that commit?
  1. What is the difference between this commit and the previous commit?
  1. Move the HEAD of the repository back to where was originally located (last commit of the main (or master) branch)
  1. Find the commit with message “add in lite” what was change in the modified file?

  1. Move back to the latest commit in the main (or master) branch of the repo so that you can keep making commits without being in a detached HEAD.

  2. Using your terminal add a new file “myexample.txt” in the repo, stage, commit and push the file to your remote repo

  1. Let’s add another file same as above now called “myexample2.txt”. Stage the file and then unstage the file.

  1. Stage “myexample2.txt”, commit and push it to the remote repository.

  2. You realized that you made a mistake and you want to undo 17. You don’t want to remove the commit from the history. How can you do that?

  1. Run a git log –oneline and have a look at the commit that you did before the last commit.

  2. Pick the commit that you did before the last commit and do git reset SHA. What happens? Why is this not best practice?