WP COS MeetupGit 101- An Introduction to Version Control using Git11/24/15

If you are new to Version Control you are probably thinking it is something like WordPress post revisions or a daily back-up in that you

save a copy of your project sequentially over time.

(It’s very linear)

And you would be partly right…

What is Version Control?

A B C D

The purpose of something like revisions and backups is to restore your project to an earlier instance

What is Version Control?

A B C D

Restore

Each snapshot is an instance of a point in time. It is very linear.

This is not the case with a Version Control System such as Git.( Although you can use it that way.)

The purpose of a Version Control System like Git is to assist you in the development of your project, not simply restoring it if issues occur.

When Git stores a snapshop of your project (called commits) it also stores which previous instance you made changes to.

Branching

A B D G

C E F

H I

This results in a non linear instance structure.

It looks complicated, but it results in an extremely powerful concept called

Branching Branching is the heart and soul of what makes something like Git so

powerful.

Branching

Feature Branch

Master Branch

Branching allows you (and others) to work on parts of your project independent of the other parts.

Then, when you are ready, you can “merge” your part back into the main project.

Branching

A B

C D

E F- - - - - - - - - - - - - - -

You can have as many other branches as you want,but you will always have a master branch

Basic Git Workflow

From the command line:

Staging Area

The staging area stores information about what will go into your next commit. It’s sometimes referred to as the “index”, but it’s also common to refer to it as the staging area.

Working Directory (your Project Directory)

The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.

Basic Git Workflow:1. Modify (add) files in working directory2. Stage your modified files3. Commit the staged files to the repo

Git Repo

Where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.

Resides in the .git directory of your project root.

The easiest way to install it is to use the Github Desktop app.

https://desktop.github.com/

This will install the app and also provide a command line interface as well.

(I’ll be using the windows version, but Mac version is fine)

Git Basics

Create a local repoGit stores everything in repositories. So we need to create one, in your Project directory create the repo:

Note:1. I’ll be using the command line, but

everything I do can be done from the GUI.2. The .git directory is hidden normally by

Windows.

Your project directory is called the working directory in Git

From the command line:> git init

> git statusGit status tells you the status of the files in the working directory including what branch you are working on.

We have no files so lets create a couple.

> git status

Files are either tracked or untracked. Untracked files - any files in your working directory that were not in your last snapshot and are not in your staging area. Tracked files are files git has or will save in the snapshot called a commit.

> git add <filename>Before we can take a snapshot of our project, we have to tell git what files to track. We do this with the add command:

We could also use wildcards:

> git add <filename>

> git add *

> git commitTo commit all the files in the your staging area to your local repo and take a snapshot of the current instance of your project, you commit.

The message is important because it helps you recall what you did. Make the message mean something.

> git commit –m “message”

> git commitWhen you have added all the files in your staging area to the repo and there are no untracked files, your working directory is clean.

There is nothing for git to do.

The Three Stages of FilesImportant!!

Git has 3 main states that your tracked files can reside in:

Modified means that you have changed the file but have not committed it to your staging area yet.

Staged means that you have marked a modified file in its current version to go into your next commit snapshot.

Committed means that the data is safely stored in your local db (repo).

Basic Git Workflow

From the command line:

Staging Area

The staging area stores information about what will go into your next commit. It’s sometimes referred to as the “index”, but it’s also common to refer to it as the staging area.

Working Directory (your Project Directory)

The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.

Basic Git Workflow:1. Modify (add) files in working directory2. Stage your modified files3. Commit the staged files to the repo

Git Repo

Where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.

Resides in the .git directory of your project root.

Lets do some workLet’s modify our readme.txt file.

To keep it simple lets just add a second line.

Be sure to do a git add and commit.

Some more changesLet’s change the second line.

Save, add, and commit it.

> Git log We have made a few commits at this point how do we see them?

As you can see the commit messages start to play an important role. But what about those numbers before the commit messages.

> git log –onelineUse the –oneline flag

These are the ID’s git uses to keep track of the commits.

(They’re actually each a hash, but that is another discussion)

Some more changesLet’s add a third line line.

Save, add, and commit it.

Opps, that wasn’t right, now what?

Opps, now what?We made a mistake, what do we do? If it is simple like this, correct the file and save a new commit.

But what if we had tried a whole new feature, with like 30 changed files, and we need to go back?

We can reset git to the commit we want to revert to.

> git reset --hard b2d50c6

B2d50c6 is the ID git uses to track commits.

There’s a better way Remember we talked about branches? Up until now we have been making all our changes in our master branch.

That really doesn’t leverage the true power of git; Branches.

So let’s try again, this time using branches.

BranchesRemember, branching allows you to work on parts of your project independent of the other parts.

To create a branch:

To switch to a branch:

All at once:

> git checkout <branch_name>

> git branch <branch_name>

> git checkout -b <branch_name>

More changesLets add another file, say details.txt

Save, add and commit it.

Even More changesLets make a few more changes and commits.

And lets use a better log

> git log –oneline --decorate

Now we know what branch the commit was on.

HEAD is just a pointer to the current commit on the current branch.

Oh no, bugsNow while we are working on details.txt we are told of a bug in readme.txt Lets fix that. But it isn’t part of what we are doing in this branch so lets create a new branch in which to fix it.

But we are currently in myfirstbranch so we need to switch to master first, then create it.

Fix the bugsWe made the necessary fixes and committed them.

Status

We did a bunch of things lets see what we have commits on three branches.

We are on branch bugfixes.

What happened to myfirstbranch?

Myfirstbranch

It is still there, but we have to switch to it.

bugfixes

Visually

Visually it looks like this.

myfirstbranch

Master Branch A B C D

E F G

H I

> Git merge <branch>

Now we want to merge these bug fixes back into the master branch so we can give it to our client.

Will merge <branch_name> into the current branch.

So let’s switch to master and merge bugfixes.

> git merge <branch_name>

Visually

Now master and bugfixes are still independent of each other but look identical.

bugfixes

myfirstbranch

Master Branch D

E F G

H I

H IH & I are notnew commits

Another changeLet’s switch back to myfirstbranch and make a change to the readme.txt file.

> Git merge myfirstbranch

Now we want to merge myfirstbranch into the master branch.

> git merge myfirstbranch

Visually

Master contains all the changes, merged.

bugfixes

myfirstbranch

Master Branch D

E F G

H I

H I E F G------------------------------------------------

-------------------------------------------

Deleting unnecessary branches

Suppose now we try to re-factor myfirstbranch and it just isn’t working. We may have made a dozen commits to it but just no joy. What do we do?

Simple we just delete the branch.Create a new one and try again.

This preserves our master branch

> git branch -D <branch>

Discussion & Best practices Those are the basics for using git.

There is so much more.

Public and Private on-line repositories Working in teams Git diff Advanced workflows

Can anyone say Git201?