Mastering Everyday Git Strategies

My Git Journey

  • UTHSC - Migrate to Git, Github from ???
  • Autozone Migrate to Git, Gitlab, from SVN
  • LensRentals - Git, Github, Well established Workflow/Rebasing 👍
  • Green Mountain - Git, Bitbucket, No rebasing 😱
  • Ookla - Git, Github, Rebasing 👍

The Purpose of This talk

  • Most git problems can be avoided by adhering to some simple principles.
  • Visualizing the graph is absolutely critical to using git effectively.
  • Developers should understand rebasing operations and have the confidence to package and apply their changes to the graph in the most useful way.

Git Operations

  • init
  • clone
  • push
  • pull
  • add
  • commit
  • branch
  • checkout
  • merge
  • stash
  • fetch
  • amend
  • reset
  • rebase
  • cherrypick
  • status
  • log

"But I just squash everything"

Who needs separate commits?

Git Commits

Git Commits

  • In git, commits are the containers for changes.
  • They represent a collection of changes - often across multiple files - that comprise a single atomic change to a codebase.
  • The changes included in a commit, the commit message, and where the commit appears in the graph are all important and should be carefully considered
  • Commit Often
  • Commit indiscriminately (You can always clean up later)
  • Always create a nope out branch
  • Bullet Three

How most people see Git

Visualizing the Graph

  • Understanding the graph and how commits fit in to it is essential to mastering git.

  • It’s hard to fully understand it without being able to see it.

  • You can view the graph from the command line but most modern git GUIs are based on a visualization of the graph.

Visualizing the Graph

Visualizing the Graph

Visualizing the Graph

Visualizing the Graph

Visualizing Git Operations

Rebase

Interactive Rebasing

Reset

Hard

Hard (Branch)

Soft

Cherrypick

You can choose to commit immediately or not

 

Useful for "manually rebasing" difficult branches

Splitting Commits

Cherrypick commit you want to split to a new branch (don't commit immediately)

 

Stage and commit changes as needed

 

Cherrypick remaining commits

Visualizing Git Problems

Never Merge Main In To A Feature Branch!

Rebase instead

  • Merging a source branch in to a sub branch adds complexity to the graph, creates messy conflict resolutions, and it makes the history confusing.
  • Main should NEVER be merged in to a feature branch that will be merged back in to main later (or right-away, as is often the case.)
  • The appropriate action is to rebase the branch on main. The graph will be clean, conflicts will be handled in the commits in which they were created (and invisible after the rebase), and the history will be easy to understand.
  • That Goes For Sub-branches Too. Never “merge-right”

Keep Your Branch Rebased As You Work!

  • Sometimes we work on changes for weeks or even months. As PRs get merged in, it’s easy for branches to get left behind and get stale. Eventually it’s time to merge and it turns out several changes have been merged in to main since the branch was checked out.
  • This creates huge unavoidable tangled messes and requires surgery to fix.
  • You should rebase your branch regularly - ideally, anytime new changes get merged to main. Graph visualizations incentivize this good behavior because you want your commits to be at the top. If new changes come in to master, you rebase to get on top of them, incrementally resolving conflicts as they arise.

Conflict Resolutions

Made with Slides.com