Class notes: Mastering Git

code git

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)


Leave a comment

There was an error. It's me, not you. You could try again later? Or try another method? Email? Smoke signals? Tell me what went wrong!

please enter a substantive message with no link or website address
please enter your name
please enter an email

Comment successfully sent, and it awaits moderation.