• Understand different workflow models

• Understand pros/cons of each

It should enhance the effectiveness of your team

It should not be a burden

• Does this workflow scale with team size?

• Is it easy to undo mistakes & errors?

• Does it impose unnecessary overhead?

Centralized

Feature branch

Forking

git status
git add
git rebase --continue

• Easy for new team members to pick up

• Can lead to lots of merge conflicts

• A central repo with a main branch for official history

• Developers create a new branch for every new feature

• Updates are made via pull requests

• Changes are not immediately merged into main branch

• Rather, the feature branch is pushed to remote repo

• Changes are reviewed by the team

• Accepted changes are merged into main and pushed to remote repo

git checkout -b marys-feature main

## switch to main branch
git checkout main
## pull changes from main
git pull
## pull changes from feature
git pull origin marys-feature
## push changes to main
git push 

• Keeps development separate from production

• Can be hard for beginners to understand

• Start with a central remote repo

• Instead of cloning a repo, team members fork the repo, which creates a remote copy

• Each team member then clones their remote fork to their local machine

• [optional] A new local feature branch is created

• [optional] Team member makes changes on the feature branch

• Commits are pushed to the developer’s own remote copy

• Team member opens a pull request from the (optionally feature) branch to the “official” repository

• Pull request is approved & merged into the original remote repository

• This is the preferred method for contributing to other packages/projects

• Each team member has their own copy of the repo

• It can be hard to keep track of others

We’ll learn about best practices for creating, reading, and sharing data