Menu
I'm always interested in trying new things with my workflow, and I thought it might be an interesting experiment to automatically commit between red, green and refactor steps, but then manually squash the commits down once I finish a specific feature (and before pushing).
I was just wondering if anyone else has tried this before? I thought I read about this once, but I'm unable to find any references.
I'm hoping one benefit might be to focus more on committing often, as well as being able to see my workflow visually so that I can improve it. For example, before squashing I can see if my time between red and green is too long, or if the number of code changes I make is larger than necessary between each step.
I was going to implement this as a guard plugin so that when I save a spec or library file, it runs the specs and commits the change with a commit message like:
Green: 1621 examples, 0 failures, 2 pending (1659 tests/s, 0.0006 p/test)
The idea being that I could visually scan this when squashing and determine where to group the related Red/Green/Refactor commits by logical changes.
At worst I thought this might be a fun experiment, at best it might give me a different way of seeing how I work.
504
The red, green, refactor approach helps developers compartmentalize their focus into three phases: Red — think about what you want to develop. Green — think about how to make your tests pass. Refactor — think about how to improve your existing implementation.
The git commit --amend command is a convenient way to modify the most recent commit. It lets you combine staged changes with the previous commit instead of creating an entirely new commit. It can also be used to simply edit the previous commit message without changing its snapshot.
On the command line, navigate to the repository that contains the commit you want to amend. Type git commit --amend and press Enter. In your text editor, edit the commit message, and save the commit.
About amending a commit Amending a commit is a way to modify the most recent commit you have made in your current branch. This can be helpful if you need to edit the commit message or if you forgot to include changes in the commit. You can continue to amend a commit until you push it to the remote repository.
I like the idea.
Showing the new / updated spec could be a plus. :)
It might be tricky for this plugin to know when the code reached a "true" Red / Green state.
Would it:
118
Yeah, I think this would be a fun experiment to do as the information gathered would be interesting to analyze. You could look at your average cycle times, and see what parts of the projects (files) have slower cycle times which could be veiwed as a code metric. The more information in the git log the better.. i.e. which spec is failing etc. Please share any progress and/or results that come from the idea.
27
Wow!! Believe it or not, I had a similar idea a few days back (to do as a weekend project), when I was reading on Unit Testing, that I wanted to build a module for git doing similar thing.
My idea was not completely automating, but rather a part. For example, a custom commit will see what are the REDs and give them some ID, and subsequent GREEN will see what all REDs does it solve, and append a suitable comment in the commit message along with the test ID and the RED commits.
Some additional functionality may include browsing through these commits based on some criteria...
Anyways, if you find this reference that you are talking about, please update this thread.
1
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
