Git Real - Level 2

Notes from Code School's Git Real Course - Level 2

Git Diff

$ git diff

  Use to show unstaged differences since last commit. But once you stage a file ($ git add <filename>), it will no longer show up.

$ git diff --staged

  If your files are already staged, use this to see the differences since the last commit.

Unstaging Files

$ git reset HEAD <filename> 

  This will remove the specified file from the staging area.  Note: no quotes around filename

  e.g.s

    $ git reset HEAD LICENSE

    $ git reset HEAD index.html

    $ git reset HEAD styles.css

Discard Changes

$ git checkout -- <filename>

  This will reset the file to the state it was in at the time of the last commit. You are essentially pulling down the last version of the file and overwriting the current changed version. 

Stage and Commit in 1 Step

$ git commit -a -m "modify README.txt"

  This will allow you to do the staging and commit in one fell swoop. But, if you have any untracked files, this action will not stage or commit them.

Undoing a Commit

$ git reset --soft HEAD^

  Moves your last committed items back to the staging area. HEAD refers to the last commit you made.

Git Timeline

Adding to a Commit

  Amending a commit is a two step process, first add file to the staging area, then commit with a new message.

$ git add <filename>

$ git commit --amend -m "New message that will overwrite original message"

- The new commit message overwrites the old commit message

- --amend adds to the last commit

- whatever has been staged will be amended into the last commit

Undoing All Changes Made By a Commit

 You can rollback changes by using the $ git reset command. This will wipe out the committed changes completely. They will not land back in the staging area like a soft reset.

$ git reset --hard HEAD^

 Undo all changes since the last commit

$ git reset --hard HEAD^^

  Undo all changes made in the last 2 commits.

undoing git commit with git reset --hard HEAD^^

How to Share Files

Remote Repository Hosting

Git itself doesn't handle authorization and access issues (who can see/share your files). Options for remote repo hosting include a hosted solution or a self-managed solution.

Hosted solution example: GitHub, BitBucket

Self-Managed solution example: Gitosis or Gitorious

For most beginners, GitHub or BitBucket will work just fine.

git remote repository workflow

How to Store Your Files on GitHub

- Go to https://github.com/

- Create an account

- Create a new remote repository (using the GUI)

- GitHub will give you a remote URL to push your project to, as well as the exact text to use in your command line to do so

The commands will look something like this:

$ git remote add origin <insert the url github provided here between "">

$ git push -u origin master

e.g. 

$ git remote add origin "https://github.com/helengutz/sample_app.git"

$ git push -u origin master

- origin = name of the remote repository

- master = name of local repository

- url = address of the remote repository

- by using -u, you are telling the system to remember that address, so you can just do git push next time

The $ git remote add origin "https://github.com/helengutz/sample_app.git" part creates a bookmark of the remote repository

To view all your remote repositories, run:

$ git remote -v

The $ git push -u origin master part actually pushes the files to the remote repository

Pushing To Remote

$ git push -u origin master

  Use the above the first time you commit to a new remote repository, after that you can just do git push

master(local) --> origin(remote)

You will also be asked for your GitHub username and password to ensure you have authorization. You can go to https://help.github.com/articles/set-up-git to learn about password caching so you don't have to enter it every time.

Pulling From Remote

$ git pull

  Use this to pull down changes from the remote repository. Its important to do this often if multiple people are working on the same project.

master(local) <-- origin(remote)

Having Multiple Remotes

 Its not uncommon to have multiple remote repositories. One for testing for example, and another for production.

working with multiple remote repositories workflow

To Add a New Remote Repository

$ git remote add <name> <address>

e.g.

$ git remote add pb git://github.com/paulboone/ticgit.git

- example sourced from: http://git-scm.com/book/ch2-5.html

To Remove Remotes

$ git remote rm <name>

e,g.

$ git remote rm pb

- This removes the repository added in the above example

To Push Remotes

$ git push -u <name> <branch>

e.g.

$ git push -u origin master

$ git push -u pb master

- the branch is usually master

- remote repositories are usually called "origin", but can be named whatever you want, like "pb"

- by using -u, the next time you push you don't have to specify name and branch

Heroku Remote

Heroku is a hosting platform. To use it you need a Heroku account, and the Heroku gem installed.

Once you have these, you can run:

$ heroku create

This gives you a git repository ssh address, and creates a remote repository called "heroku"

$ git push heroku master 

  Use to push files to heroku and deploy your app

About this blog: This blog is an attempt to summarize my learnings as I learn them. Expect inaccuracies, incompleteness and inconsistencies.

Git Real - Level 1

Notes from Code School's Git Real Course - Level 1

Intro to Git

Git is a version control repository that lives locally on your machine. It helps manage files by tracking changes as well as taking snapshots of your work. These snapshots are recorded in a timeline for your reference, as well as for your use, if you wish to go back to previous versions of your work. Git does not take these snapshots automatically, you must manually "stage" and "commit" them. Staging is basically choosing which items to "take a picture of", and committing means "taking the picture".  Git can help you manage files remotely as well (more later).

