Workflow to revert dev branch changes to master

Asked

Viewed 301 times

7

  • The branch dev is automatically merged to the master; this, for his time, there’s a deploy automatic application.
  • The branch dev has some changes ahead of the branch master and will be disposed of.
  • The branch feature incorrectly left the workflow and was created to
    from the master.

What I need to do is:

  1. Delete the changes from dev and leave it as the master

    1. Merge the feature in dev

I thought to "reset" the dev, erasing and creating it from the masterbut I don’t know if this is the solution to these cases.

inserir a descrição da imagem aqui

@Edit

After effecting the reset, commit and push i get the following error because my branch dev has changes saved in remote.

hint: Updates Were Rejected because the tip of your Current branch is Behind

hint: its remote Counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing Again.

hint: See the 'Noteabout fast-forwards' in 'git push --help' for Details.

git

  • There is code in "dev" and/or "Features" that needs to be used?

  • The code in the branch features should remain, @Sergio

  • If you just want to "go back to" with Features you could do git reset --hard master when you’re in the branch dev and making a git fetch master if it is remote to be updated in memory. So delete commits from dev which equals the master, and the features is 2 commits ahead of the dev and of master.

  • Is the code in dev really disposable? da para fazer também um rebase in feature in dev so you lose nothing.

  • Yes, the commits of dev ahead of the master are disposable. @gmsantos

  • @Sergio, I edited the issue with a forgotten detail about the branch dev

  • your central repository is Bare?

  • No, @zwitterion

  • That’s what I figured. That’s why you’re getting these error messages when you try to update between environments.

Show 4 more comments

1 answer

3


Which I suggest in this case:

1: Reset dev branch to master state. See on documentation the difference in flags --soft, --mixed (default) and --hard.

git reset master

2: Create a backup Stash with those changes that occurred in those reverted commits, which are now in your Working copy

git stash

As an alternative to stash, you can create a Feature branch at the C6 commit point by reverting only the dev branch marker. No problem that branch gets "disintegrated" from master.

3: Force a merge of the Feature branch into the dev branch

git merge feature --no-ff

The flag --no-ff will avoid fast-forward merge, and force a "merge" commit between the two branches. Since you have a somewhat structured development/release workflow, it is recommended in this case to maintain the history of merges. The same concern applies to herds.

4: After this process, when you push the dev branch, you should do it forcibly, since you will remove commits from origin.

git push -f origin dev

It’s important that this process is communicated to the entire team, who can have their commit-based branches that are lost

  • The stash after the reset even?

  • If I’m not mistaken, the default reset is not in hard mode, and keeps commits changes in your Working copy, so you can stash later

  • Understood, but I saw now that I have one more problem and I will add in the question: My branch dev has the changes saved on the remote, when I give the commit and push he is rejected.

  • Rebase your master over origin/master

  • The master and origin/master are ok, @Everton. The problem only occurs in dev

  • Oh yes, in that case you must push through, using the -f flag

  • Updated answer :) It is important that whenever you are forced to push, that this is communicated to the team.

  • 1

    Understood, the team is aware of the procedures discussed here.

Show 3 more comments

Browser other questions tagged git

You are not signed in. Login or sign up in order to post.