Gittin' it done!

Rouben Tchakhmakhtchian - TKF2015

Follow-along at http://slides.com/rouben/tkf2015-git/live

Thursday, May 7, 2015 at 9:30am

Questions... Problems...

Image credit: git-tower.com, used with permission.

Answers!

  • Storing versions properly and efficiently.
  • Documenting what happened, when and why.
  • Free backups as a side effect! Go back in time sans 1.21 GW.
  • Collaborate with others efficiently (like a boss!)

Image credit: git-tower.com, used with permission.

Why git?

There are plenty of VCSs out there, but git remains one of the most popular, because...

  • github.com - social coding!
  • it is FAST!
  • large[st] community
  • one of the first of its kind

Neat stuff you can do with git...

Image credit: git-tower.com, used with permission.

...without setting your hair on fire!

Basic workflow

Image credit: git-tower.com, used with permission.

Step 1: Create the repository

OR...

Basic workflow

Image credit: git-tower.com, used with permission.

Step 1: Clone the repository

Demo time!

Step 1: Create or clone a repository

git config --global user.name "John Doe"
git config --global user.email "john@doe.org"
git config --global color.ui auto

git init                Create a new repository in current directory

Example:
$ mkdir myproject
$ cd myproject
$ git init
Initialized empty Git repository in /Users/tchakhma/tkf2015-git/myproject/.git/


git clone <address>     Clone remote repository at <address> to current directory

Example:
$ git clone https://github.com/pcottle/learnGitBranching.git
Cloning into 'learnGitBranching'...
remote: Counting objects: 12885, done.
remote: Compressing objects: 100% (16/16), done.
remote: Total 12885 (delta 3), reused 0 (delta 0), pack-reused 12869
Receiving objects: 100% (12885/12885), 27.86 MiB | 808.00 KiB/s, done.
Resolving deltas: 100% (6820/6820), done.
Checking connectivity... done.

Basic workflow

Image credit: git-tower.com, used with permission.

Step 2: Work work work

Basic workflow

Image credit: git-tower.com, used with permission.

Step 3: Review changes

Demo time!

Step 3: Review changes

In case of NEW (untracked) files...
$ git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	one.txt
	three.txt
	two.txt

nothing added to commit but untracked files present (use "git add" to track)

In case of modified existing (tracked) files...
$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   one.txt

no changes added to commit (use "git add" and/or "git commit -a")

$ git diff
diff --git a/one.txt b/one.txt
index 5626abf..ec32321 100644
--- a/one.txt
+++ b/one.txt
@@ -1 +1,2 @@
-one
+this is the first line of one.txt
+this is the second line of one.txt

Basic workflow

Image credit: git-tower.com, used with permission.

Step 4: Stage the next commit

Demo time!

Step 4: Stage the next commit

$ git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	one.txt
	three.txt
	two.txt

nothing added to commit but untracked files present (use "git add" to track)

$ git add one.txt two.txt three.txt
$ git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

	new file:   one.txt
	new file:   three.txt
	new file:   two.txt

Basic workflow

Image credit: git-tower.com, used with permission.

Step 5: Commit!

Demo time!

Step 5: Commit!

$ git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

	new file:   one.txt
	new file:   three.txt
	new file:   two.txt

$ git commit -m 'Added files one two and three'
[master (root-commit) 4afc746] Added files one two and three
 3 files changed, 3 insertions(+)
 create mode 100644 one.txt
 create mode 100644 three.txt
 create mode 100644 two.txt

$ git status
On branch master
nothing to commit, working directory clean

Basic workflow

Step 6: Review commit history

Git commit logs provide the following:

  • Date of commit (when)
  • Author of commit (who)
  • Commit message (what)
  • Commit hash (unique ID)

 

Q: Why use commit hashes as IDs instead of numbers?

A: Sequential numbers lose meaning in multi-user, multi-context environment, particularly when working offline. Plus, you get data integrity as a bonus!

 

