This is not a talk about all the commands you can run in Git.
- Introduction to Git video lessons
- Git Documentation
- Pro Git
- ungit web UI / visualization tool
This talk is kind of about how Joe and I decided to incorporate rebasing into our workflow.
For the record: I still think rebasing is fundamentally wrong.
And I have the mic.
Git makes me angry inside. You can read why...if you want.
Note: tl;dr: it is arrogant, poorly documented software.
"Here's a list of 23893467 commands!
You should memorize use them!"
Note: We tend to lead with the code. This is not adult education best practices. This is not best practices for adult education. "Andragogy" tells us adults want information which is relevant to their job, and immediately actionable. Adult learners are selfish.
By the end of this session you should be able to:
- Determine a permission strategy for your project.
- Determine a branching strategy for your project.
- Create documentation which outlines how your team members will use version control.
Note: We are going to examine these three concepts throughout this presentation.
- Who has permission to commit code?
- At what point(s) does the code need to be reviewed and approved?
- How often do you deploy code?
- Inconsistency leads to mistakes.
- Anything that is arbitrary must follow a convention.
- Conventions should be documented.
- Only tested code is deployed.
- Faster is better.
Note: this is where we want to end up by the end of today. You know where each branch lives. You know how / where a branch is closed.
==========
Note: Centralized: everyone works in master from the same disk. Branching how we work. Anyone can check into master. Forking how most FOSS projects work; also for CI where the testbot gets final approval into master.
Everyone has read access. Very few have write access. Suggested changes are presented as a patch file for review.
- Pro: Forces a review process.
- Con: Patches need to be rerolled to stay up-to-date.
- Example: Drupal
Project forks give full permissions to developers so they can do work. New work is added to the main project through a request to upstream project.
- Pro: Forces a review process.
- Pro: "Modern" way of doing patches.
- Pro: Encourages experimentation (dev controls their own project clone)
- Example: joind.in
- Pro: Ensures clean/working master (good for CI)
- Pro: Encourages experimentation (cheap to branch)
- Pro: Reduces overhead of forking workflow
- Con: Encourages code review (does not require)
- Example: your internal project (probably)
==========
- Scheduled Release: Gitflow or Simplified Gitflow
- Continuous Deployment: Branch Per Feature or GitHub Flow
- Hybrid: Squash Workflow
- Incorporates human-reviews, and possibly automated tests.
- Allows you to collate many smaller changes into a single release.
- Code is deployed faster than scheduled releases.
- Requires (trusted) test coverage.
- Typically uses a mechanical gatekeeper to check in code to the master branch.
- Fewer branches to maintain / keep updated.
==========
- These examples are pulled from Drupalize.Me.
- This is a product with no external stakeholders.
- YMMV, YOLO, etc.
Note: these are both in the resources for the repository
Note: this is the star wars sprintflow. There are more layers for the WP workflow.
- Use terms which resonate with your team (MVP -> LBB).
- Giving a descriptive name to projects and processes allows you to change the meaning by changing the name.
- There are a lot of Ewoks.
- There are more My Little Ponies.
- Drupal 6 -> Drupal 7 upgrade
- Aiming for speed of code work, not stability.
- Changes were not being deployed to the live server.
- Total time: 18 months.
- Star Wars Sprintflow
- Aiming for stability first, speed second.
- We do not have complete test coverage.
- Changes are collated weekly onto a QA server, and deployed from there.
- Whispering Pines Weekly Workflow
- Release philosophy
- Deployment
==========
- Managing Chaos: Digital Governance by Design
- Workflows and Permissions Strategies
- Scheduled Release: Gitflow (Cheatsheet) or Simplified Gitflow
- Continuous Deployment: Branch Per Feature or GitHub Flow
- Hybrid: Squash Workflow
