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
- 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
- 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
- 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
- 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)