In this post:
My Git Workflow
I've started using git as a tool, and not just something that I have to do. In this way it's turned from a liability into an asset. There's nothing crazy going on - although there is just maaaybe a little bit of magic happening.
The Workflow
Here are fragments of how I approach git and incorporate it into my work:
- Am I starting a new feature?
- Ok, checkout a new branch.
- Have I produced any work that is:
- Complete?
- Incomplete but is substantial/meaningful and hasn't broken anything else?
- Commit that branch with an appropriate message.
-
Can I merge complete work on a side branch into my main branch?
- Merge into main.
-
Have I gone too far down the wrong path?
- Checkout an earlier commit.
- I'm now in the DETACHED HEAD state.
- Have I completed work on the detached head that I'd like to preserve?
- Merge it! (So far i've only done that by creating a new branch out of it and then merging that new branch. But there are ways of merging it directly.)
-
Am I curious about some feature of an earlier commit?
- Look it up and investigate based on a clearly written commit message!
The Magic
I might have noticed that writing with committing in mind has changed how I approach code. I have always enjoyed writing code that is runnable/testable as possible. That means moving incrementally, starting with the fundamental kernel of what I'm trying to achieve and then building with subsequent rounds of code here. Git reinforces that.
I want to commit often. I also want to commit working code. A synergy exists between these two forces.
I've long been comfortable operating with a starting vision, and writing code, switching between files as I put those varied pieces together, and often layering additional, non-elemental (for that stage), functionality on top as I go. Working with git has given me a greater discipline for keeping stages (those pieces of work between commits) simpler, and functional.
Top comments (0)