I tend to get headaches when having to plan an upgrade of a framework bringing breaking changes, quite possibly caused by a lack of trust in (my) git (skills). Fortunately, I mostly work alone on such projects, so I can easily just finish and merge all my feature branches, before upgrading the framework as the final step. Only then start again with new features.
But honestly, this can not be the way to go. This is why I want to ask you now, how do you handle this in teams? Suppose the following scenario:
- upgrade
- necessary as soon as possible (security? mad boss?)
- brings breaking changes
- file & directory structure
- configuration
- few deprecations dropped
- team
- has open feature branches
- changes to configuration
- can not be merged before upgrade
- should obviously not upgrade each and everyone for himself
- has open feature branches
This may be a near-to-worst-case-scenario, but I wonder what is the git workflow to handle the upgrade and merge the feature branches later? Is this something that just works by default and I make me think for nothing?
Top comments (1)
I'd say, merge framework upgrade to
develop/master(depends on how you organize your git workflow), rebase feature branches on top, resolve conflicts, run tests, do code review, then merge them as well.But if you're making feature branches big with a lot of commits, rebasing may take a lot of time and effort. Also, after rebasing you need to make sure that each commit contains code that compiles, because should you decide to revert code at some point, you need some guarantees that nothing will break.
So try to keep your feature branches small and isolated as well.
And doing research before upgrading also helps. At least you'll know what might brake and cater for that accordingly.