用另一个分支的更改覆盖分支

Question

Hello fellow git users!

I am having the following problem and I don't know what would be the best and correct way to avoid it. So here I will explain:

I am working with 2 different branches:

• master --> production

• dev --> development

The workflow I am currently using is the following:

1. Changes are made on dev branch
2. Changes are tested and approved
3. Checkout master and merge dev to include new changes

Nothing crazy so far, right?

Now, the following scenario appeared a few weeks ago:

1. Changes are made on dev branch

2. Changes are tested and approved

3. Checkout master and merge dev to include new changes

4. Someone realized part of those changes should not be in master (production)

5. In master branch we commented those changes so that those are not enabled in master

Current situation:

• All changes are in dev

• All changes are in master but part of them are disabled

• So far so good

A few days later, the following happened:

1. A few more changes were added to dev

2. Changes were tested and approved

3. Checkout master and merge dev to include recent new changes and also part of the change that is now commented in master .

4. As a result, everything is included in master but the change that had been commented is still commented in master .

At the beginning, I was kind of expecting master to be overwritten with the dev version but then I realised that does not make much sense as merging is actually putting together changes from both branches so the result is making absolute sense. However, it is not what I need.

What would be the best solution for this? I was thinking about the following options:

1. To absolutely prohibit making changes in master branch. So any change (like commenting part of the code) should be done first in dev and then go to master .

2. When merging into master to use a parameter saying ignore all changes in the current branch and just take all that is coming from dev branch . That would be awesome and obviously I don't know how to do it in git.

Anyway, your comments will be much appreciated.

Thanks!

Answer 1

This is what you should have done

You should have merged your master into dev (a sort of hotfix, which are fine) right after you made the changes to master .

Then on dev you should have reverted the commit ( git revert commit-id ) which commented out things in master .

Then when you went on to merge dev into master again, things would be fine.

Now that things have gone further you can:

1. [BEST APPROACH] try those steps above; if changes made in dev aren't deep enough and/or don't touch the same places as the commit , chances are the all is going to be right; or

2. in master branch go on to revert ( git revert ) the commit .

Answer 2

Please read up on GitFlow, at Vincent Driessen's original blog about it .

What's missing here is that you made commits directly to master . Never do that: :)

You have a few options, depending on your exact situation, but if you are following GitFlow, here would be the answer:

1. When ready for a release, make a release_xxx branch, which is essentially a release candidate for a new version.
2. Use the release branch during integration and system testing with other repos/code, etc.
3. If a change is required, make it to release , but then merge that change to dev as well.
4. When release is fully tested, merge it into master, ending it.

If you don't normally need any extended time for a release branch, you can create a hotfix branch, which, after testing, would be merged both to master and dev . Hotfix branches are normally for production problems from something already released into production - it's like a feature branch that merges into dev , except intended to merge directly back to master (in addition to dev so all the development branches get the change as well).

This allows you to continue with other parallel development in dev without having to push new things put in dev to master , leaving just the changes needed for the fix to happen in a release or hotfix branch, and you can manage pushing that back to dev separately to make sure it incorporates with any parallel work.

Credit: Vincent Driessen

---

To resolve the current issue

You should reverse-merge master into dev , resolve all differences (ie add or remove comments, etc.), and then merge back to master . If you just want to cleanup, you can do so and direct push to master, but it's better to have a PR with review of peers in dev to give traceability and shows clearly what was done in the git history.