• Distributed*, rather than central, needs careful control.
  
• Choose workflow that lends itself to catching problems early.
  

• Github saves entire repository for each user.
  
• No need for individual branches for each user upstream: they belong on the individual's Github repository.
  
• Branches are cheap, create them often, push them often.
  
• Upstream has the "one source of truth" master branch*.

1. Git networks.
2. Rules of the game.
3. The workflow.
4. Rebase vs Merging.
5. Sandbox.
6. Makes it easier to catch mistakes.

1. Keep master a previous copy of upstream/master (FF).
2. Only branch off master.
3. Branch often, branch for each feature.
4. Push only to origin (your Github repository).
5. Do rebase.

git fetch upstream
git checkout master
git ff upstream/master  # ffum
git push origin master  # pom
git checkout back_to_branch

git checkout master
git checkout -b featureA 

1. Don't pull
   
2. Don't merge
   
3. Don't commit to master
   

• fetch
  
• ff (fast forward)
• checkout
  
• checkout -b
• commit
  
• push
  
• rebase

• Once set up, update the local copy using.
  

 git fetch upstream

• I then recommend updating your master branch
  

git checkout master
git ff upstream/master  # ff = merge --ff-only

git checkout -b featureA

git checkout featureA

git status
git diff

git add -A

git add myfile.py myotherfile.py

git reset myotherfile.py 

git push origin featureA

git fetch upstream
git checkout master
git ff upstream/master  # ffum
git push origin master

git checkout master
git checkout -b feature_branch
# do stuff
git commit
git push origin feature_branch

# PULL REQUEST VIA GITHUB

# you took a backup right?
git checkout featureA_backup # go to the branch 
git branch -D featureA  # hard delete the unsuccessful branch
git checkout -b featureA  # create branch with the same name
# back where we started, try rebase -i again

• Show off what you've done
• Everyone alerted to request, opportunity to review
• Feedback from colleagues (e.g. code simplification, learn)
• "Feedback" from CI ("Good to merge")
• Give feedback to colleagues (it goes both ways)!

• git checkout pr/1234 

• Ensure your features aren't being removed!
  
• Ensure no-one is doing anything stupid - including you!
• 
  
• Cross link actual commits/discussion with issue/bug-tracker 

• Down the line the new code will be read and re-read
  
• This cycle is more direct if all are alerted to the changes
  
• If you have a merge conflict you'll know why (I remember this pull request, I understand what I'm rebasing over)
• Fewer bugs down the line

• In the rebase model, merge commits are first indication something is amiss (See also the Easier to Catch Mistakes slide)... before they're in master.
  

git rebase master

• pre-push hook can stop accidental force pushes to master
  
• no force pushing to an upstream (shared) branch
  

git push --force origin featureA 

• People are working off of master, not random branches*
  
• Pull requests are kept up to date, and discussion resumes in the same place (no need for a new pull request)
• No merge commits in pull requests (if you're rebasing)

• Easy to deleted recent commits and screw everything up
  
• Recommend pre-push hook to reject force pushing upstream
  
• (Enforce programatically rather than rely on habit.)

git rebase --interactive HEAD~N 

• See who is doing what and when.
  
• Drill down to individual commits. 
  

• Each dot is a commit OR a merge commit.
  
• Merge commits may hide merge conflict resolutions.
  
• Responsibility of merge conflict resolution is unclear.
• Complicated to reason about diffs.
  
• Merge commits hide actual work... was there a conflict?

• It feels more familiar.
  
• You have a history of everything (merge commits)*.
  
• More commits, more satisfying.
  
• Sometimes fewer conflicts to resolve (can skip over shared diff rather than each commit)**.

• Each dot is a commit.
  
• Each arrow is a merge commit (without merge conflicts).
• We can click and drill down to the diff.
• Network history is "clean".
• Responsibility of merge conflict resolution (was) transparent.

• Everyone is starting at the same place (there wasn't a rogue commit three months ago included in Betty's branch).
• Obvious where each merge commits are.
• Easy to "squash" entire branches into a single commit**.

• If you haven't been updating often rebasing can be painful*.
  
• Maintenance overhead in continuously updating branches.
• Possible to delete your work**.
• Can get tripped up if someone rebases something you've started working on already - so don't do that.

• Merge commits appearing in pull requests.
• Unusual activity in the network graph.
• File changes which have nothing to do with the feature appear in the pull request (an incorrect merge resolution).

1. No merge commits.
   
2. Files/lines changed should make sense.
   
3. Tests pass.
   

• Set up git aliases (e.g. git ff)
  
• Show git branch in the terminal
• Adding and changing remotes
• Don't allow pushes to upstream remote.
• Have upstream remote to disallow force push

[color]
    ui = true
[alias]
  r = rebase
  f = fetch
  ff = merge --ff-only
  co = checkout
  c = commit
  a = add
  d = diff
  p = push
  pull = pull --rebase  # but don't use pull
  s = status
  h = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short

  po = push origin
  rum = rebase upstream/master
  fu = fetch upstream
  ffum = merge --ff-only upstream/master
  dum = !git diff $(git merge-base upstream/master HEAD)

[remote "upstream"]
  fetch = +refs/heads/*:refs/remotes/upstream/*
  fetch = +refs/pull/*/head:refs/remotes/upstream/pr/* 

• Use a theme
  
• or  set up by tweaking your terminals PS1 e.g. on ubuntu.

git remote show upstream

• fetch and push urls
• all branches on the remote
• "tracked" branches

git remote add betty https://github.com/bettys_username/project.git

git fetch betty

git remote set-url --push origin no_push