learning-git

# Udacity course on Git version control
The first few modules give the history of version control systems, advantages and disadvantages of each and then introduces Git version control.
## Version Control Systems
- Manual Saving
- Dropbox
- Google Docs
- Wikipedia
- Git
- SVN

## Git was created by Linus Torvalds

- Git requires a commit be made for each logical unit of code change
- The command 'git diff" can be used to see changes between two versions of the same file, ie, comparing two commits to the same file and seeing what changed.  The results is similar to the Mac OS command comparing two separate files.

## How often to Commit?

It is a good idea to keep commits small, that way you don't have to worry if you need to revert changes from a commit because it is small.Think of a commit as a logical change - each change that is unique should be a separate commit.

### Commit Size Comparisons
1. You commit all the changes required to add a new feature, which you’ve been working on for a week. You haven’t committed since you started working on it.
- This commit is probably too big to understand all of the changes made over an entire week

2. You found three typos in your README. You fix and commit the first.
- This commit is too small, it is better to fix all of the typos and then commit, not one at a time

3.  You commit all the changes required to add a new feature, which you’ve been working on for an hour.
- This is a good size, the feature is contained and the amount of changes over the last hour all support the new feature.

4.  You fix two small bugs in different functions and commit them both at once.
- THis is probably too big since you are fixing different features - keeping the commit separate is best here.

## Repository
In Git version control, the repository is a collection of files where all of them are tracked under version control

Multi-file commits allows the interconnected files (ie. for an app or website) to remain in sync as changes in one file impact others.

## Cloning
The command 'git clone' allows you to copy an entire repository (repo) from one computer to another including the changes made since the beginning.

## Git Diff
First use the command 'git log' to see each commit and what the change was.  Then copy the two commits you wish to compare.  In my course I used the following commits 'git diff 292faae8b1d912f93f3194f107acaabc6194ef96 daebb756018ed433d7d5986efaef2bc56cc13188' and the result was as follows:
```diff --git a/game.js b/game.js
index 532e64a..0392105 100644
--- a/game.js
+++ b/game.js
@@ -171,7 +171,9 @@ $(function () {

   bullet.configureMatrix = function () {};
   bullet.draw = function () {
-    canvas.fillEllipse(this.x, this.y, 2, 2);
+    if (this.visible) {
+      canvas.fillEllipse(this.x-1, this.y-1, 2, 2);
+    }
   };
   bullet.postMove = function () {
     if (this.x >= canvasWidth || this.x <= 0 ||
@@ -218,10 +220,13 @@ $(function () {
         for (var i = 0; i < bullets.length; i++) {
           if (!bullets[i].visible) {
             var rad = ((ship.rot-90) * Math.PI)/180;
-            bullets[i].x = ship.x;
-            bullets[i].y = ship.y;
-            bullets[i].vel.x = 6 * Math.cos(rad) + ship.vel.x;
-            bullets[i].vel.y = 6 * Math.sin(rad) + ship.vel.y;
+            var vectorx = Math.cos(rad);
+            var vectory = Math.sin(rad);
+            // move to the nose of the ship
+            bullets[i].x = ship.x + vectorx * 4;
+            bullets[i].y = ship.y + vectory * 4;
+            bullets[i].vel.x = 6 * vectorx + ship.vel.x;
+            bullets[i].vel.y = 6 * vectory + ship.vel.y;
             bullets[i].visible = true;
             break;
           }
@@ -238,10 +243,12 @@ $(function () {

   ship.postMove = function () {
     if (ship.x >= canvasWidth || ship.x <= 0) {
-      ship.vel.x = -ship.vel.x
+      ship.vel.x = -ship.vel.x;
+      ship.x = ship.x <= 0 ? 0 : canvasWidth;
     }
     if (ship.y >= canvasHeight || ship.y <= 0) {
-      ship.vel.y = -ship.vel.y
+      ship.vel.y = -ship.vel.y;
+      ship.y = ship.y <= 0 ? 0 : canvasHeight;
     }
   };
```
In revieiwing the changes I can see the number of lines added and removed and they are color coded within the command line so I can see exactly what was changed between the commits

