Program Structure

class ValueInvest(object):

    def __init__(self, start_year, end_year):

    def simulate(self):

    def load_finance_data(self, file_name, skip=0):

    def calc_cagr(first, last, periods):

    def calc_mdd(self):

    def calc_sr(self):

def main():

    start_year = 2008

    end_year = 2016
 
    ValueInvest(start_year, end_year).simulate()

if __name__ == "__main__":

     main()

1. What is Version Control

Git to help us manage different versions of our project.

I just said "version control". Now since you're in this course, you might already know a bit about version control. But if you don't, a handy trick I've learned is to try reading the words in reverse - so "version control" would become "control version"! So a Version Control System is just software that helps you control (or manage) the different versions...of something (typically source code).

There are a number of version control systems out there, but three of the most popular are
Git, Subversion and Mercurial.

There are actually two different categories.
There's the centralized model and then the distributed model.

In a centralized model there's one all powerful central computer that host the project.
Every interaction must go through this central computer.

In the distributed model, there's no central repository of information.
Each developer has a complete copy of the project on their computer, which is cool because that means you can also work off line.

In this course, we'll be using the version control system Git, which is a distributed version control system.



Now, you might have heard of Git Hub.
Git and GitHub are quite different.

Git, is the version control tool,
while GitHub is the service that hosts Git projects.

To work with Git projects you're not required to use GitHub, but it's an awesome tool and you should definitely check it out.

VCS Info

There are a number of Version Control Systems out there. This alone should prove that version control is incredibly important. Three of the most popular version control systems are:

• Git
• Subversion
• Mercurial

There are two main types of version control system models:

• the centralized model - all users connect to a central, master repository
• the distributed model - each user has the entire repository on their computer

Further Research

• Centralized vs. DVCS from the Atlassian Blog
• Distributed version control on Wikipedia

Recap

Remember that the main point of a version control system is to help you maintain a detailed history of the project as well as the ability to work on different versions of it. Having a detailed history of a project is important because it lets you see the progress of the project over time. If needed, you can also jump back to any point in the project to recover data or files.

In this course, we'll be using Git which is a distributed version control system. You might be surprised to discover that you're already using version control all the time!

2. Version Control In Daily Use

Version Control Is Everywhere

My job revolves around working with documents. I create new documents all the time, I fill them with information (hopefully informative information!) and then edit...edit...edit! Is your job like this? Perhaps it's not documents of text, but you're probably working with data in some form or another that changes over time.

Now you might not think that you're using version control when working with documents, and you'd be right...sort of. You're not actively maintaining different versions of a document as you write it. But that doesn't mean there aren't different versions of the document. The computer is keeping track of the different versions for you!

Don't believe me? Aside from pondering your propensity towards doubting, let's prove I'm right:

• open up your favorite text editor/code editor
• type some content (how about "version control is dull!")
• change one of the words in you wrote (e.g. change "dull" to "life-changing awesome")
• now (here it comes…!) press cmd + z or ctrl + z

