Learning Git

The more you learn, the less you know.

You will always be learning…

• Basic Python syntax
• Creating functions and classes
• How to make objects from classes
• Import and use modules

• Automated code testing
• Create Python projects
  and virtual environments
• Basic Git skills
• Github skills, including forking and creating pull requests

Snapshot (copy) a version of all files in your project

What about viewing other versions of your project?

This is a version control system (VCS)

Pretend we start a project.

Label first snapshot A.

We change our code.

Now we have version B.

We send it to our robot…

And work on another change.

Which we call, C.

Find a bug on robot, based on B.

We can jump backwards in time to that code!

We fix the bug, and send it to robot.

We call this version D (based on B).

Ugh. Another bug on robot.

This fix is version E.

We jump forward to where we were working…

We can get any version, any time.

We finish our new feature.

Which we label, F.

But we want our bug fixes!

We merge E with our current code, F.

The primary line of changes: master

Github hosts our code. Use clone to make a copy to your system.

Notice that you get a complete copy… including the history.

Making a commit, I, to your copy

Now your version and Github’s are out of sync

Synchronize your code with our code using push:

What if another team member push a their new version?

Go to www.codecademy.com/learn/learn-git

Note: You may want to learn the Terminal www.codecademy.com/learn/learn-the-command-line

• Create a folder to hold your new project
• Create at least one file
• Create more folders and file if you want

Now:

• Start the Terminal program
• Jump to your folder using cd

Make your project Git-able with init:

$ git init
Initialized empty Git repository in /home/howard/Work/robotics/experiment/.git/

Does little except for create a directory, .git

Your world of versions are stored there.
We’ll look more at it later.

What files should be added to snapshot?

git add README.md
git add Pipfile

To create a snapshot of all file versions, type:

git commit --message="A- Initial start of my new project"

Notice the double dashes:

[master (root-commit) 1d8835d] A- Initial start of my new project
 2 files changed, 15 insertions(+)
 create mode 100644 Pipfile
 create mode 100644 README.md

Currently, we have one commit:

How do we know? Type:

git log

Shows all commits in your history. Let’s make this long.

Use your editor to change some files.

Repeat the process to specify files:

git add README.md

And commit them:

git commit --message="B- Updated the README explaining experiment"

Now, we have:

Pretend we sent B to the robot. Let’s make a new commit.

Edit one or more of your files, and:

git add README.md Pipfile

And commit them:

git commit --message="C- New robot interface needs new module"

We now have:

How are you doing? Look at the history:

git log

Let’s go back in time:

git checkout 690871d # Beginning of commit ID

Only need the first 7 characters. Now back to B:

Did you do it? Type:

git log

To see full history of changes, type:

git log --all

To return to where you were, use C’s ID:

git checkout f4e622d

We are back to C:

Look at the full history again:

git log

Git it?

Each commit has a long (but unique) ID.
Only have to type the first 7 characters…

Annoying. Try this:

$ git checkout 'HEAD^1'
Previous HEAD position was f4e622d... C- New robot interface needs new module
HEAD is now at 690871d... B- Updated the README explaining experiment

That says, go back one.

Note: You can’t do HEAD+1 to go forward. Git only remembers where a change came from not where it is going.

Re-edit one or more of your files, and:

git add README.md

And commit that:

git commit --message="D- Fixing a bug sent to robot"

We now have:

Edit, add, and commit again to make E:

Notice the history when you type:

git log

Compare that to:

git log --all

$ git init
Initialized empty Git repository in /home/howard/Work/robotics/experiment/.git/

 $ echo 'test content' | git hash-object -w --stdin
297632f498c27317f9ef21aea16d20ab88fb2d3e

There it is!

$ tree objects
objects
├── 29
│   └── 7632f498c27317f9ef21aea16d20ab88fb2d3e
├── info
└── pack

Notice the first two letters are the directory, and the rest of the 40 character checksum is the file.

Using the hash, get the content back:

git cat-file -p 297632f498c27317f9ef21aea16d20ab88fb2d3e

Create and store a file:

echo 'version 1' > test.txt
git hash-object -w test.txt

Which returns the hash: 83baae61804e65cc73a7201a7252750c76066a30

Do it again:

echo 'version 2' > test.txt
git hash-object -w test.txt

Which return a new hash: 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a

Revert your code:

git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt

But that just stores the blob … doesn’t even have the file’s name!