0

The repo I'm working on does not use master as the bleeding edge, they use a develop branch. master is used to follow the latest release. Thus, master should always be behind develop.

I did not realize this workflow, and pushed a documentation fix (involving things like README files) to master. As a simple example, our site used to be on Sourceforge, and I updated the readme to talk about GitHub instead.

Because I then realized I was on the wrong branch, I reverted things. In GitHub land, the way to do this is with another merge request that basically reverts your first commit.

My master branch currently shows Sourceforge-related wording in my READMEs. My develop branch currently shows GitHub-related wording. But the develop branch is 16 commits behind master.

Using GitHub's "merge" function shows me a diff that would revert my docs, just like the master branch was reverted.

So far, the only fix I've found is to manually merge the 16 commits, but de-conflict them by manually discarding all the changes. Obviously the commits that update the docs already happened in develop, because the words are correct.

Using either git rebase master or git merge master in the develop branch blows away my changes. I need, effectively, a "db-only" merge.

Gushi
  • 31
  • 3
  • Can you show the commit graph you would like to have, and what you have now instead? – mkrieger1 Jun 05 '22 at 19:53
  • 2
    Revert, in Git, does not mean "revert to" but rather "add something that undoes". So in general, reverting pushes you further ahead. This is often desirable, and hence often desired. When and whether it's *your* desire is another question entirely and requires a lot more information than you've provided. See @mkrieger1's comment above as well, but look up the difference between the misnamed "revert" and `git reset`. – torek Jun 05 '22 at 20:08
  • So I've figured this out, simply enough, the answer is: On the develop branch, I did `git merge -s ours master`, which pushed those 17 commits into my develop branch again, but discarded their texts. At some point in the future, when we cut a new release (which is the only time master gets touched) those changes will finally make it to Master, as a single diff, which being all-docs, is fine from a `git blame` pov. – Gushi Jun 05 '22 at 20:51

1 Answers1

0

Merging back master to develop is one solution.

The other, depending on the level of communication between the team, would have to reset --hard your master branch and force push it immediately, making sure your teammates are aware of that, and fetch the new master history immediately as well.
That way, no need to revert/merge and mess up the history.
But that would mean no other commits would have been pushed to master at the time of the reset.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250