💥 Version control in action! (See?...told you I wasn't lying) I bet you use the "undo" command all the time. I know that I sure do!

Practically every application I've ever used has an undo feature. You can think of this as a form of version control, but it's a rather limited form of version control. Let's look at a more powerful form by checking out a Google Docs document.

The Google Doc outline for this Git Course.

If you've ever written in a Google doc, have you noticed the small gray text at the top that tells you about the status of the document? Ever noticed that as you type, it's actively saving the document? Then, when you finish typing, it tells you that the document has saved.

Status of a Google Docs document. The status says "Saving…" while the document is being edited, and changes to "All changes saved in Drive" after the content is saved.

The real question is, did you know that is a link that you can click on? Wanna see for yourself? Try it out in one of your own Google Docs.

Clicking on the link takes you to a "Revision history" page. (Ooo! Did you notice the word "revision"? The word "version" is a synonym for "revision"!)

Revision History Isn't Powerful Enough

Google Docs' Revision history page is incredibly powerful! I've used it on several occasions to salvage text that I'd written at one point, erased, and then realized I actually did want to keep.

But for all its ability, it's not as powerful as we'd like. What's it missing? A few that I can think of are:

• the ability to label a change
• the ability to give a detailed explanation of why a change was made
• the ability to move between different versions of the same document
• the ability to undo change A, make edit B, then get back change A without affecting edit B

The version control tool, Git, can do all of those things - and more!!! (bet you didn't see that coming!) So have I sold you yet on the awesomeness that is Git? I hope so, cause we're about to dive into it in the next section.

3. Git and Version Control Terminology

When i was first learning Git, one of the hardest things for me to pick up on were all the various terms that were used.
For those of you that see a big long list of terms and zone out, don't worry.
Just skim the list for big picture ideas.

These terms are the vocabulary we use to talk about version control, features of a version control system, changes we like to make to our code while it's in a version control system, and so on.

I've created one for you that lists the most important terms along with a brief definition as a companion to this course.

You can find the Terminology handout in the Resources panel. The file is named Git Key Terms and is in the Course Materials section.

Terminology

Version Control System / Source Code Manager

A version control system (abbreviated as VCS) is a tool that manages different versions of source code. A source code manager (abbreviated as SCM) is another name for a version control system.

Git is an SCM (and therefore a VCS!). The URL for the Git website is https://git-scm.com/ (see how it has "SCM" directly in its domain!).

Commit

Git thinks of its data like a set of snapshots of a mini filesystem. Every time you commit (save the state of your project in Git), it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. You can think of it as a save point in a game - it saves your project's files and any information about them.

Everything you do in Git is to help you make commits, so a commit is the fundamental unit in Git.

Repository / repo

A repository is a directory which contains your project work, as well as a few files (hidden by default on Mac OS X) which are used to communicate with Git. Repositories can exist either locally on your computer or as a remote copy on another computer. A repository is made up of commits.

Working Directory

The Working Directory is the files that you see in your computer's file system. When you open your project files up on a code editor, you're working with files in the Working Directory.

This is in contrast to the files that have been saved (in commits!) in the repository.

When working with Git, the Working Directory is also different from the command line's concept of thecurrent working directory which is the directory that your shell is "looking at" right now.

Checkout

A checkout is when content in the repository has been copied to the Working Directory.

Staging Area / Staging Index / Index

A file in the Git directory that stores information about what will go into your next commit. You can think of the staging area as a prep table where Git will take the next commit. Files on the Staging Index are poised to be added to the repository.

SHA

A SHA is basically an ID number for each commit. Here's what a commit's SHA might look like: e2adf8ae3e2e4ed40add75cc44cf9d0a869afeb6.

It is a 40-character string composed of characters (0–9 and a–f) and calculated based on the contents of a file or directory structure in Git. "SHA" is shorthand for "Secure Hash Algorithm". If you're interested in learning about hashes, check out our Intro to Computer Science course.

Branch

A branch is when a new line of development is created that diverges from the main line of development. This alternative line of development can continue without altering the main line.

Going back to the example of save point in a game, you can think of a branch as where you make a save point in your game and then decide to try out a risky move in the game. If the risky move doesn't pan out, then you can just go back to the save point. The key thing that makes branches incredibly powerful is that you can make save points on one branch, and then switch to a different branch and make save points there, too.

With this terminology in mind, let's take a high-level look at how we'll be using Git by looking at the typical workflow when working with version control.

4. Mac/Linux Setup

Installing Git

Git is actually installed on MacOS, but we'll be reinstalling it so that we'll have the newest version:

1. go to https://git-scm.com/downloads
2. download the software for Mac
3. install Git choosing all of the default options

Once everything is installed, you should be able to run git on the command line. If it displays the usage information, then you're good to go!

If you run into any issues, let us know in the forum.

Configuring Mac's Terminal

We're about to configure the Terminal to display helpful information when in a directory that's under version control. This is an optional step! You do not need to re-configure your terminal for Git to work. You can complete the entire course without reconfiguring it. However, reconfiguring the Terminal makes it significantly easier to use.

If you choose to configure your Terminal, here's what it should look like when you're finished.

The terminal application on MacOS. The terminal has been configured to display version control information.

Configuration Steps

To configure the terminal, we'll perform the following steps:

1. download the zipped file
2. move the directory udacity-terminal-config to your home directory and name it .udacity-terminal-config (there's a dot at the front, now!)
3. move the bash_profile file to your home directory and name it .bash_profile (there's a dot at the front, now!)
   • if you already have a .bash_profile file in your home directory, transfer the content from the downloaded bash_profile to your existing .bash_profile

Download the zipped file in the Resources pane to get started.

First Time Git Configuration

Before you can start using Git, you need to configure it. Run each of the following lines on the command line to make sure everything is set up.

# sets up Git with your name
git config --global user.name ""

# sets up Git with your email
git config --global user.email ""

# makes sure that Git output is colored
git config --global color.ui auto

# displays the original state in a conflict
git config --global merge.conflictstyle diff3

git config --list

Git & Code Editor

The last step of configuration is to get Git working with your code editor. Below are three of the most popular code editors. If you use a different editor, then do a quick search on Google for "associate X text editor with Git" (replace the X with the name of your code editor).

Atom Editor Setup

git config --global core.editor "atom --wait"

Sublime Text Setup

git config --global core.editor "'/Applications/Sublime Text 2.app/Contents/SharedSupport/bin/subl' -n -w"

VSCode Setup

git config --global core.editor "code --wait"

5. Windows Setup

Installing Git

To download Git:

1. go to https://git-scm.com/downloads
2. download the software for Windows
3. install Git choosing all of the default options

Once everything is installed, you should be able to run git on the command line. If it displays the usage information, then you're good to go!

If you run into any issues, let us know in the forum.

Configuring the Command Prompt on Windows

We're about to configure the Command Prompt to display helpful information when in a directory that's under version control. This is an optional step! You do not need to re-configure your Command Prompt for Git to work. You can complete the entire course without reconfiguring it. However, reconfiguring the Command Prompt makes it significantly easier to use.

If you choose to configure your Command Prompt, here's what it should look like when you're finished.

The Command Prompt application on Windows. The Command Prompt has been configured to display version control information.

First Time Git Configuration

Before you can start using Git, you need to configure it. Run each of the following lines on the command line to make sure everything is set up.

# sets up Git with your name
git config --global user.name ""

# sets up Git with your email
git config --global user.email ""

# makes sure that Git output is colored
git config --global color.ui auto

# displays the original state in a conflict
git config --global merge.conflictstyle diff3

git config --list

Git & Code Editor

The last step of configuration is to get Git working with your code editor. Below are three of the most popular code editors. If you use a different editor, then do a quick search on Google for "associate X text editor with Git" (replace the X with the name of your code editor).

Atom Editor Setup

git config --global core.editor "atom --wait"

Sublime Text Setup

git config --global core.editor "'C:/Program Files/Sublime Text 2/sublime_text.exe' -n -w"

VSCode Setup

git config --global core.editor "code --wait"

6. Onward

Going through this lesson you laid a solid foundation to start learning version control.

Now let's head to the next lesson to learn how to create a GIT repository.