A valuable lesson, and one of my biggest stumbling blocks during my first week or two at Haught Codeworks, was learning some new ways to handle my Git workflow.
In my time at Turing School of Software & Design, my workflow had become pretty automatic, and I didn’t spend much time thinking about it or experimenting with different ways of doing things. I’d make small, frequent commits as I worked. I’d give them short, descriptive, present tense names. I’d push up work on my branch, and a teammate would review my pull request. My team and I would have a productive conversation in the PR comments. When my PR was approved, I’d simply click the “Merge” button on GitHub, and off my branch went to join master. I frequently deleted merged branches on my remote and on local.
My workflow at Turing was fine for the most part, but one of the best parts of being at Haught Codeworks is not just learning new ways of doing things, but working with people who take the time to explain WHY it’s worth doing something a different way. That brings me to my rebase vs. merge debacle.
Rebase vs. Merge
I spent about a week being scared of this command: “git rebase -i master.” It seemed to magically work every time I’d walk through the rebase process while pairing with a senior developer, but every time I’d try it on my own, something would go awry in the interactive editor. I thought surely merging was good enough, and much less scary. Given that Atlassian writes, “The git rebase command has a reputation for being magical Git voodoo that beginners should stay away from,” I felt justified in my fear.
Part of the beauty of this apprenticeship is feeling like I’m encouraged to spend time learning and fostering my growth as a developer. After an afternoon of digging deeper into Git than I had in a while, and experimenting in the terminal, I felt much more comfortable with some new Git commands. More importantly, I understood more of the whys behind my new team’s workflow decisions.
Rebasing eliminates uninformative merge commits and gives a more detailed project history by moving all of the branch commits to master. By rebasing interactively, I had the chance to be thoughtful about my commits, squashing them if necessary before putting them all on master. Thoughtbot, as usual, sums up the process nicely in this post. If you’re feeling a little mystified by some of the magic that is Git, I’d encourage you to give it, and the Atlassian article I referenced above, a read.