I have a Develop branch that is actively getting committed to a lot. Before I start my work I like to create a feature branch off of Develop. However, before I submit a pull request for it, I like to proactively resolve merge conflicts. So what I want to do is pull down the changes to the Develop branch and ultimately get those changes into my feature branch all nice and clean.
The problem is that after I submit my pull request, it may be weeks sometimes months before it gets merged in. Beyond that, the particular commits need to remain isolated as much as possible because it frequently gets cherry-picked into a test branch afterward due to requests for only certain features at certain times.
I believe that after I pull down updates for the Develop branch, if I merge the Develop branch into my feature branch, those commits become part of my feature branch's commits, and my feature commits become cluttered and dependent on the new ones merged in. I think..
Is this the time to use rebase? Or does rebase become a problem because my feature branch (fb1) will sit idle for a long time afterward? (I read that this is a problem somehow because more commits will be added to the development branch while the pull request waits) Is my only option to create a new branch (fb2) off of the develop branch freshly updated and then merge my feature branch (fb1) into (fb2) and then make my pull request for (fb2) into the develop branch?
I'm sure this is a redundant question but I'm having a hard time finding anyone giving advice in a situation quite like this, considering the branch will most certainly become stale before it gets (attempted) to be merged in.
Maybe I am misguided about how I think merging works in the first place.
Thanks!
Yes, you can use rebase to keep your feature branch up-to-date while you wait for your merge request (MR) to be approved and merged.
The workflow I use at work is to branch off develop for features, and before creating an MR, I rebase my feature branch onto develop. This way, merging into develop when the MR is approved simply becomes a fast-forward merge without merge commit. This keeps the commit history clean and tidy.
If your MR becomes stale, it is better to keep your feature branch up-to-date with develop by rebasing often. If you wait for too long, the amount of new code in develop may make your merge difficult with lots of conflicts to resolve. It also gives you the opportunity to test your feature with the new code from develop.