cart253-2018

Tools / CART 253 / Fall 2018 / Pippin Barr

Version control

In this module

Why version control?
Git, GitHub, and GitHub Desktop
Creating a repository
A version control workflow
Using GitHub Desktop and GitHub

Why version control?

Version control is an industry standard used to make sure software projects are maintained systematically
In CART253 version control will allow us to:
- Submit our assignments easily
- Keep our files backed up in the cloud (on github.com)
- Go back to a previous version of our work if we make a horrible mistake
- Have our work be open source and publicly available
- Track the progress of our projects step by step over time
- (Collaborate successfully with other in larger projects - though this is not something we’ll be doing in CART253)

Git, GitHub, and GitHub Desktop

There are many forms of version control and many version control applications
We will be using a very popular tool called Git and a very popular Git server called GitHub
To make things simpler, we will use an application called GitHub Desktop to interface with Git, so that we don’t have to use scary command-line tools

???

Yes, GitHub was bought by Microsoft which makes it part of a scary corporate juggernaut that doesn’t particularly support free and open software
In an ideal world we would use something less tied up in corporate interests, but GitHub remains a fantastic service and a good place for us to start with version control
There are other services such as GitLab and BitBucket and other applications such as SourceTree that you should feel free to look into in your own time

Repositories

When we work on a project with Git we create a repository for that project
The repository will basically just keep track of all your files over time
On your computer the repository for this course will just be a folder containing all your course work
Using Git and GitHub Desktop we will keep that folder synchronised with an online version on GitHub
For this course we’ll just use one repository the whole time, as if the whole course is a project
But usually people have a repository for each project they do

Create a cart253-2018 repository

Let’s create our repository!
Go to github.com and log in (you’ve already have registered, RIGHT?)
Once you’re logged in click on the green “New repository” button
Name your repository cart253-2018 (note the lowercase, the hyphen, etc.)
Make sure it’s set to public
Select Initialize this repository with a README
Ignore the .gitignore and license options for now
Click the green Create repository button

Cloning a repository!

You now have a repository called cart253-2018
Right now it exists only on GitHub though, and not on your computer
We need to clone it to our local computer (cloning just means downloading)
Launch GitHub Desktop (log in to GitHub here)
Go to File > Clone Repository...
Select the GitHub.com tab at the top of the window that appears
Select your cart253-2018 repository (it will be the only one there if you haven’t used GitHub before)
For now select your Desktop as the Local Path
Click the blue Clone button

Your local repository

Now you see the standard GitHub Desktop interface
This is the interface we will be using to deal with our repositories from now on
If you check your Desktop you’ll see a folder with the same name as your repository
That is your local copy of the repository!

Ready to work!

Now that we have our cart253-2018 repository on our computer we’re ready to work
When we do work we just create and edit our class projects etc. inside that cart253-2018 folder
And we keep it synchronised with the version on GitHub

A version control workflow

The simplest workflow using Git and GitHub is this:

You make some changes to your project in your local folder. Something like an hour’s work, say, reaching some sort of defined goal perhaps. (Mostly in Atom, but also includes adding files, renaming folders, etc.)
You commit your changes to the local repository using GitHub Desktop. This stores this newest version of the project in the repository.
You push your changes to the remote repository on github.com using GitHub Desktop. This makes sure your newest version is also safe in the “cloud”.

–

So basically you develop a rhythm of doing a chunk of work, committing and pushing it, doing another chunk of work, committing and pushing it, etc.

Let’s try it…

1. Make some changes

Go to the cart253-2018 folder on your desktop and open it
You should see a file called README.md that was created when you created the repository
Open README.md in Atom
Right now it probably just says ## cart253-2018
Under the name of the repository write a simple description of it

## cart253-2018

This is the repository for the course CART 253 for Pippin Barr.
It is going to contain __exciting exercises__, __passionate projects__,
and a __succulent sandbox__.

