In my computer science capstone project, we have a team of 5 working on various things for an Android app for Pokemon as a multiplayer game (Github). One or two people are working on implementing the "battle engine" for the Pokemon games (Generation I only). This feature has a lot going on. Initially we had a single issue with about 50 checkboxes of things to implement. I since split that into 12 separate issues.
All development on this battle engine is being done in a branch called
match-api-integration. It's a long-term branch, because it could take us several sprints to fully implement it. To implement an engine-specific feature, we branch off of
match-api-integration, do some work, submit a pull request and then merge back into
match-api-integration when it's approved. However, we want the most up-to-date battle engine for several other feature branches to ensure that the integration is correct between UI and data components, for example.
Because this branch is long-lived, how should we get those added features into other feature branches? Having periodic merges into other feature branches worked on during the sprint to have the most up-to-date engine clutters them with merge
whatever-feature messages. It's not a big deal, but cluttering nonetheless.
Is this the typical practice for such a branch, or is there some alternative that is more appropriate that we haven't thought of?
Edit: The proposed duplicate is asking about what frequency in which to merge feature branches into a main branch, either incomplete or complete. My question is asking about how to update feature branches with code from yet another feature branch that happens to be a long-term branch. The advice in the duplicate also does not apply to my scenario; "only merge stable code" - of course the code in the long-term branch is stable, but how to update several other branches which depend on it is a different question to the one proposed int he duplicate.