3 ms·
I envy your ability to use that workflow. Across three enterprise jobs over the last 7 years, all places using git and GitHub, I’ve never worked on any sections
by mlthoughts2018 8y ago
I envy your ability to use that workflow. Across three enterprise jobs over the last 7 years, all places using git and GitHub, I’ve never worked on any sections of code where this could be tractable, except maybe for the process of using —amend in some rare cases where we wouldn’t want this history of those commits to be well separated for later purposes of bisecting to find regressions and bugs.
- iainmerrick 8y agoThis is not something I’d do on master, of course -- just on my own branch while working on stuff that will eventually become a single PR. I like to curate my commit(s) as I go, so that the final PR is easy to understand.
- mlthoughts2018 8y agoOh, I see. Yes, that is a very standard workflow. I also commonly address PR change requests in isolated commits as well, and then link back in the PR review page with something like “fixed in <commit hash>”, so that reviewers can see isolated commit changes fixing itemized requests, and also so that no review comments ever go without some explicit reply, either demonstrating the fix or explain why to not do it or table it for later. I guess in this sense, these items don’t have much to do with whether the big conjunction of conditions necessary for TCR are satisfied or not.