I am a member of a small team which is part of a larger team of developers working with Git. We (the larger team) have a main branch in a central repository into which we commit our work for the next release (let's call it 1.0).The smaller team has been tasked with developing a feature (upgrading an existing one, actually) that will not make it into release 1.0, but a later release (1.1).I'm wondering how to manage the development of this feature in Git. I have looked at several Git workflows but could not find one that really fits.First, we're working on this feature as a team, so I thought it would be appropriate to maintain a remote feature branch on the central repository which we'll all push to and then merge with the main branch when the feature is done. But releasing 1.0 could take a few months and that means we'll be isolated from the main branch for a long time, which would probably make merging back into main very hard. Ideally I would want to pull changes from main into our feature branch daily/weekly (as to deal with conflicts early on and not in one go after several months) but I've read this is not recommended in Git (to my understanding, merging from main to a feature branch or rebasing a public branch is discouraged).I've seen a similar question but the accepted answer just says to not work this way. As I am not the one deciding our releases, this is not a solution that works for me. Relating to this, even if I think the code is stable I cannot commit it to main, because QA doesn't have time to check the feature for the 1.0 release and the code changes might introduce a bug. I know about automatic regression testing and continuous integration and I'm pushing hard for both, but right now these things aren't possible.What is the best way to handle this?
Git workflow - possibly long running branches for future release
git;branching