1

We have this branch structure:

  • master (build/deployed on production)
  • qa (build/deployed on Q&A environment)
  • features branches

So we create a feature branch from master and then merge it to qa (created from master) when we need to validate the feature with Q&A.

Sometimes we need to rebuild qa from master because some development was directly merged to master (small ones or bug fixes).

What I did:

git checkout qa
git reset --hard master
git push --force origin qa

So the remote is now exactly just like I want it.

BUT now when the other developers do git fetch, all the commits they have on their local qa that were not on master appear as outgoing commits. This seems logical. We had to do a git reset --hard origin/qa on everyone's machine but it's kind of dangerous.

Any other solution?

EDIT: Why are we doing this: Some feature that was on the qa branch were abandoned so we need to recreate the qa branch from master and then merge on it all the other branches.

Melebius
  • 6,183
  • 4
  • 39
  • 52
remi bourgarel
  • 9,231
  • 4
  • 40
  • 73

2 Answers2

0

After you have done git push --force forcing pull on all client is the only option. To make it less dangerous first create a temporary branch to preserve branch qa on a client, do forced pull, then cherry-pick commits from preserved qa and remove the temporary branch.

phd
  • 82,685
  • 13
  • 120
  • 165
0

You are using (maybe without knowing) the "branch per feature" workflow from Adam Dymitruk, and that is a great workflow indeed.

Note that Dymitruk suggests to re-create qa from scratch (i.e., from master) everytime you change anything, not only when you want to "unmerge" a feature.

That means: simply delete the qa branch and rebuild it completely; taking care to merge all the feature branches that have been it in in the exact same order. You obviously also want to activate the git rerere cache and make sure all devs synchronize that cache between each other (using git of course).

Thus, there will be no weird merges or resets anywhere, just a clean, fresh qa at each time. The whole operation will best be done with the help of some script, or automatically by your CI/CD agent.

See Dymitruk's site for a full description.

AnoE
  • 8,048
  • 1
  • 21
  • 36
  • we are indeed using this flow (and we know it). We tried to delete qa branch and then create it from master but the developpers kept pushing commit that was not on the new qa branch but was on the old one, they have to remove their local qa, checkout it out and merge their feature into it. – remi bourgarel Jul 20 '17 at 15:12
  • @remibourgarel: Yes, they do. This part of that workflow (re-creating qa) is, in my eyes both the greatest thing ever, and a curse to get right in a team. Commits directly into qa need to be strictly forbidden, or things will go wrong badly. – AnoE Jul 20 '17 at 15:13
  • indeed, with VS2017 we'll try to create hooks for avoiding it (your are on qa branch because you just did a merge and forgot to go back to your feature) – remi bourgarel Jul 21 '17 at 09:00