Good news: Usually first 4-8 characters of commit hash is enough.

Demo time!

Step 6: Review commit history

$ git log
commit 184811419ad75501005c047de532c7ca60661c9d
Author: Rouben Tchakhmakhtchian <rouben.tchakhmakhtchian@utoronto.ca>
Date:   Thu May 7 01:45:23 2015 -0400

    Made file one.txt more verbose

commit 4afc746022274a3b8eb33e3c5d9f8362aaf6f3f3
Author: Rouben Tchakhmakhtchian <rouben.tchakhmakhtchian@utoronto.ca>
Date:   Thu May 7 00:34:09 2015 -0400

    Added files one two and three

$ git log -p -1
commit 184811419ad75501005c047de532c7ca60661c9d
Author: Rouben Tchakhmakhtchian <rouben.tchakhmakhtchian@utoronto.ca>
Date:   Thu May 7 01:45:23 2015 -0400

    Made file one.txt more verbose

diff --git a/one.txt b/one.txt
index 5626abf..ec32321 100644
--- a/one.txt
+++ b/one.txt
@@ -1 +1,2 @@
-one
+this is the first line of one.txt
+this is the second line of one.txt

Golden rules

#1 Commit related changes

#2 Write good commit messages

Bad commit message

(Single giant commit)

Added login screen, fixed bug #123, deleted obsolete CSS, refactored function getStuffDone()

Good commit messages

(Multiple smaller commits)

* Implemented login GUI
* Implemented login logic
* Fixed bug #123
* Deleted obsolete CSS
* Refactored function
  getStuffDone()

Basic Interesting workflows

Image credit: git-tower.com, used with permission.

Step 7: Branch, merge & share!

My aim is to try and cover as much of this as we can today...

Basic workflow

Image credit: git-tower.com, used with permission.

Let's review...

Basic-ish workflows

Undoing!

  • Fixing the very last commit (message and/or content):

    • (Optional) git add forgotten_file.html
    • git commit --amend -m 'New commit message'
  • Create a new commit that "undoes" (reverts) changes made in commit X:
    • git revert <target commit hash>
  • Delete all commits made since commit X, and roll back contents of working copy to commit X:
    • git reset --hard <target commit hash>
  • Time-travel working copy to commit X without affecting repository contents:
    • git checkout <target commit hash>

Interesting workflows

Image credit: git-tower.com, used with permission.

Golden rules

#1 Commit related changes

#2 Write good commit messages

#3 Use branches extensively

  • Think of branches as "folders" for related groups of commits
  • Branches can be used to logically separate commit histories for:
    • Individual features
    • Experiments and "drafts"
    • Changes that only make sense locally (e.g. configuration)
    • Pretty much anything you can think of...
  • Git will keep track of inter-branch relationships!
  • Branches are awesome and a cornerstone feature of git.

Interesting workflows

  • At all times you're almost always working on a branch.

    • The default branch is called master; it's just a label.

    • Remember: branches are like contexts or topics; logical containers for sets of related commits.

  • Only one branch is "active" at a time called the HEAD.
  • The HEAD points to where you're located (branch or commit).
  • git log output will match the current HEAD branch.

Cheat sheet

  • Create a new branch:
    • git branch newbranch
  • Check out (make HEAD point to newbranch and replace working copy contents with newbranch contents):
    • git checkout newbranch

Interesting workflows

  • Merging: integrating changes (sets of commits) from one branch into another, as they occurred in each branch.

    • The current HEAD branch is the recipient branch by default

Cheat sheet

  • First checkout the branch you want to merge into (recipient):
    • git checkout master
  • Merge in the changes from target branch (e.g. contact-form):
    • git merge contact-form

Interesting workflows

