0

Suppose the following happens in an Azure DevOps, GIT environment

  1. Developer 1 creates "Branch A" from "master" to work on a bug.
  2. Developer 2 creates "Branch B", from "Branch A" to do some extra work for Developer 1
  3. When the Developer 2 is done, he pushes his changes to B and creates a pull request for the Developer 1
  4. Developer 1 uses the Azure DevOps web interface, approves, then completes completes the pull request

Now typically, when we just have a simple branch off master, everything gets merged to master and that's great. But in this case, with a sub-branch off a branch, I want to be sure of something:

When the Branch B gets merged in my scenario, it is only merged back to the immediate parent "Branch A", right? In other words, Azure DevOps doesn't merge anything all the way to "master", does it?

This might be a dumb question but discussions of pull requests (that I have seen) tend to talk about a simple, branch-off-master scenario. Besides, I'm not sure if Azure DevOps, in the interest of making things easier, might use any defaults that would not be assumed in another Git environment so I feel I should ask this to be sure.

Joe
  • 5,394
  • 3
  • 23
  • 54

1 Answers1

0

A Pull Request is merging one branch into another branch of your choosing.

In #3, when Developer2 creates a Pull Request (PR), he must choose a source and target branch, and the answer to your question is whichever target branch he chooses.

Therefore either option is possible. If he creates the PR for Branch-B into master, then that's where it will be merged, and in that case, assuming Developer1 agrees with it, Branch-A can simply be deleted since it will already be merged into master when Branch-B was merged in.

If instead he creates a PR from Branch-B to Branch-A, then the result will be that Branch-A now contains the new changes as well, and then Branch-A can be PR'd into master when Developer1 is ready. Note that if this is the desired goal, you probably don't even need to use a PR. Typically master would be protected and require a PR, but Branch-A would not, so instead of making a new branch off of Branch-A, Developer2 could notify Developer1 that they are going to add some commits to Branch-A, and then they can do so and push out Branch-A. Developer1 would then pull Branch-A to get the latest and create the PR into master when ready.

TTT
  • 22,611
  • 8
  • 63
  • 69