1

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!

Eric
  • 476
  • 2
  • 8
  • 20
  • 1
    Yes. I do this all the time. – Guildenstern Apr 27 '23 at 23:33
  • 1
    Rebase your feature branch until you submit the pull request. Then leave it dormant until it is merged. The people who merge the pull request will come back to you with instructions what to do if they rejected the feature because it became stale. This is the earliest next time that you can rebase it again. – j6t Apr 28 '23 at 05:33
  • 1
    Honestly, it sounds like maybe you are trying to use a CMS feature to cover up some less-than-ideal development practices. Letting work sit for months without merging and cherry-picking "_due to requests for only certain features_" is stretching the CMS beyond its design intentions. Perhaps too many projects are lumped together? You might want to consider, for example, private [NPM packages](https://docs.npmjs.com/creating-and-publishing-private-packages) or [NuGet hosting](https://learn.microsoft.com/en-us/nuget/hosting-packages/overview). – JDB Apr 28 '23 at 20:58
  • @JDB Yeah, definitely less than ideal. Thanks for the suggestions. – Eric Apr 28 '23 at 22:25

2 Answers2

3

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.

olliebulle
  • 390
  • 3
  • 10
  • 1
    What happens if a stale feature branch is approved and merged, but meanwhile you have rebased it locally? Now you have two copies of the changes: the approved ones, and your local ones. What do you do? – j6t Apr 28 '23 at 05:30
  • @j6t our workflow enforces the fast-forward merge method so if the feature branch has not integrated the latest modifications from develop, it is not allowed to merge. If we were to rebase locally, it means we need to integrate the new changes, so it is not possible that the branch was merged in the meantime. – olliebulle Apr 28 '23 at 11:12
1

Don't rebase as it misrepresents where you started your effort. The "clean git history" goal is done at the expense of accuracy of accounting of what actually happened when you developed the work. If you want to test if the latest tip of development will be able to receive the changes from your branch, make a test merge locally. If it's got things that break, fix the compilation errors, broken tests and merge conflicts when doing this merge. When you have fixed it, do a PR with this merge included. That represents what actually happened.

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..

This is called a "back-merge" and is a definite no-no. Linus Torvalds used to blow up on people that did this. Always merge with the higher-order branch checked out.

Your issue is really about your work not being merged in a reasonable amount of time. If this is something that can't be changed, just repeat merging into develop, fast forwarding the feature branch to that merge with all the fixes, then update the PR to reflect this commit. Don't push the develop branch, push your feature branch.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • 3
    I think Linus “blew up” because the merges weren’t motivated, not necessarily because they were back merges. Your approach of merging “to the left” (c.f. back merge) has the same potential problem (the reason is often just “keep up to date with the main branch” and is done at arbitrary points). – Guildenstern Apr 28 '23 at 08:13
  • 1
    This left-merge (merge while your own `develop` is checked out) could also be a problem when you are viewing the changes since they keep drifting to the right. With a back-merge they are easy to look at as a straight line with `--first-parent`. – Guildenstern Apr 28 '23 at 08:16
  • 1
    I don't have an issue with people having preferences, but I don't understand absolutes like "Don't rebase as it misrepresents where you started your effort." Who cares? Most tools track the history of the PR/MR anyway so you can always see where you started if you want to. Besides, I've seen some developers that are new to Git, when getting conflicts on a PR, literally create a new branch and start over! When I show them they could rebase instead and resolve the conflict, and save a lot of time, they are happy. And the end result is the same. (Except that the commit and author dates differ.) – TTT May 02 '23 at 19:58
  • I should point out as a possible rebuttal to my previous comment, that if you have merge conflicts, and you resolve them by rebasing, and you mess it up, and you don't notice until long after the PR is completed, it's harder to determine it from the Git history alone. (You may have to look at the history of the PR in the tool to see it.) If the mistaken conflict resolution existed in a merge commit instead it would be easier to spot. (IMHO this isn't enough reason to always choose merge over rebase, but it's certainly worth considering, especially if you aren't using a PR tool at all.) – TTT May 02 '23 at 20:33
  • @TTT To guard against potential problems after a rebase, [`git test`](https://github.com/mhagger/git-test) is a superb tool to use (and depending on how thorough people are, it is not guaranteed that the the branch was i tip top shape before the rebase, so using `git test` is univerally good and not directly only required for rebase). – hlovdal Jun 01 '23 at 10:18
  • @hlovdal my comment about something going wrong is geared towards the situation where either something isn't under test, or it slips through existing tests. (The error could be due to auto-merging side effects or mistakes during conflict resolution, and the lack of tests is due to... a lack of good tests.) If you have good test coverage you will test the tip commit after either merging or rebasing, in which case it shouldn't make a difference which method you used. That aside, I see the value in automating tests against sets of commits like that tool provides. – TTT Jun 01 '23 at 18:55
  • Just testing the tip of a branch after a rebase is not enough, there might have been introduced errors like dependency on missing imports/includes on previous commits that eventually resolves in later commits, but then causes problems for running git bisect in the future. – hlovdal Jun 02 '23 at 07:46