Agenda

Day 1

• disclaimer
• what's this all about?
• (brief) history of SCM
• workshop

Agenda

Day 2

• advanced workflows
• workshop

Distributed vs Centralized

Centralized VCS

• there is only one repository every contributor connects to
• there is a single history of revisions
• easy to administer and manage access control
• single point of failure

Centralized VCS

• SVN
• TFS
• CVS

Distributed VCS

• every contributor mirrors the entire history
• every clone is a full backup

Distributed VCS

• git
• Mercurial
• BitKeeper
• Veracity

Distributed as the New Centralized

Integration Manager

Dictator and Lieutenants

Exercise 1: outline your team

Who is in your team?

Exercise 1: outline your team

What are their roles?

• developers
• designers
• project managers
• clients

Exercise 1: outline your team

What task are they responsible for?

• writing code
• reviewing code
• pushing code to servers
• fixing broken code

Exercise 1: outline your team

What constraints are you dealing with?

• how do you schedule your deadlines?
• where is your code hosted?
• do you have a staging instance?
• where are the server you push to?
• do you use a local development pattern?

A Simple Workflow

Shared repository with two contributors

A Restricted Access Workflow

Contributor have no access to the main repository

Interlude - VCS and the ecosystem

• ticket driven development (issue tracking)
• milestones
• code review
• QA (testing strategies)
• releases, versioning scheme

Interlude - VCS and the ecosystem

• deployment strategies
• documentation (GitHub pages, wikis)
• continuous integration (CI)
• continuous deployment

Desktop-like software

• few months to a year between releases
• every release involves significant overhead
• different versions installed at the same time
• need to support more then one release

Desktop-like software

one branch per release

Desktop-like software

consolidation branches

Desktop-like software

ready to release!

Desktop-like software

oops: here comes the bug

Desktop-like software

non-trivial features

Web Applications

• little overhead for releasing
• releasing means deploying
• user often unaware of versioning
• usually only one version is maintained

Web Applications

Web Applications

• more importance to feature branches
• continuous deployment with automation
• support transparent rollback

Centralized Workflow

Centralized WF

• flat learning curve for CVCS users
• allows isolated environment
• forget about upstream until convenient
• cheap and robust branch & merging

Centralized WF

Centralized WF

Centralized WF

Centralized WF

Centralized WF

Centralized WF

Centralized WF

Centralized WF

Hands-on session

Initialize repo

$ git init

.git gets created

$ ls -la
total 0
drwxr-xr-x   3 gizero  staff   102B Jan 14 20:48 .
drwxr-xr-x  18 gizero  staff   612B Jan 14 20:48 ..
drwxr-xr-x   9 gizero  staff   306B Jan 14 20:48 .git

Check file status

$ git status

• Untracked - changes are not recorded by git
• Tracked
  • unmodified - no changes since last snapshot
  • modified - modified since last snapshot
  • staged - a modified snapshot which is ready for commit

Check file status

$ git status
On branch master

Initial commit

nothing to commit (create/copy files and use "git add" to track)

Check file status

Then create a new file

$ touch README
$ git status
On branch master

Initial commit

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

          README

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

Adding a file

$ git add README

Check the status again

$ git status
On branch master

Initial commit

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

          new file:   README

Modify tracked file

$ $EDITOR index.html

What's the status now?

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   README

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:   index.html

Stage Changes

$ git add index.html

And the status?

$ git status
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   README
        modified:   index.html

git add

a multipurpose command

• git add to track new files
• git add to stage files
• git add to mark conflicts as resolved

Check changes

$ git diff             # changes still unstaged

(shows nothing)

$ git diff --cached    # changes staged for commit

(shows staged diffs)

Time to Commit

$ git commit -m "That's fun, isn't it?"
[master b795273] That's fun, isn't it?
 2 files changed, 10 insertions(+)
 create mode 100644 README

All in One

$ git commit -a -m "fix stuff"

• will stage and commit the files in a single operation
• automatically stages modified and deleted files
• does not affect untracked files
• use with caution!

Fix last commit

$ git commit --ammend

• use when you mispelled your last commit message
• you can also stage other changes before amending

Removing files

$ git rm README            # removes from repo & working directory
$ git rm --cached README   # removes from repo

Moving and renaming files

$ git mv README README.txt

Is just a shorthand for:

$ mv README README.txt
$ git rm README
$ git add README.txt

Ignoring files

$ $EDITOR .gitignore

IDE files, build dir, local settings, etc...

$ git add .gitignore
$ git commit -m 'tell git to ignore these files'

View history

$ git log

Undoing

Removing a file from the stage

$ git reset README

Undoing

Reverting uncommitted changes

$ git checkout README

Undoing

Reverting a commit

$ git revert b79527

Remotes

List remotes

$ git remote -v

Add a remote

$ git remote add <name> <url>

Fetch changes from remote

$ git fetch <remote>

Fetch + Merge with branch

$ git pull <remote> <branch>

Pushing

$ git push <origin> <branch>

Branching & Merging

How git stores a commit?

How does git stores many commits?

A branch is a pointer

Multiple branches

Which branch I'm on?

HEAD

Which branch I'm on?

HEAD

Recap

commit consists of

• Message
• Author
• Commiter
• Date
• Pointer to tree (snapshot)
• Pointer to previous commits

