![]() This the reason I used -f when creating feature-branch-old. ![]() If you do this, you can simply repeat the above steps as often as you need to. Though, if you plan to continue to update feature-branch by rebasing onto future versions of origin/master, then you might as well keep it around until feature-branch no longer exists. Once the sub-branches are all rebased you can delete branch feature-branch-old. Note, the main difference here is for each sub-branch, instead of a basic rebase: git rebase feature-branch, you just need to a do a "fancy" rebase to change the starting point. Git rebase -onto feature-branch feature-branch-old Git branch feature-branch-old -f # -f is explained below If you use rebase, you just need to keep track of the old commit of feature-branch before it gets rebased onto the latest master: git switch feature-branch # if not already checked out If you are willing to rebase all of the sub-branches, then that means you can still rebase feature-branch onto master if you prefer that over merging. I did rebase the sub-branches on top of the feature-branch(with latest changes) and all looks fine. However, OP has added an answer as well, which contains some new information: If I rebase my feature-branch on master branch, all the sub-branches which were on feature-branch will become stranded (based on my previous experience).Īnd to prevent that issue, the obvious answer is to merge the latest master into feature-branch, which BTW doesn't require having a local copy of master since you can use the remote (usually called origin): git switch feature-branch # if not already checked out Hopefully it should be clear now what your options are. To stay on the safe side, don't rebase branches that are already publicly available. If you would decide to rebase feature-2 onto feature-1 (post the initial master integration) Git would then figure out that commits ol42g and 09qr2 are already present, and hence automatically strip those patches out from your rebased version of feature-2.Ī cautionary warning: Rebasing branches that have already been published can cause headaches for your team mates, so make sure to keep a tight dialog if that would be the case. If you then want to integrate all changes into feature-2 you are once again left with the option of merging or rebasing. without the newly integrated changes from master into feature-1). Regardless of how you decide to integrate the changes from master into feature-1 ( merge or rebase), feature-2 will be left as is (i.e. ![]() Now, let's try to answer your initial question with a similar illustration where two feature branches ( feature-1 & feature-2) are based on each other, and currently trails behind master. The difference can be seen in above illustration. First of all, let's agreeing on how merge and rebase differs, before looking at the case your are asking for, where multiple feature branches based on each other.Īs you are probably aware merge preserves history as it happened, while rebase rewrites it. Let's try to answer this with a couple of general illustrations, since we don't know exactly how your particular case look like.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |