Title: Intermmediate git
Speakers: Amanda Olsen
For more blog posts, see the DevNexus 2018 live blogging table of contents
- fetch – gets latest for other branches (I didn’t know this one)
- current branch – the branch you are in when you run a command
- 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)
- 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
- 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
- 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
- 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
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.