Also, like a story, it can take on many structures or forms. The narrative told by your commits is the vehicle by which you convey the meaning of your changes. Outline your narrative, and reorganize your commits to match it. Jumping in without a plan – the mindset of following a narrative – makes that process slower than it needs to be. Fluctuating between “fun” and “frustrating,” this approach eventually yields good results, but it’s far from efficient. Alternatively, they’ll remember some vague details and simply assume earlier commits properly set up later ones, failing to identify potential issues.īut how does a scatterbrained narrative hurt the developer? A developer’s first instinct when working on a new project is often to hack on it until they get something functional. To ensure earlier commits properly set up later ones (for example, verifying a newly-created function is used properly), the reviewer ultimately needs to piece together the narrative on their own for each commit, figure out which earlier changes establish the relevant background context and tediously click back and forth between them. If those commits do not tell a singular, easy-to-follow story, the reviewer will need to context-switch as the author’s commits jump from topic to topic. Reviewing commit-by-commit is the easiest way to avoid being overwhelmed by the changes in a sufficiently large pull request. The problemĭisorganized commits that eschew a clear narrative will affect two people: the reviewer, and the developer themself.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |