Mastering Everyday Git Strategies
My Git Journey
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
deck
By gpspake
