Full stack web dev.
Studying FP web development approaches, while helping Mission Bit create paths to programming for underserved public school kids.
Previously @ Gradescope.
is the integration of the master code into your changes (not the other way around) at a high frequency
That's interesting. Your comment led me to look up the origins of the term. It seems like Booch and the other XPers specifically advocate merging working copies into the main line daily, but I agree that it's more useful to just make sure that working copies remain in a state where they're ready to be -- so, given distributed version control, to have master merged in often.
I'm sure the hardcore agilists would say that you shouldn't end up with something that's not ready to merge in the first place, since you're fully TDD / YAGNI / etc., but IME there may be good reasons to wait until something's fully baked (schema changes come to mind).
FWIW my preferred thing is for PRs to be small, but self-contained -- i.e. as simple as possible but no simpler.
I agree. I simply meant you want to ensure the integration of your code and master will not cause master to faulter so safer to merge out to you than in to master until stability is confirmed
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That's interesting. Your comment led me to look up the origins of the term. It seems like Booch and the other XPers specifically advocate merging working copies into the main line daily, but I agree that it's more useful to just make sure that working copies remain in a state where they're ready to be -- so, given distributed version control, to have master merged in often.
I'm sure the hardcore agilists would say that you shouldn't end up with something that's not ready to merge in the first place, since you're fully TDD / YAGNI / etc., but IME there may be good reasons to wait until something's fully baked (schema changes come to mind).
FWIW my preferred thing is for PRs to be small, but self-contained -- i.e. as simple as possible but no simpler.
I agree. I simply meant you want to ensure the integration of your code and master will not cause master to faulter so safer to merge out to you than in to master until stability is confirmed