while resuming work on a repository, make a ~brief note of the state it is in, before starting to make edits, to avoid edits tangling into each other, to the extent that it is hard to review changes and filter out artifacts such that meaningful / semantically-rich commits are made.
in the heat of the moment, i made many changes. later i get back to the codebase, and have meagre context around the thing i was working on. it's not so clear in my head so i have to read through my code to understand what it is doing. worse if these changes span multiple features.
with all these piled changes, it's too much work figuring out which change should be grouped into which commit, and you don't know whether to just commit-it-all nonsemantically, put it on a junk branch, or just discard those pending changes
to make an atomic, semantically well grouped, transactional change to the repo, get in the habit of creating/merging/rebasing/deleting branches often
declare intentions in the newbranchname, switch branch - work - stash - switch branch - work - stash - return to branch - unstash - complete work - commit - repeat-intermixingly
i am working on a feature. somewhere i think, maybe i should try a different scheme altogether to implement this feature. but i'd like to be also able to compare and contrast these different implementations of the same contract, side by side. #advise
while resuming work on a repository, make a ~brief note of the state it is in, before starting to make edits, to avoid edits tangling into each other, to the extent that it is hard to review changes and filter out artifacts such that meaningful / semantically-rich commits are made.
in the heat of the moment, i made many changes. later i get back to the codebase, and have meagre context around the thing i was working on. it's not so clear in my head so i have to read through my code to understand what it is doing. worse if these changes span multiple features.
with all these piled changes, it's too much work figuring out which change should be grouped into which commit, and you don't know whether to just commit-it-all nonsemantically, put it on a junk branch, or just discard those pending changes
to make an atomic, semantically well grouped, transactional change to the repo, get in the habit of creating/merging/rebasing/deleting branches often
declare intentions in the newbranchname, switch branch - work - stash - switch branch - work - stash - return to branch - unstash - complete work - commit - repeat-intermixingly
i am working on a feature. somewhere i think, maybe i should try a different scheme altogether to implement this feature. but i'd like to be also able to compare and contrast these different implementations of the same contract, side by side. #advise