## Git Error messages
### Should not be doing an octopus
Octopus is a git strategy for combinning versions of code and this error message means you have used an inappropriate combination

###You are in 'detached HEAD' state
HEAD is what Git calls the commit you are currently on. You can “detach” the HEAD by switching to a previous commit, which we’ll see in the next video. Despite what it sounds like, it’s actually not a bad thing to detach the HEAD. Git just warns you so that you’ll realize you’re doing it.

## Git Checkout
This command resets all files to how they were at the time that commit was made.  As you find a bug shows up you can checkout older commits and check the behavior until you find the commit that introduced the error.  Then use the 'git diff' command to compare the two commits and see the exact changes to see if you can spot the rror and make the fix.

## Git Command Review
1. Compare two commits
### Git diff
2. Make a copy on an entire repo
### Git clone
3. Temporarily reset all changes to their state at the time of a specific commit
### Git checkout
4. Show all commits made in the repo
### Git log

## Behavior of git checkout
### Checking out an earlier commit will change the state of at least one file.

This is sometimes true. Git doesn't allow you to save a new commit if no files have been updated, so you might think this is always true. However, it's possible to do the following:

- Save a commit (call this commit 1).
- Update some files and save another commit (call this commit 2).
- Change all the files back to their state during commit 1, then save again (call this commit 3).
This sometimes happens if commit 2 contained a bug, and it's important to fix the bug quickly. The easiest thing to do might be to remove all the changes introduced by commit 2 to fix the bug, then figure out how to safely reintroduce the changes later.

At this point, commit 3 is the latest commit, so if you checkout commit 1, none of the files will be changed. 

### Checking out an earlier commit will change the state of more than one file.

### Checking out an earlier commit will change the state of every file in the repository.

Both of these are sometimes true. Since each commit tracks the state of all files in the repository, it is possible that checking out an earlier commit will change the state of multiple files, or even all the files in the repository. However, it is possible to save a new commit after changing only one file, so it is possible only one file will change. 


### After checking out a commit, the state of all the files in the repository will be from the same point in time.

This is always true. A commit saves a snapshot of all files in the repository at the time the commit was made, so checking out an earlier commit will result in all the files being reverted to their state at the time the commit was made. That is, the files will be in a consistent state.

## Creating a new repo from scratch
Use the command 'git init" to start tracking chnages in a repo.  You can make a folder or directory and then using the command line interface, change your directory to the newly created directory and then run 'git init'.  You will find a ".git" file has been created..
When you create a new repo there is no commit.  Git using a staging area to hold files with changes until you are ready to make the commit.

### getting ready for a commit
- use 'git status' to se the changes to the working directory
- then use 'git add [filename]' to add each file to the staginging area
- finalliy use 'git commit -m'message describing initial commit' to commit the files and changes for your intial commit
- use 'git log' to see the initial commit

## Git branches
Branches allow you to make changes to your solution without impacting the 'production ready' version.
You can create your branches with common names
You can use the command 'git branch' to see all branches in your repo
Each branch stores a reference to it's "parent" so it knows the tip of the branch status before the branch was created
Git can automatically combine two branches via the merge command
When you merge a branch onto master then all commits will be shown when you run 'git log'

## Git Merge
You merge a branch "on to" Master.  in order to do this follow below:
- 'git checkout [branh name you want to merge ONTO]
- 'git merge [branch name to merge FROM]
- the example is I want to merge branch "coins" onto "master"
- I use 'git checkout master'
- I use 'git merge coins'
- the result is coins is merged ONTO master
- If git finds changes in the same area of a file it will prompt you to decide versus trying to automatically merge the files and create somethign totally un-workabale.