Cloning a Repository

A lot of the real utility of version control systems is that you can use them to access and keep track of other people's work.

If you look at Adafruit Industries on GitHub, for example, you can find hundreds of repositories. Using the advanced search, you can see them sorted by how many people have starred them. (GitHub's equivalent of a bookmark or favorite.)

Adafruit-Raspberry-Pi-Python-Code is one of the most popular of these, and a good fit for the Raspberry Pi we've been using for examples, so let's get a copy. Visit that page and look for an HTTPS clone URL:

It should be https://github.com/adafruit/Adafruit-Raspberry-Pi-Python-Code.git - go back to your terminal and cd to your code directory, then clone the repo:

Navigating History

Now check out the log of recent commits:

If you want, you can scroll all the way through the history of the repository from here. You can also slice the display of commits in all sorts of ways - try git help log for a lot of detail. A couple of my favorites are:

The --graph option lets you see the flow of history as branches are created and merged back into master.

If you're working on a desktop system, you can probably even use gitk, which will give you an old-school but sometimes very useful way to navigate and search the project's history:

Assigning Responsibility / History Within a File

Among the most helpful questions a version control system can answer are these:

1. Who changed this line?
2. When?
3. Why did they change it?
4. What else did they change at the same time?

Suppose you're looking at a file, and you have one or more of these questions. Maybe you need to figure out who to talk to before you change a given piece of code, or make sure it wasn't your change that broke something. (It's amazing how often I have been working myself up to yelling at someone else about a bug only to check up and realize that it was my fault in the first place. Version control often breeds humility.)

There's a simple but powerful way to go about this. Let's say the file in question is README.md:

This may look a little bit inscrutable at first glance, but it's a simple format. Here's the first line as an example:

Now if you want to explore the changes that led to a file being in the shape it's in, you can use commands like git show 7b26f754 to read the relevant commit message and see all the changes that were part of that commit at once.

This has a lot to do with why you should write good, thorough commit messages: They become a cheatsheet for a future version of yourself who has forgotten everything.