Rebasing!

  • Rebasing: integrating changes (sets of commits) from one branch into another. Commits from the recipient branch are always appended after the commits from the target branch.

    • The current HEAD branch is the recipient branch by default

    • This can be useful when ensuring that local modifications (e.g. application configuration) always appear as the last commit.

    • WARNING! This operation rewrites commit history!

Cheat sheet

  • First checkout the branch you want to merge into (recipient):
    • git checkout <recipient branch>
  • Merge in the changes from target branch (e.g. contact-form):
    • git rebase <source branch>

Interesting workflows

Image credit: git-tower.com, used with permission.

vs. merge...

Interesting workflows

Working with remotes!

  • 90% of all git work is done locally. Remote repositories come into play when locally stored work needs to be shared or published.

Image credit: git-tower.com, used with permission.

Interesting workflows

Working with remotes!

Git terminology refresher cheat sheet

  • Working copy: the project files stored locally on your computer.
  • Repository: the "database" keeping track of all the changes, branches, commits, etc. Can be either local or remote.
  • Staging area: changes stored locally within the repository database that are selected for inclusion in the next commit.

New concepts!

  • Remote (repository): your repository's clone on a remote server. The default name (just a label) is origin.
  • Remote (tracking) branch: a branch on the remote server corresponding to a local branch. The naming convention is remote-repository/remote-branch, e.g. origin/master.

Interesting workflows

Working with remotes: clone

  • git clone completely copies all data from a remote repository locally. It literally creates a "clone" of what's on the server.

Image credit: git-tower.com, used with permission.

Interesting workflows

Working with remotes: remote, checkout and status

  • git remote and git branch help manage remote repositories and remote branches respectively.

  • git checkout --tracking can be used to check out remote branches locally and set up a two way link (tracking) between them.

  • git status will compare the status of the current HEAD branch with its marching (tracking) remote counterpart. Remember: git stores a snapshot of the remote repository state locally, so don't forget to fetch the latest updates first. It will NOT update this snapshot automatically unless you explicitly tell it to.

Interesting workflows

Working with remotes: fetch

  • git fetch copies new data from the remote branch locally, but doesn't yet integrate (merge or rebase) it into your local branches.

  • Think of it as a "staging area" for changes imported from the remote, allowing you to review before you merge or rebase.

Image credit: git-tower.com, used with permission.

Interesting workflows

Working with remotes: pull

  • git pull copies all new data from the remote branch locally, AND integrates (merge or rebase) it into the local matching branch.

  • git pull = git fetch + git merge (yes, it's just a shortcut to two different commands run in succession)

Image credit: git-tower.com, used with permission.

Interesting workflows

Working with remotes: push

  • git push copies all new data from a local branch to the remote repository, AND integrates (merge!) it into the remote branch.

  • git push = the opposite of git pull

Image credit: git-tower.com, used with permission.

Interesting workflows

Working with remotes: command cheat sheet

  • Connect to a remote repository
    • $ git remote add origin https://example.com/project.git
  • Review remote repositories
    • $ git remote -v
      origin   https://example.com/project.git (fetch)
      origin   https://example.com/project.git (push)
      
  • Note: git clone will set up the above automatically.
    • $ git clone https://example.com/project.git
  • Check out a remote branch
    • git checkout --track origin/branch-A
  • List all local and remote branches
    • git branch -v -a

Interesting workflows

Image credit: git-tower.com, used with permission.

$ git status
# On branch dev
# Your branch and 'origin/dev' have diverged,
# and have 1 and 2 different commits each, respectively.
#
nothing to commit (working directory clean)

What's happening...

What git status will look like...

That's all folks!

Thanks for attending!

Illustration credits: git-tower.com; used with permission

 

Resources

http://slides.com/rouben/tkf2015-git/live/

Gittin' it done!

By Rouben Tchakhmakhtchian

Gittin' it done!

This is the slide deck to accompany the presentation given on May 7, 2015 at 9:30am at the annual University of Toronto TechKnowFile (TKF) conference by Rouben Tchakhmakhtchian.

  • 927