-2

We're migrating from TFS to Git (Azure DevOps) and I'm not clear on the best strategy for the following scenario:

We have two Stories in a Sprint.

  1. PBI-1: Add functionality XYZ
  2. PBI-2: Extend functionality XYZ

Note:

  • Each PBI will be quite "large", i.e. involve multiple Commits and may involve multiple developers
  • PBI-2 is obviously dependant upon PBI-1, and can't start until PBI-1 is completed

Also note:

  • We have a policy on our 'develop' branch that all code must be Approved by the Approver before it can be merged in
  • When merging to 'develop' we do a "squash merge" and then the source branch is automatically deleted

Okay, so from what I've read, it seems to me that each PBI ought be on its own "Feature Branch" (created from the "develop" branch). That being the case, then I'm guessing:

At the start of the Sprint, we'd create a new feature branch off of 'develop' called "Feature/Add-XYZ".

Multiple developers would then start work on this, with the usual flow of daily re-basing (note: see comment below regarding why not to use rebasing) from 'develop', regular Commits and Pushes to the server version of the branch "Feature/Add-XYZ" (on DevOps).

When all work on PBI-1 is complete and all code pushed to the server, a Pull Request would be created and sent to the Approver.

However, the Approver is very busy and may not get to the Pull Request for several days; we don't want this to be an impediment, so how should the team start on the next PBI bearing in mind:

  • PBI-2 is dependant on code sitting in the branch "Feature/Add-XYZ"
  • The branch "Feature/Add-XYZ" will be deleted as soon as the Approval Process is complete

My guess is that I'd:

  1. Create a new branch off of "master" called "Feature/Extend-XYZ" (this won't contain any code related to XYZ as that is still in the branch "Feature/Add-XYZ")
  2. I would then need to "copy" the relevant code from the branch "Feature/Add-XYZ" to "Feature/Extend-XYZ".

If this is the right way to go, then what is the recommended way to achieve step 2? Is it a simple "Merge From"?

DrGriff
  • 4,394
  • 9
  • 43
  • 92

1 Answers1

0

My guess is that I'd:

  1. Create a new branch off of "master" called "Feature/Extend-XYZ" (this won't contain any code related to XYZ as that is still in the branch "Feature/Add-XYZ")
  2. I would then need to "copy" the relevant code from the branch "Feature/Add-XYZ" to "Feature/Extend-XYZ".

No, you would never want to copy the code from one branch to the other. You would simply branch your second branch off of the first, as soon as you're ready to begin work on the second feature. If, over time, any new additions are made to the first branch, you would merge that branch into your second branch.

To circle back on why...

  • PBI-2 is dependant on code sitting in the branch "Feature/Add-XYZ"
  • The branch "Feature/Add-XYZ" will be deleted as soon as the Approval Process is complete

The deletion doesn't matter. Deleting a branch does not affect branches that branch off of it.

A final note:

with the usual flow of daily re-basing

You should not be rebasing a branch that has multiple people actively working on it. If one person does this, the history of the branch will be broken for everybody else. Instead, merge develop into your feature branch.

Community
  • 1
  • 1
user229044
  • 232,980
  • 40
  • 330
  • 338
  • Regarding rebasing. My understanding was that GIT a) undid you local changes on the target branch, b) brought over the changes from the source [develop] branch, and then c) replayed your local changes. If that is the case then why is the local history lost, or are the changes "squashed" when they're added in c)? – DrGriff Jan 20 '20 at 17:59
  • 1
    After you rebase, your history no longer matches anybody else's. If you want to push your rebased changes, you need to *force* push, that is, overwrite the remote state of the branch. Then, nobody else can push until they manually force-reset their branch to the new rewritten history the remote branch now has. This is exhaustively discussed all over the place since the dawn of Git, I'd suggest just Googling why rebasing is harmful. – user229044 Jan 20 '20 at 18:02