Recap

branches

• lightweight movable pointer to one commit
• when you commit, the branch moves forward, pointing to the new commit

Branching is inexpensive

• creating a new branch is just creating another pointer
• creating a new branch is as quick as writing 41 bytes to a file (40 characters and a newline)
• branching is a local operation, no server communication is needed
• switching branches changes the files in the working directory
• a special pointer called HEAD always points to the current branch

Create a branch

$ git branch <branch_name>

Delete a branch

$ git branch -d <branch_name>

Move to another branch

$ git checkout <branch_name>

Create a branch and switch to it

$ git checkout -b <branch_name>

List branches

$ git branch

Branching model

or

Branching strategy

A branching model allows to...

• release your code more frequently
• keep a production ready state of your product
• don't wait for nobody to push that hotfix
• better collaborate on features

Examples of branching models

Topic branches

You should branch everytime you do something new

• fixes
• features
• experiments

Long-running branches

• always-stable master as production branch
• stable release versions maintainance branches

A successful/common model

Sample scenario

• governance: master = production branch
• development style: ticket driven
• work on a web site
• create a branch for a new story you're working on
• do some work in that branch, then...

Boss calls for a hotfix

• revert back to your production branch
• create a branch to add the hotfix
• after it's tested, merge the hotfix branch, and push to production
• switch back to your original story and continue working

In the begining...

Start working on issue #53

$ git checkout -b iss53
Switched to a new branch "iss53"

Do some work

$ $EDITOR index.html
$ git commit -a -m 'added a new footer [issue 53]'

Boss calls - Back to master

$ git checkout master
Switched to branch "master"

Fixing the problem

$ git checkout -b hotfix
Switched to a new branch "hotfix"
$ $EDITOR index.html
$ git commit -a -m 'fixed the broken email address'
[hotfix]: created 3a0874c: "fixed the broken email address"
 1 files changed, 0 insertions(+), 1 deletions(-)

Merge hotfix to master

$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
Fast forward
 index.html |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

Let's continue working on issue #53

$ git checkout iss53
Switched to branch "iss53"
$ $EDITOR index.html
$ git commit -a -m 'finished the new footer [issue 53]'
[iss53]: created ad82d7a: "finished the new footer [issue 53]"
 1 files changed, 1 insertions(+), 0 deletions(-)

Time to merge into master

$ git checkout master
$ git merge iss53
Merge made by recursive.
 index.html |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

The end result

Conflicts

$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

Checking the status

$ git status
index.html: needs merge
# 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)
#
#   unmerged:   index.html
#

Conflict example

<<<<<<< HEAD:index.html
<div id="container">Awesome!</div>
=======
<div id="container">
    Cool!
</div>
>>>>>>> iss53:index.html

Remember: HEAD is what you checked out before running merge command

Mark file as resolved

$ git add <filename>

With external merge tool

$ git mergetool

Continue merge after solving conflicts

$ git commit

Rebasing

• reapplying a diverging branch onto another
• after rebasing, a merge of master with "experiment" will fast-forward master
• use when explicit merge commits are not desirable
• has drawbacks (rewrites history)

Rebasing

git checkout experiment
git rebase master

How rebase works

Example

Merge

Rebase - Step #1

$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command

Rebase - Step #2

$ git checkout master
$ git merge experiment

A more interesting rebase

Integrate the client changes to master

Rebase while pulling

$ git pull --rebase origin master

Rebase vs Merge

• rebasing replays changes from one line of work onto another in the order they were introduced
• merging takes the endpoints and merges them together
• the only difference between merging and rebasing is the resulting history, not the content

Rebase vs Merge

• dont't rebase pushed branches (unless allowed by your policy)
• rebase to polish your history (interactive rebase)
• rebase to keep up-to-date feature branches in a cleaner way
• ...otherwise merge

Best Practices

Best Practices

Always run 'diff' before committing

Best Practices

Read diffs from other developers

• you can learn something
• informal review

Best Practices

Keep your repos as small as possible

• minimal set of "sources"
• never store generated files
• store content, not representations
• maintain your .gitignore

Best Practices

Organize commits into logically related changes

• no more than one "task" per commit
• no less then one "task" per commit
• commit semantically

Best Practices

Commit log messages

• <50 chars short summary (git log --online)
• blank line
• more in-depth description (wrap at 72 chars)

Best Practices

Commit log messages

• the body should answer these questions:
  • what was the motivation for this change?
  • how does it differ from previous implementation?
• use imperative present tense for verbs
• keep references to tickets/issues/bugs

Best Practices

Example commit log message

Best Practices

Commit log messages

• consider enforcing standards with hooks

Best Practices

• don't commit half-done work
• VCS != backup system

Best Practices

Don't comment code: just delete it

• tools allow for easy recovery if needed
• keep things more readable
• can have performance inpact in sources for the web

Best Practices

Choose a workflow

• take your time to experiment with different options
• build your team around this decision
• once you agree ensure everyone follows

Best Practices

If you chose master == production workflows, always use origin/master instead of your local master

$ git checkout -b dev-[issue_num]-short-description origin/master

Best Practices

Read (continuously) about git online

• https://git-scm.com/book/en/v2
• http://sethrobertson.github.io/GitBestPractices/
• and many many others...
• then...

Best Practices

Choose and document your workflows/practices