- [My homepage](https://www.pippinbarr.com/)
- [Twitter](https://www.twitter.com/pippinbarr)
- [Instagram](https://www.instagram.com/pippinbarr)

This file with extension .md is written in a very neat format called Markdown
It’s a plain text file with special symbols that allow us to insert formatting when it’s displayed on GitHub and in other situations
For example in Markdown the two hash symbols (##) mean a level-two heading
When you surround text with two underscores on either side it makes the text inside bold
You can see how we write hyperlinks above, too!

???

In fact, the slides for this course are written in Markdown too!
In fact, Pippin writes almost everything he ever does in Markdown!
It’s that good!

GitHub Desktop knows what you did (last summer)

Save your README.md if you haven’t already
Go back to GitHub Desktop
Notice how the interface has changed!
The left-hand pane should be showing you a list of changes detected in your repository (if it’s not selected, select the Changes tab on the left!)
The right-hand pane is probably showing you the changes made to the only file we’ve changed, README.md (it shows insertions in green and deletions in red)
If there were more changed files we could select them on the left and see the changes on the right, which can be very helpful

2. Commit your changes

Let’s assume we want to keep the edits to README.md
At the bottom of the left pane you can see the interface for committing changes
There’s a Summary which you use to describe the changes you made
So write what you did in there, e.g. “Wrote first version of README”
There’s also a Description where you can write more detailed notes about what you did if you want to expand on it (this can be super helpful to other people)
Finally there’s the blue Commit to master button
Click it

Committed

Now the Changes area goes blank because there are no new changes to the repository since our last commit (just now)
That means those changes are stored in the local repository
If you click on the History tab in the left pane you’ll see a reverse chronological list of all the changes
You can see that your commit message (the summary) is listed there to explain what happened
This history is especially great for keeping track of a project when you’re working with other people
In this course we will be using the commit messages and history to evaluate whether you’re following good version control and development practices

???

Note that if you go and check your repository on GitHub the changes are not there yet because we’ve only committed to the local repository

Push your changes

In order to upload our updated repository to the cloud on GitHub we need to push the changes
Notice that there’s a Push origin button at the top of the window
It should have a little number 1 with an up arrow next to it, indicating there is one commit to be pushed
Click it
You’ll see a few updating messages appear on the button as GitHub Desktop uploads the repository
And the messages about it fetching the repository again to synchronise it…
And then it’s done and the name has changed to Fetch origin because there’s nothing to push

???

It is hopefully obvious that if you’re not connected to the internet, you can’t push

Check GitHub

Just to make sure this first time, let’s go back to github.com in our browser
Navigate to your account and click on your cart253-2018 repository if it’s not already loaded
If it’s already loaded then reload the page
You should see your README.md file sitting in the list of files
And because README.md is automatically displayed by GitHub, you should see the changes you made listed below the file list!
You can also click the file name in the file list to display the file
It worked!

???

You can use the fact that the file called README.md is automatically displayed in any folder to add READMEs to other folders if you want to

That workflow again

So that’s the basic process of using version control

Make changes locally (in your cart253-2018 repository folder)
Commit changes to the local repository with a message (using GitHub Desktop)
Push changes to the remote repository (using GitHub Desktop)

If you follow that simple workflow, you’ll be loved and respected by developers everywhere
You’ll also make your own life a lot easier
(And you’ll get a better grade!)

???

A lot of the time the kinds of changes you’ll be making will be editing code, adding new folders, adding images, etc.

“When should I commit?”

There’s no single answer to the question of when you should commit and push changes
A simple answer is just to commit when you’ve made some important change that was work to do and you want to save it as part of the history of development
Another answer is that you probably can’t commit too often, it’s almost always a good thing to do and you’re more likely to do it too little than too much

Working offline

Note that it’s possible to commit to your local repository without pushing to the remote repository
This means that if you aren’t online you can do you work and keep committing locally
Then when you connect to the internet again you can Push to origin in GitHub Desktop to synchronise all that work to GitHub

Working on a different computer

GitHub makes it possible for you to do your work on different computers as needed!
Whenever you want to work on a computer you just need to Clone the cart253-2018 repository again, as we did at the start of this module
Cloning will download the latest version of the folder to that computer and you can just start working (assuming you have all the right software of course)
Then when you push from that computer, it will update GitHub and you can clone it somewhere else, etc. etc.

“For I am CDA, destroyer of worlds”

In fact, because of the way CDA computers work, this will be necessary
CDA computers erase all local data every night
This means when you come in the next day it will have deleted the cart253-2018 folder from your desktop
And it will have deleted your GitHub Desktop settings! Argh!
Basically you’ll have to
- Sign in to GitHub Desktop again
- Clone your cart253-2018 repository again
- And get back to work

???

If you work on your own computer then this won’t happen to you and you’ll be able to just keep using the same folder as if nothing had happened
You could try keeping your cart253-2018 repository folder inside your hosted folder on the CDA computers, which would mean it won’t be deleted
But your GitHub Desktop settings will still be deleted and so it’s probably just easier to clone your repository each time you sit down to work

Ignorance is bliss

There are certain kinds of files that you never want to commit to your repository
For example, on a Mac there is that stupid secret file called .DS_Store that gets created in every folder - we don’t need it in our repository
Fortunately, there is a special kind of file in Git-based version called .gitignore
For now let’s tell our GitHub Desktop to ignore .DS_Score

Ignore `.DS_Store`

In GitHub Desktop
Make sure you cart253-2018 repository is the Current Repository selected in the top left
Go to Repository > Repository Settings...
Selected the Ignored Files tab
Type .DS_Store in the text field
Click Save
Notice that doing this changes your repository (because it adds a .gitignore file)
So you need to now commit and push the file

Activity

Given that we have done Exercise 0 (RIGHT?) we have a JavaScript project we could put into our repository! So:

Find your Exercise 0 folder and rename it to exercise0
Create a folder called exercises inside your cart253-2018 repository folder
Put the exercise0 folder into the exercises folder
Go to GitHub Desktop and check that it sees the changes
Write a commit message like “Added exercise 0 to the repository”
Commit the changes
Push the changes

(Normally our changes won’t be adding a whole project at once, they’ll be more incremental.)

Summary

Git, GitHub, and GitHub Desktop are the key tools we will use for version control
The basic workflow is: make changes, commit changes, push changes
If you keep to this workflow you will become a better developer

cart253-2018

Tools / CART 253 / Fall 2018 / Pippin Barr

Version control

In this module

Why version control?

Git, GitHub, and GitHub Desktop

Repositories

Create a cart253-2018 repository

Let’s create our repository!

Go to github.com and log in (you’ve already have registered, RIGHT?)

Once you’re logged in click on the green “New repository” button

Name your repository cart253-2018 (note the lowercase, the hyphen, etc.)

Make sure it’s set to public

Select Initialize this repository with a README

Cloning a repository!

We need to clone it to our local computer (cloning just means downloading)

Launch GitHub Desktop (log in to GitHub here)

Go to File > Clone Repository...

Select the GitHub.com tab at the top of the window that appears

Select your cart253-2018 repository (it will be the only one there if you haven’t used GitHub before)

For now select your Desktop as the Local Path

Your local repository

Ready to work!

A version control workflow

The simplest workflow using Git and GitHub is this:

You make some changes to your project in your local folder. Something like an hour’s work, say, reaching some sort of defined goal perhaps. (Mostly in Atom, but also includes adding files, renaming folders, etc.)

You commit your changes to the local repository using GitHub Desktop. This stores this newest version of the project in the repository.

1. Make some changes

GitHub Desktop knows what you did (last summer)

Notice how the interface has changed!

The left-hand pane should be showing you a list of changes detected in your repository (if it’s not selected, select the Changes tab on the left!)

The right-hand pane is probably showing you the changes made to the only file we’ve changed, README.md (it shows insertions in green and deletions in red)

2. Commit your changes

Let’s assume we want to keep the edits to README.md

At the bottom of the left pane you can see the interface for committing changes

So write what you did in there, e.g. “Wrote first version of README”

There’s also a Description where you can write more detailed notes about what you did if you want to expand on it (this can be super helpful to other people)

Committed

That means those changes are stored in the local repository

You can see that your commit message (the summary) is listed there to explain what happened

Push your changes

Click it

Check GitHub

If it’s already loaded then reload the page

You can also click the file name in the file list to display the file

That workflow again

“When should I commit?”

Working offline

Working on a different computer

“For I am CDA, destroyer of worlds”

And it will have deleted your GitHub Desktop settings! Argh!

Ignorance is bliss

Ignore .DS_Store

Activity

Summary

Fin.

Name your repository `cart253-2018` (note the lowercase, the hyphen, etc.)

Go to `File > Clone Repository...`

Select the `GitHub.com` tab at the top of the window that appears

Select your `cart253-2018` repository (it will be the only one there if you haven’t used GitHub before)

The right-hand pane is probably showing you the changes made to the only file we’ve changed, `README.md` (it shows insertions in green and deletions in red)

Let’s assume we want to keep the edits to `README.md`

Ignore `.DS_Store`