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. Is this just expected behaviour and I am supposed to ignore it or did I do something wrong.Let's try to answer this with a couple of general illustrations, since we don't know exactly how your particular case look like. I pushed to bitbucket and took a look around at my project to see this merge and noticed the following: 1 commit(s) on master and not on developġ79 commit(s) on develop and not on master In my head I now check out develop again and continue working. This seems like something useful since I wouldn't pollute the master branch with the same WIP commits that are in the develop branch.įrom here everything looks as I expected, master has 2 commits, develop still has 180. Today I am finally ready to merge the develop branch into the master, I did some reading and found out about squash. I have a develop branch with 180 commits.
I have a master branch with 1 commit (init). I'm fairly new to git and only work by myself so I don't use many of the features it can do but I am running into a process that either I am thinking about it wrong or doing something wrong.
0 kommentar(er)
