|
Hello Fred,
thanks for your interest. about the history for a feature: most branching based workflows prefer squashing commits when merging, so most probably the history is lost whatsoever. you're right I didn't explain how I do code reviews - and, effectively, I usually prefer pair programming when pushing, and after-the-commit code reviews - but before the feature is toggled on by default. There's a reason for this, I usually say that a review should review the status after a merge, not just a change; many a times I've seen reviews for a PR that miss the whole point, along the lines of "the change is good, even though the resulting merged code is complete mess"; on the contrary, if you review a certain commit before toggling a feature on, you're basically declaring that the code, at the point, is basically good. Yes, it may be hard for a large codebase, and often reviews are done by looking at what changed, and not at everything. But I've seen many, many, many stupid errors done or overlooked because people just looked at the change and not at the whole code after such change. |