Long-term branch - when and how to merge it?

Question

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 match-api-intgration into 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?

_{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.}

Possible duplicate of What is a good frequency for merging up feature branches to a main line? — Greg Burghardt, Oct 19 '16 at 17:05
What happens when those secondary feature branches merging from the long lives branch get completed? Where do they merge back to? If it's to the mainline then having the long lived branch seems meaningless. — axl, Oct 20 '16 at 00:33
@axl The secondary feature branches (e.g. implementing new damage calculations for the engine) get merged back into the long-living feature branch for the engine. — Chris Cirefice, Oct 20 '16 at 00:48

EJoshuaS - Stand with Ukraine · Accepted Answer · 2021-07-25T18:15:14.457

In general, if people are working on multiple branches, I think it's helpful to integrate back into the main branch as often as possible. If you have one "big" merge every few months (or even every few weeks) it can quickly become very painful and error-prone (especially if you're doing merges between multiple people).

I also strongly encourage regular re-baselining (i.e. having everyone merge from the Main branch to their local branches) to prevent the local branches from getting too far "out of sync" with the main branch.

Keep in mind that, even for very well-architected systems, it's highly unlikely that significant changes to other parts of the system will have no effect on your branch at all.

gardenhead · Answer 2 · 2016-10-19T17:56:24.080

3

This is an unusual git workflow as far as I'm aware. Your long-lived branch match-api-integration is essentially splitting your application into two separate components, which is detrimental because you want every developer's copy of the repository to be as similar as possible.

Check out git flow. Instead of having a separate branch for the "battle engine", you would only create separate branches for adding features to the battle engine, like you're doing now. When a feature is complete, you would merge those changes back into develop, which everyone should be merging from daily.

Also, if you don't like cluttering your history with merge commits, you can consider rebasing, but be warned that rebasing is slightly more complex than simple merging.

edited Oct 19 '16 at 17:56

answered Oct 19 '16 at 17:47

gardenhead

4,747

1

Git Flow and Rebasing are not the only options. Git Flow also mandates a set of permanent branches and forbids fast-forward merges, making your history more complicated and much more difficult to manage. ...It basically tells you to use git like SVN in terms of branch management. – jpmc26 Oct 19 '16 at 18:00
This is easier said than done. I'm working on a new project at work right now that's very volatile. I had to take a branch out for two weeks to work on some major overhaul that touched many parts of the budding system. Normally, I'd rebase, but the size of the changeset persuaded me otherwise. I merged master in, and verified (or corrected) all the diffs manually. I can't find any "good" way to do it, just less objectionable ways. – mgw854 Oct 20 '16 at 00:20
@mgw854 Part of the solution to that is to rebase often. Daily at least. If even that proves too difficult, you can merge daily. Not perfect, but better than doing it all at the end. – jpmc26 Oct 20 '16 at 19:20

Long-term branch - when and how to merge it?

2 Answers2