These are my class notes to Paolo Perrotta's excellent and entertaining video course Mastering Git, comprising 8 videos of 2 hours 45 minutes total. I recently took up the Microsoft Dev Collective's offer for a 30-day free trial of Pluralsight and this was one of several that I enjoyed. I highly recommend this course if you are familiar with git, but even a little unclear on how git works. Especially if, like me, you use the same git commands every day with only a vague notion of what they do. Signore Perrotta explains everything brilliantly.

git tracks changes in 4 places:

• working directory - this is the project directory in the OS file structure
• index - a.k.a the staging area
• repository - in the .git directory
• stash - a kind of scratch pad or clipboard for the developer

2 questions which will completely define and explain any command:

• How does this command move information across the 4 areas?
• How does this command change the repository?

Some useful git log commands:

• git log --graph --decorate --oneline
• git log --patch
• git log -- <filename>

Distributed Workflow patterns. This is the social side of git: how git users on a team use it. These are useful terms for fruitful discussion.

• Distribution models: how sourcecode is shared among repositories
  • Peer-to-peer: developers pulling from each other's repositories
  • Centralized: one repository holds the canonical version
  • Pull-request model: devs do not push directly, but request
  • hierarchical model: some devs are gatekeepers to canonical repositories
  • etc.
• Branching models: how branches are used
  • Stable versus unstable (does a branch allow broken code?)
  • Integration (is there a "master" branch to which all repos merge/rebase?)
  • Release branch
  • Feature branch
  • Hotfix branch (versus cherry-pick, which is a rebase)
• Constraints: allowed, disallowed and preferred methods
  • Merge versus rebase (messy truth versus clean inaccuracy)
  • Gatekeeping and responsibility (do some devs have privs)
  • "Don't push when the build is broken" (CI error)
  • clean history before push to integration?
  • Every pull request linked to an issue/ticket number

Gitflow: such an influential model deserves separate discussion

• Don't "just use Gitflow". It is not optimal for every project, e.g.:
  • web apps that need to maintain only one release branch
  • project with continuous integration in which features released immediately, Gitflow has too many layers
  • projects with long term feature development
    • large code bases touching everywhere could cause integration headaches
    • perhaps better to integrate often, even when features are not yet complete

Growing a workflow: Avoid designing a complete workflow from the beginning, but start small and grow it.

• Sample starter workflow:

  • Distribution model: Centralized
  • Branching model:
    • One integration branch (master)
    • One feature branch per feature
  • Constraints:
    • Keep master stable, fix ASAP if it breaks
    • Integrate feature branches every few days
    • User merge over rebase by default

  "Simple, clear purpose and principles give rise to complex intelligent behavior. Complex rules and regulations give rise to simple stupid behavior."

  -- Dee Hock

Personal thoughts:

• Other constraints I have seen:
• Merge feature branches into the master branch, but clean up with interactive rebase the history of the branch before doing so.
• Do not rebase the history of the master branch.
• Features that are not released yet should be hidden by default, to be turned on with an internal flag
• Branches should have an associated issue number, and commit messages should reference that number (required a githook to enforce)