Chapter_5

1 - Distributed Workflows

• Each developer can be a public repo if desired

Centralized Workflow

• One central repo like GitHub

Integration-Manager Workflow

• Each dev has their own public repo that they build off of and contribute too
• Once they have changes they want in the official repo, they send a request to the maintainer to pull their changes
• Common in GitHub with forks

Dictator Workflow

• Same as integration-manager but with one layer above
• Once one part of the repo has been merged the dictator will merge all of the small bits together
• This is the linux kernel

2 - Contributing

Commit Guidelines

• git diff --check Checks for whitespace errors
• Each commit or branch should be for a single issue

Small Teams

• Fetch/Merge before you try to push. Done

Private Managed Team

• Use collaboration branches to work with team members on features
• Most people don't need merge access to master, can be relegated to only an integrator or to PR's with reviews

Forked Public Project

• git request-pull will generate a pull request that can be emailed
• Using GitHub's PR mechanism is easier

Public Project Over Email

• Create a patch and email it to the maintainers
• They usually have a standard set of practices to use when emailing and it will change by project

3 - Maintaining a Project

• Use feature branches for most work
• These can be used to work together with other devs on the team if they are pushed to the remote or if the other team members add you as a remote
• RERERE
  • git config --global rerere.enabled true
  • Automatically fixes merge conflicts if they have been seen before
• git describe gives you a readable name with the partial commit and the most recent tag
• git shortlog gets you a short changelist

Summary

• Useful commands
  • git diff --check
  • git config --global rerere.enabled true
  • git describe
  • git shortlog