Git it Together – Why use a version control system? – What is version control?

View Github Repository Open presentation in a new window

PeterEltgroth

See all presentation from PeterEltgroth

Git it Together – Why use a version control system? – What is version control?

1 0

GITitTogether

On Github PeterEltgroth / GITitTogether

Git it Together

Peter Eltgroth

Lead Technical Analystpeter.eltgroth@so.mnscu.edu

Jeremy Heydman

Web Architectjeremy.heydman@so.mnscu.edu

Why use a version control system?

Imagine for a moment you don't use a version control system, or perhaps some of you do not need to imagine.

Changing Requirements

After you have finished making changes and demonstrate it, have ever heard something like: "The customer changed their mind and now want it to do X" OR "Sorry, I guess I liked it the old way better."?
Without VCS: How do I go back? With VCS: Revert to a previous checkout.

This worked in the last release . . .

Without VCS: What changed? With VCS: You know exactly what changed.

How can I solve this?

What if you don't know which solution will work?
Without VCS: Make multiple copies of your source code to try things. With VCS: Make a branch for each experiement.

What is version control?

A system that:

records changes over time allows you to revert versions does comparisons across time knows who changed what and when it was changed

About Version Control

Local Version Control Systems

Local Version Control

Could do this manually by copying & versioning files/directories, but that's error prone. Pros: At least you have versioning. Cons: Can't easily share across computers. VMS automates this by appending a version number to the file name.

Centralized Version Control Systems

Centralized Version Control

A single server holds all the versioned files and clients connect to it and check them out. Pros: Can share across computers and administrators can control priviledges. Cons: Single point of failure & clients must be connected to the server to see history. Examples: CVS, Subversion, Perforce, ClearCase, TFS

Distributed Version Control Systems

Distributed Version Control

Pros: Everyone has a full copy of the repository, built in backup! Cons: More complicated to learn. Examples: Git, Mercurial, Bazaar, Darcs

Why Git?

Design goals:

Speed Simplicity (like other *nix tools) Support for non-linear development Fully distributed Able to handle large projects Short History

How?

Git takes a stream snapshots by doing a SHA-1 check-sum of everything before it is committed.

Git Basics

If a file has not changed Git points to the previous version, this is a Directed Acyclyic Graph

Ability to commit work offline

And later syncronize with others

Fast, flexible branching and merging

Experiment with solutions, merge the best & delete the rest.

Changing branches applies the diff between the current & new branch in a single directory structure

Full Local History

Fast comparisons over the complete life of the project

Installation

MacOS

Since Mavericks (10.9) just type 'git' in a terminal.

If you want/need a newer version downlaod it directly from git-scm, use Homebrew, or GitHub Desktop.

Windows

Download git for windows or GitHub Desktop.

Both provide a command line BASH emulation for git.

Linux

Fedora: 

							$ sudo yum install git-all

Debian-based: 

							$ sudo apt-get install git-all

SourceTree

My favorite GUI

Git Basics

The Three States

committed modified staged

Snipcademy Three States

1. Untracked files are treated the same as modified, both can be staged or discarded. 2. When a file is staged, Git is able to take a snapshot of it. 3. On commit, Git has taken a snapshot of all staged files and stored the index.

Command Line Help

							$ git {optional-command-name} --help

Try Git

Learn Git commands in your browser at try.github.io

Initialize a new Git repository

							$ mkdir myproj
						
							$ cd myproj
						
							$ git init

Initializing a repository

init

The .git/ contains everything in one place.

Checking Status

							$ git status

Short Status

							$ git status -s

status

Add (stage) a file

							$ git add {file}
						
							$ git add *.java
						
							$ git add *

add

1. Create a few files 2. git status (view untracked files) 3. git add 4. git status (untracked files are now staged)

What differences exist?

Diff of modified changes

							$ git diff

Diff of staged changes

							$ git diff --staged

diff

1. Modify a committed file. 2. git status (see what has changed) 3. git diff (see the difference, how it changed) 4. git add (stage the changes file(s))

Reset (unstage) a file

							$ git reset {file-path}
						
							$ git reset *.java
						
							$ git reset *