- Git is mostly run through the command line tool.
- You must first install Git. Go to: http://git-scm.com/book/en/Getting-Started-Installing-Git


$ git help  Use this command to access Git's help topics and list of commands

$ git help <command>  Use this command to get help on a specific command, e.g.s (config, init, and diff are Git commands)
    $ git help config
    $ git help init
    $ git help diff



You will need to configure a global user name and email for your Git (one time set up)

$ git config --global user.name "<name>"  
$ git config --global user.email <email>

e.g.s
      $ git config --global user.name "Helen"
    $ git config --global user.email helen@example.com

    $ git config --global user.name "Adam"
    $ git config --global user.email adam@gmail.com

    $ git config --global user.name "Jules"
    $ git config --global user.email juliet@isababy.com

Note:
- "global option", I'm guessing this has a local or some other counterpart, but at this time I don't really know
- Quotes are required around the user.name, "Helen", but not for the user.email, helen@example.com. This kind of inconsistency drives me mad.

To add pretty color styling to your command line, add
$ git config --global color.ui true

How to Create a New Local Git Repository

To start using Git, you first must have a project started. Maybe its an empty folder at this point, or maybe its a new rails app. Doesn't matter, just know that your command line must be within the project folder you want to apply the Git version control.

e.g.
  Helen-Williamss-MacBook-Pro: ~hwilliams$ (this is my home folder)
  Helen-Williamss-MacBook-Pro: blog_app hwilliams$   (this is the folder for the project I want to use Git for)

Create a new local Git Repository
$ git init

What this does:
- Creates a local Git repository called ".git"
- ".git" is a local hidden file
- Git metadata is stored here
- You do not need to access this file, just know that it is there.
- If you open your project folder (using GUI graphical user interface), you will see the .git file, e.g. /hwilliams/blog_app/.git

About Git Workflow

- Create a file (it is untracked at this point)
    Note: Although this file is "untracked", Git knows its there (creepy? I think so). So it IS tracked, in a sense. But it is not under version control yet, so we'll call it "untracked".
- Add file to staging area (this is the file you want to take a snapshot of)
- Commit file (take a snapshot of file)

Another example of Git workflow:
- modify file (Say you make a change to a file you already committed)
- add file to staging area (Prepare it to get its picture taken)
- commit file (Take picture)

Git Workflow Commands (status, add, commit, and log)

$ git add <filename> 
- This adds your file to the staging area

$ git status
- Run this to view all files that are currently in the staging area

$ git commit -m "a message that describes your commit" 
- Commit all files currently in the staging area with a descriptive message so when you come back later, you know what the heck you did (also helpful for others to see what you did)

$ git log
- Run this to see the commits you've already made (and read those helpful descriptions so you know what's going on).

e.g.
$ git add README.txt
  (adds README.txt to staging area)

$ git status
  (Will output a dialog in pretty colors saying README.txt is currently staged)

$ git commit -m "Add README.txt"
  (Takes picture of README as it exists at that exact point in time, with a nice descriptive message of course.)

$ git log
  (Will output a dialog showing that README.txt was committed with the text "Add a README.txt")

-Note: Commit messages should be in the present tense, otherwise you will confuse your future self because time is like, relative.

e.g. 2
$ git add README.txt index.html
  (note: no quotes or commas when adding multiple files at once)

$ git add myprettystyles.css
  (oops, need this one too! adds myprettystyles.css to staging area)

$ git status
  (Outputs dialog showing README.txt, index.html, and myprettystyles.css are all in the staging area)

$ git commit -m "Modify README.txt, Create index.html and myprettystyles.css"

The Timeline

When you make a commit it adds the files to the HEAD. Use $ git log to view your commits.

Different Ways to Add Files to the Staging Area

$ git add <list of files>
      Add a list of files to the staging area (note: no quotes or commas separating file names)
      e.g.s
        $ git add index.html about.html contact.html
        $ git add styles.css index.html README.txt routes.rb
        $ git add application.rb posts.html.erb

$ git add --all 
    Add all files in the current directory to the staging area

$ git add *.txt
    Add all .txt files in the current directory to the staging area. Substitute any filetype for 'txt'.
    e.g.s
      $ git add *.txt       (adds all text files)
      $ git add *.css       (adds all css files)
      $ git add *.html.erb  (adds all erb files)

$ git add app/*.txt
    Add all .txt files in the app folder to the staging area. Substitute your folder name for 'app', and any filetype for 'txt'.
   e.g.s
               $ git add mydocs/*.txt
      $ git add app/*.html
      $ git add stylesheets/*.css

$ git add app/
   Adds all files in the app folder to the staging area. Substitute your folder name for 'app'
  e.g.s
      $ git add mydocs/
      $ git add app/
      $ git add stylesheets/

$ git add "*.txt"
  Add all .txt project files to the staging area, not just the ones in the current directory. Substitute any filetype for 'txt'.
e.g.s
      $ git add "*.txt"
      $ git add "*.css"
      $ git add "*.html"


About this blog: This blog is an attempt to summarize my learnings as I learn them. Expect inaccuracies, incompleteness and inconsistencies.