This article is Part 4 of 11 in a series about Habit of a Solid Developer.
- Part 1 - Introduction
- Part 2 - Automatically Enforce Project Conventions
- Part 3 - Self Prescribed Code Reviews
- Part 4 - (current) - Git Dance
- Part 5 - Update or Add Documentation while Reading Code
- Part 6 - Dig a Little Deeper
- Part 7 - Changes Should be Taken with Baby Steps
- Part 8 - Podcasts
- Part 9 - Rapid Feedback
When it comes to solid dev habits, source control should be on the top of your list as a given. So much so that I'm not going to talk about the pro's and pro's (see what I did there?) of source control. I did however, want to walk through something I call my
git dance which is mostly just the rhythmic steps I take while pulling in changes from a remote repository while working on a project.
For a little context, this workflow is what I usually do while working on an internal project using git with a team where we may or may not be using pull requests, but the goal of this dance is to bring in any remote changes and layer my changes in on the
master branch (or whatever branch we're developing on).
My favorite thing about git is there is no "right way" to do things and when you get good enough at it the 'rules' people place on using git can mostly be wiped away. However, the below steps, while not always followed, are generally what I use to stay happy and healthy when dealing with others changes.
So if we know or don't know that there are changes remotely
or sometimes (if I have multiple remotes)
git fetch --all
fetch when I could be using
I prefer to
fetch any changes as this gives me the opportunity to review a visual of the commit graph before any action is taken. This allows me to take different paths depending on what the before commit graph looks like vs what I want the after to look like.
Git pull is essentially a short-cut for both
mergeing the code and I often don't want to just merge a remote change.
After I have any remote changes pulled (err fetched) locally I like to get a mental model of the recent commits.
Review remote changes
gitk U.I. is horrible to look at (and I'm sure you have your favorite git visualizer), but it provides enough info to review changes between the current
HEAD of my local branch and any remote changes that have come in with the
git fetch step above. The
--all is important in gitk, as it will show you all branches (including remote branches) that were fetched.
I use this overview to not only code review changes, but to help determine whether I want to
rebase with the remote changes.
Merge or Rebase
Once my review is complete, I've taken a look at the overall changes, and I have a mental model of what the current commit graph looks like. I generate a mental visual of what I want the commit graph to look like when I'm done. I will decide to either:
git merge [origin/master | otherBranch]
git rebase [origin/master | otherBranch]
Once my changes have been synced up with the remote changes, I push them up.
Ship changes up to the origin
git push origin master
git push origin <branchName>
Now it's not a complicated workflow and it can get a bit trickier, but the key here is doing the fetch, review, integrate workflow over automatically pulling in remote changes. This allows me the space to potentially interactive rebase or muck with my commits locally before pushing anything public.