在子分支已合并回master之后，VSTS Git将孙分支合并到master

Question

We had a long-running branch branch1, branched off of master, that was undergoing a full regression test, which took a while.

While that was being tested, I was working on a feature which required changes in branch1, call it branch1a, which was branched off of branch1. I'm still working on that but it should be done soon ^TM .

This morning, branch1 testing was finished and it was merged back into master. We're using VSTS. I'm not exactly sure how it was merged (rebase, squash, etc.). There is a PR which lists a bunch of commits and other PRs for branch1. It looks like it shows up as 1 commit in master history.

Now I'm not really sure what to do when I'm done, my parent branch is sort of gone, but sort of not. If I create a PR versus master I get 400 files changed, if I create it vs branch1 I get 12 files changed.

It looks like a merge will use the common parent, before branch1 was branched, instead of where I branched branch1a off of branch1, which seems like it might result in a lot of problems (though, technically, there are only a few changes in the actual most recent files).

Would a rebase instead of a merge make more sense here? My commits should replay pretty cleanly against what is now master (if I understand rebase correctly).

We have policies in VSTS such that we can't commit directly to master--we need to use PRs. I'm not sure if I can create a PR that uses rebase...maybe I should branch master, branch2, and rebase my branch to branch2, then make a PR to master from branch2?

Answer 1

It will help to think like git thinks; so in that sense, branch1 is not "sort of gone". It either has been deleted and is gone, or it has not been deleted and is not gone. From what you describe, I think the latter.

To really be sure, you should find out how the branch was combined with master . I suspect it was just merged. Depending on how you look at master's history, you might (or might not) describe the result of a merge as "a single commit". (The documentation for squash can be confusing in this regard, IMO.)

Does that singe commit have a 2nd parent? If so it's a true merge. If not it's a squash (and that will make things harder). If it's only one commit, it's not a simple rebase (but a squash is really just a special type of rebase, so that's splitting hairs I guess).

If it's a true merge, everything is fine. You can merge branch1a to master ; at most this might make conflict resolution a little more intimidating. If you want to break that into smaller pieces of conflict resolution work (or if you just want to maintain a sense of symmetry in the branch topology), you can merge branch1a to branch1 and then merge branch1 to master again.

I would not expect a rebase to make things any easier, and if any of the branch1a commits have been pushed to a remote repo then I recommend against rebasing. At any rate, the reason to rebase is if you want a more linear history, which some people find cleaner (even though it might create unbuildable intermediate states).

As for your last paragraph... you're making things too complicated for yourself with that idea. There's just no need.