|
|
|
|
|
|
by fredoliveira
3599 days ago
|
|
|
Your suggestion feels a little misguided. You end your post by saying that you contest the a priori idea of branching, but seem to forget everything that is right about branching in the first place: * Want to see the history for a specific feature? Impossible in your proposal, native in a feature/topic branching model. * Want to do a code review on a specific feature? Again, impossible in your proposal, trivial in a feature/topic branching model. * Want multiple developers to work under the same codebase with minimal conflict resolution and clear separation of tasks? Very hard under your proposal, easy in a feature/topic branching model. You also say that using topic branching means not doing CI. I've used the idea of proper feature branching for years, and have never _not_ had a CI process. CI tools are most definitely ready for (and are quite welcoming of) workflows like git-flow. I'd be happy to speak at more length about how we implement it if you'd like, but I assure you it is all but complicated. |
|
|
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.