Title: Intermmediate git
Speakers: Amanda Olsen

Deck with pictures

For more blog posts, see the DevNexus 2018 live blogging table of contents

Beginner git

• add
• commit
• push
• fetch – gets latest for other branches (I didn’t know this one)
• checkout
• pull

Concepts

• current branch – the branch you are in when you run a command

Merge

• git merge feature – merges the code from feature into current branch. All commits since branched in same commit in your branch
• One cycle of merge conflicts (if merge conflicts)
• If look at git log, see full chronological history looks as if all changes were made in one branch using original commit numbers.
• Can see time of initial commit (from history looking like there).
• Can see time of final commit (from the merge commit)

Rebase

• git rebase feature – applies the commits one at a time but don’t have merge commits.
• Potentially many cycles of merge conflicts
• If look at git log, have new commit hashes for each commit
• Don’t rebase a shared branch unless you coordinate the effort. If two or more people are developing in same branch, need to be really careful. Merge doesn’t have this problem. If you only have one person in a feature branch, it is a moot point. [at the robotics team, we have multiple people on the same branch; maybe this explains some of our challenges]
• Rebasing rewrites history in that there are new commits. However, they are the same commits so it is more like a copy. Think of history as parent/child relationships instead. Since you have a new child/new commit, it isn’t really rewriting. Merge has a similar problem. It looks like commits were made in a branch when they were really made in a different branch and “moved” to target branch later.
• Can see the time of final commit (from the commit)

Merge vs rebase

• Merge
  • records that it was a merge commit
  • displays chronologically correct history if initial commits
  • Chronologically incorrect history of commits from perspective of master
  • Makes master more complicated
  • Difficult to roll back
  • Creates extra commits
• Rebase
  • Simple master branch
  • Understanding master is easy
  • Rolling back is easy
  • Master doesn’t record when a branch is merged in
  • Golden rule – don’t rebase when multiple people working on a branch

Feature branch workflow

• One branch per feature
• Master is finalized work and intended to be bug free
• Feature branches probably has bugs and that is fine
• Very common workflow
• Other workflows described

Rebasing

• git rebase –continue – acknowledges that you merged one “group”
• git rebase –abort – lets you start over

What to do when stuck

• git reflog – portmanteau for “reference” and “log”
• Remember that everything is saved if committed it. Local commits like a journal. (but then combine them before push!)
• Commit any uncommitted changes
• git reflog to find commit want to go back to
• git reset –hard – move to that point in time
• reflog goes back 90 days

Example with squashing commits

• git clone
• Create new feature branch
• Start coding
• Realize need the code from master
• git fetch – pul remove branches/origin
• git rebase -i HEAD-3 – reapplies the last three commits to the tip stepping through each commit. Combines them into one commit with a new commit comment.
• git pull origin master –rebase – do a pull but rebase (instead of automatically merging). Faster to squash commits before rebase so less to go through when pull.
• git push origin feature – pushes to the feature branch
• Then can submit pull request so it gets merged into master

My take

Nice clear methodical explanation. I’m glad she mentioned what was “basic” git since I didn’t know about fetch. I like the recorded “non-live” demos. Great way to save time/reduce risk while still preserving the benefits of a demo.