reset

1. Modify a committed file. 2. git add (stage it) 3. git status (confirm that it is staged) 4. git reset (unstage a file) 5. git status (confirm that it is unstaged)

Commit Changes

							$ git commit -m '{message}'

commit

1. git status (confirm it has been committed) 2. git diff

Branching

Create

							$ git branch {branch-name}

Delete

							$ git branch -d {branch-name}

Branches in a Nutshell

branch

Checkout

							$ git checkout {branch-name}

checkout

1. Add or modify a file and commit it 2. checkout master 3. create another branch, checkout, make a change, commit 4. git diff {b1} {b2}

Merge

							$ git merge {branch-name}

merge

1. chekcout master and create a conflict 2. merge

Resolve conflicts

							$ git mergetool

mergetool

1. resolve conflict and save 2. exit merge tool 3. commit

Rebase

Replay a changeset by rewinding to a common ancestor and reapplying each change in turn.

This keeps history more linear and easier to read.

							$ git rebase {branch-name}

Rebasing

rebase

What?

Merge vs. Rebase

Merge creates a new commit, but rebase replays the existing commits. The 'experiment' branch is checked out and 'master' is rebased onto it.

Fast Forward

							$ git checkout master
						
							$ git merge experiment

Tags

Add

							$ git tag -a 0.1.0 "Alpha release"

List All

							$ git tag

List matching tags

							$ git tag -l {search-string}

List all 1.2 tags

							$ git tag -l "1.2*"

tag

Commit Log

							$ git log

Show diffs for the last n commits

							$ git log -p -{n}

Show abbreviated stats

							$ git log --stat

Show a graph

							$ git log --graph

Viewing Commit History

log

Hosted solutions

Act like a central VCS server, but are really just another copy of the repository with access controls and other useful features.

GitHub

BitBucket

GitLab

VSTS

Fork

Your copy of a repository in at the hosting provider.

Clone an existing repository

							$ git clone {path to repo}
						
							$ git clone https://github.com/PeterEltgroth/itconf2016

Clone Existing

clone

Now you have a copy of the repository with the complete history.

Remotes

List

							$ git remote

List with URLs

							$ git remote -v

Inspect

							$ git remote show {optional-remote-name}

Working with remotes

remote

By default origin is the location you cloned from, typically this will be your Fork.

Remotes

Add

							$ git remote add {remote-name} {url}

Rename

							$ git remote rename {old-name} {new-name}

Remove

							$ git remote rm {remote-name}

Working with remotes

remote

How do we know if we're caught up to repository we forked from? git remote add upstream https://github.com/heydman/itconf2016

Fetch

							$ git fetch {remote-name}

fetch

Fetch changes from a remote

Pull

Fetch & Merge the remote branch into the current branch

							$ git pull {remote-name} {remote-branch}

pull

If there are conflicts, you will need to resolve them.

Push

Push remote branch into the current branch

							$ git push {remote-name} {branch-name}

push

Create a branch, change something, commit it and push it to origin.

Rebase Warning!

If your fork (or any other repo) already has your C4 commit and then you rebase locally, it WILL cause problems.

Sorry, this is a bit random, but lets flashback to rebasing for a moment.

Pull Request

A request that a change you made be pulled back into a branch on another copy of the repository.

As a developer submitting a PR, it is generally your responsibility to catch up and resolve any merge conflicts with the branch your PR is targeting.

Managing Pull Requests

Continuous Integration

Jenkins

Registration Build

Build Details

Here you can see the commit (or commits) in the build and because I require my developers to add the story number and title in the commit message I can easily tie a change back to requirements.

Site Test

In our applications we have a site test page which shows applications version and build number. The build number is the short git commit hash, making it easy to know exactly what is running.

Resources

About Git

Git Documentation

Try Git @ GitHub

Git Real @ Code School

Git it Together on GitHub

Created with reveal.js Source code located at: GITitTogether

Thank You!
Git it Together Peter Eltgroth Lead Technical Analyst peter.eltgroth@so.mnscu.edu Jeremy Heydman Web Architect jeremy.heydman@so.mnscu.edu